محتوای آموزشی وبلاگ نت‌آرام
روی سرور لینوکسی فرمان Docker را اجرا می‌کنید و پیامی شبیه permission denied while trying to connect to the Docker daemon socket می‌بینید. ابزار
docker برای مدیریت کانتینرها باید به سرویس Docker دسترسی داشته باشد؛ در نصب معمولی لینوکس این ارتباط اغلب از یک فایل socket انجام می‌شود. اگر حساب شما اجازه استفاده از آن را نداشته باشد، فرمان متوقف می‌شود.این خطا با نصب‌نبودن برنامه یا خاموش‌بودن سرویس یکسان نیست. قبل از تغییر مجوز، باید بدانیم به کدام Docker و کدام حساب وصل می‌شویم. دادن دسترسی به Docker معمولی می‌تواند قدرتی نزدیک به مدیر کل سرور بدهد؛ بنابراین آن را به همه کاربران ندهید.
قدم اول: متن خطا و حساب فعلی را مشخص کنید
در ترمینال سرور مجاز، این دستور نام حساب جاری را نشان می‌دهد:
کد / دستورwhoami
سپس گروه‌هایی را که همین نشست از آن‌ها استفاده می‌کند ببینید:
کد / دستورid -nG
این دو فرمان تغییری ایجاد نمی‌کنند. نام حساب و گروه‌ها را با سیاست مدیر سرور تطبیق دهید. اگر کار از cron، systemd یا یک سامانه ساخت نرم‌افزار اجرا می‌شود، حساب آن ممکن است با حسابی که در SSH دیده‌اید فرق داشته باشد.
متن خطا را کامل بخوانید.
permission denied به دسترسی اشاره می‌کند؛ Cannot connect to the Docker daemon ممکن است از خاموشی سرویس، آدرس اشتباه یا علت دیگری باشد. تکرار فرمان با مجوز بیشتر بدون شناخت پیام، علت را پنهان می‌کند.قدم دوم: context و نوع Docker را ببینید
برای دیدن context انتخاب‌شده در حساب فعلی اجرا کنید:
کد / دستورdocker context show
این فرمان نام تنظیم اتصال فعال را نشان می‌دهد. ممکن است کلاینت به Docker محلی، محیط rootless یا سرور دیگری اشاره کند. متغیر محیطی
DOCKER_HOST و تنظیمات برنامه نیز می‌توانند مقصد را تغییر دهند؛ از مدیر محیط بپرسید تنظیم مجاز کدام است. جزئیات اتصال را بدون اطلاعات محرمانه نگه دارید.در نصب معمولی یا rootful، socket اغلب
کد / دستور/var/run/docker.sock است. برای مشاهده مالک و گروه آن، اگر همین مسیر واقعاً در محیط شما استفاده می‌شود:ls -l /var/run/docker.sock
خروجی نام مالک، گروه و مجوز را نشان می‌دهد. یک socket موجود و قابل مشاهده به‌تنهایی ثابت نمی‌کند سرویس سالم است. در Docker rootless مسیر معمولاً در محیط کاربر متفاوت است؛ مقادیر محیط و مستندات همان راه‌اندازی را دنبال کنید و مجوز socket سیستم را بی‌دلیل تغییر ندهید.
قدم سوم: وضعیت سرویس را جداگانه ببینید
اگر Docker به‌صورت سرویس سیستمی نصب شده، مدیر می‌تواند وضعیت را ببیند:
کد / دستورsystemctl status docker
active نشان می‌دهد سرویس systemd فعال است، ولی مجوز حساب و سلامت واقعی فرمان هنوز باید بررسی شود. اگر سرویس وجود ندارد، ممکن است Docker نصب نشده، نام یا روش نصب متفاوت باشد، یا از Docker rootless استفاده کنید. در حالت rootless، سرویس کاربری و نشست همان کاربر اهمیت دارد؛ فرمان سیستمی بالا نماینده همه حالت‌ها نیست.اگر سرویس خطا دارد، گزارش و تغییر اخیر را با مدیر بخوانید. راه‌اندازی مجدد آن ممکن است روی کانتینرهای سایت اثر بگذارد؛ پیش از هر تغییر وابستگی‌ها و روش بازگشت را مشخص کنید.
آیا باید کاربر را به گروه docker اضافه کنیم؟
در Docker معمولی، عضویت در گروهی که به socket دسترسی دارد غالباً توان کنترل گسترده میزبان را می‌دهد. راهنمای رسمی Docker درباره دسترسی در سطح ریشه هشدار می‌دهد. این دسترسی را فقط زمانی بدهید که کاربر واقعاً مجاز به مدیریت کل آن سرور باشد.
اگر مدیر تصمیم گرفته حساب مشخصی باید این سطح دسترسی را داشته باشد، ابتدا نام دقیق حساب و وجود گروه را تأیید می‌کند، تغییر را مطابق راهنمای رسمی Docker انجام می‌دهد و سپس با نشست تازه همان حساب گروه مؤثر و فرمان مجاز را آزمایش می‌کند. گروهی که در تنظیم حساب اضافه شده ممکن است در نشست قدیمی فوراً اعمال نشود. قبل از بستن اتصال فعلی، یک مسیر دسترسی مدیریتی سالم نگه دارید.
اگر کاربر نباید چنین اختیاری داشته باشد، از مدیر درباره روش محدودتر مناسب معماری خود، مانند Docker rootless برای همان کاربر یا یک سرویس کنترل‌شده، بپرسید. rootless مزایا و محدودیت‌های خودش را دارد و باید طبق مستندات راه‌اندازی و آزمایش شود.
چه کارهایی مشکل را پنهان می‌کنند؟
مجوز
777 روی socket، بازکردن Docker API برای همه شبکه یا دادن دسترسی root به حساب ناشناس، ریسک بزرگی ایجاد می‌کند. استفاده از sudo docker نیز یک فرمان بی‌خطر عمومی نیست؛ فقط مدیر مجاز و با شناخت اثر فرمان باید از آن استفاده کند. اگر با sudo کار می‌کند ولی بدون آن نه، این فقط نشانه تفاوت دسترسی است و به‌خودی‌خود مجوز اضافه‌کردن کاربر به گروه نیست.اگر پس از اصلاح هنوز خطا دارید، نام حساب اجراکننده، context، مسیر socket و وضعیت سرویس را کنار هم بگذارید. ممکن است یک اسکریپت از نشست دیگری اجرا شود یا متغیر محیطی به socket اشتباه اشاره کند.
نتیجه را چطور تأیید کنیم؟
در نشست تازه حساب مجاز، فرمان فقط‌خواندنی مناسب مانند
docker info را اجرا و مطمئن شوید به daemon مورد انتظار وصل می‌شوید. خروجی ممکن است جزئیات زیرساخت را نشان دهد؛ آن را عمومی منتشر نکنید. همچنین بررسی کنید حساب غیرمجاز هنوز به socket دسترسی ندارد و کانتینرهای موجود سالم‌اند.برای سرور مجازی ایران، اگر مدیریت سیستم‌عامل با شماست، سیاست دسترسی Docker و بازیابی سرویس را پیش از سپردن حساب به افراد دیگر مشخص کنید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام