کنترل ورژن در Cloud

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

قابلیت تولید مجدد مانند یک عصای جادویی است که به ایجاد سیستم‌های یکسان کمک می‌کند، هرچقدر هم که سیستم پیچیده باشد.

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

مزایای ارائه شده توسط قابلیت تولید مجدد و ردیابی از قبل توسط جامعه توسعه دهنده به خوبی درک شده است:

• کیفیت بالا: فقط کد تست شده را نگهداری می‌کنید تا از مبدأ شروع تغییر با تمام جزئیات مطلع شوید.
• بازیابی: برای تولید مجدد محیط در یک زمان مشخص هر موقع که مشکلی در سرویس رخ دهد.
• عیب یابی: برای مشخص کردن علت اصلی یا علت احتمالی هرگونه مشکل اساسی در سرویس.

آیا می‌توانیم کنترل نسخه را روی cloud اعمال کنیم؟

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

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

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

اما فقط استفاده از کنترل نسخه بر روی کد منبع IaC کافی نیست. IaC مسئول تأمین منابع ابری است و این منابع ابری عمر خاص خود را دارند. به عنوان مثال حجم EBS می‌تواند طول عمر EC2 را که به آن متصل است بیش از حد کند. این اتصال در ویژگی‌های منبع منعکس شده است و این ویژگی‌ها بر اساس نوع منبع ابری تغییر می‌کنند.

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

چگونه نسخه ابری را کنترل کنیم؟

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

برای کنترل نسخه منابع ابری باید با APIهای کنترل ابری کار کنیم. این APIها باید برای به دست آوردن همه منابع ابری موجود و خصوصیات منابع آنها در آن زمان استفاده شوند. کنترل نسخه نیز باید هوشمند باشد تا عمر منبع را به عنوان created، available و deleted مشخص کند. ممکن است این کار را یک اسنپ شات از ابر بنامیم. اسنپ شات تمام منابع ابر و ویژگی‌های موجود در آن زمان را مشخص می‌کند.

هرچند از لحاظ تئوری منطقی به نظر می‌رسد، اما باید واقعیت را نیز درک کنیم. منابع ابری به ندرت به صورت جداگانه وجود دارند. یک نمودار رابطه‌ای پیچیده این منابع را به هم متصل می‌کند. بنابراین هر راه حل بی خطر نیاز به پوشش جامع منابع ابری دارد. هر منبع گمشده فقط نمودار را می‌شکند. با این وجود با توجه به سرعت فروشندگان ابر در ارائه خدمات جدید و گسترش خدمات موجود، این سوال بزرگی است. در زمان نوشتن این مقاله، تقریبا بیش از 250 سرویس ابری برای AWS cloud در دسترس است. در واقع از نظر IaC ، Terraform پوشش بسیار بهتری نسبت به CloudFormation دارد و CloudFormation همیشه عقب مانده تلقی می‌شود.

بنابراین آیا تلاش‌هایی توسط فروشندگان ابر برای نسخه ابری انجام شده است؟

عمدتا در دو سطح صورت می‌گیرد: سطح منابع فردی ابر و با معرفی خدمات برای مدیریت پیکربندی منابع ابر.

در AWS Cloud اکنون شاهد نسخه بندی در سطح منابع هستیم. به عنوان مثال وظایف ECS به صراحت نسخه بندی می‌شوند. به همین ترتیب الگوهای راه اندازی دارای نسخه‌هایی هستند. در حالی که این طرح‌های نسخه سازی برای آن منابع ابری منفرد مفید می‌باشند که از منظر کلی ابر داشتن این موارد کافی نیست.

شما هنوز هم به اسنپ شات‌هایی در مورد همه منابع ابر نیاز دارید. همچنین به یک رویکرد جامع نیاز داریم که تمام ابر را در چندین حساب، چندین منطقه و تقریبا همه منابع ابر پوشش دهد.

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

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

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

خوشبختانه خدمات کمی در این فضا ظاهر شده‌اند که می‌توانند مفید باشند.

AWS Config

