نصب داکر روی اوبونتو؛ چک لیست اولیه قبل از اجرای سرویس ها

نصب داکر روی اوبونتو کار حدود ده دقیقه ایه، به شرطی که از مخزن رسمی داکر نصب کنی، با یه کاربر غیر root کار کنی و پیش از اجرای هر سرویس سه چیز رو ببندی: دسترسی کاربر، پورت های باز، و مصرف منابع و لاگ. یه نکته هم از همون اول: روی هاست اشتراکی یا سی پنل معمولی داکر اجرا نمی شه. سرور مجازی با دسترسی root لازمه.

فرض کن یه فروشگاه آنلاین داری و برنامه نویست می گه «همه چیز رو با داکر بالا میاریم». نصب راحت پیش می ره، سایت بالا میاد و همه خوشحالن. سه ماه بعد دیسک از لاگ پر شده، دیتابیس از بیرون در دسترسه یا یه کانتینر همه رم رو بلعیده و درگاه پرداخت وسط فروش جواب نمی ده. هزینه این اتفاق ها از هزینه یه سرور خیلی بیشتره. این چک لیست برای همین نوشته شده و هر مورد یه اولویت داره: حیاتی، مهم یا بهتر است. اگه وقت کم داری، از بالا شروع کن.

قبل از نصب: سرورت برای داکر مناسبه؟ (اولویت: حیاتی)

اول ببین چی داری. داکر به دسترسی root و هسته لینوکس نیاز داره. روی هاست اشتراکی این دسترسی نیست و سی پنل هم برای مدیریت سایت های سنتی ساخته شده، نه کانتینر. اگه هنوز سرور نداری، میزبانی وب و سرور مجازی ایران نقطه شروع منطقیه.

چند چیز رو قبل از نصب چک کن:

• نوع مجازی سازی: روی KVM مشکلی نیست. بعضی بسترهای مبتنی بر کانتینر (مثل OpenVZ قدیمی) ممکنه درست کار نکنن. از ارائه دهنده بپرس یا این دستور رو بزن: systemd-detect-virt
• نسخه اوبونتو: یکی از نسخه هایی که داکر رسماً پشتیبانی می کنه (معمولاً نسخه های LTS). فهرست دقیقش رو از مستندات رسمی داکر چک کن.
• به روزرسانی: sudo apt update && sudo apt upgrade رو بزن و اگه هسته عوض شد، یه بار ریبوت کن.
• ورود امن: یه کاربر عادی با sudo بساز و با کلید SSH وارد شو. اول مطمئن شو ورود با کلید جواب می ده، بعد ورود مستقیم root و ورود با رمز رو ببند.
• فضای دیسک: داکر ایمیج ها و لایه ها رو توی /var/lib/docker جمع می کنه. اگه دیسک کوچیکه، از الان حسابش رو بکن.
• swap: یه swap کوچیک مثل تور ایمنیه، ولی جای رم رو نمی گیره. اگه سرویست مدام به swap می افته، مشکل از رمه.

نصب داکر روی اوبونتو: مسیر تمیز و مسیرهای پرخطر (اولویت: حیاتی)

سه راه رایج هست. اولی بسته docker.io از مخزن خود اوبونتوئه. نصبش راحته، ولی نسخه ش معمولاً از نسخه رسمی داکر عقب تره. دومی اسکریپت یک خطی curl | sh هست. سریعه، ولی روی سرور تولیدی یه فایل ندیده رو با دسترسی root اجرا می کنی. سومی مخزن رسمی داکره و برای سرور کسب و کار همین رو پیشنهاد می کنیم، چون به روزرسانی ها با همون apt همیشگی میان.

اگه قبلاً بسته های قدیمی نصب شده، اول پاکشون کن:

sudo apt remove docker.io docker-compose docker-doc podman-docker containerd runc

بعد مخزن رسمی رو اضافه و داکر رو نصب کن:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

