استراتژی استقرار نرم‌افزار (Software Deployment Strategy) چیست؟

پیاده‌سازی و استقرار نرم‌افزار، مانند تمام فعالیت‌های دیگر نیاز به فرایندی مشخص دارد تا موفقیت‌آمیز باشد. برای استقرار موفق نرم‌افزار، استراتژی‌های مختلفی وجود دارد که به استراتژی استقرار نرم افزار (Software Deployment Strategy) معروف هستند.

استراتژی‌های استقرار نرم‌افزار، از موضوعات مهم در دواپس است که هم برای تیم توسعه و هم عملیات اهمیت دارد. در این مقاله از بلاگ آسا، قصد داریم ابتدا با تعاریف اولیه استراتژی و استقرار نرم‌افزار آشنا شویم و سپس ترکیب این دو تعریف یعنی استراتژی استقرار نرم‌افزار را بررسی کنیم. با ما همراه باشید.

استراتژی چیست؟

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

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

اگر بخواهیم با دید جامع‌تری به این مفهوم نگاه کنیم، می‌توانیم سه تعریف زیر را در نظر بگیریم:

۱. استراتژی برنامه‌ای جامع برای رسیدن به اهداف در شرایط متغیر است.

۲. استراتژی در واقع الگویی است که در مجموعه تصمیمات ما وجود دارد.

۳. استراتژی به معنای انجام کارها در حالت بهینه و منحصر به فرد است.

استقرار (Deployment) چیست؟

استقرار در لغت به معنی قرار دادن، ایجاد و تثبیت است. در فرایند استقرار، با داشتن برنامه و استفاده از منابع مختلف، می‌خواهیم به هدفی خاص برسیم.

استقرار نرم‌افزار چیست؟

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

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

استراتژی استقرار نرم‌افزار چیست؟

استراتژی استقرار نرم‌افزار (Software Deployment Strategy) فرایندی است که در آن، برنامه و مراحل لازم برای استقرار را مشخص می‌کنیم. این برنامه شامل نحوه استقرار، نیازمندی‌ها، پیکربندی، جزئیات عملکردی و … است.

تا چندین سال قبل، فرایند استقرار به صورت سنتی و با استفاده از سیستم FTP برای انتقال فایل‌ها به سرور صورت می‌گرفت. اما ظهور اپلیکیشن‌های مختلف و نسخه‌های جدیدتر سرور و … باعث تکامل و پیشرفت روش‌های Software Deployment شد.

اهداف استراتژی‌های استقرار نرم‌افزار

تدوین استراتژی استقرار اهداف مختلفی را دنبال می‌کند؛ اما از مهم‌ترین اهداف این استراتژی می‌توانیم به موارد زیر اشاره کنیم:

۱. کاهش یا به صفر رساندن Downtime

۲. کاهش ریسک‌های استقرار

۳. شناسایی مشکلات نسخه‌های جدید در سریع‌ترین زمان بعد از عملیاتی شدن

۴. کاهش ریسک‌های عملیات

۵. بازگشت سریع‌تر به نسخه‌های قبلی (Rollback)

انواع استراتژی استقرار نرم‌افزار 

فرایند Software Deployment دارای چند استراتژی پایه است؛ اما نکته مهم اینجاست که این استراتژی‌ها می‌توانند با هم ترکیب شوند و استراتژی‌های جدید ایجاد کنند. استراتژی‌های پایه استقرار عبارتند از:

• Recreate Deployment Strategy
• Rolling Deployment Strategy

علاوه بر دو مورد پایه، برخی استراتژی‌های پیشرفته‌تر نیز برای استقرار نرم‌افزار استفاده می‌شوند که عبارتند از:

• Canary Deployment Strategy
• Blue-Green Deployment Strategy
• Dark Launch Strategy
• A/B Deployment Strategy
• Immutable Server

در این مقاله روی استراتژی‌های پایه تمرکز می‌کنیم و به یکی از استراتژی‌های پیشرفته که همراه با پایه استفاده می‌شود اشاره می‌کنیم.

Recreate Strategy | Recreate Deployment

این روش یکی از استراتژی‌های پایه Software Deployment است. در استراتژی Recreate Deployment برای بازطراحی و استقرار نرم‌افزار، دقیقا مشابه زمانی عمل می‌کنیم که یک نرم‌افزار برای اولین بار نصب می‌شود؛ یعنی همه چیز باید مرحله به مرحله و از ابتدا اجرا شود.

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

چه زمانی از Recreate Deployment استفاده کنیم؟

• در زمان نیاز به مهاجرت دیتا یا سرور، قبل از انتشار نسخه جدید
• در زمان عدم نیاز همزمان به دو نسخه قدیم و جدید
• در زمان استفاده از RWO Volume بدون قابلیت اشتراک‌گذاری بین چند نسخه

برای مثال، در شکل زیر می‌توانید مراحل این استراتژی را برای محیطی دارای ۳ نود (گره) ببینید.

مرحله اول: قبل از شروع فرایند، ترافیک فعلی به سرور حاوی نسخه قدیمی اپلیکیشن هدایت می‌شود.

مرحله دوم: نودها غیرفعال می‌شوند و ترافیک عملیات به آن‌ها هدایت نمی‌شود. در این مرحله Downtime اتفاق می‌افتد و برنامه به روزرسانی می‌شود.

