چگونه کانتینرهای داکر را مانند یک ابرقهرمان رفع و اشکال‌زدایی کنیم.

در حالی که کانتینرها به توسعه دهندگان کمک می کنند تا به سرعت برنامه های چند پلتفرمی را بسازند و اجرا کنند، ایجاد برنامه های بدون خطا یک چالش همیشگی است. و در حالی که همیشه مشخص نیست که خطاهای کانتینر چگونه رخ می دهند، کشف این معما برای توسعه دهندگان جدیدتر سخت تر است. فهمیدن نحوه اشکال زدایی ظروف Docker می تواند دلهره آور به نظر برسد. در این جلسه انجمن، Ákos Takács نشان داد که چگونه می توان بسیاری از این مشکلات مزاحم را حل کرد و قدرت فوق العاده تعمیر کانتینرها را به دست آورد.هر مسئله می تواند بر ساخت تصویر و برنامه های نهایی شما تأثیر بگذارد. برخی از اشکالات ممکن است پیام‌های خطای واضح را راه‌اندازی نکنند. برای پیچیده تر کردن مسائل، بازرسی کد منبع همیشه مفید نیست.
اما، مشکلات رایج کانتینر نباید دغدغه شما باشد! ما نکات مورد علاقه Ákos را به اشتراک می گذاریم و به شما نشان می دهیم که چگونه بر این چالش های توسعه غلبه کنید.

در این آموزش:
پیدا کردن و رفع اشتباهات رایج کانتینر
استفاده از CLI برای دید بیشتر کانتینر
قالب بندی خروجی CLI خود را برای مشاهده و خوانایی تغییر دهید
به یاد داشته باشید که از لاگ های خود استفاده کنید
با ENTRYPOINT مشکلات را حل کنید
دسترسی و بازرسی محتوای کانتینر
عمیقاً در فایل ها و پوشه ها فرو بروید
خطاهای Docker Build را حل کنید
حل خطاهای Docker Compose اختیاری:
ویرایش مستقیم فایل را در کانتینرهای در حال اجرا انجام دهید
کمتر تحقیق کنید و بیشتر توسعه دهید

پیدا کردن و رفع اشتباهات رایج کانتینر

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

استفاده از CLI برای دید بیشتر کانتینر

فرض کنید ما یک تصویر دانلود شده از Docker Hub داریم – اصلاً هر تصویری – و برای اجرای آن از تغییراتی در دستور

docker run

استفاده کنید. کانتینر حاصل دستور پیش فرض را اجرا خواهد کرد. اگر می‌خواهید آن دستور را ظاهر کنید، با وارد کردن

docker container ls –all

فهرستی از کانتینرها با دستورات مربوطه را دریافت می‌کند. کاربران اغلب این دستورات را کپی کرده و از آنها در سایر دستورات طولانی تر CLI استفاده می کنند. همانطور که انتظار دارید، برجسته کردن اشتباه، کپی کردن یک عبارت ناقص و اجرای یک دستور معیوب که از آن استفاده می کند، فوق العاده آسان است.

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

اجرای دستور

docker container ls –all

نیز نکاتی را ارائه می دهد. به دستور کانتینر

httpd-foregroun

که با کانتینر ایجاد شده (اما نه در حال اجرا) آن و با همراه هست  توجه کنید. برعکس، کانتینر v0 که با موفقیت در حال اجرا است از یک فرمان معتبر و کامل استفاده می کند:

چگونه بیشتر بررسی کنیم؟

از دستور

docker run –rm -it –name MYCONTAINER [IMAGE] bash

برای باز کردن یک ترمینال تعاملی در کانتینر خود استفاده کنید. دستور پیش فرض کانتینر را بگیرید و سعی کنید دوباره آن را اجرا کنید. پیغام خطای “command not found” ظاهر می شود. این بسیار مختصرتر است و نشان می دهد که احتمالاً دستور اشتباهی را وارد کرده اید – تقریباً برای هر تصویر کانتینر قابل اجرا است.

قالب بندی خروجی CLI خود را برای مشاهده و خوانایی تغییر دهید

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

خوشبختانه، Ákos نشان داد که چگونه فرمت

–format ‘{{ json . }}’ | jq -C

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

docker container ls –all

 خروجی اینطور دیده میشود:

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

