خانه / DevOps / رویکردهای مختلف جهت Provisioning سرویس های برنامه

رویکردهای مختلف جهت Provisioning سرویس های برنامه

رویکردهای مختلفی جهت Provisioning سرویس های برنامه و سرورهایی که این سرویس بر روی اونها هاست میشه وجود داره و استفاده میشه. ساده ترین رویکرد copy-and-past سرویس های جدید و سپس تنظیم کانفیگ فایلها و تنظیمات محیط سرور و … بصورت manual می باشد. این رویکرد ساده مبتنی بر نیروی انسانی و دارای مشکلات زیادی هست، طولانی بودن فرآیند، احتمال خطای زیاد، audit-able نبودن نیروی انسانی، reproduce کردن مجدد همراه با مشکلات فراوان و … بخشی از این مشکلاتِ.

الگوهایی متفاوتی با pros-and-cons مخصوص خود برای provisioning مطرح واستفاده شده، که مختصرا در اینجا در موردشون توضیح داده میشه.
——————-
Snowflake Server

یکی از این الگوها معروف به Snowflake Servers هست. که هم بصورت manual و هم با چاشنی Automation در برخی فرآیندها همراه هست. ویژگی اصلی snowflake سرورها که بیشتر با bare metal server ها همراهِ و اصلی ترین پاشنه آشیل این روش است موضوع unique بودن سرورهای تولید شده
در این روشِ .

سرورهای Snowflake در طی زمان تمایل زیادی به unique بودن دارند بخاطر کانفیگ های اختصاصی تنظیمات محیطی متفاوت و موارد security متفاوتی که
به هر کدام بصورت مجزا اعمال میشود
در واقع در اینجا سرورهای متفاوت بصورت مجزای از هم ایجاد و سپس بسته به نیاز کانفیگ خواهند شد. که این امر منجر به این میشود که پس از مدتی با مجموعه ای از سرورهای تولید شده و البته اماده ی استفاده ولی با ویژگی ها و کانفیگ های متفاوت مواجه باشیم.
مشکلی که اصطلاحا به آن Configuration Drift گفته میشه

ساده ترین روش جهت حل مشکل configuration drift که منجر به Snowflake Servers میشه استفاده از الگوی Configuration Synchronization و قرار دادن تمام تنظیمات کانفیگی در یک فرآیند اتوماتیک به فرم receipts که بصورت DSL جنریت میشن به کمک ابزارهایی از جمله Puppet، Chef و GoCD هست.
نکته مهم در اینجا دسترسی اعمال تغییرات فقط از طریق سورس کنترل، جهتدaudit کردن تغییرات مورد نظر میباشد.

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

—————
Phoenix Servers

رویکرد دیگر Phoenix Servers هست. فونیکس سرورها ابتدا به ساکن سعی میکنه مشکل Unique بودن سرورها در رویکرد Snowflake را حل کنند.

رویکرد Phoenix Servers جهت حل این مشکلات، ایجاد سرورها و ایمیچ ها به عنوان بخشی از فرآیند CD از روی یک base image و سپس ایجاد صفی از آنها جهت جابجایی و استفاده به گاه نیاز هست.
همونطور که مارتین فاولر اشاره میکنه مهمترین مزیت این الگو نسبت به Snowflake Servers اجتناب از configuration drift هست.

The primary advantage of using phoenix servers is to avoid configuration drift: ad hoc changes to a systems configuration that go unrecorded. Drift is the name of a street that leads to SnowflakeServers, and you don’t want to go there without a big plough.

در این الگو بهنگام ایجاد مشکل سرورهای جدید از روی یک base image بصورت
سریع تولید و جایگزین خواهد شد

As Martin Fowler recommends, “A server should be like a phoenix, regularly rising out of the ashes.”

همانطور که Kief Morris هم اشاره میکنه تمرکز اصلی Phoenix بر ایجاد مجدد سرور از یک base inage هست. و سعی میکنه گاهی اوقات در صورت نیاز و بهنگام تغییر کانفیگ، این تغییرات رو بر روی سرور درحال اجرا اعمال کنه، و این اعمال تغییرات تا جایی اعمال میشه که fault رخ بده و مجدد از روی base image سرور جدیدی
ایجاد و provision بشه.

Package Server Image>Provision Server Instance>Apply Configuration Changes>….
هست، که باید از آن اجتناب کرد،

Kief Morris:
But while we can continue to run configuration management updates on a server during its brief lifetime, there’s less value in doing so. In fact, there is considerable value in not doing so, since any change to a running system introduces risk.
———————
Immutable Servers

الگوی Immutable Servers یک extension بر الگوی Phoenix Servers هست. تفاوت اصلی این الگو با Phoenix Servers در Immutable بودن instance های سرور تولید شده از base image هست، یعنی درصورتی که توی Configuration تغییری ایجاد بشه در این الگو سعی نمیشه این تغییرات بر روی سرور در حال اجرا اعمال شه، در عوض سرور و image جدیدی با کانفیگ تغییر یافته ایجاد و provision میشه

نکته ی مهم صرفنظر از الگوهای بالا، استفاده از virtualization بجای bare metal server هاست

درباره ی masoud@admin

همچنین ببینید

از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!!

از آقا یا خانم DevOps توقع بیجا نداشته باشیم!!! احتمالا شما هم با دیدن عبارت “آقا …

اسید و بازها و چالش سازگاری در سیستم های توزیع شده

اسید و بازها و چالش سازگاری در سیستم های توزیع شده بدون شک سازگاری یکی …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن