معرفی

تیم پلتفرم داده بلادرنگ Grab کبان، منابع زیرساخت را از طریق زیرساخت به عنوان کد (IaC) مدیریت می کند. از طریق رویکرد IaC، از Terraform برای حفظ هماهنگی زیرساخت استفاده می شود، اتوماسیون و آسانی استقرار زیرساخت جریان زنده ما، به خصوص:

با رشد نماینده Grab، باید راه بهتری برای تغییر سازمانی زیرساخت به طور خودکار وجود داشته باشد. حرکت به سمت روند GitOps در بسیاری از راه ها برای ما سودمند است:

نسخه بندی و غیرقابل تغییر: با ذخیره کد منبع در مخازن Git، حالت مطلوب زیرساخت در یک محیط ذخیره می شود که عدم قابلیت تغییر، نسخه بندی و نگهداری تاریخچه نسخه را اجبار می کند، که در بازرسی و قابلیت ردیابی کمک می کند.استقرار سریعتر: با اتوماسیون فرآیند استقرار منابع پس از ادغام کد، ما مراحل دستی را حذف می کنیم و به طور کلی بهره وری مهندسی کلی را افزایش می دهیم در حالی که هماهنگی را حفظ می کنیم.بازگشت آسانتر: این به راحتی مانند بازگشت روی یک کامیت Git است در مقایسه با ایجاد یک درخواست ادغام (MR) و توضیح دستورات Atlantis است که مراحل اضافی را اضافه می کند و به افزایش زمان میانگین برای حل موارد عملکرد مشارکت می کند (MTTR) برای حوادث.

پیش زمینه

برخلاف، Coban پیاده سازی اتوماسیون منابع Terraform را با استفاده از Atlantis، یک برنامه که بر اساس نظرات کاربر در MR ها عمل می کند، انجام می دهد.

ما با Atlantis راه زیادی پیموده ایم. این به ما کمک کرده است تا جریان کاری خود را اتوماتیک کنیم و امکانات خود خدمت را برای مهندسین ما در دسترس قرار دهیم. با این حال، چند محدودیت در راه اندازی ما وجود داشت که می خواستیم بهبود ببخشیم:

دانسگرانه: راهی برای محدود کردن انواع منابع Terraform که کاربران می توانند ایجاد کنند وجود ندارد، که مسائل امنیتی را ایجاد می کند. به عنوان مثال، اگر یک کاربر یکی از صاحبان کد باشد، می تواند با تأییدیه تیم خود، دوره امتیاز IAM دیگری با دسترسی های مدیریتی ایجاد کند. همه جا در مخزن.

راه حل

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

امنیت: قابلیت ایمنی خط لوله با اسکریپت ها و جریان کارهای سفارشی زیادی را دارد.تجربه کاربری ساده (UX): جریان کاری ساده شده و خطاهای انسانی را با اتوماسیون جلوگیری می کند.DRY: کاهش کدهای boilerplate. کاربران فقط نیاز به ایجاد یک منبع Terraform و نه یک پروژه کامل Terraform را دارند.

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

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

مراحل لوله کاری

پیاده سازی لوله کاری Khone با سه مرحله طراحی شده است. هر مرحله وظایف و مسئولیت های مختلفی را در تأیید ورودی کاربر و ایجاد ایمن منابع ایجاد می کند.

مرحله اولیه

در این مرحله، تغییرات را به منابع حذف شده، ایجاد شده یا تغییر کرده و انواع منابع پشتیبانی نشده را فیلتر می کنیم. همچنین با اعتبارسنجی تغییرات بر اساس مسیر منبع و بررسی کد منبع HCL در ماژول Terraform آنها را از ایجاد منابع ناخواسته جلوگیری می کنیم. این مرحله همچنین آرتیفکت ها را برای مراحل بعدی آماده می کند.

مرحله Terraform

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

برای هر کار جداگانه، ما چندین گیت آنی امنیتی را پیاده سازی کرده ایم مانند:

بررسی کد: از کتابخانه python-hcl2 برای خواندن محتوای HCL منابع Terraform برای انجام اعتبارسنجی، محدود کردن انواع منابع Terraform که کاربران می توانند ایجاد کنند و اطمینان حاصل می کند که منابع تنظیمات مورد نظر دارند. همچنین از منبع Terraform مجاز به اعتبارسنجی مبدا ویدیویی استفاده کرده ایم بر اساس نوع منبع اعلام شده. این به ما این امکان را می دهد که از انعطاف پذیری زبان پایتون به عنوان یک زبان برنامه نویسی بهره ببریم و اعتبارسنجی ها را به طور پویا تر وابسته به توابع HCL بیشتر انجام دهیم.اعتبارسنجی منابع: ما تنظیمات را بر اساس مسیر منبع اعتبارسنجی می کنیم تا اطمینان حاصل کنیم کاربران با ساختار مسیر صحیح و قصد شده دنبال می کنند.اندازه گیری و قالب بندی: استفاده از برنامه Terraform CLI برای لینتینگ و قالب بندی کد HCL به منظور اطمینان از همسانی کد.

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

مسیر = یکی (regexall (join ("/",
[
    "^ * "،
    "(? P <repository> khone | khone-dev) "،
    "منابع"،
    "(? P <namespace> [^/] *) "،
    "(? P <resource_type> [^/] *) "،
    "(? P <env> [^/] *) "،
    "(? P <cluster_name> [^/] *) "،
    "(? P <resource_name> [^/] *) $ "
] )، مسیر ( مسیر کاری))

مرحله معیار

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

برای معیارهای ما، با حذف کاربران از Coban، به دست آوردن کاربران واقعی را تشخیص دادیم. این به ما کمک می کند معیارهای موفقیت را به طور پیوسته اندازه گیری کنیم زیرا می توانیم معیارها را از لوله های تست CI / CD جدا کنیم.

در نیمه دوم سال 2022، ما به یک uptime 100٪ برسید