رفع مشکل Docker بعد از Ubuntu Update؛ عیب‌یابی بدون حذف کانتینرها

چرا Docker بعد از آپدیت Ubuntu خراب می‌شود؟

آپدیت Ubuntu فقط چند برنامه معمولی را تغییر نمی‌دهد. بسته به نوع آپدیت ممکن است کرنل لینوکس، systemd، AppArmor، iptables، کتابخانه‌های سیستم و پکیج‌های مرتبط با Docker و containerd نیز تغییر کنند. به همین دلیل خطایی که دقیقاً بعد از آپدیت دیده می‌شود لزوماً یک علت واحد ندارد.

قبل از تعمیر Docker چه کار کنیم؟

اگر سرور میزبان سایت، دیتابیس یا سرویس مهمی است، قبل از تغییر پکیج‌ها وضعیت فعلی را ثبت کنید. مخصوصاً از حذف پوشه‌های Docker یا اجرای دستورهای پاک‌سازی مانند docker system prune برای «امتحان‌کردن» خودداری کنید.

ابتدا نسخه Ubuntu و کرنل فعال را ببینید:

cat /etc/os-release
uname -r

سپس نسخه پکیج‌های مرتبط را بررسی کنید:

docker --version
containerd --version
dpkg -l | grep -E 'docker|containerd|runc'

اگر دستور docker –version نسخه را نشان می‌دهد، این موضوع فقط وجود Docker CLI را تأیید می‌کند؛ به معنی سالم‌بودن Docker daemon نیست.

مرحله ۱: وضعیت سرویس Docker را بررسی کنید

اولین تست، مشاهده وضعیت systemd است:

sudo systemctl status docker --no-pager -l

اگر Docker فقط متوقف شده باشد، آن را اجرا کنید:

sudo systemctl start docker

دوباره وضعیت را ببینید:

sudo systemctl is-active docker

اگر خروجی active بود، daemon اجرا شده است. در غیر این صورت مرتب Docker را restart نکنید؛ باید خطای واقعی را از لاگ پیدا کنیم.

مرحله ۲: لاگ Docker را بخوانید

روی Ubuntu که از systemd استفاده می‌کند، یکی از مهم‌ترین دستورهای عیب‌یابی Docker این است:

sudo journalctl -xu docker.service --no-pager

برای دیدن فقط پیام‌های اخیر می‌توانید از این دستور استفاده کنید:

sudo journalctl -u docker.service --since "30 minutes ago" --no-pager

در خروجی به عبارت‌هایی مانند failed، error، iptables، containerd، AppArmor، overlay و daemon.json توجه کنید. این پیام‌ها مشخص می‌کنند باید کدام شاخه از عیب‌یابی را ادامه دهید.

مرحله ۳: وضعیت containerd را بررسی کنید

Docker Engine برای اجرای کانتینرها به اجزای دیگری از جمله containerd وابسته است. اگر containerd بعد از آپدیت Ubuntu مشکل داشته باشد، Docker نیز ممکن است بالا نیاید.

sudo systemctl status containerd --no-pager -l

اگر سرویس متوقف است:

sudo systemctl restart containerd
sudo systemctl restart docker

سپس هر دو سرویس را کنترل کنید:

systemctl is-active containerd
systemctl is-active docker

مرحله ۴: بررسی کنید سرور نیاز به reboot دارد یا نه

یکی از ساده‌ترین مواردی که بعد از Ubuntu Update فراموش می‌شود reboot است. به‌روزرسانی کرنل یا بعضی مؤلفه‌های امنیتی ممکن است تا زمان راه‌اندازی مجدد کامل اعمال نشوند.

برای بررسی وجود درخواست reboot:

if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; else echo "No reboot required flag"; fi

اگر reboot لازم است و زمان مناسب برای قطعی کوتاه دارید:

sudo reboot

بعد از اتصال مجدد به سرور:

sudo systemctl status docker --no-pager
docker ps -a

مرحله ۵: فایل daemon.json را بررسی کنید

گاهی Docker قبل از آپدیت با تنظیم خاصی کار می‌کرده اما نسخه جدید دیگر آن گزینه را نمی‌پذیرد یا میان گزینه‌های systemd و daemon.json تعارض ایجاد شده است.

ابتدا وجود فایل را بررسی کنید:

