آموزش داکر (بخش چهارم) — به زبان ساده

۲۱۷ بازدید
آخرین به‌روزرسانی: ۲۸ شهریور ۱۴۰۲
زمان مطالعه: ۷ دقیقه
آموزش داکر (بخش چهارم) — به زبان ساده

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

یک مقاله آموزشی جامع دیگر نیز برای آموزش داکر در مجله فرادرس منتشر شده است که مطالعه آن به علاقه‌مندان پیشنهاد می‌شود:

ایمیج‌های داکر

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

کش کردن

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

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

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

ایمیج‌های داکر

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

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

برای نمونه زمانی که یک دستورالعمل RUN pip install -r requirements.txt در داکرفایل پیدا شود، داکر به دنبال همان دستورالعمل در ایمیج‌های واسط که به صورت محلی کش کرده است می‌گردد. محتوای فایل‌های قدیم و جدید requirements.txt مقایسه نمی‌شوند.

این رفتار در مواردی که فایل requirements.txt خود را با بسته‌های جدید به‌روزرسانی کنید و از RUN pip install استفاده کنید و بخواهید به نصب بسته‌ای با نام‌های بسته جدید بازگردید، مشکل‌زا خواهد بود. در ادامه راه‌حل این وضعیت را بیان خواهیم کرد.

برخلاف دستورالعمل‌های دیگر داکر، دستورالعمل‌های ADD و COPY از داکر می‌خواهند که محتوای فایل (ها) را مورد بررسی قرار دهید تا ببینید آیا مورد کش شده‌ای هست یا نه. بدین ترتیب Checksum فایل مورد ارجاع با Checksum فایل در ایمیج‌های واسط موجود بررسی می‌شود. اگر محتوای فایل یا فراداده تغییری یافته باشد در این صورت کش اعتبار زدایی می‌شود.

در ادامه چند نکته برای استفاده کارآمد از کش معرفی شده است:

  • کش کردن می‌تواند به وسیله ارسال --no-cache=True از سوی docker build غیرفعال شود.
  • اگر قصد دارید تغییراتی در دستورالعمل ایجاد کنید، در این صورت هر لایه‌ای که در ادامه می‌آید به طور مکرر ساخته خواهد شد. می‌توانید برای بهره‌گیری از مزیت کش کردن، دستورالعمل‌هایی را که احتمال تغییر زیادی دارند در داکرفایل خود در مراحل آخر قرار دهید.
  • دستورهای RUN apt-get update و apt-get install را با هم زنجیره‌سازی کنید تا از بروز مشکلات فقدان کش اجتناب شود.
  • اگر از یک نصاب بسته مانند pip به همراه فایل requirements.txt استفاده می‌کنید در این صورت از یک مدل مانند زیر استفاده کنید تا مطمئن شوید که یک ایمیج واسط کهنه با بسته‌های قدیمی لیست شده در requirements.txt دریافت نخواهید کرد.
1COPY requirements.txt /tmp/
2RUN pip install -r /tmp/requirements.txt
3COPY. /tmp/

این‌ها موادی از پیشنهاد‌هایی بودند که برای استفاده مؤثر از کش بیلد داکر قابل استفاده هستند.

کاهش اندازه

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

ایمیج‌های داکر
به جای شیرینی از سبزیجات استفاده کنید.

یک ایمیج مبنای Alpine در واقع توزیع کاملی از لینوکس بدون هیچ چیز دیگر است. این توزیع معمولاً حجمی کمتر از 5 مگابایت دارد؛ اما اگر می‌خواهید وابستگی‌هایی برای ساخت یک اپلیکیشن عملیاتی بنویسید به زمان بیشتری نیاز خواهید داشت.

ایمیج‌های داکر
کلمه Alpine از کوهستان آلپ می‌آید.

اگر می‌خواهید از پایتون در کانتینر خود استفاده کنید، بیلد Python Alpine گزینه مناسبی برای شما است. این ایمیج شامل لینوکس و همچنین پایتون است و تقریباً همه چیزهای لازم در آن عرضه شده است.

