ارکستر سکو چیست؟

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

به روز بمان

این ساده است - برای خبرنامه ما ثبت نام کنید.

مقدمه

یک ارکستر سکو ، محور یک پلت فرم توسعه دهنده داخلی پویا (IDP) است. هر زمان که یک خط لوله CI مجاور ارکستور یک ساخت جدید را آگاه کند ، ارکستر مدل برنامه اعلانی را می خواند ، نمایشی از برنامه را به همراه منابع وابسته خود تولید می کند و آن را مستقر می کند.

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

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

چرا به "دستگاه پخت" نیاز دارید

برای به دست آوردن چرا ما به یک ارکستر سکو نیاز داریم ، باید یک قدم عقب برداریم و کاستی های گردش کار Yaml-CI-CD را که احتمالاً امروز با آن آشنا هستید ، درک کنیم. تنظیماتی که تقریباً امروز در حال اجرا هستید ، همان چیزی است که ما آن را "استاتیک" می نامیم."استاتیک" به دلیل رویکرد کاربردی در پیکربندی برنامه و زیرساخت ها به صورت آماری بر اساس محیط به محیط زیست با استفاده از پرونده های YAML و پرونده های IAC که به صورت دستی "بومی سازی" در متن هستند (به عنوان مثال محیط).

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

برای اینکه مشکل قابل هضم تر باشد ، سفر پخت کیک را تصور کنید. کیک با کرم لخته شده ، توت فرنگی و بسیاری از چیزهای خوب دیگر. ما باید حداقل یک کیک را خیلی خوب تحویل دهیم ، بنابراین یک کیک dev ، یک کیک مرحله ای و کیک تولید نهایی را پختیم. خوب کار کرد ، کیک خوب و براق است ، ما می توانیم توت فرنگی ها را به روز کنیم زیرا نسخه های بهبود یافته همراه هستند و همه خوشحال هستند.

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

جدا از اینکه کیک شما بعد از این روش واقعاً زشت به نظر می رسد ، این یک مثال عالی از آنچه در مدیریت پیکربندی استاتیک اشتباه است. برای حل این مسئله در برابر دنیای واقعی ، کیک ما برنامه ای است که در محیط های مختلف اجرا می شود. اجزای آن توسط پرونده های پیکربندی (YAML یا IAC مانند Terraform و غیره) که به صورت دستی برای زمینه برنامه در محیط مربوطه نوشته شده اند ، در کنار هم نگهداری می شوند. همه چیز همراه با ساختار یا سازگاری کمی ، در مکان های مختلف ، توسط افراد مختلف در هم آمیخته شده است. این تعدادی از نقاط ضعف دارد:

• نگهداری آن سخت است
• استاندارد سازی در بین تیم ها دشوار است
• این در حال حرکت با تغییر بالاتر است
• کار و هضم توسط یک فرد مجرد دشوار است ، زیرا اجزای درهم و برهم درک این مسئله را به چه روشی دشوار می کند.

و در حالی که خوب است اگر یک کیک را با یک تیم کوچک پخت کنید ، اگر ده ها توسعه دهنده در حال پخت کیک هستید ، اطمینان حاصل می کنید که آخرین توت فرنگی را پیدا کرده اید.

رویکرد جایگزین مدیریت پیکربندی پویا نامیده می شود. برای ماندن در قیاس پخت ما: به جای پخت بسیاری از کیک ها و جستجوی توت فرنگی ، ما فقط یک دستور العمل پخت می نویسیم و توضیحی در مورد چگونگی تغییر کیک بین محیط ها اضافه می کنیم. سپس کیک را با هر اعزام از زمین به بالا پختیم. این کار توسط یک دستگاه پخت انجام می شود و این دستگاه پخت در زمینه Cloud Native یک ارکستر سکو نامیده می شود.

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

Orchestrator Platform دستور العمل پخت ما ، مدل برنامه اعلامی را می خواند و کیک ، برنامه ما را پخت می کند. این دارای مثبت زیادی است:

• شما به عنوان یک توسعه دهنده اکنون مجبور نیستید با هر قسمت از تنظیمات سر و کار داشته باشید ، فقط می توانید روی حجم کار و مشخصات بار کار مانند Score. dev تمرکز کنید). این به شما امکان می دهد بدون بسته به دیگران ، برنامه هایی را از ایده به تولید بسازید.
• در همان زمان شما به عنوان توسعه دهنده تمام زمینه های مورد نیاز خود را دارید. تیم های پلتفرم می توانند پروفایل های بار کاری و تعاریف منابع را تنظیم کنند اما می توانید زیرساخت های اساسی را به عنوان کد مشاهده کنید. حتی می توانید درخواست کشش ارسال کرده و آن را تغییر دهید!
• تنظیم پروفایل ها و به اشتراک گذاری آنها در بارهای کاری و تیم ها به شما امکان می دهد بدون اینکه آنها را به صورت تهاجمی اجرا کنید ، شیوه ها را در سراسر سازمان استاندارد کنید. به عنوان مثال ، تیم ها می توانند اطمینان حاصل کنند که برچسب ها و حاشیه نویسی ها برای مجموعه APM خود را به همه بار کاری تبدیل می کنند. یا طاق Hashicorp باید به عنوان یک ماشین جانبی برای هر بار کاری جدید شروع شود. ما این استاندارد را با طراحی می نامیم.

