انواع استراتژی های استقرار -Deployment Strategies
مقدمه ای بر استراتژی های استقرار: Blue-Green, Canary و موارد دیگر
در عصر فناوری اطلاعات و ارتباطات، استقرار نرمافزارها و سامانههای مختلف برای شرکتها و سازمانها بسیار حائز اهمیت است. استقرار نرمافزار به معنی انتقال نسخههای جدید یک سامانه به محیط تولید است و بسیاری از شرکتها برای این کار از استراتژیهای مختلفی استفاده میکنند. در این مقاله به بررسی انواع استراتژی استقرار مثل blue-green، canary و موارد دیگر پرداخته خواهد شد.
استراتژی های استقرار – Deployment Strategies
استراتژیهای استقرار، شیوههایی هستند که برای تغییر یا ارتقاء یک نمونه در حال اجرا از یک برنامه استفاده میشوند. بخش های بعدی شش استراتژی استقرار را توضیح خواهند داد. بیایید با بحث در مورد استقرار اساسی شروع کنیم.
The Basic Deployment
در یک استقرار اولیه، تمام گرهها در یک محیط هدف به طور همزمان با یک سرویس جدید یا نسخه مصنوع بهروزرسانی میشوند. به همین دلیل، استقرارهای اولیه ضد قطع نیستند و فرآیندها یا استراتژیهای بازگشت را کاهش میدهند. از بین همه استراتژیهای استقرار مشترک، این پرخطرترین است.
مزایا:
مزایای این استراتژی این است که ساده، سریع و ارزان است. اگر
1) سرویس برنامه شما برای کسب و کار، مأموریت یا درآمد حیاتی نیست،
یا 2) استقرار شما در یک محیط پایین تر، در ساعات غیرفعال یا با سرویسی است که استفاده نمی شود، از این استراتژی استفاده کنید.
معایب:
از بین همه استراتژیهای استقرار مشترک، این استراتژی خطرناکترین است و در بهترین شیوهها قرار نمیگیرد. استقرارهای اولیه outage-proof نیستند و امکان بازگشت آسان را فراهم نمی کنند. استقرار چند سرویس در یک استقرار چند سرویس، تمام گرهها در یک محیط هدف با چندین سرویس جدید به طور همزمان به روز میشوند. این استراتژی برای سرویسهای برنامهای استفاده میشود که وابستگی به سرویس یا نسخه دارند، یا اگر در حال استفاده از ساعات غیرفعال در منابعی هستید که استفاده نمیشوند.
The Multi-Service Deployment
در یک استقرار چند سرویس، تمام گرهها در یک محیط هدف با چندین سرویس جدید به طور همزمان به روز میشوند. این استراتژی برای سرویسهای برنامهای استفاده میشود که وابستگی به سرویس یا نسخه دارند، یا اگر در حال استفاده از ساعات غیرفعال در منابعی هستید که استفاده نمیشوند.
مزایا:
استقرار چند سرویس ساده، سریع، ارزان هستند و به اندازه یک استقرار اولیه در معرض خطر نیستند.
معایب:
استقرار چند سرویس به کندی انجام می شود و outage-proof نیست. استفاده از این استراتژی استقرار همچنین منجر به مشکل در مدیریت، آزمایش و تأیید تمام وابستگیهای سرویس میشود.
Rolling Deployment
در این روش، نسخه جدید سامانه به صورت تدریجی بر روی تمام سرورها استقرار داده میشود. در هر مرحله، تعدادی از سرورها به نسخه جدید ارتقاء مییابند و ترافیک به آنها هدایت میشود. در صورت بروز هرگونه مشکل، ترافیک به سرورهای قبلی بازگردانده میشود.
مزایا:
مزایای استقرار چرخشی این است که عقب انداختن آن نسبتاً ساده است، خطر کمتری نسبت به استقرار اولیه دارد و پیاده سازی آن ساده است.
معایب:
از آنجایی که گرهها به صورت دستهای بهروزرسانی میشوند، استقرار رول به خدماتی برای پشتیبانی از نسخههای جدید و قدیمی یک مصنوع نیاز دارد. تأیید استقرار یک برنامه در هر تغییر تدریجی نیز این استقرار را کند می کند.
استراتژی Blue-Green
در این روش، دو محیط تولید (blue و green) برای سامانه ایجاد میشود. در ابتدا، نسخه جدید سامانه در محیط green استقرار میشود و پس از تست و اطمینان از عملکرد صحیح، ترافیک به سمت green هدایت میشود. در همین حال، نسخه قبلی سامانه در محیط blue باقی میماند. در صورت بروز هرگونه مشکل در نسخه جدید، ترافیک به سمت blue هدایت میشود و نسخه جدید از سامانه در محیط green پیشبینی نشده و بدون اختلال استقرار داده میشود.
استقرار سبز-آبی یک استراتژی استقرار است که از دو محیط یکسان، یک محیط «آبی» (با نام مستعار مرحلهبندی) و یک محیط «سبز» (معروف به تولید) با نسخههای مختلف یک برنامه یا سرویس استفاده میکند. تضمین کیفیت و تست پذیرش کاربر معمولاً در محیط آبی انجام می شود که میزبان نسخه ها یا تغییرات جدید است. هنگامی که تغییرات جدید در محیط آبی آزمایش شده و پذیرفته شده اند، ترافیک کاربر از محیط سبز به محیط آبی منتقل می شود. پس از موفقیت آمیز بودن استقرار، می توانید به محیط جدید بروید.
مزایا:
یکی از مزایای استقرار سبز-آبی این است که ساده، سریع، به خوبی درک شده و اجرای آن آسان است. بازگشت مجدد نیز ساده است، زیرا در صورت بروز هر گونه مشکلی می توانید به سادگی ترافیک را به محیط قدیمی برگردانید. بنابراین استقرار سبز-آبی در مقایسه با سایر استراتژیهای استقرار خطرناک نیست.
معایب:
هزینه یک نقطه ضعف برای استقرار سبز-آبی است. تکرار یک محیط تولید می تواند پیچیده و پرهزینه باشد، به خصوص در هنگام کار با میکروسرویس ها. تضمین کیفیت و آزمایش پذیرش کاربر ممکن است همه ناهنجاری ها یا رگرسیون ها را شناسایی نکند، بنابراین جابجایی همه ترافیک کاربر به یکباره می تواند خطراتی را ایجاد کند. یک قطع یا مشکل همچنین میتواند تأثیر تجاری گستردهای را قبل از شروع بازگشت داشته باشد و بسته به اجرا، تراکنشهای کاربر در پرواز ممکن است با تغییر ترافیک از بین بروند.
استراتژی Canary
استقرار Canary یک استراتژی استقرار است که یک برنامه یا سرویس را به صورت تدریجی برای زیرمجموعه ای از کاربران منتشر می کند. تمام زیرساخت ها در یک محیط هدف در مراحل کوچک به روز می شوند (به عنوان مثال: 2٪، 25٪، 75٪، 100٪). انجام Canary در مقایسه با سایر استراتژیهای استقرار، به دلیل این کنترل، کمترین خطر را دارد.
در این روش، نسخه جدید سامانه به صورت تدریجی بر روی یک سرور کوچک و در کنار نسخه قبلی سامانه استقرار داده میشود. این سرور به عنوان canary server شناخته میشود و ترافیک به صورت تدریجی به آن هدایت میشود. در صورت عدم وجود مشکل در نسخه جدید، ترافیک به صورت تدریجی به آن هدایت میشود و در صورت بروز هرگونه مشکل، ترافیک به نسخه قبلی سامانه هدایت میشود.
مزایا:
استقرار Canary به سازمان ها این امکان را می دهد که در تولید با کاربران واقعی آزمایش کنند و موارد استفاده و نسخه های مختلف خدمات را در کنار یکدیگر مقایسه کنند. این ارزانتر از استقرار سبز-آبی است زیرا به دو محیط تولید نیاز ندارد. و در نهایت، راه اندازی بازگشت به نسخه قبلی یک برنامه سریع و ایمن است.
معایب:
معایب استقرار Canary شامل آزمایش در تولید و اجرای مورد نیاز است. نوشتن فیلمنامه رهاسازی Canary می تواند پیچیده باشد: تأیید یا آزمایش دستی می تواند زمان بر باشد و نظارت و ابزار دقیق مورد نیاز برای آزمایش در تولید ممکن است مستلزم تحقیقات بیشتری باشد.
استراتژی A/B Testing
در تست A/B، نسخههای مختلف یک سرویس بهطور همزمان بهعنوان «آزمایشها» در یک محیط یکسان برای یک دوره زمانی اجرا میشوند. آزمایشها یا با تغییر پرچمهای ویژگی، ابزارهای آزمایش A/B، یا از طریق استقرار خدمات متمایز کنترل میشوند. این مسئولیت مالک آزمایش است که نحوه هدایت ترافیک کاربر به هر آزمایش و نسخه یک برنامه کاربردی را تعیین کند. معمولاً ترافیک کاربر بر اساس قوانین خاص یا جمعیت شناسی کاربر جهت انجام اندازه گیری ها و مقایسه بین نسخه های سرویس هدایت می شود. سپس محیط های هدف را می توان با نسخه سرویس بهینه به روز کرد. بزرگترین تفاوت بین تست A/B و سایر استراتژی های استقرار این است که تست A/B در درجه اول بر آزمایش و اکتشاف متمرکز است. در حالی که سایر استراتژیهای استقرار، بسیاری از نسخههای یک سرویس را با هدف فوری بهروزرسانی همه گرهها با یک نسخه خاص، در محیطی مستقر میکنند، آزمایش A/B در مورد آزمایش ایدههای متعدد در مقابل استقرار یک ایده آزمایش شده خاص است.
در این روش، دو نسخه از سامانه (A و B) به صورت همزمان استقرار داده میشود و ترافیک به صورت تصادفی به هر دو نسخه هدایت میشود. در این روش، نسخه B شامل تغییراتی است که باید تست شود. در پایان، نسخهای که عملکرد بهتری داشته باشد، به عنوان نسخه پایدار انتخاب میشود.
مزایا:
تست A/B یک روش استاندارد، آسان و ارزان برای آزمایش ویژگی های جدید در تولید است. و خوشبختانه امروزه ابزارهای زیادی برای کمک به فعال کردن تست A/B وجود دارد.
معایب:
معایب تست A/B شامل ماهیت تجربی مورد استفاده آن است. آزمایشها گاهی اوقات میتوانند اپلیکیشن، سرویس یا تجربه کاربر را خراب کنند. در نهایت، اسکریپت نویسی یا خودکار کردن تست های AB نیز می تواند پیچیده باشد.
از کدام استراتژی استقرار باید استفاده کنم؟
اکنون که تکنیک های مختلف استقرار را می شناسیم، ممکن است یک سوال رایج این باشد که از کدام استراتژی استقرار استفاده کنم؟ پاسخ به نوع اپلیکیشن شما و محیط هدف شما بستگی دارد، اکثر تیم ها از استقرار سبز-آبی یا Canary برای برنامه های کاربردی وب حیاتی استفاده می کنند. مشتریان هنگام مهاجرت از استراتژی استقرار سبز-آبی به استراتژی استقرار Canary ، تأثیر بسیار کمی دارند. همچنین معمول است که تیم ها استراتژی خود را بر اساس ترکیب استراتژی هایی که در این پست وبلاگ به اشتراک گذاشته ایم ایجاد کنند. به عنوان مثال، برخی از مشتریان استقرار Canary چند سرویس را انجام می دهند.
حذف استقرار پس از ساعت کاری
ارائه نرم افزار چالش برانگیز است. هر کسی که یک داستان ترسناک استقرار دارد می تواند این را تأیید کند. یکی از راههایی که میتوانیم زحمت را حذف کنیم و زمان و تلاش خود را در جایی که واقعاً مهم است صرف کنیم، استفاده از برخی استراتژیها و شیوههای استقرار است که میتواند به عملیاتی کردن خدمات ما کمک کند.
برخی از شیوه ها یا استانداردهایی که باید اجرا شوند عبارتند از:
چک لیست های استقرار ویژه خدمات یکپارچه سازی مداوم (CI) و تحویل مداوم (CD)
محیط های کاملاً تعریف شده و درک شده
ساخت ابزار اتوماسیون
ابزارهای مدیریت پیکربندی
کانال های ارتباطی مانند Slack
سرویس های call manager برای پاسخگویی به تماس یا حادثه
برگشت های خودکار – rollbacks
بخش خوبی از این شیوهها میتواند به خرابی سرور یا سرویس، اشکالات نرمافزار، بازخورد مداوم و استقرار برنامههای جدید کمک کند.
