تمرینات تحویل مداوم با Docker (بررسی و ویدیو)

ما وبلاگ خود را با انتشارات بر اساس آخرین صحبت های مدیر فنی خود شروع خواهیم کرد منقطع (دیمیتری استولیاروف). همه آنها در سال 2016 در رویدادهای حرفه ای مختلف برگزار شدند و به موضوع DevOps و Docker اختصاص داشتند. ما قبلاً یک ویدیو از جلسه داکر مسکو در دفتر Badoo داریم منتشر شده برخط. مقالات جدید با مقالاتی همراه خواهند شد که ماهیت گزارش ها را بیان می کنند. بنابراین…

31 مه در کنفرانس RootConf 2016، که به عنوان بخشی از جشنواره "تکنولوژی های اینترنت روسیه" (RIT++ 2016) برگزار شد، بخش "استقرار و استقرار مستمر" با گزارش "بهترین شیوه های تحویل مداوم با داکر" افتتاح شد. بهترین روش‌ها را برای ایجاد فرآیند تحویل مستمر (CD) با استفاده از Docker و سایر محصولات منبع باز خلاصه و نظام‌مند کرد. ما با این راه حل ها در تولید کار می کنیم که به ما امکان می دهد به تجربه عملی تکیه کنیم.

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

تحویل مداوم با Docker

تحت تحویل مداوم ما زنجیره ای از رویدادها را درک می کنیم که در نتیجه کد برنامه از مخزن Git ابتدا به تولید می رسد و سپس در بایگانی قرار می گیرد. او شبیه این است: Git → Build → Test → Release → Operate.

بیشتر گزارش به مرحله ساخت (مونتاژ برنامه) اختصاص دارد و موضوعات انتشار و عملکرد به طور مختصر مورد بررسی قرار می گیرند. ما در مورد مشکلات و الگوهایی صحبت خواهیم کرد که به شما امکان می دهد آنها را حل کنید و پیاده سازی های خاص این الگوها ممکن است متفاوت باشد.

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

الگوی عرضه اصلی

بنابراین، هنگامی که ما نسخه های جدید برنامه را ارائه می کنیم، مطمئناً با آن مواجه می شویم مشکل خرابی، در هنگام تعویض سرور تولید ایجاد می شود. ترافیک از نسخه قدیمی برنامه به نسخه جدید نمی تواند فوراً تغییر کند: ابتدا باید مطمئن شویم که نسخه جدید نه تنها با موفقیت بارگیری شده است، بلکه "گرم شده است" (یعنی کاملاً آماده ارائه درخواست ها).

بنابراین، برای مدتی هر دو نسخه برنامه (قدیمی و جدید) به طور همزمان کار خواهند کرد. که به طور خودکار منجر به تضاد منابع مشترک: شبکه، سیستم فایل، IPC و غیره با Docker، این مشکل به راحتی با اجرای نسخه های مختلف برنامه در کانتینرهای جداگانه حل می شود، که جداسازی منابع در همان میزبان (سرور/ماشین مجازی) تضمین شده است. البته، شما می توانید با برخی از ترفندها بدون عایق کاری کنار بیایید، اما اگر یک ابزار آماده و راحت وجود دارد، دلیل مخالف وجود دارد - از آن غافل نشوید.

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

بیایید تعمیم دهیم الگوی عرضه اصلی نسخه های جدید با در نظر گرفتن عوامل زیر:

1. در ابتدا، نسخه قدیمی برنامه در اولین کانتینر اجرا می شود.
2. سپس نسخه جدید در ظرف دوم ریخته شده و "گرم می شود". قابل توجه است که خود این نسخه جدید ممکن است نه تنها کد برنامه به روز شده، بلکه هر یک از وابستگی های آن و همچنین اجزای سیستم را نیز داشته باشد (به عنوان مثال، نسخه جدید OpenSSL یا کل توزیع).
3. هنگامی که نسخه جدید به طور کامل برای ارائه درخواست ها آماده است، ترافیک از اولین کانتینر به کانتینر دوم تغییر می کند.
4. نسخه قدیمی اکنون می تواند متوقف شود.

این رویکرد استقرار نسخه های مختلف برنامه در کانتینرهای جداگانه راحتی دیگری را فراهم می کند - برگشت سریع به نسخه قدیمی (پس از همه، کافی است ترافیک را به ظرف مورد نظر تغییر دهید).

