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

پنج شنبه ۱۴ شهریور ۹۸ توسط سالار ساری نوایی

یک مرور سریع!

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

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

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

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

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

 

طبق قرار، اگر به مدت یک ماه برای هر بخش زمان بگذارید، الان باید در ماه چهارم باشیم.

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

حالا زمان آن است که چگونگی استقرار کدمان را بررسی کنیم.

استقرار کد

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

اما چرا؟

دلایل متعددی وجود دارد اما به نظر من اکثریت آن‌ها به تفاوت‌ها مربوط می‌شوند. به طور ویژه، تفاوت‌های میان محیطی که کد در آن تولید شده و محیطی که کد در آن اجرا می‌شود.

در واقع بهترین کاری که برای بهبود کلی استقرار کد و حتی زمان اجرای پس از استقرار آن می‌توانید انجام بدهید این است که این تفاوت‌ها را به حداقل برسانید.

بسیار خب، حالا چگونه باید تفاوت‌های میان این محیط‌هایمان را کاهش بدهیم یا از بین ببریم؟

این روی ماشین من کار می‌کرد!

اگر زیرساخت توسعه‌ی شما مانند شکل زیر است

 

اما زیرساخت تولید شما به این صورت است

 

شما با مشکل مواجه‌اید.

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

اگر این طور نیست هم نیاز به ناراحتی ندارد. شما تنها نیستید! یه روز وقت بگذارید و کم و کاستی‌هایتان را شناسایی کنید و طبق قاعده به نوبت به آ‌ن‌ها رسیدگی کنید.

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

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

با فرض این که این کار انجام شده است، من معتقدم که بهترین راه برای استقرار کد این است که کد را مستقر نکنیم.

رویکردهای مدرن برای استقرار کد

درست است – استقرار کد در ماشین‌های تولیدی از دهه 90 میلادی انجام می‌شود.

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

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

این کار "استقرار تغییر ناپذیر" نام دارد و به شما کمک می‌کند که از سردردهای بی‌اندازه‌ی پس از استقرار دوری کنید.

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

اما ممکن است بگویید که "تولید من با توسعه تفاوت دارد! نام کاربری و رمز عبور پایگاه داده، استرینگ‌های ارتباطی، مکان‌های S3 Bucket آمازون و غیره. همه‌ی این‌ها تفاوت دارد."

بله، این‌ها متفاوت هستند.

راه حل این مسئله در قاعده‌ی 12 فاکتور تنظیم برنامه نهفته است. تمامی تنظیمات شما باید به صورت خارجی انجام شوند و سپس به عنوان متغیرهای محیطی وارد ماشین بشوند.

به عنوان نمونه، اگر در محیط AWS هستید، از SSM به عنوان انبار پارامتر خارجی استفاده کنید. SSM به زیبایی با CloudFormation ادغام می‌شود. همچنین ست کردن متغیرهای محیطی به صورت مستقیم با دستورات cli درون aws ssm به آسانی انجام می‌شود. البته سایر سرویس‌دهندگان ابری نیز مکانیزم‌های مشابهی دارند.

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

در واقع هدف شما باید این باشد که همواره و تحت هر شرایطی، دسترسی به ماشین تولیدی غیرممکن باشد. نه ssh، نه scp و نه دسترسی تولیدی. نه برای شما و نه برای هر کس دیگری.

اما اگر برای پیدا کردن مشکلات به لاگ نیاز داشته باشم چطور؟

درست حدس زدید. لاگ‌های شما باید خارج از ماشین باشند. حالت ایده‌آل این است که لاگ‌ها با برنامه‌هایی مانند ElasticSearch، Logstash، Kibana، SumoLogic یا Datadog به جای دیگری منتقل شوند.

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

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

جنبه‌ی فنی استقرار کد

بسیار خب، حالا می‌دانید که باید چه کاری بکنید، اما چگونه؟

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

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

در حقیقت، راه‌اندازی‌های واقعا مقاوم و حرفه‌ای Jenkins بسیار نادر هستند و تنها در بزرگترین سازمان‌ها دیده می‌شوند.

پس با این شرایط چرا Jenkins را به شما پیشنهاد می‌کنم؟

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

به خاطر داشته باشید که در زمان یادگیری Jenkins از مسیر جدیدتر BlueOcean پیروی کنید، نه از مسیر قدیمی Jenkins Job.

این اهمیت بالایی دارد. چرا که شما می‌خواهید پایپ لاین CI/CD شما در مخزن گیت کدتان حاضر باشد. در این صورت خود پایپ لاین به یک قطعه‌ی نسخه‌گذاری شده از کد تبدیل می‌شود.

این به حدی مهم است که دوباره تکرار کردن آن ارزشش را دارد.

همه چیز کد است.

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

در این جا هدف این است که یک محیط واقعا آسیب ناپذیر را برای دولوپرهای مرکزی فراهم کنیم.

برای مثال، من باید بتوانم کد میکروسرویس کوچکم را بنویسم، هر آزمایشی که به نظرم مناسب است را اضافه کنم، یک Jenkinsfile اضافه کنم، تنظیمات نظارت به عنوان کد را اضافه کنم، پارامترهایم را در یک فایل “env.yaml” تعیین کنم، همه این‌ها را در یک مخزن ذخیره کنم، اجازه بدهم که Jenkins مخزن نام برده را به طور خودکار پیدا کند، آن را بسازد، آزمایش کند و مستقر کند و در پایان کار با یک ایمیل به من اطلاع بدهد!

هدف ما این است! در واقع ماموریت اصلی و اساسی مهندسان دواپس همین است.

جایگزین‌هایی برای Jenkins

همان طور که اشاره کردم، مدت زیادی است Jenkins در این عرصه حضور دارد و الان به نظر من گزینه‌های بهتری هم وجود دارد، حتی اگر از محبوبیت کمتری برخوردار باشند.

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

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

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

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

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

در واقع می‌توانید کارتان را آسان‌تر و بدون هیچ کانتینری شروع کنید که موضوع پست بعدی ما خواهد بود. با ما همراه باشید!


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

منابع: medium.com

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