docker container ls –all –format ‘{{ json . }}’ | python3 -m json.tool –json-lines

در نهایت، چرا فقط نمای جدول اصلی را گسترش ندهید در حالی که فقط اطلاعات مرتبط را نمایش می دهید؟ دستور زیر را با 

–no-trunc

اجرا کنید تا آن ردیف های جدول را گسترش دهید و محتویات هر سلول را به طور کامل آشکار کنید:

docker container ls –all –format ‘table {{ .Names }}/t{{ .Status }}/t{{ .Command }}’ –no-trunc

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

به یاد داشته باشید که از لاگ های خود استفاده کنید

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

docker logs

این کار را فعال می کند:

روند تنظیم گزارش‌های شما بین ابزارها و زبان‌ها متفاوت است. به عنوان مثال، Ákos از روش‌های شامل httpd – مانند trace برای پیام‌های سطح ردیابی دقیق یا LogLevel برای فیلتر کردن پیام‌های خطا – استفاده کرد، اما این روش‌ها به طور گسترده قابل اجرا هستند. احتمالاً می خواهید خطاهای راه اندازی و زمان اجرا را برای تشخیص بیشتر مشکلات به صفر برسانید.

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

100 لاگ   آخر کانتینر خود را بردارید:

docker logs –tail 100 [container ID]

همه لاگ ها را برای یک کانتینر خاص را مشاهده کنید :

docker logs [container ID]

مشاهده تمام فرآیندهای فعال در یک کانتینر در حال اجرا، در صورتی که گزارش‌های آن غیرقابل دسترسی باشد:

docker top [container ID]

بازرسی ورود به سیستم امکان اصلاح آسان تر را فراهم می کند. در کنار Ákos، ما موافقت می‌کنیم که پس از انجام هرگونه تغییر یا اصلاح کانتینر، آنها را تأیید کنید. این بدان معنی است که شما قدم های درستی برداشته اید و می توانید جلو بروید. آیا می خواهید تمام گزارش های خود را با هم در Docker Desktop مشاهده کنید؟ افزونه Logs Explorer ما را دانلود کنید، که به شما امکان می‌دهد با استفاده از فیلترها و قابلیت‌های جستجوی پیشرفته، فهرست‌های خود را مرور کنید. شما حتی می‌توانید گزارش‌های جدید را با پر شدن آنها مشاهده کنید.

با ENTRYPOINT مشکلات را حل کنید

هنگام اجرای برنامه ها، باید فایل های اجرایی را در ظرف خود اجرا کنید. بخش ENTRYPOINT از Dockerfile شما دستور اصلی را در یک کانتینر تنظیم می کند و اساساً به آن یک وظیفه اختصاص می دهد. این دستورالعمل های ENTRYPOINT به فایل های اجرایی که در کانتینر هستند متکی هستند.

در مثال Ákos، او با سناریویی مقابله می‌کند که در آن مجوزهای نادرست می‌توانند مانع از نصب و اجرای موفقیت‌آمیز داکر یک فایل اجرایی enterpoint.sh شوند. با انجام کارهای زیر می توانید رویکرد او را کپی کنید:

از دستور

ls -l $PWD/examples/v6/entrypoint.sh

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

چرا این اتفاق می افتد؟ بسیاری نمی‌دانند که با تنظیم –entrypoint، هر تصویری که دستور پیش‌فرض داشته باشد، آن دستور را به‌طور خودکار خالی می‌کند. برای اینکه کانتینر شما به درستی کار کند، باید دستور خود را دوباره تعریف کنید. در اینجا نحوه ظاهر آن دستور CLI آمده است:

docker run -d -v $PWD/examples/v7/entrypoint.sh:/entrypoint.sh –entrypoint /entrypoint.sh –name v7-running httpd:2.4 httpd-foreground

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

دسترسی و بازرسی محتوای کانتینر

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

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

docker cp

با یک فهرست مشخص.

این برای مشاهده و تأیید محتویات کانتینر شما عالی است. و ما می‌توانیم با

docker container diff v8

هر مشکلی را یک قدم جلوتر تشخیص دهیم تا ببینیم کدام فایل‌ها تغییر، اضافه یا حتی حذف شده‌اند. اگر رفتار کانتینر عجیبی را تجربه می‌کنید، حفاری در این فایل‌ها ممکن است مفید باشد.

