با مروری بر قسمت‌های گذشته چگونه در شش ماه یک مهندس دواپس شویم، در نظر داریم تا قسمت ششم آنکه مرحله اجرا می‌باشد را شرح دهیم. در قسمت اول مبانی و فرهنگ DevOps خدمت شما معرفی شد. پس از آن در قسمت دوم با چگونگی پیکربندی و اهمیت استقرار کدهای تغییرناپذیر آشنایی مختصری پیدا کردید. در قسمت سوم در رابطه با چگونگی سازماندهی و حفظ کدهای مستقر شده توضیحاتی خدمت شما ارائه دادیم. در قسمت چهارم و پنجم نیز نحوه دسته بندی و استقرار کد و اجرای آسان و اجراهای بعدی شرح داده شد. دقت داشته باشید که برای یادگیری باید حدود یک ماه برای هر قسمت زمان بگذارید. شکل زیر به‌طور کامل مرحله یادگیری را خدمت شما نشان می‌دهد:
آیا برای اجرای آن آماده هستید؟
در این قسمت ما تلاش کردیم تا کدی نوشته، آن را بسته‌بندی و سپس مستقر نمائیم.
قصد داریم بدون درنظر گرفتن فرآیند ساخت ماشین مجازی (به عنوان مثال سرویس سرو آوند یا EC2) و با تمرکز بر روی کانتینر ادامه دهیم. اما سوالی که در ذهن ایجاد می شود این است که دلیل این کار چیست؟
با توجه به این مسئله که ساخت یک AMI(ایمیج ماشین آمازون) تغییرناپذیر در منبع، کپی کردن آن در تمامی نقاط و سپس به اجرا درآوردن آن کاری دشوار محسوب می‌شود. اگر موظف به انجام آن هستید بهترین راه استفاده از الگوی مناسب است.
با این حال، به شما توصیه می‌کنم که به این فکر کنید که آیا اصلا مجبور به انجام این کار هستید یا نه؟ اگر جواب منفی است، اقدام به سازماندهی مجدد میکروسرویس‌ها به عنوان کانتینر یا توابع بدون سرور کنید.
توجه: اگر این مسئله امکان‌پذیر نیست، تنها دلیل آن می‌تواند تصمیم شما برای نوشتن، بسته‌بندی و استقرار نرم‌افزارها به عنوان یک برنامه یکپارچه باشد. پس استفاده از الگوی AMI تغییرناپذیر می‌تواند نتیجه‌بخش باشد. یا به عنوان مثال، اگر شما مجبور هستید که کارهایتان را به صورت non-cloud native یا با نرم‌افزارهای تجاری “همان‌طور که هست” انجام دهید، این مقاله مناسب شما نیست.
حال که ما کانتینرها را بسته‌بندی و آماده‌سازی کرده‌ایم، سوال اینجاست که چگونه باید آن‌ها را اجرا کنیم؟
اجرای کانتینرها
خب... ساده‌ترین کاری که می‌توانید انجام دهید این است که دستور docker run my Image را به اجرا درآورید و در طول روز با آن ارتباط برقرار کنید. هر چند که این ایده از نظر بسیاری از افراد کارآمد نیست.
اما چرا این روش را ناکارآمد می‌دانند؟
چه اتفاق رخ می‌دهد؟
⦁ اگر کانتینر از بین رفت چه ؟
⦁ آیا به بیش از یک کانتینر برای تحمل بار بیشتر نیاز است؟
⦁ آیا باید به صورت همیشه در دسترس استقرار پیدا کنید؟
⦁ آیا تمایل دارید تا میکروسرویس‌هایتان در معرض دید کامل باشند؟
⦁ آیا می‌خواهید یک خط CD/CI برای ارائه ارزش‌های خود به مشتریان داشته باشید؟
⦁ و....
به عبارت ساده‌تر، چه اتفاقی رخ می‌دهد اگر شما نیاز به ساخت یک برنامه واقعی، در درجه سازمانی و توزیع شده را به وجود آورید؟
به وضوح، چیزی به سادگی docker run قرار نیست این برنامه را ایجاد کند.
توجه: docker-compose مجموعه‌ی بسیار مشابهی از مشکلات را در بردارد. در واقع نمی‌توان از docker-compose برای استقرار در محیط عملیاتی استفاده نمود؛ هدف اصلی آن ساخت یک نمونه محلی و یا آزمایش سرعت عملکرد و یا استقرار آن در مقیاس کوچک است.
حال که ما نمی‌توانیم هدف خود را به راحتی انجام دهیم، چه اقداماتی باید در پیش گیریم؟
مدیریت جمعی درست کانتینرها برای نجات!!!!
منظور از مدیریت جمعی (orchestration) کانتینر چیست؟
همانند سایر موقعیت‌هایی که در زندگی برای‌مان رخ می‌دهد، در این‌جا نیز باید بدانید که بیش از یک جواب برای رفع این مشکل وجود دارد. اولین و بارزترین آن kubernetes است.
که یکی از پروژه‌های داخلی گوگل می‌باشد هم‌اکنون به عنوان استاندارد مدیریت جمعی کانتینرها مورد استفاده قرار می‌گیرد. همچنین در صورتی که در محیط‌های زیر کار می‌کنید تنها راه حل موجود است:
⦁ یک مرکز داده خصوصی
⦁ ابر گوگل
⦁ پلتفرم رایانش ابری مایکروسافت ( آژور مایکروسافت)
⦁ هر ابر عمومی دیگر نظیر ابر آوند
با این‌حال اگر از محیط AWS استفاده می‌کنید، گزینه دیگری همچون ECS نیز پیش روی شما قرار می‌گیرد.
توجه: این مسئله به طور کامل صحیح نیست. شما Nomad از Hashicorp (همان تیمی که ترافورم را عرضه کرده) و docker Swarm از docker را نیز در اختیار دارید. مشکل اینجاست این موارد جزء پلتفرم‌هایی با حداقل استفاده هستند که می‌توانیم از آنان برای رشد سریع‌تر صرف‌نظر کنیم.
به هر حال، به ECS برگردیم. خدمات ارائه شده توسط AWS به عنوان کانتینر الاستیک ( ECS) برای شروع کار بسیار ساده است. و می‌توان از سازگاری کامل آن با سایر اکوسیستم‌های AWS لذت برد. باید بدانید که این سیستم توانایی انجام تعدادی محدودی کار، اما به بهترین نحو را دارد. به‌طور خلاصه، می‌توان گفت که به اندازه kubernetes خوب نیست.
در واقع اگر ECS توانسته به اندازه کافی برای مک‌دونالد خوب باشد، برای شما نیز مناسب خواهد بود.
اگر بخواهیم در این زمان، از منظر ایجاد شغل به این مسئله نگاه کنیم، هیچ شکی در این که kubernetes انتخاب بهتری محسوب می‌شود وجود ندارد؛ حتی اگر 99 درصد شرکت‌های بزرگ فعال در AWS، از عملکرد ECS راضی باشند.
حال، شما باید راه خود را انتخاب کنید. اگر تازه وارد این کار شده‌اید، خود را آماده یک شعار بسیار بلند در زمین kubernetes کنید. یادگیری تمامی نکات مرتبط به دواپس آن هم به تنهایی و خارج از تیم مهندسان به‌هیچ عنوان کار ساده‌ای محسوب نمی‌شود.
هرچند به‌طور قطع انجام آن امکان‌پذیر است، این مسئله خصوصا با ارائه دوره‌های رایگان Google و AWS و همچنین آموزش‌های موجود در Youtube/Udemy و قیمت‌گذاری‌های نقطه‌ای AWS فراهم شده است.
توجه: اگر تصمیم به قرار گرفتن در این مسیر دارید، توصیه می‌شود که با GKE یا kops کار را آغاز کنید. kubernetes با مدیریت آمازون (EKS) هزینه زیادی را برای شما در پی دارد و مکان خوبی برای شروع محسوب نمی‌شود.
با این‌حال، اگر شما در این زمینه تازه وارد نیستید و در حال حاضر در اکوسیستم AWS کار می‌کنید، توصیه می‌شود که میکروسرویس‌های خود را به صورت کانتینر روی ECS مستقر کنید. kubernetes به شما این امکان را می‌دهد که از خواب شب خود لذت ببرید و یک تجربه خوب کاری را در سطح جهانی به‌دست آورید.
زیرا با سر شیرجه زدن در kubernetes همچون حرکت بر روی یک طناب باریک است و حتی می‌تواند شما را از ماموریت واقعی خود که تحویل سریع و موثر به مشتری است دور کند.
آیا واقعا به kubernetes نیاز دارم؟
جواب مشخص است: «خیر»
اما در بازار کار می‌گویند یا باید kubernetes بلد باشی یا خانه نشین می‌شوی
در ابتدا، شاید برایتان جالب باشد که بدانید با توجه به تاثیرگذاری ای که از kubernetes بر لبه فناوری در ذهن بسیاری از متخصصان وجود دارد، ایده kubernetes نسبتا قدیمی است. درواقع وقتی گوگل در سال 2015 استفاده از Borg را در پیش گرفت هم یک ایده نسبتا قدیمی به حساب می‌آمد:
به طور خلاصه:
کوبرنتیز یک بخش بزرگ از معماری و ویژگی‌های سیستم borg محسوب می‌شود که تصمیمات مهم از جمله طراحی، تجزیه و تحلیل و حتی برخی سیاست‌های سیستم را برعهده دارد. و تجربیات آن به بیش‌از یک دهه برمی‌گردد.
این جمله دقیقا kubernetes را در صفحه اصلی شرح می‌دهد.
کوبرنتیز(K8s) یک سیستم با منبع باز محسوب می‌شود که به صورت خودکار به استقرار، مقیاس‌دهی و مدیریت برنامه‌های کانتینر می‌پردازد کانتینرها را به منظور مدیریت و کشف آسان برنامه‌ها در واحدهای منطقی گروه‌بندی می‌کند، kubernetes با گذشت 15 سال از تجربه بارگذاری در گوگل همراه با ایده‌ها و شیوه‌های برتر جزء بهترین‌ها به حساب می‌آید.
پس اگر در آینده شنیدید که از kubernetes به عنوان یک ایده جدید و داغ صحبت شد، بدانید که آن‌ها تنها در حال حمایت از یک فناوری هستند که پانزده سال قدمت دارد.
این مسئله خیلی ابتکاری به حساب نمی‌آید. موافق نیستید؟
دوم اینکه باید به مخاطب هدف فکر کنید. Google ابزارهایی را برای حل مشکلات خود در مقیاس خود راه‌اندازی می‌کند. که باز هم kubernetes در صفحه اصلی خود به طور واضح به آن پرداخته است:
معیار بزرگ (سیاره)
با همان اصولی طراحی شده است که به گوگل این اجازه را می‌دهد تا میلیاردها کانتینر را در طول هفته به اجرا درآورد. نکته اینجاست که kubernetes نیز این توانایی را دارد که بدون هیچ‌گونه افزایش تعداد افراد تیم عملیات شما، بزرگتر شود.
در نهایت، یکی از توسعه‌دهندگان اصلی kubernetes که مدافع سخنگوی آن است به این نکته تاکید دارد که:
کوبرنتیز برای آن دسته از افرادی‌ست که پلتفرم می‌سازند. درواقع، اگر شما به عنوان توسعه‌دهنده‌ای شناخته می‌شوید که پلتفرم شخصی خود را ایجاد کرده است. ( موتور برنامه، برنامه های مبتنی بر ابر و...) پس می‌توان نتیجه گرفت که kubernetes برای شما مناسب است.
اگر مقیاس‌های بزرگ را برای کار خود در نظر گرفته‌اید و یا در هفته بر روی میلیاردها کانتینر کار می‌کنید و یا اینکه یک ابر را برای استفاده دیگران به وجود آورده‌اید، kubernetes می‌تواند یک انتخاب بسیار مناسب محسوب شود.
اگر این‌گونه نیست. پس به پایان داستان رسیده‌اید.
هیچ اهمیتی ندارد که مادربزرگتان به سراغ خواندن توئیت‌های مرتبط با Kelsey آن هم در وقت نهار می‌رود و و بعدش سایت گل‌فروشی‌‌اش را با ابزارهای خودکار CI/CD به kubernetes منتقل می‌کند. kubernetes ابزار مناسبی برای برطرف سازی نیازهای شما نیست.
چه کسی اهمیت می‌دهد:
آن‌ها همواره می‌گویند؛ آیا واقعا این مسئله مهم است؟ پاسخ این است:
kubernetes = $$$
پس باید به سطح بالاتر برویم و از حرکت در مسیر دواپس و به‌دست آوردن تجربیات جدید لذت ببریم.
منبع:
How To Become a DevOps Engineer In Six Months or Less, Part 6