این همچنین طیف گسترده ای از ویژگی ها را که با یک تنظیم استاتیک سخت یا غیرممکن بودند ، روکش می کند. چیزهایی مانند:

• بازگشت به استقرار قبلی با یک دستور واحد
• چرخش محیط های کاملاً پیکربندی شده با یک دستور واحد
• استفاده از تغییرات معماری مانند افزودن/حذف سرویس جدید یا منبع یا سایر وابستگی ها و چرخاندن آنها به سرعت به همه محیط ها
• مدل سازی برنامه ها و وابستگی ها از طریق CLI ، API ، UI یا کد مبتنی بر
• به روزرسانی زیرساخت ها و پروفایل های بار کاری در یک مکان و دور زدن آنها در سراسر سازمان
• بسته بندی خدمات و منابع پیش فرض به عنوان "بستر به عنوان کد" و به دست آوردن توسعه دهندگان خود به یک تجربه سریع رعد و برق در چرخش خدمات جدید + منابع وابسته به استاندارد با یک دستور
• با استفاده از موقعیت مرکزی ارکستر درچین ابزار برای جمع آوری داده ها/سیاهههای مربوط و غیره در یک مکان
• استفاده از کنترل دسترسی مبتنی بر نقش دانه ریز (RBAC) در مراحل مختلف چرخه تحویل

چه اتفاقی می افتد (با جزئیات) اگر با یک ارکستر سکو مستقر شوید؟

ما آموخته ایم که ارکستر مدل برنامه اعلامی را می گیرد و کیک را پخت می کند. اما بیایید دنباله را با جزئیات دنبال کنیم. توجه داشته باشید که این متفاوت از ارکستر تا ارکستر است ، اما نمونه ای که ما می گیریم بسیار رایج است (از مقدار رو به رشد اما هنوز هم اندک سیستم عامل های توسعه دهنده داخلی پویا در آنجا گرفته شده است). بیایید فرض کنیم که ما یک بار کار را در یک خوشه EKS مستقر می کنیم که با RDS به یک Postgres متصل می شود و از طریق DNS در اینترنت عمومی قرار می گیرد. اکنون این برنامه را در برابر محیطی از نوع "توسعه" مستقر خواهیم کرد. بیایید فرض کنیم این اولین استقرار در این محیط است ، بنابراین منابع هنوز وجود ندارند. این همان چیزی است که اتفاق خواهد افتاد:

1. خط لوله CI یک تصویر را ایجاد می کند و آن را به یک رجیستری تصویر سوق می دهد (مثلاً ECR). اعلان ساخت از خط لوله به ارکستر اطلاع می دهد که وقت آن است که پخت و استقرار داشته باشد.
2. ارکستور آخرین تغییرات را در مدل برنامه اعلانی می خواند و مانیفست ها را ایجاد می کند.
3. از مانیفست ها استفاده می کند و آنها را در برابر Kubectl برای پیکربندی Kubeetes اجرا می کند.
4. در مرحله بعد به نظر می رسد که از مشخصات زیرساختی برای زمینه محیط استفاده می شود ، که در مورد ما "توسعه" است.
5. در مورد ما ، تعریف منابع از Terraform برای ایجاد یک پایگاه داده در یک نمونه موجود Postgres ، یک فضای نام جدید در EKS و DNS جدید با Route53 استفاده می کند.
6. این اعتبار را از منابع دریافت می کند و آنها را به عنوان اسرار در زمان اجرا به ظروف تزریق می کند.

و این همان است ، نمایندگی جدید (پیکربندی اجرایی مانند مانیفست ها و ماژول های IAC) برنامه شما ایجاد می شود و برنامه مستقر می شود.

رابط در ارکستر سکو شما

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

به دنبال روش GITOPS ، رابط ها می توانند مبتنی بر API یا کاملاً مبتنی بر کد باشند. برخی از ارکستراتورها با CLI های اختصاصی و برخی از UI ها برای تجسم و اجرای عملیات کاربردی خود رابط می کنند. ارکستور را می توان با کاتالوگ های APM و کاتالوگ خدمات خود برای تجسم و ورود به سیستم خدمات خود ، پیوند مخزن و موارد دیگر. Backstage ، یک پروژه برجسته منبع باز در فضای کاتالوگ سرویس اغلب در ترکیب با یک ارکستر سکو استفاده می شود.

خلاصه

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

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

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