دستورها رو پیش از اجرا با صفحه نصب رسمی داکر برای اوبونتو مقایسه کن، چون نشانی ها و بسته ها گاهی عوض می شن. پلاگین docker-compose-plugin همون داکر کامپوزه و با docker compose (بدون خط تیره) اجرا می شه.

یه دردسر ایرانی هم هست: ممکنه سرورت نتونه به download.docker.com وصل بشه. اون وقت یا باید از آینه ای که ارائه دهنده سرور فراهم کرده استفاده کنی، یا بسته ها رو جای دیگه دانلود و منتقل کنی. این رو همون اول بفهم، نه وسط یه نصب نیمه کاره.

برای تست می تونی sudo docker run hello-world رو بزنی، ولی اگه شکست خورد، لزوماً نصب خراب نیست. این دستور ایمیج رو از Docker Hub می گیره و ممکنه به خاطر محدودیت دسترسی جواب نده. با sudo docker version و sudo systemctl status docker مطمئن شو سرویس بالاست.

کاربر غیر root: دری که راحت باز می مونه (اولویت: حیاتی)

همه دوست دارن کاربرشون رو به گروه docker اضافه کنن تا هر بار sudo ننویسن:

sudo usermod -aG docker $USER

کار می کنه (فقط یه بار خارج شو و دوباره وارد شو)، ولی بدون تعارف بگم: عضو گروه docker بودن تقریباً یعنی root بودن. کسی که بتونه داکر رو اجرا کنه، می تونه کل فایل سیستم سرور رو داخل یه کانتینر mount کنه و هر چی خواست بخونه یا عوض کنه. پس این گروه رو فقط به آدم هایی بده که اگه root هم داشتن، نگرانشون نبودی.

چند قاعده ساده:

• حساب مشترک بین چند نفر نساز. هر نفر کاربر و کلید SSH خودش رو داشته باشه، تا اگه کسی از تیم رفت، فقط یه کلید رو حذف کنی.
• کلید خصوصی SSH رو فقط روی لپ تاپی نگه دار که قفل و رمز داره.
• سوکت /var/run/docker.sock رو داخل هیچ کانتینری mount نکن، مگر اینکه دقیقاً بدونی چرا. هر کانتینری که به این سوکت دسترسی داشته باشه، عملاً کنترل سرور دست اونه.
• اگه سرویست اجازه می ده، به حالت rootless فکر کن. این حالت دسترسی رو محدودتر می کنه، ولی بعضی کارها (مثل استفاده از پورت های زیر ۱۰۲۴) رو سخت تر می کنه. برای تیم کوچیک اغلب کاربر عادی و قاعده های بالا کافیه.

فایروال: داکر UFW رو دور می زنه (اولویت: حیاتی)

اینجا بیشترین غافلگیری پیش میاد. با ufw فقط پورت 22، 80 و 443 رو باز کردی و فکر می کنی بقیه بسته ان. بعد یه کانتینر با -p 5432:5432 بالا میاری و دیتابیست از بیرون در دسترسه. داکر قانون های خودش رو مستقیم توی iptables می نویسه و ترافیک از مسیری رد می شه که ufw اصلاً نمی بینه.

راه حل ها به ترتیب اولویت:

1. پورت رو فقط روی لوکال publish کن. به جای "8080:80" بنویس "127.0.0.1:8080:80". این ساده ترین و مطمئن ترین راهه.
2. پورت دیتابیس و سرویس های داخلی رو اصلاً publish نکن. فقط وب سرور (مثلاً reverse proxy) پورت باز داشته باشه و بقیه توی شبکه داخلی داکر بمونن و با نام سرویس همدیگه رو ببینن.
3. اگه لازمه فقط CDN به سرور برسه، قانون رو توی زنجیره DOCKER-USER هم بذار، نه فقط ufw.

برای مورد سوم، قانون ها هم توی ufw باشن و هم توی DOCKER-USER، تا فقط شبکه CDN به سرور برسه. اگه درباره منطق این کار کنجکاوی، CDN برای سایت؛ آیا جای هاست قوی را می گیرد؟ رو بخون.

یه نمونه از شکل کلی قانون (آدرس ها و اسم کارت شبکه رو با سرور خودت جایگزین کن):