در موردی که ما یک ایمیج جدید با بیلد Python Alpine و به همراه اسکریپت ("print(“hello world نوشتیم حجمی معادل 78.5 مگابایت یافت. داکرفایل آن چنین است:

1FROM python:3.7.2-alpine3.8
2COPY. /app
3ENTRYPOINT [“python”,./app/my_script.py”, “my_var”]

در وب‌سایت داکر هاب این ایمیج مبنا با اندازه 29 مگابایت مشاهده می‌شود. زمانی که ایمیج فرزند که آن را ساخته است اقدام به دانلود و نصب پایتون می‌کند باعث افزایش اندازه آن می‌شود.

به جز ایمیج‌های مبنای Alpine روش دیگری نیز برای کاهش اندازه این ایمیج‌ها با استفاده از بیلد‌های چندمرحله‌ای وجود دارد. دقت کنید که این تکنیک موجب افزایش پیچیدگی داکرفایل نیز می‌شود.

بیلد‌های چند مرحله‌ای

«بیلدهای چندمرحله‌ای» (Multistage Builds) از چندین دستورالعمل FROM استفاده می‌کنند. شما می‌توانید به طور گزینشی فایل‌ها را کپی کنید و اینترفیس‌های بیلد را از یک مرحله به مرحله بعد فراخوانی کنید. همچنین می‌توانید همه آن چیزی که در ایمیج نهایی نمی‌خواهید را رها کنید. این روش موجب کاهش اندازه کلی ایمیج می‌شود.

هر دستورالعمل FROM دارای خصوصیات زیر است:

  • یک مرحله جدید در بیلد آغاز می‌شود.
  • هر حالتی که در مراحل قبلی ایجاد شده رها می‌شود.

می‌توان از مبنای متفاوتی استفاده کرد. در ادامه مثالی از یک بیلد چندمرحله‌ای را می‌بینید از که مستندات داکر اخذ شده است:

1FROM golang:1.7.3 AS build
2WORKDIR /go/src/github.com/alexellis/href-counter/
3RUN go get -d -v golang.org/x/net/html  
4COPY app.go .
5RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .
6FROM alpine:latest  
7RUN apk --no-cache add ca-certificates
8WORKDIR /root/
9COPY --from=build /go/src/github.com/alexellis/href-counter/app .
10CMD ["./app"]

توجه داشته باشید که ما مرحله نخست را با الحاق نام به دستورالعمل FROM ساخته‌ایم. مرحله نام دار در ادامه می‌تواند در دستورالعمل COPY --from= در دستورالعمل بعدی داکرفایل مورد ارجاع قرار گیرد.

بیلد های چندمرحله‌ای در برخی موارد که می‌خواهید تعداد زیادی کانتینر در محیط production بسازید به کار خواهند آمد. بیلدهای چندمرحله‌ای می‌توانند به کاهش اندازه ایمیج‌ها در حد بسیار زیاد کمک کنند. با این وجود در برخی موارد بیلدهای چندمرحله‌ای پیچیدگی زیادی دارند و ممکن است نگهداری ایمیج‌ها دشوارتر شود و از این رو احتمالاً در اغلب بیلدها از آن‌ها استفاده نخواهیم کرد.

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

dockerignore.

فایل‌های dockerignore. چیزی هستند که به عنوان فردی که اطلاعات داکر خوبی دارد باید از آن‌ها مطلع باشید. dockerignore. مفهومی مشابه gitignore. است. این یک فایل از الگوهای نام برای داکر است که با نام‌های فایل مطابقت دارد و آن‌ها را از یک ایمیج مستثنی می‌کند. فایل dockerignore. خود را در همان پوشه‌ای که داکرفایل و بقیه چارچوب بیلد تان قرار دارد ایجاد کنید.

زمانی که دستور docker build را برای ساخت یک ایمیج اجرا می‌کنید، داکر بررسی می‌کند که آیا یک فایل dockerignore. وجود دارد یا نه. اگر چنین فایلی یافت شود در مرحله بعد به بررسی خط به خط فایل می‌پردازد و از قواعد مطابقت مسیر فایل (+) و چند قاعده خود داکر (+) استفاده می‌کند تا نام‌های فایل‌ها را برای استثنا کردن از فرایند بیلد پیدا کند. این الگوها چیزی شبیه به الگوهای سراسری با سبک یونیکس هستند و نه عبارت‌های منظم.

بنابراین jpg.* موجب می‌شود که همه فایل‌های با پسوند jpg. از شمول بیلد داکر خارج شوند. همچنین الگوی videos موجب استثنا شدن پوشه videos و محتوای آن می‌شود. شما می‌توانید کاری که می‌خواهید انجام دهید را در فایل dockerignore. به وسیله کامنت‌هایی که با # آغاز می‌شوند توضیح دهید. استفاده از dockerignore. برای استثنا کردن فایل‌ها از ایمیج داکر ایده مناسبی محسوب می‌شود. فایل dockerignore. می‌تواند کارهای زیر را انجام دهد:

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

این‌ها دلایلی هستند که باید از یک فایل dockerignore. استفاده کنیم. برای کسب اطلاعات بیشتر به مستندات (+) مراجعه می‌کنید.

بازبینی اندازه

در این بخش به توضیح روش‌های تشخیص اندازه ایمیج‌های داکر و کانتینرها از خط فرمان می‌پردازیم.

  • برای مشاهده اندازه تقریبی کانتینر در حال اجرا می‌توانید از دستور زیر استفاده کنید:
docker container ls –s
  • اجرای دستور زیر نیز اندازه‌های ایمیج‌های شما را نمایش می‌دهد:
docker image ls
  • برای دیدن اندازه ایمیج‌های میانی که ایمیج شما را تشکیل می‌دهند، می‌توانید از دستور زیر استفاده کنید:
docker image history my_image:my_tag
  • اجرای دستور زیر نیز موارد زیادی را در مورد ایمیج به شما نشان خواهد داد که شامل اندازه‌های هر لایه می‌شود:
docker image inspect my_image:tag
  • لایه‌ها تفاوت ظریفی با ایمیج‌هایی که یک ایمیج کلی را تشکیل می‌دهند دارند. اما در اغلب موارد آن‌ها را می‌توان یکسان فرض کرد.
  • نصب و استفاده از بسته dive (+) موجب می‌شود که به راحتی بتوانید محتوای لایه‌ها را مشاهده کنید.

در بخش بعدی به بررسی بهترین رویه‌های کاهش اندازه ایمیج‌ها می‌پردازیم.

هشت مورد از بهترین رویه‌های کاهش اندازه ایمیج و زمان بیلد

این هشت روش را می‌توانید در فهرست زیر مشاهده کنید:

  • در همه موارد ممکن، از یک ایمیج مبنای رسمی استفاده کنید چون ایمیج‌های رسمی به طور منظم به‌روزرسانی می‌شوند و مطمئن‌تر ایمیج‌های غیررسمی هستند.
  • هر زمان که ممکن باشد، از نسخه‌هایی از ایمیج Alpine استفاده کنید تا ایمیج‌هایتان سبک باشند.
  • اگر از apt استفاده می‌کنید همواره دستورهای RUN apt-get update را با apt-get install ترکیب کنید. سپس بسته‌های چندگانه را در دستورالعمل به صورت زنجیری بیاورید. بسته‌ها را با ترتیب الفبایی در چند خط با استفاده از کاراکتر \ بیاورید. برای نمونه:
1RUN apt-get update && apt-get install -y \
2    package-one \
3    package-two 
4 && rm -rf /var/lib/apt/lists/*

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

  • در انتهای دستور RUN خود از عبارت زیر استفاده کنید تا کش apt پاکسازی شود و در لایه ذخیره نشود:
&& rm -rf /var/lib/apt/lists/*
  • با قرار دادن دستورالعمل‌هایی که احتمال تغییر بیشتری دارند، در بخش‌های انتهایی داکرفایل، می‌توانید از کش به صورت هوشمندانه‌ای استفاده کنید.
  • از یک فایل dockerignore. برای حفظ فایل‌های ناخواسته در خارج از ایمیج استفاده کنید.
  • از ابزار dive (+) استفاده کنید. dive یک ابزار جالب برای بررسی لایه‌های ایمیج داکر و کمک به کاهش اندازه آن است.
  • بسته‌هایی که نیاز ندارید را نصب نکنید، گرچه این توصیه بدیهی به نظر می‌رسد؛ اما همواره باید آن را برای خودتان تکرار کنید.

ایمیج‌های داکر

اینک شما با روش ساخت ایمیج‌هایی که بیلد و دانلود سریعی دارند و فضای زیادی اشغال نمی‌کنند آشنا شده‌اید. البته همانند تغذیه سالم، دانستن تنها نیمی از راه است. در بخش بعدی این سری مقالات به بررسی دستورهای ضروری داکر می‌پردازیم:

اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

==

بر اساس رای ۲ نفر
آیا این مطلب برای شما مفید بود؟
اگر بازخوردی درباره این مطلب دارید یا پرسشی دارید که بدون پاسخ مانده است، آن را از طریق بخش نظرات مطرح کنید.
منابع:
towardsdatascience
نظر شما چیست؟

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *