Docker Engine روی اوبونتو محیط اجرای کانتینر را نصب می‌کند تا به‌جای بسته‌های قدیمی توزیع، از مخزن رسمی Docker نسخهٔ به‌روز بگیرید. این آموزش از پیش‌نیازها تا اولین hello-world همان مسیر مستند رسمی را دنبال می‌کند.
آموزش نصب Docker Engine روی اوبونتو از صفر
اول نسخه و معماری سیستم را بدانید: اوبونتوی پشتیبانی‌شده در ماتریس Docker، و مثلاً amd64 یا arm64. روی سرور تازه، دسترسی sudo و اتصال سالم به اینترنت لازم است. اگر قبلاً بستهٔ docker.io از مخزن اوبونتو یا اسنپ Docker نصب کرده‌اید، قبل از افزودن مخزن رسمی آن‌ها را جمع کنید تا دو موتور با هم قاطی نشوند.
الگوی کلی طبق مستند Docker این است: به‌روزرسانی فهرست بسته‌ها، نصب پیش‌نیازهایی مثل ca-certificates و curl، افزودن کلید و مخزن apt رسمی، سپس نصب docker-ce، docker-ce-cli، containerd.io و افزونه‌های Buildx و Compose. فرمان‌های دقیق و به‌روز را همیشه از صفحهٔ نصب اوبونتو کپی کنید؛ این متن جریان کار را آموزش می‌دهد نه اینکه جایگزین یک خط مخزن شود.
- با sudo apt-get update فهرست را تازه کنید.
- پیش‌نیازها و مخزن رسمی را طبق مستند اضافه کنید.
- بستهٔ Engine و CLI را نصب کنید.
- سرویس را با systemctl status docker ببینید.
- با sudo docker run hello-world دود تست بگیرید.
راستی‌آزمایی، گروه docker و امنیت
به‌صورت پیش‌فرض فقط root (یا sudo) به سوکت Docker دسترسی دارد. عضویت در گروه docker کنترل هم‌ارز root روی موتور می‌دهد؛ فقط کاربران مورد اعتماد را اضافه کنید و پس از usermod یک‌بار از سیستم خارج و دوباره وارد شوید.
اگر پیام permission denied دیدید، در نظرات بگویید با sudo تست کرده‌اید یا نه و خروجی کوتاه docker version چیست تا مشخص شود مشکل گروه است یا سرویس.
چک‌لیست و اشتباه‌های پرتکرار
سوکت Docker را روی شبکه باز نکنید، ایمیج را از رجیستری نامعتبر نکشید، و پورت‌های منتشرشده را با docker ps مرور کنید. مرجع رسمی در Install Docker Engine on Ubuntu | Docker Docs است. گام بعدی Compose برای یک استک ساده است یا اول فقط چند ایمیج پایه؟
تفاوت پرتکرار مبتدی این است که بستهٔ قدیمی توزیع را با Engine رسمی یکی فرض می‌کند. مسیر مستند Docker مخزن apt اختصاصی می‌سازد تا نسخه‌ها با ماتریس پشتیبانی هم‌خوان بمانند. قبل از کپی فرمان‌ها، صفحهٔ رسمی را باز کنید؛ کلید و مسیر signed-by ممکن است در طول زمان دقیق‌تر از حافظهٔ آموزشی به‌روز شود.
روی سرور تازه، بعد از نصب سرویس docker باید active باشد. اگر failed دیدید، journalctl همان واحد را بخوانید نه اینکه فوراً reinstall بزنید. تداخل snappy یا باینری دستی در PATH گاهی پیامهای عجیب می‌سازد؛ یک which docker و docker context ls مسیر را روشن می‌کند.
گروه docker قدرت زیادی می‌دهد: هر عضو عملاً می‌تواند کانتینر privileged بالا بیاورد یا به فایل‌های میزبان از طریق mount برسد. در لپ‌تاپ شخصی تک‌کاربره معمول است؛ روی سرور تیمی فقط حساب‌های لازم را عضو کنید و عضویت را دوره‌ای مرور کنید. خروج و ورود مجدد بعد از usermod را فراموش نکنید وگرنه permission denied می‌ماند.
hello-world فقط دود تست است. قدم منطقی بعدی کشیدن یک ایمیج شناخته‌شده مثل nginx در پورت غیر۸۰ برای آزمایش publish است، بعد Compose برای چند سرویس. تا وقتی Engine پایدار نشده، سراغ orchestration نروید تا لایهٔ خطا قاطی نشود.
به‌روزرسانی امنیتی Engine را از همان کانال apt رسمی بگیرید و با apt list --upgradable وضعیت را ببینید. ایمیج‌های در حال اجرا با ارتقای باینری میزبان خودبه‌خود بازسازی نمی‌شوند؛ پس از ارتقای بزرگ، کانتینرهای حساس را در پنجرهٔ نگهداری بازبینی کنید. سوکت را با TCP بیTLS روی اینترنت publish نکنید.
اگر پشت پروکسی سازمانی هستید، متغیرهای HTTPS_PROXY برای apt و جداگانه برای daemon Docker موضوع جداگانه‌ای است؛ در آموزش پایه فرض بر دسترسی مستقیم است. وقتی pull شکست می‌خورد، اول DNS و ساعت سیستم را چک کنید چون خطای TLS گاهی از زمان غلط می‌آید نه از خود مخزن.
ثبت کوتاه نسخهٔ docker version پس از نصب در مستند سرور، مقایسهٔ بعدی بین محیطها را ساده می‌کند. همین ثبت مشخص می‌کند CLI و Engine هم‌نسخه‌اند یا کلاینت از جای دیگری می‌آید.