sudo iptables -I DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 443 ! -s CDN_IP_RANGE -j DROP

چند هشدار: توی DOCKER-USER ترافیک بعد از تغییر آدرس مقصد دیده می شه، برای همین از conntrack استفاده شده. قانون های iptables هم بعد از ریبوت می پرن، مگر اینکه ماندگارشون کنی (مثلاً با iptables-persistent). و همیشه قبل از بستن چیزی، یه نشست SSH دوم باز نگه دار تا اگه اشتباه کردی بیرون نمونی.

محدودیت منابع: نذار یه کانتینر کل سرور رو ببره (اولویت: مهم)

بدون محدودیت، یه کانتینر می تونه تمام رم سرور رو بگیره. اون وقت هسته لینوکس برای نجات سرور یه پروسه رو می کشه و ممکنه قربانی دیتابیس یا وب سرور خودت باشه. اگه این اتفاق وسط اوج فروش بیفته، بدترین زمان ممکنه.

توی داکر کامپوز محدودیت ها خیلی ساده نوشته می شن (عددها فقط نمونه ان و باید با نیاز سرویس تو جور باشن):

services:
  app:
    image: myapp:1.0
    restart: unless-stopped
    mem_limit: 512m
    cpus: 1.0
    ports:
      - "127.0.0.1:8080:80"

چند نکته درباره محدودیت حافظه:

• محدودیت رو از روی مصرف واقعی تعیین کن. یه مدت با docker stats نگاه کن و یه حاشیه امن بالای اوج مصرف بذار.
• اگه عدد رو خیلی کم بذاری، سرویس مدام کشته و دوباره بالا میاد. این وضعیت از خطای واضح بدتره، چون سایت «گاهی» کار نمی کنه و ردش سخته.
• restart: unless-stopped رو بذار تا بعد از ریبوت یا خطا، سرویس خودش برگرده. فقط یادت باشه راه اندازی دوباره مشکل رو حل نمی کنه، فقط قایمش می کنه. لاگ رو بخون.

لاگ داکر: قبل از اینکه دیسک پر شه (اولویت: مهم)

به طور پیش فرض، لاگ هر کانتینر توی داکر سقف نداره. یه سرویس پرحرف توی چند ماه می تونه دیسک رو پر کنه و بعدش حتی دیتابیس هم نمی تونه بنویسه. راه حل یه تنظیم کوچیکه. فایل /etc/docker/daemon.json رو بساز یا ویرایش کن:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

بعدش sudo systemctl restart docker رو بزن. حواست باشه ریستارت داکر ممکنه کانتینرها رو چند لحظه قطع کنه، پس ساعت شلوغی انجامش نده. این تنظیم فقط برای کانتینرهای جدید اثر داره. کانتینرهای قدیمی رو باید دوباره بسازی (docker compose up -d --force-recreate). بعد از چند روز هم با docker system df ببین فضا کجا می ره. ایمیج های بدون استفاده و کش build معمولاً مقصرن.

شبکه، رمزها و فایل env (اولویت: مهم)

توی داکر کامپوز، سرویس ها به طور پیش فرض توی یه شبکه داخلی با هم حرف می زنن. از این استفاده کن: وب سرور پورت داشته باشه، اپلیکیشن و دیتابیس نه. رمز دیتابیس رو هم داخل فایل compose که توی گیت می ره ننویس. از .env یا secrets استفاده کن و .env رو به .gitignore اضافه کن. اگه کلید درگاه پرداخت یا پنل پیامک کسب و کارت توی همین فایل هاست، این اشتباه گرون تموم می شه.

یه چیز دیگه: تگ latest رو برای تولید کنار بذار. نسخه مشخص (مثل postgres:16) بنویس تا یه به روزرسانی ناخواسته وسط شب سایت رو خراب نکنه.

ایمیج ها از ایران: وقتی Docker Hub جواب نمی ده (اولویت: مهم)

