استقرار سبز آبی چیست؟

Deploy Green Green یک مدل انتشار برنامه است که به تدریج ترافیک کاربر را از نسخه قبلی یک برنامه یا میکروسرویس به یک نسخه جدید تقریباً یکسان منتقل می کند - هر دو در حال تولید هستند.

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

در این مدل استقرار مداوم ، خطوطی وجود دارد. همه محیط ها دارای همان نیازهای به موقع یا منابع لازم برای انجام درست فرآیندهای CI/CD مانند Blue Green نیستند. اما بسیاری از برنامه ها برای پشتیبانی از تحویل مداوم تکامل می یابند که شرکت هایی که از آنها حمایت می کنند به صورت دیجیتالی تبدیل می شوند.

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

اینجوری درباره اش فکر کنید. شما یک برنامه ساده و بومی ابر ایجاد کرده اید-یک بازی موبایل که در آن کاربران امتیاز می گیرند که بالن های چند رنگ را که در صفحه نمایش پرواز می کنند ، ضربه می زنند. انتهای بازی توسط میکروسرویسهای مبتنی بر کانتینر پشتیبانی می شود که دستاوردهای بازی ، امتیاز دهی ، مکانیک ، ارتباطات و شناسایی بازیکن را بر عهده دارند.

صدها کاربر پس از انتشار اولیه آن بازی را شروع می کنند. آنها هر دقیقه هزاران معامله را وارد می کنند. تیم DevOps شما را ترغیب کرده است که زودتر و غالباً آزاد شوید ، به همین دلیل شما قصد دارید یک به روزرسانی جزئی را برای میکروسرویس مکانیک منتشر کنید که باعث افزایش اندازه و سرعت بالون قرمز می شود.

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

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

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

استقرار سبز آبی و Kubeetes

Kubeetes با تمام عناصر مرتبط با فرآیند استقرار سبز آبی ، از جمله برنامه های ابر بومی ، میکروسرویس ، ظروف ، ادغام مداوم ، تحویل مداوم ، استقرار مداوم ، SRE و DevOps مناسب است. به عنوان یک بستر منبع باز که به صورت خودکار عملیات کانتینر Linux® را خودکار می کند ، Kubeetes نه تنها به ارکستر ظروف بسته بندی شده برنامه های برنامه های Cloud Native کمک می کند ، بلکه Kubeetes نیز توسط مجموعه ای از الگوهای معماری پشتیبانی می شود که توسعه دهندگان می توانند به جای ایجاد معماری های کاربردی از ابتدا استفاده کنند. بشر

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

چرا کلاه قرمز را انتخاب کنید؟

از آنجا که ما پلت فرم پیشرو Kubeetes - Red Hat® OpenShift - را با قابلیت CI/CD در هسته خود سخت کرده ایم. و ما قبلاً مستندات خطوط فرمان و آرگومان های خط به مرحله را ثبت کرده ایم تا استقرار سبز آبی را در محیط Red Hat OpenShift خود از بین ببریم.

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

بنابراین پیش بروید: کد منبع را در پشت فن آوری های ما بازرسی ، اصلاح و تقویت کنید. با وجود محصولات مورد اعتماد بیش از 90 ٪ از شرکت های Fortune 500 ،* خیلی کم نیست که شما نمی توانید با زیرساخت هایی که بر روی محصولات و فناوری های Red Hat ساخته شده است ، انجام دهید.