همه شما با مفهوم داکر و کانتینر ها آشنا هستید و میدونید که چی هستن و چکار میکنن (ایشالا).
اما این وسط یه سری نکته هست که ممکنه هر کسی بهش نپرداخته باشه که یادش بگیره و حتی خیلی هامون تا وقتی که یک چیزی کار کنه ممکنه که اصلاً دنبال بهبود کارایی اون چیز نریم برای مثال: داکر فایل که تو مرحله بیلد به کار میره و داخلش دستورهای لازم برای ساختن یک ایمیج رو میدیم
خب بریم سراغ اصل مطلب:
داکر برای کم کردن زمان ساخت یک ایمیج از کشینگ استفاده میکنه که در واقع عملیات کشینگش به این صورت هست که یه ساختار لایه ای داره که بهش اجازه میده تا عملیات بیلد رو تکه تکه و قابل تفکیک و همچنین مناسب برای استفاده مجدد جلو ببره.
Dockerfile FROM ubuntu:18.04 RUN apt-get update RUN apt-get install -y build-essential WORKDIR /app COPY app/hello.c /app/ RUN gcc -o hello hello.c ENTRYPOINT [ "/app/hello" ]
داخل داکر فایل هر خط از فایلی که ما می نویسیم در واقع خودش به یک ایمیج کوچیک تبدیل میشه که داکر با درون هم قرار دادن این ایمیج ها ایمیج نهایی و کانتینر مقصد رو براتون میسازه اما نکته ای که این وسط قابل اشاره است اینکه داکر از ایمیج های ریز برای عملیات کشینگ استفاده میکنه تا در هر بار بیلد تمام مراحل از اول انجام نشه و با توجه به ساختار نستد این ایمیج ها هر ایمیجی که دچار تغییر بشه اون ایمیج و تمامی ایمیج هایی که درون اون نست "nest" شدن باید از اول پیاده سازی بشن در واقع با هر بار تغییر تو هر خط فقط اون خط و خط های بعد از اون اجرا می شوند که این به زمان بیلد بشدت کمک میکنه و اون رو تا حد زیادی کاهش میده مخصوصاً جایی که نیاز به دانلود یک ایمیج باشد یا نصب یک یا چند پکیج نیاز باشد یا ....
خب ببینیم وقتی داکر فایل بالا رو برای اولین بار اجرا میکنیم چی میشه:
$ docker build -t stage0 . Sending build context to Docker daemon 77.31kB Step 1/7 : FROM ubuntu:18.04 18.04: Pulling from library/ubuntu f22ccc0b8772: Pull complete 3cf8fb62ba5f: Pull complete e80c964ece6a: Pull complete Digest: sha256:fd25e706f3dea2a5ff705dbc3353cf37f08307798f3e360a13e9385840f73fb3 Status: Downloaded newer image for ubuntu:18.04 ---> 2c047404e52d Step 2/7 : RUN apt-get update ---> Running in a8d65ab87a93 Get:1 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB] Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] ... Fetched 21.8 MB in 20s (1078 kB/s) Reading package lists... Removing intermediate container a8d65ab87a93 ---> fcdd591c3bfd Step 3/7 : RUN apt-get install -y build-essential ---> Running in c15a1c650b0a Reading package lists... Building dependency tree... ... Processing triggers for libc-bin (2.27-3ubuntu1.3) ... Removing intermediate container c15a1c650b0a ---> 9fbbc8093ab5 Step 4/7 : WORKDIR /app ---> Running in fed79856ded7 Removing intermediate container fed79856ded7 ---> 8bec0c4a2826 Step 5/7 : COPY app/hello.c /app/ ---> 5bf5977f4128 Step 6/7 : RUN gcc -o hello hello.c ---> Running in 48c0f7dc9fcb Removing intermediate container 48c0f7dc9fcb ---> 8a99d3e111df Step 7/7 : CMD [ "/app/hello" ] ---> Running in 2cc8c55e417b Removing intermediate container 2cc8c55e417b ---> 87a0e7eb81da Successfully built 87a0e7eb81da Successfully tagged stage0:latest $
و اما برای دومین بار که بیلد میشه:
$ docker build -t stage0 . Sending build context to Docker daemon 77.31kB Step 1/7 : FROM ubuntu:18.04 ---> 2c047404e52d Step 2/7 : RUN apt-get update ---> Using cache ---> fcdd591c3bfd Step 3/7 : RUN apt-get install -y build-essential ---> Using cache ---> 9fbbc8093ab5 Step 4/7 : WORKDIR /app ---> Using cache ---> 8bec0c4a2826 Step 5/7 : COPY app/hello.c /app/ ---> 3853b3aff546 Step 6/7 : RUN gcc -o hello hello.c ---> Running in 580c3f378281 Removing intermediate container 580c3f378281 ---> 583b361ff9a2 Step 7/7 : CMD [ "/app/hello" ] ---> Running in a2d18fe0c6b9 Removing intermediate container a2d18fe0c6b9 ---> 8fb6676c5b38 Successfully built 8fb6676c5b38 Successfully tagged stage0:latest
به اون using cache دقت کردید دیگه ایشالا؟
بعد از دونستن یه همچین مفهومی میتونیم درک کنیم که چرا جای خط ها در داکر فایل مهمه و این که منظور من از او عکس هفت سنگ چیه.
دقیقا مثل هفت سنگ که هر تعدادی سنگ بریزه باید شما باز اون سنگ و سنگای بالاییش رو روی هم بچینید که یه ساختار ۷ تایی درست کنید داکر هم مجبوره همینطوری کار کنه!
بعضی وقت ها بیلد ها صرفاً با عوض کردن جای یک خط پایپ لاین از بالای ربع ساعت به ۱ الی ۲ دقیقه میرسد که این بهبود عملکرد جایی که یک سیستم بزرگ برای پیاده سازی داشته باشیم بشدت ملموس است جایی که حداقل زمان بیلد ۲۰ دقیقه خواهد بود و حداکثر زمان می تواند حتی ساعت ها طول بکشد بنابراین اهمیت جایگذاری هر خط در جای مناسب خودش یکی از نکاتی است که باید در نوشتن داکر فایل به آن توجه شود برای این باید به دو نکته توجه کرد :
۱ - نکته اول اینکه هر خطی که ممکن است تغییرات بیشتری در آن رخ بدهد باید پایین تر قرار گیرد نسبت به بقیه لایه هایی که در آن ها تغییرات کمتری داریم پس هرچه فرکانس تغییر ها بالاتر جایگذاری پایینتر!
۲ - دومین نکته این است که برای درست کردن یک ساختار خیلی وقت ها نیاز است که یک لایه قبل از لایه های دیگر قرار بگیرد و در واقع محیط کار را برای لایه بعدی آماده کند بنا بر این در اینجا علاوه بر فرکانس تغییرات باید به پیش نیاز ها هم توجه کرد
با ترکیب دو اصل بالا میتوانیم داکر فایلی بسازیم که از لحاظ صحت عملکرد سالم و از لحاظ کارایی و زمان بیلد در بهینه ترین حالت خود قرار گیرد
اینو یادمون نره که داکر فایل خیلی کم نیاز به تغییر داره و هر بار تقریباً همون فایل برای ساخت ایمیج استفاده میشه پس با یه مقدار وقت گذاشتن بیشتر و بهینه کردن و جایگذاری درست هر خط از داکر فایل خودتونو برای یه مدت زیادی بیمه کنید
"""یه نکته ی خیلی مهم هم این آخر بهتون بگم که استفاده از تگ های latest یکی از بدترین کاراییه که میتونید با خودتون بکنید پس یه لطف به خودتون بکنید و ورژن هاتون رو فیکس کنید که نه برنامه تون به مشکل بخوره نه زمان بیلد رو چند برابر کنید."""
