چگونه در کمتر از شش ماه به یک مهندس دواپس (DevOps) تبدیل شویم؟ بخش چهارم: پکیج

یکشنبه ۱۰ شهریور ۹۸ توسط سالار ساری نوایی

یک مرور سریع!

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

در بخش دوم به راه و روش فراهم‌سازی بستر کد با در نظر داشتن پیاده‌سازی‌های آینده اشاره کردیم.

در بخش سوم نیز درباره‌ی مرتب و منظم نگه داشتن کارها و کدهایتان توضیحاتی ارائه دادیم.

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

برای یادآوری بیشتر، الان در این مرحله از ماجرای دواپس هستیم.

نکته: می‌توانید ببینید که هر بخش به کمک بخش قبلی ساخته می‌شود و همچنین بنیان‌گذار بخش بعد از خود است. این نکته‌ اهمیت بالایی دارد و بی‌دلیل به این گونه طراحی نشده است.

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

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

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

بسیار خب، برویم سراغ اصل مطلب!

الفبای مجازی‌سازی

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

بله، اول آن‌ها آمدند!

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

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

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

مدت زیادی روی این موضوع کار شد و شرکت‌هایی مانند VMWare بهره‌ی زیادی از آن بردند.

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

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

به طور خلاصه، کار داکر (Docker) همین است.

تولد داکر

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

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

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

اما این عبارت در عمل به چه معناست؟

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

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

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

بسیار کارآمد است!

خب، وقت آن است که به سراغ مزایا و معایب داکر برویم.

مزایای داکر

ایزوله‌سازی فرآیند

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

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

این کار از جنبه‌ی امنیتی هم مزایای خود را دارد. اگر یک کانتینر آسیب ببیند، خارج شدن از آن کانتینر و هک کردن سیستم عامل پایه بسیار دشوار است (اما غیرممکن نیست!).

در نهایت اگر یک کانتینر رفتار درستی از خود نشان نمی‌دهد (مصرف بیش از حد پردازنده یا حافظه) می‌توان بدون تحت تاثیر قرار دادن سیستم، آن کانتینر را از کار انداخت.

پیاده‌سازی

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

اگر این برنامه به زبان پایتون باشد، پکیج‌های مختلفی از پایتون را به همراه خواهد داشت. برخی از آن‌ها به عنوان ماژول pip نصب می‌شوند و برخی دیگر نیز پکیج‌های rpm یا deb هستند. سایر پکیج‌ها نیز فایل‌های نصبی git clone هستند. اگر این کار را در یک محیط مجازی انجام بدهید، این کار با یک فایل زیپ که شامل تمام وابستگی‌ها است صورت می‌گیرد.

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

منظورم را فهمیده‌اید. برنامه‌های مختلف با زبان‌های مختلف و زمان اجراهای مختلف، در زمان پیاده‌سازی می‌توانند چالش برانگیز باشند.

چگونه می‌توانیم همه‌ی این وابستگی‌ها را ارضا کنیم؟

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

در این جا داکر وارد بازی می‌شود.

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

مدیریت زمان اجرا

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

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

نکته: از دسامبر 2018، دیگر مجبور نیستید که میان شروع سریع و امنیت ماشین‌های مجازی یکی را انتخاب کنید. به لطف آمازون، Project Firecracker سعی می‌کند که بهترین مزایای هر کدام از این دو مورد را ارائه بدهد. البته این تکنولوژی بسیار جدید است و هنوز مناسب پیاده‌سازی برای تولید نیست.

اما در نهایت داکر معایبی هم به همراه دارد.

لامبدا وارد می‌شود

اجرای داکر هم اجرای سرور است. سرورها هم آسیب‌پذیر هستند. باید آن‌ها را مدیریت کرد و به آن‌ها رسیدگی نمود و اهمیت داد.

ضمن این که داکر به طور 100% ایمن نیست. حداقل به اندازه‌ی ماشین مجازی ایمنی ندارد. دلیلی وجود دارد که شرکت‌های بزرگ کانتینرهای هاست‌شده را درون ماشین‌های مجازی اجرا می‌کنند. آن‌ها دنبال سرعت بالای کانتینرها و امنیت ماشین‌های مجازی هستند!

همچنین در حقیقت هیچ کس داکر را به تنهایی استفاده نمی‌کند. معمولا داکر به عنوان بخشی از فابریک یک کانتینر پیچیده مانند Kubernetes، ECS، docker-swarm یا Normad به کار گرفته می‌شود. این‌ها پلتفرم‌های پیچیده‌ای هستند که برای اجرا به پرسنل مخصوص خود نیاز دارند (در ادامه بیشتر به این راهکارها می‌پردازیم).

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

جواب کوتاه این است که بستگی دارد!

برای کسانی که می‌خواهند یک نفر دیگر کدشان را اجرا کند، AWS Lambda مناسب است.

AWS Lambda به شما اجازه می‌دهد که بدون نظارت یا مدیریت سرورها کدتان را اجرا کنید. تنها برای زمانی که در حال پردازش هستید هزینه پرداخت می‌کنید و اگر کد شما در حال اجرا نباشد خرجی برای شما ندارد.

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

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

عالی نیست؟

البته که هست اما باز هم باید نکاتی را در نظر داشت.

اولا که لامبداها حداکثر برای 15 دقیقه می‌توانند اجرا شوند (از نوامبر 2018). این یعنی که فرآیندهای بلند مدت مانند مصرف کنندگان کافکا یا برنامه‌های محاسباتی نمی‌توانند در لامبدا اجرا بشوند.

دوما، لامبداها تابع به عنوان سرویس محسوب می‌شوند. این یعنی که برنامه‌های شما باید کاملا به میکروسرویس‌ها تجزیه شوند و در کنار سرویس‌های PaaS پیچیده‌ی دیگر مانند AWS Step Functions هماهنگ شوند. هر سازمانی در این سطح از معماری میکروسرویس قرار ندارد.

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

به طور خلاصه، هیچ وقت کفه‌ی ترازو کامل به یک سمت نیست.

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

جمع‌بندی

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

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

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

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

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


کلیدواژه: آموزش devops آموزش دواپس آموزش داکر آموزش Docker

منابع: medium.com

ارسال دیدگاه:
برای ارسال دیگاه باید به سیستم وارد شوید و یا ثبت نام کنید. ثبت نام چند لحظه بیشتر زمان شما را نمیگیرد.