sudo ls -l /etc/docker/daemon.json
sudo cat /etc/docker/daemon.json

اگر فایل وجود دارد، قبل از تغییر از آن بکاپ بگیرید:

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.backup

اشتباه در JSON، گزینه‌های منسوخ یا تعریف یک تنظیم هم در systemd و هم در daemon.json می‌تواند مانع اجرای daemon شود. پیام دقیق خطا را از journalctl بررسی کنید و گزینه مشکل‌دار را بر اساس مستندات نسخه نصب‌شده اصلاح کنید.

مرحله ۶: پکیج‌های Docker را برای تعارض بررسی کنید

دو مسیر رایج برای نصب Docker روی Ubuntu وجود دارد: بسته‌های توزیع Ubuntu و بسته‌های مخزن رسمی Docker. مخلوط‌کردن پکیج‌های دو مسیر می‌تواند دردسرساز شود.

وضعیت فعلی را بدون حذف چیزی ببینید:

dpkg -l | grep -E 'docker-ce|docker.io|containerd.io|containerd|runc|docker-compose'

همچنین منبع نسخه‌های نصب‌شده را بررسی کنید:

apt-cache policy docker-ce docker.io containerd.io containerd runc

وجود همه این نام‌ها الزاماً به معنی تعارض نیست، اما قبل از نصب مجدد باید بدانید Docker فعلی از کدام منبع نصب شده است. نصب کورکورانه docker-ce روی سیستمی که با بسته‌های دیگری مدیریت شده، روش مناسبی برای عیب‌یابی نیست.

مرحله ۷: مشکل AppArmor بعد از Ubuntu Update

AppArmor یکی از لایه‌های امنیتی Ubuntu است و Docker نیز از پروفایل‌های AppArmor استفاده می‌کند. در Ubuntu 24.04 و نسخه‌های جدیدتر، AppArmor ارتباط نزدیکی با کرنل دارد. بنابراین در بعضی سناریوهای آپدیت، reboot می‌تواند برای بارگذاری کامل تغییرات لازم باشد.

وضعیت AppArmor را بررسی کنید:

sudo aa-status

سپس لاگ Docker را برای خطاهای AppArmor بررسی کنید:

sudo journalctl -u docker.service --no-pager | grep -i apparmor

مرحله ۸: بررسی iptables، nftables و شبکه Docker

اگر Docker اجرا می‌شود اما کانتینر اینترنت ندارند، پورت‌ها باز نمی‌شوند یا ساخت network با خطا مواجه می‌شود، احتمالاً باید لایه شبکه را بررسی کنید.

ابتدا اطلاعات شبکه Docker را ببینید:

docker network ls
sudo iptables -L -n
sudo iptables -t nat -L -n

backend فعلی iptables را نیز می‌توانید ببینید:

sudo update-alternatives --display iptables
sudo update-alternatives --display ip6tables

Docker Engine 29 پشتیبانی آزمایشی از nftables را نیز دارد. اگر بعد از ارتقای عمده Docker تنظیمات فایروال یا backend شبکه را تغییر داده‌اید، تنظیمات نسخه قبلی را بدون بررسی به نسخه جدید منتقل نکنید.

IP forwarding را نیز بررسی کنید:

sysctl net.ipv4.ip_forward

اگر از backend جدید nftables استفاده می‌کنید، غیرفعال‌بودن forwarding می‌تواند روی ایجاد bridge network یا port forwarding اثر بگذارد. قبل از تغییر sysctl ابتدا مطمئن شوید خطای لاگ واقعاً به همین موضوع مربوط است.

مرحله ۹: فضای دیسک و inode را بررسی کنید

گاهی هم‌زمانی خرابی Docker با Ubuntu Update اتفاقی است و مشکل واقعی، پرشدن فضای دیسک است. Docker برای image، layer، log و داده‌های writable کانتینر به فضای ذخیره‌سازی نیاز دارد.

df -h
df -i

اگر Docker هنوز قابل دسترس است، مصرف فضای آن را نیز ببینید:

docker system df

اگر فضای دیسک پر شده، ابتدا مشخص کنید چه چیزی فضا را مصرف کرده است. اجرای مستقیم prune روی سروری که وضعیت imageها، cacheها و volumeهای آن را نمی‌شناسید پیشنهاد نمی‌شود.

مرحله ۱۰: Docker اجرا می‌شود اما کانتینرها بالا نمی‌آیند