روی سرورهای داخل ایران، دریافت ایمیج از Docker Hub و بعضی مخزن ها ممکنه به خاطر محدودیت IP جواب نده یا خیلی کند باشه. یه راه عملی اینه که ایمیج رو روی سیستم توسعه بسازی و با SSH به سرور منتقل کنی:

docker save myapp:1.0 | gzip | ssh user@server 'gunzip | docker load'

این روش به رجیستری نیاز نداره و همه لایه ها یکجا منتقل می شن. اگه تیم بزرگ تر شد، می تونی یه رجیستری خصوصی راه بندازی. تا اون موقع این روش کافیه و وابستگی به یه سرویس خارجی رو هم کم می کنه.

بکاپ و مانیتورینگ (اولویت: بهتر است)

کانتینر دور ریختنیه، داده نه. هر چیزی که نباید گم بشه (دیتابیس، فایل های آپلود شده) باید توی volume یا مسیر مشخص باشه و از همون جا بکاپ بگیری. بکاپی که تست بازیابی نشده، فقط یه فایل خوش خیاله. اصول تست بازیابی رو توی بکاپ سی پنل؛ آموزش تهیه و آزمایش بازیابی سایت بخون. برای داکر هم همین اصول جواب می ده.

مانیتورینگ هم لازم نیست پیچیده باشه. حداقلش: فضای دیسک، رم، و بالا بودن آدرس اصلی سایت. اگه نمی خوای خودت درگیرش بشی، مدیریت و امن سازی سرور ما کارهایی مثل همین چک لیست رو برات انجام می ده.

خلاصه چک لیست با اولویت

سوالات متداول

نصب داکر روی اوبونتو روی هاست سی پنل هم ممکنه؟

نه. هاست اشتراکی و سی پنل معمولی دسترسی root به هسته سرور نمی دن و داکر به همین دسترسی نیاز داره. باید یه سرور مجازی بگیری و داکر رو اونجا نصب کنی.

بدون اینترنت بین المللی می شه ایمیج داکر گرفت؟

معمولاً نه به شکل مستقیم، چون Docker Hub و بعضی مخزن ها از IP ایران ممکنه در دسترس نباشن. راه عملی اینه که ایمیج رو روی سیستم توسعه بسازی و با docker save و SSH به سرور منتقل کنی.

چرا با وجود ufw، پورت دیتابیس بازه؟

چون داکر قانون های خودش رو مستقیم توی iptables می نویسه و ufw اون ها رو کنترل نمی کنه. پورت های داخلی رو publish نکن، یا فقط روی 127.0.0.1 بذارشون و برای محدود کردن مبدأ، از زنجیره DOCKER-USER استفاده کن.

لازمه حتماً از داکر کامپوز استفاده کنم؟

برای یه کانتینر ساده لازم نیست. ولی اگه چند سرویس داری (وب، اپلیکیشن، دیتابیس)، داکر کامپوز تنظیم ها رو توی یه فایل نگه می داره و راه اندازی دوباره رو ساده می کنه. برای کسب و کار کوچیک، همین یه فایل مستند فنی هم هست.

بعد از نصب داکر، اول کدوم تنظیم رو انجام بدم؟

اول دسترسی کاربر و پورت ها، بعد سقف لاگ، بعد محدودیت منابع. این سه تا با کمترین زمان بیشترین خطر رو می بندن. بقیه رو در هفته های بعد کامل کن.

قبل از اولین سرویس، ده دقیقه وقت بذار

نصب خودش سخت نیست. دردسر از چیزهایی میاد که بعد از نصب فراموش می شن: گروه docker، پورت های باز، لاگ بی سقف و ایمیج هایی که شاید از ایران دریافت نشن. اگه امروز فقط وقت داری یه کار بکنی، پورت ها رو بررسی کن و هر چیزی که نباید از بیرون دیده بشه رو ببند. بعد سقف لاگ رو بذار، بعد محدودیت رم. با همین سه کار، سرورت از خیلی از سرورهایی که «فقط نصب شدن» جلوتره. اگه کمک خواستی، پشتیبانی فنی ما کنارته.