اولین توصیه نهایی به نظر چیزی است که حتی کاپیتان هم نمی تواند ایرادی در آن پیدا کند:[هنگام سازماندهی تحویل مداوم با داکر] از Docker استفاده کنید [و درک کنید که چه چیزی می دهد]" به یاد داشته باشید، این یک گلوله نقره ای نیست که هر مشکلی را حل می کند، بلکه ابزاری است که پایه و اساس فوق العاده ای را فراهم می کند.

تکرارپذیری

منظور ما از «تکرارپذیری» مجموعه کلی از مشکلاتی است که هنگام اجرای برنامه‌ها با آن مواجه می‌شویم. ما در مورد چنین مواردی صحبت می کنیم:

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

ماهیت کلی آنها در این واقعیت خلاصه می شود که انطباق کامل با محیط های مورد استفاده (و همچنین عدم وجود عامل انسانی) ضروری است. چگونه می توانیم تکرارپذیری را تضمین کنیم؟ تصاویر داکر را بسازید بر اساس کد از Git، و سپس از آنها برای هر کاری استفاده کنید: در سایت های آزمایشی، در تولید، در ماشین های محلی برنامه نویسان ... در عین حال، مهم است که اقدامات انجام شده را به حداقل برسانید. پس از مونتاژ تصویر: هر چه ساده تر باشد، احتمال خطا کمتر است.

زیرساخت کد است

اگر الزامات زیرساخت (در دسترس بودن نرم افزار سرور، نسخه آن، و غیره) رسمی و "برنامه ریزی" نشده باشند، در این صورت عرضه هر به روز رسانی برنامه می تواند عواقب فاجعه باری به همراه داشته باشد. به عنوان مثال، در مرحله‌بندی شما قبلاً به PHP 7.0 تغییر داده‌اید و کد را بر اساس آن بازنویسی کرده‌اید - سپس ظاهر آن در تولید با برخی از PHP قدیمی (5.5) مطمئناً کسی را شگفت‌زده خواهد کرد. ممکن است تغییر عمده در نسخه مترجم را فراموش نکنید، اما "شیطان در جزئیات است": شگفتی ممکن است در یک به روز رسانی جزئی از هر وابستگی باشد.

یک رویکرد برای حل این مشکل به عنوان شناخته شده است IaC (زیرساخت به عنوان کد، زیرساخت به عنوان کد) و شامل ذخیره زیرساخت مورد نیاز همراه با کد برنامه است. با استفاده از آن، توسعه دهندگان و متخصصان DevOps می توانند با همان مخزن برنامه Git کار کنند، اما در قسمت های مختلف آن. از این کد، یک تصویر Docker در Git ایجاد می شود که در آن برنامه با در نظر گرفتن تمام مشخصات زیرساخت مستقر می شود. به عبارت ساده، اسکریپت ها (قوانین) برای مونتاژ تصاویر باید در یک مخزن با کد منبع قرار گرفته و با هم ادغام شوند.

در مورد معماری برنامه چندلایه - به عنوان مثال، nginx وجود دارد که در مقابل برنامه‌ای قرار می‌گیرد که قبلاً در یک ظرف Docker در حال اجرا است - تصاویر Docker باید از کد موجود در Git برای هر لایه ایجاد شوند. سپس تصویر اول شامل یک برنامه کاربردی با یک مفسر و سایر وابستگی‌های "بسته" است و تصویر دوم حاوی nginx بالادستی است.

تصاویر داکر، ارتباط با Git

ما تمام تصاویر Docker جمع آوری شده از Git را به دو دسته تقسیم می کنیم: موقت و انتشار. تصاویر موقت با نام شاخه در Git برچسب گذاری شده است، می تواند توسط commit بعدی بازنویسی شود و فقط برای پیش نمایش (نه برای تولید) منتشر می شود. این تفاوت اصلی آنها با نسخه‌های انتشار است: شما هرگز نمی‌دانید کدام commit خاص در آنها وجود دارد.

جمع‌آوری در تصاویر موقت منطقی است: شاخه اصلی (شما می‌توانید به طور خودکار آن را در یک سایت جداگانه قرار دهید تا دائماً نسخه فعلی Master را ببینید)، شاخه‌های منتشر شده، شاخه‌هایی از نوآوری‌های خاص.

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

dapp