مرحله سوم: نودها بعد از به روزرسانی مجددا فعال می‌شوند.

Rolling Strategy | Rolling Deployment

یکی دیگر از استراتژی‌های پایه استقرار نرم‌افزار، استراتژی Rolling Deployment است. هدف این استراتژی، کم کردن ریسک استقرار و کاهش هرچه بیشتر Downtime است؛ به همین خاطر یکی از استراتژی‌های مناسب برای محیط‌های عملیاتی است که استقرار در آن‌ها باید بدون اختلال در نرم‌افزار صورت بگیرد.

برای استفاده از این استراتژی، معمولا به محیطی با تعداد نودها (سرورها) زیاد نیاز داریم و برعکس استراتژی Recreate نیازی به سرور مجزا یا محیط متفاوتی نیست؛ با این استراتژی می‌توانیم با استفاده از سرورها و محیط اجرایی فعلی برنامه جدید را مستقر کنیم.

چه زمانی از Rolling Deployment استفاده کنیم ؟

• استقرار و به روزرسانی نرم‌افزار بدون وقفه در عملکرد (Downtime)
• توانایی اجرای همزمان نرم‌افزار با نسخه قدیم و جدید

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

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

روش انجام Rolling Deployment 

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

به همین ترتیب تمام نودها به صورت گروه گروه از دسترس خارج، به روزرسانی و سپس مجدد فعال می‌شوند.

مثال: در شکل زیر می‌توانید مراحل استراتژی Rolling در یک محیط با ۳ سرور و یک روتر (Router) یا Load-Balancer ببینید. این محیط یک محیط عملیاتی است و روتر، وظیفه کنترل و هدایت ترافیک کاربران را دارد.

مرحله صفر: قبل از شروع فرایند، ترافیک به هر سه سرور با نسخه قدیمی اپلیکیشن هدایت می‌شود.

مرحله اول : در این مرحله یکی از نودها (سرورها) از دسترس خارج می‌شود و ترافیک عملیاتی به سمت آن هدایت نمی‌شود. سپس نودی که از مدار خارج شده است، به‌ روزرسانی می‌شود.

مرحله دوم: نودی که به‌روزرسانی شده است مجدد فعال می‌شود و نود دیگری از مدار خارج و به‌روزرسانی می‌شود.

مرحله سوم: مرحله دوم برای تمامی نودهای باقی‌مانده تکرار می‌شود.

مرحله چهارم: در انتهای فرایند، تمامی نودها به فعال می‌شوند و ترافیک به سمت آن‌ها هدایت می‌شود.

معایب استقرار نرم‌افزار به روش‌های قدیمی

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

در طول توسعه و استقرار، ممکن است نیاز به راه‌اندازی سرور جدیدی داشته باشید؛ برای تغییر دیتاسنتر، افزودن سرور برای مقیاس‌پذیری بیشتر، بهبود امنیت و …. اما با روش‌های قدیمی استقرار و تبدیل سرور شما به سرور‌های Snowflake، افزودن سرور جدید بسیار سخت و با ریسک و هزینه بالا خواهد بود.

رانش پیکربندی

یکی دیگر از معایب استقرار نرم‌افزار به شیوه قدیمی، مشکل رانش پیکربندی یا Configuration Drift است. این مشکل زمانی رخ می‌دهد که تغییرات مختلف و موردی، بدون مستندسازی و توجه به جزئیات روی سرور اعمال می‌شوند و سرور منحصر به فرد می‌شود.

همانطور که گفتیم سرور منحصر به فرد مشکلاتی دارد که به آن‌ها اشاره کردیم؛ اما با استفاده از ابزارهایی مانند Chef, Puppet و Ansible برای مدیریت پیکربندی، می‌توانیم از رانش پیکربندی و مشکلات آن جلوگیری کنیم.

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

Immutable Server

برای جلوگیری از ایجاد رانش پیکربندی و سرور Snowflake، استراتژی وجود دارد که با عنوان Immutable Server یا سرور تغییر ناپذیر شناخته می‌شود. در این استراتژی، سرور‌ها به صورت دوره‌ای حذف و با سرور جدیدی جایگزین می‌شوند؛ سپس با کمک ابزارهای پیکربندی، به صورت اتوماتیک پیکربندی انجام می‌شود.

با کمک این استراتژی، تغییر و ایجاد سرورها بسیار سریع و بدون مشکل خواهد بود. از این استراتژی معمولا در کنار Recreate Deployment Strategy استفاده می‌شود.

جمع‌بندی

در این مقاله به مفهوم استراتژی‌های استقرار نرم‌افزار پرداختیم، به بعضی از اهداف و چالش‌ها در این زمینه اشاره کردیم و دو مورد از استراتژی‌های پایه استقرار نرم‌افزار را به نام‌های Recreate و Rolling با ذکر مثال شرح دادیم.

همچنین مواقعی را که می‌توانیم از این استراتژی‌ها استفاده کنیم را بررسی کردیم. امیدوارم این مقاله برای شما کاربردی باشد. در مقالات آتی، استراتژی‌های پیشرفته استقرار نرم‌افزار را که در Continuous Deployment و DevOps کاربرد دارند، بررسی خواهیم کرد.