ممکن است daemon کاملاً سالم باشد اما بعد از reboot کانتینرهای قبلی اجرا نشده باشند. ابتدا همه کانتینرها را ببینید:

docker ps -a

برای کانتینری که متوقف شده، وضعیت دقیق را بررسی کنید:

docker inspect CONTAINER_NAME --format '{{.State.Status}} {{.State.ExitCode}} {{.State.Error}}'

CONTAINER_NAME را با نام واقعی کانتینر جایگزین کنید.

لاگ همان کانتینر:

docker logs --tail 100 CONTAINER_NAME

اگر فقط restart policy تنظیم نشده، آن را با خرابی Docker اشتباه نگیرید. Docker از policyهایی مانند always و unless-stopped برای اجرای مجدد کانتینرها استفاده می‌کند.

برای مشاهده policy فعلی:

docker inspect CONTAINER_NAME --format '{{.HostConfig.RestartPolicy.Name}}'

اگر پروژه با Docker Compose اجرا می‌شود

ابتدا وارد پوشه‌ای شوید که فایل Compose واقعی پروژه در آن قرار دارد و وضعیت سرویس‌ها را ببینید:

docker compose ps

اگر سرویس‌ها وجود دارند اما متوقف‌اند:

docker compose up -d

سپس وضعیت را دوباره بررسی کنید:

docker compose ps

اگر کانتینر دوباره متوقف شد، به‌جای تکرار restart لاگ سرویس را بخوانید:

docker compose logs --tail=100

وقتی Imageها یا Containerها ناگهان ناپدید شده‌اند

این حالت حساس است. اگر بعد از ارتقای Docker دستور docker images یا docker ps -a اطلاعات قبلی را نشان نمی‌دهد، فوراً پوشه Docker را حذف نکنید.

در Docker Engineهای جدید، containerd image store اهمیت بیشتری پیدا کرده و در نصب‌های تازه Docker Engine 29 به بعد به‌صورت پیش‌فرض استفاده می‌شود. تغییر storage backend می‌تواند باعث شود imageها و containerهای ذخیره‌شده با backend قبلی موقتاً در Docker دیده نشوند، در حالی که داده هنوز روی دیسک وجود دارد.

ابتدا اطلاعات storage را بررسی کنید:

docker info

همچنین تنظیمات daemon را بررسی کنید:

sudo cat /etc/docker/daemon.json 2>/dev/null

فعال‌کردن اجرای Docker بعد از reboot

اگر Docker سالم است اما بعد از هر reboot باید آن را دستی اجرا کنید، سرویس‌های مربوط را برای startup فعال کنید:

sudo systemctl enable docker.service
sudo systemctl enable containerd.service

و وضعیت آن‌ها را بررسی کنید:

systemctl is-enabled docker.service
systemctl is-enabled containerd.service

آیا Docker را حذف و دوباره نصب کنیم؟

نصب مجدد باید یکی از مراحل آخر باشد، نه اولین واکنش. اگر لاگ مشخص کرده که پکیج‌ها ناقص یا متعارض شده‌اند، ابتدا مشخص کنید Docker از مخزن Ubuntu نصب شده یا مخزن رسمی Docker.

نکته مهم این است که حذف خود پکیج Docker الزاماً داده‌های موجود در /var/lib/docker را پاک نمی‌کند؛ اما اجرای فرمان‌های حذف دستی روی این پوشه موضوع کاملاً متفاوتی است.

تست نهایی بعد از تعمیر Docker

بعد از رفع خطا، فقط سبزشدن وضعیت systemd کافی نیست. چند بررسی انجام دهید:

مرحله ۱: وضعیت daemon:

sudo systemctl is-active docker
docker info

مرحله ۲: وضعیت کانتینرها:

docker ps -a

مرحله ۳: بررسی خطاهای جدید daemon:

sudo journalctl -u docker.service --since "10 minutes ago" --no-pager

مرحله ۴: در صورت امکان، سلامت واقعی سرویس‌های داخل کانتینرها را از طریق پورت، HTTP endpoint یا روش مخصوص همان برنامه بررسی کنید. Running بودن کانتینر الزاماً به معنی سالم‌بودن برنامه داخل آن نیست.

چطور از تکرار مشکل بعد از Ubuntu Update جلوگیری کنیم؟

