در دسترس قرار دادن ویژگی ها یا خدمات جدید برای گروه کوچکی از کاربران یک استراتژی توسعه خوب برای کاهش ریسک است.
پارادایم استقرار توسعه، آزمایش، تولید و بازیابی بلایا از روزهای قبل از ابر، قبل از میکروسرویس ها هنوز در ذهن من باقی مانده است. در آن روزها، خرید، پیکربندی و نگهداری زیرساخت گران و پیچیده بود، بنابراین بعید بود که تیم عملیات مرکز داده را وادار به ایجاد محیطهای بیشتر و انعطافپذیریهای استقرار کنید. طبق استانداردهای امروزی، فرکانسهای استقرار پایین بود، بنابراین تیمهای توسعه چابک راههایی برای اکتفا به زیرساختهای موجود پیدا کردند.
امروزه، سازمانهای توسعهدهنده از CI/CD (ادغام پیوسته و تحویل مداوم) برای تحویل خودکار، زیرساخت بهعنوان کد برای پیکربندی زیرساخت، Kubernetes برای محفظه کردن محیط ها، آزمایش مداوم برای بهبود کیفیت، و AIops a> برای متمرکز کردن هشدارهای نظارت و مشاهده. این شیوهها افزایش فرکانس استقرار را در عین به حداقل رساندن خطرات امنیتی، عملکرد و قابلیت اطمینان ناشی از تغییرات ممکن میسازد.
اما زمانی که باید ریسک را کاهش دهید و انتشارات را بر اساس آنچه در حال تغییر است و افرادی که به تغییرات دسترسی دارند کنترل کنید، به تکنیکهای بیشتری برای پیکربندی و مدیریت برنامه یا استقرار نیاز دارید.
خطوط لوله انتشار به کنترلهای انعطافپذیر و گزینههای استقرار نیاز دارند
یکی از راههای ایجاد پیادهسازیهای کنترلشده، استفاده از پرچمهای ویژگی برای تغییر وضعیت، تست A/B، و بخشبندی دسترسی کاربر به ویژگیها است. تیم Devops میتواند از پرچمهای ویژگی برای تأیید اعتبار ویژگیهای مهندسی مجدد هنگام انتقال برنامهها به فضای ابری یا بازسازی برنامههای یکپارچه به میکروسرویسها استفاده کند.
پرچمهای ویژگی برای تیمهای توسعه و مدیران محصول که میخواهند کنترل کنند چه کسی چه قابلیتهایی را در یک برنامه یا میکروسرویس میبیند مفید است. اما گاهی اوقات، تیمهای عملیاتی توسعه یا فناوری اطلاعات به انعطافپذیری در مدیریت استقرارها و کنترل نسخههای متعدد یک برنامه کاربردی در حال تولید نیاز دارند. چند مثال:
- تأیید اعتبار برنامهها و ریزسرویسها هنگام وصله یا ارتقاء اجزای حیاتی سیستم مانند سیستمعاملها، پایگاههای داده یا میانافزار
- آزمایش برنامهها و سرویسها هنگام استقرار در چندین ابر
- نظارت بر تجربیات کاربر پس از انتشار نسخههای جدید مدلهای یادگیری ماشین
چندین راهبردهای استقرار مختلف برای میکروسرویس ها و برنامه های کاربردی ابری وجود دارد. در روزهای اولیه توسعه برنامههای کاربردی برای ابر، ما از استقرار سبز-آبی استفاده میکردیم که در آن دو محیط تولید وجود داشت: یک محیط سبز زنده و دیگری آبی در حالت آماده به کار. استقرار به محیط آبی رفت، و سپس بار متعادل کننده ها برش را کنترل کردند، و به طور موثر محیط آبی را با آخرین استقرار زنده و محیط سبز جدید را نسخه پشتیبان ساختند.
استقرارهای سبز-آبی در به حداقل رساندن زمان از کار افتادگی در طول استقرار مؤثر بودند و در صورت لزوم گزینه بازگشت را فراهم کردند. اما آنها ناکارآمد بودند زیرا به زیرساخت اختصاصی برای محیط آبی نیاز داشتند.
استقرار قناری چیست؟
تکامل استقرار سبز-آبی شامل استقرار یا رهاسازی قناری است. من با روهان گوپتا، مدیر ارشد محصول در Harness، در مورد چگونگی تعریف او از قناری صحبت کردم. او میگوید: «آزادسازی قناری یک استراتژی استقرار است که یک برنامه یا سرویس را بهصورت تدریجی برای زیرمجموعهای از کاربران منتشر میکند و دامنه، تأثیر و خطر استقرار مصنوعات نرمافزاری جدید را برای تولید کاهش میدهد. تمام زیرساخت ها در یک محیط هدف در فازهای کوچک به روز می شوند (به عنوان مثال، با افزایش ۲٪، ۲۵٪، ۷۵٪، ۱۰۰٪ بار ترافیک)، و به دلیل این کنترل، رهاسازی قناری کم خطرترین رویکرد است. در مقایسه با سایر استراتژیهای استقرار.”
راههای مختلفی برای پیادهسازی استقرار قناری با مجازیسازی و فناوریهای ابری و Spinnaker وجود دارد. /a> یکی از ابزارهای منبع باز است که از این قابلیت پشتیبانی می کند. رویکرد تعمیمیافته دارای یک محیط تولید، یک نمونه تولید پایه کوچکتر و یک محیط قناری برای استقرار جدید است. مسیریابی هوشمند ترافیک به این محیطها را به صورت پویا کنترل میکند و قوانین تعیین میکنند که آیا استقرار قناری جدید معیارهای پذیرش را دارد یا نه.
استقرار قناری یکی از رویکردهای دستیابی به استقرار مداوم است که در آن خطوط لوله CI/CD همچنین باعث استقرار در محیط های تولید می شود. استقرار مستمر به فرآیند توسعه نرمافزار مستحکم، روشهای قابل مشاهده قوی، خطوط لوله CI/CD قابل اعتماد، قابلیتهای اتوماسیون تست قوی، نظارت جامع AIops، و روشهای استقرار هوشمند تولید نیاز دارد، که در آن جا استقرار قناری است.
چگونه تیمهای devops میتوانند از استقرار قناری استفاده کنند
John Kodumal، CTO و یکی از بنیانگذاران LaunchDarkly، نحوه استفاده تیمهای توسعهدهنده از ویژگی پرچمگذاری با استقرار قناری را به اشتراک میگذارد. او میگوید: «آزادسازی قناری زمانی است که ویژگیهای نرمافزار جدیدی را قبل از انتشار گستردهتر در اختیار تعداد محدودی از کاربران قرار میدهید. هدف آن ارائه یک تجربه نرم افزاری بهتر برای کاربران با ریسک کلی کمتر است. نسخههای قناری در ارائه یک بررسی سلامت عمومی یک نسخه مفید هستند و به طور ایدهآل با پرچمهای ویژگی کار میکنند که به لایه برنامه ضربه میزنند و میتوانند تغییرات فردی را جدا کنند.”
گوپتا میگوید یکی از دلایل اصلی استفاده از استقرار قناری، مقایسه نتایج انتشار چندگانه است. او میگوید: «استقرار قناری به سازمانها این امکان را میدهد که در تولید با کاربران واقعی آزمایش کنند و از موارد استفاده کنند و نسخههای خدمات مختلف را در کنار یکدیگر مقایسه کنند. ارزانتر از استقرار سبز-آبی است زیرا به دو محیط تولید نیاز ندارد. همچنین، راه اندازی بازگشت به نسخه قبلی یک برنامه سریع و ایمن است.»
گوپتا همچنین تصدیق می کند که انتشار قناری اغلب نیاز به معماری یک راه حل و اسکریپت پیشرفته دارد. او می گوید: «معایب استقرار قناری شامل آزمایش در تولید و تخصص مورد نیاز برای اجرای این الگوی استقرار است. نوشتن فیلمنامه انتشار قناری پیچیده است زیرا تأیید یا آزمایش دستی زمان می برد و نظارت و ابزار دقیق مورد نیاز برای آزمایش در تولید ممکن است مستلزم تلاش بیشتری باشد. یک راهحل خوب CD باید قالبها و اتوماسیونی را برای حل همه این چالشها ارائه دهد.»
اگر در حال توسعه برنامهها و ریزسرویسهایی با قابلیت اطمینان و مقیاسپذیری پایینتر هستید، استقرار Canary ممکن است بیش از حد باشد. اما برای تیمهای توسعهدهندهای که به دنبال استقرار مستمر برای تجربههای مشتری با حجم بالا، ماموریتهای حیاتی و میکروسرویسهای وابسته هستند، پس استقرار قناری میتواند یک تمرین توسعهدهنده بازی باشد.
مارگارت فرانسیس، رئیس و مدیر ارشد اجرایی در Armory، موافق است. او میگوید: «توانایی اجرای رهاسازی قناری در مقیاس بسیار مهم است. وقتی کسب و کار شما به در دسترس بودن، کارآمد بودن و قابل پیش بینی بودن سرویس شما بستگی دارد، تحویل تدریجی کد به تولید تضمین می کند که خدمات شما کارآیی داشته باشد و شما می توانید همزمان نوآوری را ارسال کنید. وقتی یک تیم دو نفره دارید و یک برنامه در ماه یک بار پخش می کنید، چندان مهم نیست. اما شرکتهایی که به خدمات دیجیتالی خود وابسته هستند و سازمانهایی با صدها توسعهدهنده که نسخههای روزانه و ساعتی را انجام میدهند باید فرآیند انتشار از نوع قناری را در اولویت قرار دهند. این سازمانها نمیتوانند سرعت نوآوری را با ثبات خدمات قربانی کنند – یا بالعکس.”
زمانی که سرعت، مقیاس و قابلیت اطمینان اهمیت دارد، استقرار مداوم را هدف قرار دهید
همانطور که قبلاً اشاره کردم، استقرار مداوم یک نوار بالا است و به تیمهای توسعهدهنده نیاز دارد که چندین آزمایش بالغ، تحویل خودکار و نظارت داشته باشند. برای بسیاری از مشاغل، برنامهها و خدمات، تحویل مستمر ممکن است کافی باشد، و ممکن است برای پیگیری قابلیتهای استقرار مداوم بسیار پرهزینه یا از نظر فنی پیچیده باشد.
اما هنگام توسعه برنامهها و ریزسرویسهای در مقیاس بزرگ، و اگر هدف انتشار مکرر است، فعال کردن نسخههای قناری یک استراتژی کلیدی برای استقرار نسخههای با کارایی بالا و قابل اعتماد است.
پست های مرتبط
چگونه رهاسازی قناری امکان استقرار مداوم را فراهم می کند
چگونه رهاسازی قناری امکان استقرار مداوم را فراهم می کند
چگونه رهاسازی قناری امکان استقرار مداوم را فراهم می کند