AWS Config یک سرویس مدیریت پیکربندی منابع ابری توسط خود AWS است. سرویس AWS بر اساس مفهوم recorder کار می‌کند که برای ثبت (اسنپ شات) منابع ابری باید پیکربندی شود. recorder را می‌توان به گونه‌ای پیکربندی کرد که شامل تمام منابع ابری یا تعداد محدودی انتخابی باشد. خصوصیات منابع نیز ثبت می‌شود. این اسنپ شات‌های پیکربندی شده می‌توانند تا 7 سال (که مقدار پیش فرض است) در S3 ذخیره شوند. به طور پیش فرض recorder فقط برای یک حساب و منطقه کار می‌کند. اگر می‌خواهید برای چندین حساب و منطقه کار کند، باید aggregator‌هایی ایجاد کنید. گاهی اوقات احساس می‌شود یک مرحله پیچیده غیر ضروری است.

در واقع منابع ابری این سرویس محدود است، تقریبا 100 نوع منبع در زمان نوشتن این مقاله پشتیبانی می‌شوند. مسئله دیگر در مورد پیکربندی AWS قیمت گذاری آن است. هر ثبت پیکربندی منبع 0.003 ~ دلار برای هر منطقه هزینه می‌برد. برای ابرهای متوسط ​​تا بزرگ هم این مبلغ بالاتر می‌رود. به خصوص هنگامی که چیزی از بین می‌رود و به سرعت به تغییر ویژگی منبع ادامه می‌دهد. با توجه به مدل پرداخت به ازای استفاده، قیمت گذاری خدمات پیچیده است.

Fugue

Fugue.co در حال حاضر یک سرویس شناخته شده با ابزار متن باز regula است و بسیاری از شما ممکن است از قبل با آن آشنا باشید. همچنین می‌توانید حساب‌های ابری را به fugue اضافه کنید تا اسکن شوند (اسنپ شات). سپس می‌توانید یک خط پایه ایجاد کنید تا به عنوان یک اسنپ شات طلایی عمل کند. به علاوه دارای یک تجسم در حال کار است که گاهی اوقات می‌تواند مدیریت ابر را آسان کند. این سرویس از 190 نوع منابع ابری پشتیبانی می‌کند که بسیار بهتر از AWS Config است.

با این حال fugue تاریخچه منابع ابری را حفظ نمی‌کند و به جز drift نمی‌توان تاریخچه منابع (خصوصیات) را مشاهده کرد. همچنین طول عمر منابع را به وضوح مشخص نمی‌کند. به نظر می‌رسد Fugue بیشتر بر انطباق متمرکز شده و شاید این توضیح دهنده قیمت تعیین شده (1250 دلار در ماه) باشد.

Cloud Yali

CloudYali.io در یک نسخه پیش نمایش رایگان انحصاری قرار دارد و شما باید برای یک دعوت نامه ثبت نام کنید. در حال حاضر از 250 نوع منابع ابری پشتیبانی می‌کند. امکان افزودن چندین حساب به سرویس وجود دارد که در نتیجه اسنپ شات هر حساب کاربری را انجام می‌دهد. همه منابع ابری از حساب‌ها و مناطق مختلف را می‌توان در یک مکان واحد مشاهده کرد. بنابراین می‌تواند برای فهرست جامع منابع مورد استفاده قرار گیرد.

رابط کاربری برای جستجوی منابع یک نوع خاص آسان‌تر می‌شود که می‌تواند در دامنه حساب‌ها، مناطق یا حتی تاریخ محدود شود. CloudYali به وضوح طول عمر هر منبع را مشخص می‌کند، بنابراین تعیین می‌کند که یک منبع خاص ایجاد یا حذف شده است. جالب اینجاست که مشاهده همه خصوصیات منابع در یک مکان واحد امکان پذیر است که به نظر من جالب و کاربردی است.

با توجه به همه این مزایا، کنترل نسخه ابری ممکن است به بخشی ضروری از یک استراتژی موفقیت آمیز در سرویس‌های ابری تبدیل شود.

منبع