عمیقاً در فایل ها و پوشه ها فرو بروید

بازرسی نزدیک جایی است که hexdump مفید است. تابع hexdump فایل شما را به کد هگزادسیمال تبدیل می کند که بسیار خواناتر از باینری است. Ákos از دستورات زیر استفاده کرد:

شما می توانید این عدد -n را برای خواندن بایت های اضافی یا کمتر تنظیم کنید. اگر فایل شما حاوی متن باشد، این محتوا برجسته می شود و هدف اصلی فایل را آشکار می کند. اما، بگویید که می خواهید به یک پوشه دسترسی داشته باشید. در حالی که تغییر دایرکتوری و اجرای بازرسی کانتینر docker… استاندارد است، این روش برای کاربران Docker Desktop کار نمی کند. از آنجایی که دسکتاپ چیزهایی را در ماشین مجازی اجرا می کند، میزبان نمی تواند به پوشه های درون آن دسترسی داشته باشد.

Ákos تصویر nsenter1 خود CTO جاستین کورمک را در GitHub به نمایش گذاشت که به ما امکان می‌دهد به آن کانتینرهایی که با محیط‌های Docker Desktop اجرا می‌شوند ضربه بزنیم. Docker Captain Bret Fisher از آن زمان با اضافه کردن دستورات مفید، اسناد nsenter1 را گسترش داده است. با قرار دادن این قطعات، دستور زیر را اجرا کنید:

docker run –rm –privileged –pid=host alpine:3.16.2 nsenter -t 1 -m -u -i -n -p — sh -c “ cd \”$(docker container inspect v8 –format ‘{{ .GraphDriver.Data.UpperDir }}’}\” \&& find .”

خروجی این دستور منعکس کننده دستور قبلی

docker container diff

است. همچنین می‌توانید با استفاده از همان تصویر بالا یک hexdump را اجرا کنید، که بدون در نظر گرفتن محیط شما، همان توانایی‌های عیب‌یابی را به شما می‌دهد. همچنین می توانید برای ایجاد تغییرات مهم، enterpoint.sh خود را بررسی کنید.

خطاهای Docker Build را حل کنید

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

docker build $PWD/[MY SOURCE] –tag “MY TAG” –progress plain

BuildKit زمینه خوانایی را برای هر مرحله فراهم می کند و خطاهای رخ داده را نمایش می دهد:

اگر خطای فایل یا دایرکتوری از دست رفته مانند تصویر بالا را مشاهده کردید، نگران نباشید! می توانید از دستور

cat $PWD/[MY SOURCE]/[MY DOCKERFILE]

برای مشاهده محتویات Dockerfile خود استفاده کنید. نه تنها می توانید واضح تر ببینید که کجا اشتباه کرده اید، بلکه می توانید دستورالعمل جدیدی را قبل از دستور failing برای فهرست کردن محتویات پوشه خود اضافه کنید.

شاید آن مطالب نیاز به به روز رسانی داشته باشند. شاید پوشه شما خالی باشد! در این صورت، باید همه چیز را به‌روزرسانی کنید تا Docker build چیزی برای استفاده داشته باشد.

سپس دستور build را با اضافه شدن پرچم –no-cache دوباره اجرا کنید. این پرچم به داکر می‌گوید که هر بار بدون اتکا به حافظه پنهان، از ابتدا به‌طور تمیز بسازد:

با توجه به ماهیت آبشاری دستورالعمل ها، می توانید به تدریج نسخه های به روز شده Dockerfile خود را بسازید و آن تغییرات را آزمایش کنید. نوشتن دستورالعمل‌های جدید بعد از آخرین دستورالعمل کاری – یا ایجاد تغییرات زودتر در فایل خود – می‌تواند این مشکلات ساخت‌وساز مزاحم را از بین ببرد. مکانیسم هایی مانند unlink یا cp مفید هستند. اولین مورد مانند rm رفتار می کند در حالی که تنها یک آرگومان را می پذیرد، در حالی که cp فایل ها و پوشه های مهم را از یک منبع در تصویر شما کپی می کند.

حل خطاهای Docker Compose

ما از Docker Compose برای چرخش چندین سرویس به طور همزمان با استفاده از دستور

docker compose –project-directory $PWD/[MY SOURCE] up -d

استفاده می کنیم.

