اجرای مستمر استقرار ما در پلت فرم مشتری

ما در True Engineering فرآیندی را برای تحویل مداوم به‌روزرسانی‌ها به سرورهای مشتریان راه‌اندازی کرده‌ایم و می‌خواهیم این تجربه را به اشتراک بگذاریم.

برای شروع، ما یک سیستم آنلاین برای مشتری ایجاد کردیم و آن را در خوشه Kubernetes خودمان مستقر کردیم. اکنون راه حل پربار ما به پلتفرم مشتری منتقل شده است، که برای آن یک فرآیند استقرار مستمر کاملاً خودکار را راه اندازی کرده ایم. به لطف این، ما زمان ورود به بازار - تحویل تغییرات در محیط محصول را تسریع کردیم.

در این مقاله در مورد تمام مراحل فرآیند استقرار مستمر (CD) یا تحویل به‌روزرسانی‌ها به پلتفرم مشتری صحبت خواهیم کرد:

1. این روند چگونه شروع می شود؟
2. همگام سازی با مخزن Git مشتری،
3. مونتاژ باطن و فرانت اند،
4. استقرار خودکار برنامه در یک محیط آزمایشی،
5. استقرار خودکار به Prod.

ما جزئیات راه اندازی را در طول مسیر به اشتراک خواهیم گذاشت.

1. سی دی را راه اندازی کنید

استقرار پیوسته با اعمال تغییرات توسط توسعه دهنده به شاخه انتشار مخزن Git ما آغاز می شود.

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

ما به چند دلیل کار را از طریق یک مخزن سازماندهی کردیم:

• سهولت توسعه - برنامه به طور فعال در حال توسعه است، بنابراین می توانید با همه کدها به طور همزمان کار کنید.
• خط لوله CI/CD منفرد که تضمین می کند که برنامه به عنوان یک سیستم واحد تمام آزمایشات را پشت سر گذاشته و به محیط تولید مشتری تحویل داده می شود.
• ما سردرگمی در نسخه ها را از بین می بریم - ما مجبور نیستیم نقشه نسخه های میکروسرویس را ذخیره کنیم و پیکربندی آن را برای هر میکروسرویس در اسکریپت های Helm توصیف کنیم.

2. همگام سازی با مخزن Git کد منبع مشتری

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

ما نمی توانیم مستقیماً با مخزن مشتری کار کنیم زیرا به محیط های خود برای توسعه و آزمایش نیاز داریم. ما از مخزن Git خود برای این اهداف استفاده می کنیم - این مخزن با مخزن Git آنها هماهنگ است. به محض اینکه یک توسعه دهنده تغییرات را در شاخه مناسب مخزن ما پست کند، GitLab بلافاصله این تغییرات را به مشتری منتقل می کند.

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

3. مونتاژ Backend و Frontend

ساخت backend و frontend دو وظیفه موازی هستند که در سیستم GitLab Runner انجام می شوند. پیکربندی اسمبلی اصلی آن در همان مخزن قرار دارد.

آموزش نوشتن اسکریپت YAML برای ساخت در GitLab.

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

ما نسخه های تصاویر خود را با نسخه انتشاری که در Docker منتشر می شود، همگام می کنیم. برای عملکرد روان، چندین تنظیم انجام داده ایم:

1. کانتینرها بین محیط آزمایش و محیط تولید بازسازی نمی شوند. ما پارامترهایی را انجام دادیم تا همان ظرف بتواند با تمام تنظیمات، متغیرهای محیطی و خدمات هم در محیط آزمایش و هم در تولید بدون بازسازی کار کند.

2. برای به روز رسانی یک اپلیکیشن از طریق Helm باید نسخه آن را مشخص کنید. ما باطن، فرانت اند را می سازیم و برنامه را به روز می کنیم - اینها سه کار متفاوت هستند، بنابراین مهم است که از نسخه یکسان برنامه در همه جا استفاده کنید. برای این کار، از داده‌های تاریخچه Git استفاده می‌کنیم، زیرا پیکربندی کلاستر K8S و برنامه‌های ما در همان مخزن Git هستند.

ما نسخه برنامه را از نتایج اجرای دستور دریافت می کنیم
git describe --tags --abbrev=7.

4. استقرار خودکار تمام تغییرات در محیط آزمایش (UAT)

مرحله بعدی در این اسکریپت ساخت، به روز رسانی خودکار کلاستر K8S است. این به شرطی رخ می دهد که کل برنامه ساخته شده باشد و تمام مصنوعات در رجیستری Docker منتشر شده باشند. پس از این، به روز رسانی محیط تست شروع می شود.

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

ما پیکربندی خوشه K8S را همراه با مونتاژ ارائه می کنیم. بنابراین، گام بعدی این است که آن را به روز کنید: configMaps، استقرار، سرویس ها، رازها و هر پیکربندی K8S دیگری که ما تغییر داده ایم.

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

5. استقرار خودکار تمام تغییرات به Prod

برای استقرار یک به روز رسانی در محیط تولید، فقط باید روی یک دکمه در GitLab کلیک کنید - و کانتینرها بلافاصله به محیط تولید تحویل داده می شوند.

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

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

سخت‌ترین کار این بود که تمام سرویس‌ها و متغیرهای مورد استفاده را که به محیط بستگی دارند، پارامتر کنیم و آنها را به متغیرهای محیطی و توصیف-پیکربندی پارامترهای محیط برای Helm ترجمه کنیم.

تنظیمات برنامه از متغیرهای محیطی استفاده می کنند. مقادیر آنها در کانتینرها با استفاده از نقشه پیکربندی K8S تنظیم می شود که با استفاده از الگوهای Go قالب بندی می شود. به عنوان مثال، تنظیم یک متغیر محیطی برای نام دامنه می تواند به صورت زیر انجام شود:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – این متغیر نام محیط (prod، stage، UAT) را ذخیره می کند.
.Values.app.properties.app_external_domain – در این متغیر دامنه مورد نظر را در فایل .Values.yaml قرار می دهیم

هنگام به روز رسانی یک برنامه، Helm یک فایل configmap.yaml از قالب ها ایجاد می کند و مقدار APP_EXTERNAL_DOMAIN را بسته به محیطی که به روز رسانی برنامه در آن شروع می شود، با مقدار دلخواه پر می کند. این متغیر قبلاً در ظرف تنظیم شده است. از طریق برنامه قابل دسترسی است، بنابراین هر محیط برنامه مقدار متفاوتی برای این متغیر خواهد داشت.

اخیراً، پشتیبانی K8S در Spring Cloud ظاهر شد، از جمله کار با configMaps: بهار ابر کوبرنتس. در حالی که پروژه به طور جدی در حال توسعه و تغییر است، ما نمی توانیم از آن در تولید استفاده کنیم. اما ما به طور فعال وضعیت آن را نظارت می کنیم و از آن در تنظیمات DEV استفاده می کنیم. به محض تثبیت، از استفاده از متغیرهای محیطی به آن تغییر می کنیم.

در کل

بنابراین، Continuous Deployment پیکربندی شده و کار می کند. همه به روز رسانی ها با یک ضربه کلید انجام می شود. تحویل تغییرات در محیط محصول به صورت خودکار انجام می شود. و مهمتر از همه، به روز رسانی سیستم را متوقف نمی کند.

برنامه های آینده: انتقال خودکار پایگاه داده

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

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

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

ما قصد داریم انتقال پایگاه داده از طریق کار K8S را خودکار کنیم و آن را در فرآیند CD ادغام کنیم. و ما قطعا این تجربه را در هابره به اشتراک خواهیم گذاشت.

منبع: www.habr.com