بهترین راهکارهای ایجاد معماری کانتینرها و میکروسرویس ها همگی بر این تاکید دارند که یک کانتینر باید تنها یک پردازش( single process ) را اجرا کند. اگر این مسئله را همیشه برای طراحی کانتینر ها در نظر بگیریم، هر کانتینر ساده تر ساخته شده، قابل عیب یابی، گسترش و دیپلوی ساده تر خواهد بود.

چرخه حیات

چرخه ی حیات( life cycle ) یک کانتینر به نحوه ی عملکرد آن و وضعیت های مختلف process در حال اجرای درون آن بستگی دارد و بر اساس هردو مورد میتوانید life cycle های پیچیده ای را طراحی کنید. این مسئله عموما در سطوح پیشرفته کاربرد دارد.

در نظر داشته باشید که طراحی رفتار و life cycle سطح بالا برای کانتینرها نیازمند دانش بسیار عمیق نسبت به: کانتینر، رفتار برنامه ی درون کانتینر و ارکستریتور(بعدا در این مورد صحبت می کنیم!) است.

در عموم کارها معمولا به مانیتورینگ و life cycle های ساده و ابتدایی قناعت می کنیم.

برای مثال از یک لایف سایکل پیچیده به تصویر زیر توجه کنید.

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

فعلا این مسئله را گوشه ی ذهن خود داشته باشید و روی ادامه ی موضوع تمرکز کنید!

به صورت کلی یک کانتینر میتوانددر وضعیت( state ) در حال اجرا( running ) یا متوقف شده( stopped ) باشد. این وضعیت توسط اپراتور، ارکیستریتور( container orchestrator ) یا وضعیت برنامه ی درون خود کانتینر تعیین می شود.

برای مثال یک اپراتور می تواند یک کانتیر را به صورت دستی( manually )، stop یا start کند. اپراتور میتواند این کار را از طریق رابط کاربری گرافیکی(GUI: گویی خوانده می شود) یا رابط کامند لاین ( command-line interface (CLI) ) و از طریق دو دستور docker stop یا docker start انجام دهد. خود داکر نیز به صورت خودکار میتواند در شرایطی که تشخیص دهد کانتینر در یک وضعیت نامناسب( unhealthy state ) قرار دارد، آن را ری استارت یا متوقف کند. در واقع انتظار داریم اگر برنامه ی داخل کانتینر دچار خطا شد( fail یا critical error) و یا متوقف شد، کانتینر نیز متوقف شود. اکثر پلتفرم های اجرای کانتینر ها در این شرایط کانتینر را به صورت خودکار ری استارت می کنند و به این خاطر سازوکارهایی برای اجرای job ها و task ها در این پلتفرم ها تعبیه شده است.

برای مطالعه ی بیشتر :

job

task

از آنجایی که یک کانتینر در صورت توقف پردازش اصلی از کار می افتد، کانتینرها یک پلتفرم خیلی خوب برای اجرای script ها ,job هایی هستند که یک طول عمر محدود ( indefinite lifespan ) دارند. تصویر زیر life cycle یک کانتینر با indefinite lifespan را مشاهده می کنید:

از محبوبیت تا اجرای کانتینر

پلتفرم های مختلفی برای اجرای کانتینرها وجود دارند و حتی میتوانید به صورت مستقیم نیز از HyperVisor استفاده کنید اما علت اصلی محبوبیت داکر، سادگی استفاده از آن است. زمانی که داکر را نصب میکنید بلافاصله می توانید کانتینرهای مختلف را دانلود کنید یا بسازید و اجرا کنید. Docker CLI یک دستور( aptly ) به نام docker run دارد که یک کانتینر را شروع و اجرا می کند. با توجه به مباحث 2قسمت قبل و این قسمت میدانیم که کانتینرها ایزولاسیون کامل برنامه را برای ما فراهم میکنند و life cycle کانتینر تنها وابسته به پردازش اصلی داخل آن است.

برای مشاهده ی کانتینرهای در حال اجرا بر روی یک سیستم میتوان از دستور docker ps استفاده کرد. docker ps مشابه دستوری یونیکسی ps است و در سیستم های لینوکسی به ما پردازش های در حال اجرا را نمایش می دهد(مثل Task Manager در ویندوز).

دقت کنید که داکر قبل از اجرای یک کانتینر هیچ container image ای در local cache خودش ندارد و تنها قبل از اجرای کانتینر، container image را از container image registry دانلود می کند. برای مشاهده ی container imageهای روی سیستم خود می توانید از دستور docker images استفاده کنید.

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

دقت کنید که هیچ پردازش و تصویری در ابتدای کار وجود ندارد و در قسمت بعد تغییر خروجی این دو دستور را میبینید!