چگونه در شش ماه مهندس دواپس شویم؟ (قسمت پنجم)

در قسمت پنجم چگونه در شش ماه مهندس دواپس شویم؛ در نظر داریم در رابطه با چگونگی استقرار کدهای مورد استفاده صحبت کنیم. اما نیاز است که قبل از هرچیزی به مرور قسمت‌های قبل بپردازیم. درواقع در قسمت اول مبانی و فرهنگ DevOps خدمت شما معرفی شد. پس از آن در قسمت دوم با چگونگی پیکربندی و اهمیت استقرار کدهای تغییرناپذیر آشنایی مختصری پیدا کردید. در قسمت سوم در رابطه با چگونگی سازماندهی و حفظ کدهای مستقر شده توضیحاتی خدمت شما ارائه دادیم. در قسمت چهارم نیز نحوه دسته بندی کد و اجرای آسان و اجراهای بعدی شرح داده شد. مرور بخش‌های گذشته کمک می‌کند تا با ذهنیتی بازتر به سراغ فراگیری قسمت جدید بروید.

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

استقرار کد

تاکنون به این مسئله فکر کرده‌اید که چرا در رابطه با " چگونه به راحتی کد خود را مستقر کنید؟ " صحبت نشده است؟ حتما باید دلیلی داشته باشد!

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

چرا اینطور است؟

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

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

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

روی دستگاه من کار می‌کند!

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

اما زیرساخت عملیاتی این‌طور باشد:

باید به این نتیجه برسید که مشکلی وجود دارد.

اگر به سراغ استفاده زیرساخت به عنوان کد به جای پیکربندی دستی بروید، تقریبا  90% راه را پیموده‌اید. اگر این‌طور نیست، ناامید نشوید؛ شما تنها نیستید. یک بعدازظهر وقت بگذارید، شکاف‌های موجود (آموزش، فرهنگ، مدرن، فرآیندها و...) را مشخص کنید و به صورت هدفمند آن‌ها را یک به یک از بین ببرید.

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

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

با فرض اینکه کارها به درستی انجام شده است، می‌توانم استدلال کنم که بهترین راه برای استقرار کد، این است که اصلا مستقر نشود!

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

درست است؛ تاریخ استقرار کد روی ماشین‌های عملیاتی، به سال 1990 میلادی برمی‌گردد.

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

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

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

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

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

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

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

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

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

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

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

در واقع، نباید کسی به هیچ وجه به ماشین‌‌های عملیاتی دسترسی داشته باشد. نه با ssh، نه با scp، چه خود شما و چه هکرهای مشتاق.

اما در صورت نیاز برای رفع مشکل چه باید کرد؟

درست حدس زدید! در واقع لاگ‌های موجود باید به صورت کامل به بیرون منتقل شوند که برای این کار می‌ةوان از ElasticSearch / Logstash / Kibana (ELK) یا نرم افزارهای تجاری مانند SumoLogic یا Datadog استفاده کرد.

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

مکانیک استقرار کد

حال شما می‌دانید که چه اقداماتی برای استقرار کد انجام دهید، اما سوال اینجاست که چگونه باید این کار را انجام دهید؟

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

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

حال سوال این است که چرا اغلب توصیه می‌شود برای استقرار کد به سراغ Jenkins بروید؟

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

بلد بودن کار با Jenkins و به طور مشخص JenkinsFile یک مزیت بزرگ برای آینده شغلی شما محسوب می‌شود و قابل چشم‌پوشی نیست.

به گفته بسیاری از افراد، در زمان یادگیری Jenkins، این اطمینان را حاصل کنید که خط جدید BlueOcean را دنبال می کنید نه مسیری قدیمی‌تر Jenkins jobs  را.

این مسئله از اهمیت بالایی برخوردار می‌باشد زیرا خط CI / CD شما در کنار Repo های GitHub  یا GitLab قرار دارد. این روش خط خود یک نسخه کد شده است!

همه چیز کد است

برنامه شما، نحوه استقرار آن، نحوه نظارت، چگونگی پیکربندی آن، و... کلیه تکه‌ کدها، ذخیره شده در GitHub / GitLab /  یا هر جای دیگر... هر آنچه که به درستی نسخه شده است را شامل می‌شود.

هدف، ایجاد یک محیط بدون اصطکاک برای توسعه دهندگان اصلی (مهندسان نرم افزارهایی است که کد ویژگی ها را می نویسند) است.

به عنوان مثال، من باید قادر به نوشتن میکروسرویس کوچک خود باشم، هر تست را که لازم بدانم اضافه کنم، یک Jenkinsfile اضافه کنم، پیکربندی monitoring-as-code را اضافه کنم، پارامترهایم را در برخی از فایل‌های "env.yaml" مشخص کنم، همه آن را در یک repo ذخیره کنم. آن را آزمایش کنم، مستقر کنم (به صورت ارغوانی یا آبی / سبز) و وقتی این کار را شد برای من ایمیل بفرستد!

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

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

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

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

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

در انتها، GitHub  محصول جدیدش به نام Actions  را رونمایی کرد که قرار است اتوماسیون خود آنها باشد.

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

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

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

منبع:

How To Become a DevOps Engineer In Six Months or Less - part 5