هر چیزی که توضیح داده شده است (تولید، مونتاژ تصویر، نگهداری بعدی) را می توان به طور مستقل با استفاده از اسکریپت های Bash و سایر ابزارهای "بداهه" پیاده سازی کرد. اما اگر این کار را انجام دهید، در برخی مواقع پیاده سازی منجر به پیچیدگی زیاد و قابلیت کنترل ضعیف می شود. با درک این موضوع، ما آمدیم تا ابزار تخصصی گردش کار خود را برای ساختن CI/CD ایجاد کنیم - dapp.

کد منبع آن به زبان روبی، متن باز نوشته شده و در آن منتشر شده است GitHub. متأسفانه در حال حاضر مستندسازی ضعیف ترین نقطه ابزار است، اما ما روی آن کار می کنیم. و ما بیش از یک بار در مورد دپ خواهیم نوشت و صحبت خواهیم کرد، زیرا ... ما صمیمانه نمی‌توانیم منتظر بمانیم تا قابلیت‌های آن را با کل جامعه علاقه‌مند به اشتراک بگذاریم، اما در عین حال، مسائل و درخواست‌های خود را ارسال کنید و/یا توسعه پروژه را در GitHub دنبال کنید.

به روز شده در 13 آگوست 2019: در حال حاضر یک پروژه dapp تغییر نام داد به ورف، کد آن به طور کامل در Go بازنویسی شده است و مستندات آن به طور قابل توجهی بهبود یافته است.

کوبرنیتس

یکی دیگر از ابزارهای متن باز آماده که قبلاً در محیط حرفه ای به رسمیت شناخته شده است کوبرنیتسیک خوشه مدیریت Docker. موضوع استفاده از آن در عملیات پروژه های ساخته شده بر روی داکر خارج از محدوده گزارش است، بنابراین ارائه به مروری بر برخی ویژگی های جالب محدود می شود.

برای عرضه، Kubernetes ارائه می دهد:

• کاوشگر آمادگی - بررسی آمادگی نسخه جدید برنامه (برای تغییر ترافیک به آن).
• به روز رسانی نورد - به روز رسانی متوالی تصویر در یک دسته از ظروف (خاموش شدن، به روز رسانی، آماده سازی برای راه اندازی، تعویض ترافیک).
• به روز رسانی همزمان - به روز رسانی یک تصویر در یک خوشه با رویکردی متفاوت: ابتدا در نیمی از ظروف، سپس در بقیه.
• انتشارات قناری - راه اندازی یک تصویر جدید در تعداد محدود (کم) ظروف برای نظارت بر ناهنجاری ها.

از آنجایی که Continuous Delivery نه تنها انتشار یک نسخه جدید است، Kubernetes دارای تعدادی قابلیت برای نگهداری زیرساخت بعدی است: نظارت داخلی و ورود به سیستم برای همه کانتینرها، مقیاس بندی خودکار، و غیره. پیاده سازی در فرآیندهای شما

توصیه های نهایی

1. از Docker استفاده کنید.
2. برای تمام نیازهای خود تصاویر Docker از برنامه ها ایجاد کنید.
3. از اصل "زیرساخت کد است" پیروی کنید.
4. Git را به Docker پیوند دهید.
5. ترتیب عرضه را تنظیم کنید.
6. از یک پلت فرم آماده (Kubernetes یا دیگری) استفاده کنید.

فیلم ها و اسلایدها

ویدئویی از اجرا (حدود یک ساعت) در یوتیوب منتشر شد (این گزارش از دقیقه 5 شروع می شود - برای پخش از این لحظه لینک را دنبال کنید).

ارائه گزارش:

PS

گزارش های دیگر در مورد موضوع در وبلاگ ما:

• «werf - ابزار ما برای CI / CD در Kubernetes (نمایش کلی و گزارش تصویری)» (دیمیتری استولیاروف؛ 27 مه 2019 در DevOpsConf);
• «پایگاه های داده و Kubernetes» (دیمیتری استولیاروف؛ 8 نوامبر 2018 در HighLoad++);
• «بهترین تمرینات CI/CD با Kubernetes و GitLab» (دیمیتری استولیاروف؛ 7 نوامبر 2017 در HighLoad++);
• «تجربه ما با Kubernetes در پروژه های کوچک» (دیمیتری استولیاروف؛ 6 ژوئن 2017 در RootConf).

منبع: www.habr.com