برای سروری که Docker روی آن سرویس مهم اجرا می‌کند، آپدیت سیستم‌عامل را مثل یک عملیات نگهداری در نظر بگیرید، نه صرفاً اجرای یک فرمان.

آیا live-restore برای آپدیت Docker مفید است؟

Docker قابلیت live-restore دارد که در برخی شرایط اجازه می‌دهد کانتینرهای Linux هنگام unavailable شدن daemon به اجرا ادامه دهند. این قابلیت می‌تواند downtime ناشی از بعضی عملیات نگهداری daemon را کاهش دهد، اما جایگزین بکاپ یا برنامه ارتقا نیست.

همچنین live-restore برای همه انواع ارتقا یک تضمین عمومی نیست؛ مستندات Docker استفاده از آن هنگام ارتقای daemon را به شرایط مشخصی محدود می‌کنند. بنابراین قبل از فعال‌کردن آن باید معماری سرویس و نسخه‌های Docker بررسی شوند.

جدول سریع عیب‌یابی Docker بعد از Ubuntu Update

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

آیا Ubuntu Update می‌تواند Docker را خراب کند؟

بله، ممکن است بعد از آپدیت تغییر در کرنل، AppArmor، پکیج‌های Docker و containerd یا بخش شبکه باعث بروز مشکل شود. با این حال باید خطا از طریق systemd و journalctl بررسی شود و نباید صرفاً به‌دلیل هم‌زمانی، آپدیت Ubuntu را علت قطعی دانست.

بعد از آپدیت Ubuntu خطای Cannot connect to the Docker daemon می‌گیرم؛ چه کنم؟

ابتدا systemctl status docker را بررسی کنید. اگر daemon اجرا نشده، لاگ journalctl -xu docker.service معمولاً اطلاعات بسیار بیشتری درباره علت ارائه می‌دهد.

آیا بعد از آپدیت Ubuntu باید سرور را reboot کنم؟

همیشه نه. اما اگر کرنل یا مؤلفه‌هایی که برای اعمال کامل تغییرات نیاز به reboot دارند آپدیت شده باشند، راه‌اندازی مجدد ممکن است لازم باشد. فایل /var/run/reboot-required یکی از نشانه‌هایی است که می‌توانید بررسی کنید.

آیا با reinstall کردن Docker کانتینرها پاک می‌شوند؟

حذف پکیج‌های Docker با پاک‌کردن دستی data directory یکسان نیست. با این حال قبل از reinstall باید از داده‌های مهم بکاپ داشته باشید و دقیقاً بدانید چه پکیج‌هایی را حذف می‌کنید. پوشه‌های داده Docker را برای عیب‌یابی اولیه پاک نکنید.

چرا Docker اجرا شده ولی کانتینرها بعد از reboot بالا نمی‌آیند؟

یکی از علت‌های رایج می‌تواند restart policy کانتینر باشد. ابتدا با docker ps -a وضعیت را ببینید و سپس policy و لاگ کانتینر متوقف‌شده را بررسی کنید.

آیا برای حل مشکل Docker باید iptables را پاک کنم؟

خیر، پاک‌کردن کورکورانه قوانین فایروال می‌تواند امنیت و شبکه سرور را مختل کند. ابتدا خطای Docker و وضعیت backend شبکه را بررسی کنید و فقط در صورت اثبات مشکل، تغییر هدفمند انجام دهید.

چرا بعد از آپدیت Docker imageهای قبلی دیده نمی‌شوند؟

یکی از مواردی که باید بررسی شود تغییر storage backend یا containerd image store است. تغییر backend می‌تواند باعث شود داده ایجادشده با backend قبلی موقتاً در Docker قابل مشاهده نباشد، بدون این‌که الزاماً از روی دیسک حذف شده باشد.

منابع رسمی

🔹 مستندات رسمی Docker برای اجرای daemon با systemd: Start the Docker daemon

🔹 راهنمای رسمی مشاهده لاگ Docker daemon: Docker daemon logs

🔹 راهنمای رسمی نصب Docker Engine روی Ubuntu: Install Docker Engine on Ubuntu

🔹 مستندات رسمی restart policy کانتینرها: Start containers automatically

🔹 مستندات containerd image store: containerd image store

🔹 مستندات امنیتی AppArmor در Ubuntu: Ubuntu AppArmor documentation