با این حال، یک یا چند مورد از آن کانتینرها ممکن است به طور غیرمنتظره ای خارج شوند. با اجرای

docker compose –project-directory $PWD/[MY SOURCE] ps

برای فهرست کردن سرویس‌های ما، می‌توانید ببینید کدام کانتینرها در حال اجرا یا خروج هستند.

برای مشخص کردن مشکل، معمولاً از طریق دستور

docker compose logs،

لاگ‌ها را می‌گیرید. در بیشتر موارد نیازی به تعیین دایرکتوری پروژه نخواهید داشت. با این حال، کانتینر شما هیچ گزارشی تولید نمی کند زیرا در حال اجرا نیست.

سپس دستور

cat $PWD/[MY SOURCE]/docker-compose.yml

را اجرا کنید تا محتویات فایل Docker Compose خود را مشاهده کنید. این احتمال وجود دارد که تعاریف خدمات شما نیاز به اصلاح داشته باشد، بنابراین حفاری خط به خط در CLI مفید است. دستور زیر را وارد کنید تا این خروجی واضح تر شود:

docker compose –project-directory $PWD/[MY SOURCE] config

هنگامی که دستورات موجود در داخل نامعتبر هستند، کانتینر شما خارج می شود – درست همانطور که قبلا دیدیم. می‌توانید ببینید که آیا دستوری را اشتباه وارد کرده‌اید یا آن دستور خالی است. از آنجا، می‌توانید فایل Compose خود را به‌روزرسانی کنید و

docker compose –project-directory $PWD/[MY SOURCE] up -d

 دوباره اجرا کنید. اکنون می توانید با فهرست کردن مجدد خدمات خود تأیید کنید که همه چیز کار می کند. ترمینال شما لاگ های مربوط را نیز خروجی می دهد!

اختیاری: ویرایش مستقیم فایل را در کانتینرهای در حال اجرا انجام دهید

در نهایت، این امکان (و وسوسه انگیز) وجود دارد که مستقیماً فایل های خود را در کانتینر خود ویرایش کنید. این در هنگام آزمایش تغییرات جدید و بازرسی کانتینرهای شما قابل اجرا است. با این حال، معمولاً بهترین روش ایجاد یک تصویر و کانتینر جدید به جای آن در نظر گرفته می‌شود. اگر می‌خواهید ویرایش‌هایی را در کانتینرهای در حال اجرا انجام دهید، ویرایشگری مانند VS Code این اجازه را می‌دهد، در حالی که IntelliJ در مقایسه با این امکان را ندارد. پسوند Docker را برای VS Code نصب کنید. سپس می توانید از طریق کانتینرهای خود در نوار کناری سمت چپ مرور کنید، مجموعه منابع خود را گسترش دهید و مستقیماً به فایل های مهم دسترسی پیدا کنید. به عنوان مثال، توسعه دهندگان وب می توانند مستقیماً فایل های index.html خود را ویرایش کنند تا نحوه ساختار محتوای کاربر را تغییر دهند.

کمتر تحقیق کنید و بیشتر توسعه دهید به طور کلی، روند تعمیر کانتینر، روی سطح، ممکن است برای کاربران جدیدتر Docker ترسناک به نظر برسد. روش هایی که در بالا برجسته کردیم می توانند پیچیدگی عیب یابی را به طور چشمگیری کاهش دهند – در زمان و تلاش شما صرفه جویی می کنند. می توانید زمان کمتری را صرف بررسی مسائل کنید و زمان بیشتری را برای ایجاد برنامه هایی که کاربران دوست دارند صرف کنید. و ما فکر می کنیم که این مهارت ها بسیار قهرمانانه هستند.

برای اطلاعات بیشتر، می توانید ارائه کامل Ákos Takács را در YouTube مشاهده کنید تا هر مرحله را به دقت دنبال کنید.

می خواهید عمیق تر شیرجه بزنید؟ برای تبدیل شدن به یک متخصص Docker، این منابع اضافی را بررسی کنید:

نحوه مشاهده لاگ های مربوط به یک کانتینر یا سرویس را بیاموزید

مستندات مرجع Docker Run ما را مشاهده کنید

با بهترین شیوه های نوشتن Dockerfiles آشنا شوید

منبع: https://www.docker.com/blog/how-to-fix-and-debug-docker-containers-like-a-superhero/