از Terraform به CloudFormation تغییر مکان داد - و از آن پشیمان شدم

ارائه زیرساخت به‌عنوان کد در قالب متنی قابل تکرار، بهترین روش ساده برای سیستم‌هایی است که نیازی به بازی با ماوس ندارند. این عمل یک نام دارد - زیرساخت به عنوان کد، و تا کنون دو ابزار محبوب برای پیاده سازی آن وجود دارد، به خصوص در AWS: Terraform и CloudFormation.

مقایسه تجربه با Terraform و CloudFormation

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

Terraform Horrible

نرم افزار بتا

Terraform حتی نسخه 1.0 را نیز منتشر نکرده است که دلیل خوبی برای عدم استفاده از آن است. از زمانی که خودم آن را امتحان کردم خیلی تغییر کرده است، اما در آن زمان terraform apply اغلب پس از چندین به روز رسانی یا به سادگی پس از چند سال استفاده خراب می شود. من می گویم "الان همه چیز متفاوت است"، اما... این چیزی است که همه می گویند، نه؟ تغییراتی وجود دارد که با نسخه‌های قبلی ناسازگار هستند، اگرچه مناسب هستند، و حتی به نظر می‌رسد که سینتکس و انتزاع‌های فروشگاه‌های منابع اکنون همان چیزی است که ما به آن نیاز داریم. ساز به نظر می رسد واقعا بهتر شده است، اما ... :-0

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

پا را ملاقات کن... گلوله است

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

Terraform عالی

بازیابی از حالت های ناقص

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

از سوی دیگر، Terraform تمایل دارد پس از انتقال های ناموفق بسیار زیباتر بهبود یابد و ابزارهای پیشرفته اشکال زدایی را ارائه می دهد.

تغییرات واضح تر در وضعیت سند

«بسیار خوب، متعادل کننده بار، شما در حال تغییر هستید. اما چطور؟"

- مهندس مضطرب، آماده فشار دادن دکمه "پذیرش".

گاهی اوقات من نیاز به انجام برخی دستکاری‌ها با load balancer در پشته CloudFormation دارم، مانند اضافه کردن شماره پورت یا تغییر یک گروه امنیتی. تغییرات نمایش ClouFormation ضعیف است. من روی پین و سوزن، فایل یامل را ده بار دوبار چک می کنم تا مطمئن شوم هیچ چیز ضروری را پاک نکرده ام و چیز غیر ضروری اضافه نکرده ام.

Terraform در این زمینه بسیار شفاف تر است. گاهی اوقات او حتی بیش از حد شفاف است (بخوانید: خسته کننده). خوشبختانه، آخرین نسخه شامل نمایش بهبود یافته تغییرات است به طوری که اکنون می توانید دقیقاً آنچه را در حال تغییر است مشاهده کنید.

انعطاف پذیری

نرم افزار را به عقب بنویسید.

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

ماژول ها در git

به اشتراک گذاری کد Terraform در چندین پشته بسیار ساده تر از به اشتراک گذاری کد CloudFormation است. با Terraform، می توانید کد خود را در یک مخزن git قرار دهید و با استفاده از کنترل نسخه معنایی به آن دسترسی پیدا کنید. هر کسی که به این مخزن دسترسی داشته باشد می تواند از کد مشترک استفاده مجدد کند. معادل CloudFormation S3 است، اما مزایای مشابهی ندارد، و دلیلی وجود ندارد که ما اصلاً git را به نفع S3 کنار بگذاریم.

سازمان رشد کرد و توانایی به اشتراک گذاشتن پشته های مشترک به سطح بحرانی رسید. Terraform این کار را آسان و طبیعی می کند، در حالی که CloudFormation باعث می شود قبل از اینکه بتوانید چیزی شبیه به این کار را انجام دهید، از حلقه ها بپرید.

عملیات به عنوان کد

"بیایید آن را اسکریپت بنویسیم و باشه."

- یک مهندس 3 سال قبل از اختراع دوچرخه Terraform.

وقتی صحبت از توسعه نرم افزار می شود، Go یا برنامه جاوا فقط کد نیست.

کد به عنوان کد

زیرساخت هایی نیز وجود دارد که روی آن کار می کند.

زیرساخت به عنوان کد

اما او اهل کجاست؟ چگونه آن را نظارت کنیم؟ کد شما کجا زندگی می کند؟ آیا توسعه دهندگان به مجوز دسترسی نیاز دارند؟

عملیات به عنوان کد

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

AWS تنها نیست: احتمالاً از سایر ارائه دهندگان استفاده می کنید. SignalFx، PagerDuty یا Github. شاید یک سرور جنکینز داخلی برای CI/CD یا یک داشبورد داخلی Grafana برای نظارت داشته باشید. Infra as Code به دلایل مختلفی انتخاب می شود و هر کدام برای هر چیزی که مربوط به نرم افزار است به یک اندازه اهمیت دارد.

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

• Я: لعنتی، این حرکات زیادی برای اورکلاک کردن یک میکروسرویس است. من باید از این زباله برای ایجاد یک حساب AWS استفاده کنم (ما به 2 حساب رفتیم میکروسرویس)، سپس این یکی برای تنظیم هشدار، این یکی برای مخزن کد، و این یکی برای لیست ایمیل، و سپس این یکی...
• رهبری: بیا اسکریپتش کنیم و باشه.
• Я: بسیار خوب، اما خود فیلمنامه تغییر خواهد کرد. ما به راهی برای بررسی به روز بودن همه این ابزارهای آمازون داخلی نیاز داریم.
• رهبری: به نظر خوب میاد و ما یک اسکریپت برای این می نویسیم.
• Я: عالی! و احتمالاً اسکریپت همچنان به تنظیم پارامترها نیاز دارد. آیا او آنها را می پذیرد؟
• رهبری: بذار هرجا میره ببره!
• Я: ممکن است روند تغییر کند و سازگاری با عقب از بین برود. نوعی کنترل نسخه معنایی مورد نیاز خواهد بود.
• رهبری: ایده عالی!
• Я: ابزارها را می توان به صورت دستی در داخل رابط کاربری تغییر داد. ما به راهی برای بررسی و رفع آن نیاز داریم.

…3 سال بعد:

• رهبری: و ما ترافورم گرفتیم.

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

ماژول‌های CloudFormation lambda در مقابل git به صورت زمینی

lambda راه حل CloudFormation برای مسئله منطق سفارشی است. با لامبدا می توانید ایجاد ماکرو یا منبع کاربر. این رویکرد پیچیدگی‌های اضافی را معرفی می‌کند که در نسخه‌سازی معنایی ماژول‌های git Terraform وجود ندارد. برای من، مهم‌ترین مشکل مدیریت مجوزها برای همه این لامبداهای کاربر بود (و اینها ده‌ها حساب AWS هستند). مشکل مهم دیگر مشکل "اولین چیزی بود، مرغ یا تخم مرغ؟" بود: به کد لامبدا مربوط می شد. این تابع خودش زیرساخت و کد است و خودش نیاز به نظارت و آپدیت دارد. میخ نهایی در تابوت مشکل در به روز رسانی معنایی تغییرات کد لامبدا بود. ما همچنین باید مطمئن می شدیم که اقدامات پشته بدون دستور مستقیم بین اجراها تغییر نمی کند.

یادم می آید یک بار می خواستم یک استقرار قناری برای محیط Elastic Beanstalk با یک متعادل کننده بار کلاسیک ایجاد کنم. ساده ترین کار این است که یک استقرار دوم برای EB در کنار محیط تولید ایجاد کنیم و آن را یک گام جلوتر ببریم: ترکیب گروه استقرار قناری مقیاس پذیر خودکار با استقرار LB در محیط تولید. و از آنجایی که Terraform استفاده می کند ASG beantalk به عنوان نتیجه گیری، این به 4 خط کد اضافی در Terraform نیاز دارد. وقتی از من پرسیدم که آیا راه حل قابل مقایسه ای در CloudFormation وجود دارد، آنها به من یک مخزن git کامل با یک خط لوله توسعه و همه چیز را نشان دادند، همه به خاطر کاری که 4 خط ضعیف کد Terraform می توانست انجام دهد.

دریفت را بهتر تشخیص می دهد

اطمینان حاصل کنید که واقعیت با انتظارات مطابقت دارد.

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

با Terraform شما قلاب های چرخه حیات بسیار پیشرفته تری برای تشخیص دریفت دارید. مثلاً دستور را وارد می کنید ignore_changes اگر می‌خواهید بدون نادیده گرفتن تغییرات در کل استقرار ECS، تغییرات تعریف کار خاص را نادیده بگیرید، مستقیماً در تعریف کار ECS قرار دهید.

CDK و آینده CloudFormation

مدیریت CloudFormation در مقیاس های بزرگ و بین زیرساختی دشوار است. بسیاری از این مشکلات شناخته شده است و ابزار به مواردی مانند نیاز دارد aws-cdk، چارچوبی برای تعریف زیرساخت ابری در کد و اجرای آن از طریق AWS CloudFormation. جالب است که ببینیم آینده aws-cdk چه خواهد شد، اما برای رقابت با دیگر نقاط قوت Terraform کار سختی خواهد داشت. برای به روز رسانی CloudFormation، تغییرات کلی مورد نیاز است.

تا Terraform ناامید نشود

این "زیرساخت به عنوان یک کد" است و نه "به عنوان یک متن".

اولین برداشت من از Terraform نسبتا بد بود. من فکر می کنم من فقط رویکرد را درک نکردم. تقریباً همه مهندسان به طور غیرارادی آن را به عنوان یک قالب متنی درک می کنند که باید به زیرساخت مورد نظر تبدیل شود. این کار را به این صورت انجام ندهید.

اصول توسعه نرم افزار خوب در مورد Terraform نیز صدق می کند.

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

چگونه می توان کد را مستند نکرد؟

من پشته های بزرگ Terraform را بدون هیچ مدرکی دیده ام. چگونه می توانید کد را در صفحات بنویسید - بدون هیچ مدرکی؟ اسنادی را اضافه کنید که شما را توضیح دهد رمز Terraform (تاکید بر کلمه "کد")، چرا این بخش تا این اندازه مهم است و شما چه می کنید.

چگونه می‌توانیم سرویس‌هایی را که زمانی یک تابع main() بزرگ بودند، مستقر کنیم؟

من پشته های بسیار پیچیده Terraform را دیده ام که به صورت یک ماژول ارائه شده اند. چرا نرم افزار را به این شکل مستقر نمی کنیم؟ چرا توابع بزرگ را به توابع کوچکتر تقسیم می کنیم؟ همین پاسخ ها در مورد Terraform نیز صدق می کند. اگر ماژول شما خیلی بزرگ است، باید آن را به ماژول های کوچکتر تقسیم کنید.

آیا شرکت شما از کتابخانه ها استفاده نمی کند؟

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

از PEP8 یا gofmt استفاده نمی کنید؟

اکثر زبان ها دارای یک طرح قالب بندی استاندارد و پذیرفته شده هستند. در پایتون این PEP8 است. در Go - gofmt. Terraform موارد خاص خود را دارد: terraform fmt. برای سلامتی خود از آن لذت ببرید!

آیا بدون دانستن جاوا اسکریپت از React استفاده خواهید کرد؟

ماژول‌های Terraform می‌توانند بخشی از زیرساخت پیچیده‌ای را که ایجاد می‌کنید ساده‌سازی کنند، اما این بدان معنا نیست که اصلاً نمی‌توانید آن را سرهم کنید. آیا می خواهید بدون درک منابع از Terraform به درستی استفاده کنید؟ شما محکوم به فنا هستید: زمان می گذرد و شما هرگز به Terraform تسلط نخواهید داشت.

آیا با تک‌تن یا تزریق وابستگی کدنویسی می‌کنید؟

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

آیا کتابخانه های شما ده کار را به خوبی انجام می دهند یا یک کار عالی؟

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

چگونه می‌توانید تغییراتی را در کتابخانه‌ها بدون سازگاری به عقب ایجاد کنید؟

یک ماژول معمولی Terraform، مانند یک کتابخانه معمولی، نیاز دارد تا تغییرات را به نحوی به کاربران منتقل کند بدون اینکه با عقب سازگار باشد. زمانی که این تغییرات در کتابخانه ها اتفاق می افتد آزاردهنده است و زمانی که تغییرات غیر سازگار با عقب ماژول های Terraform ایجاد می شود به همان اندازه آزاردهنده است. توصیه می شود هنگام استفاده از ماژول های Terraform از تگ های git و semver استفاده کنید.

آیا سرویس تولید شما روی لپ تاپ شما اجرا می شود یا در مرکز داده؟

Hashicorp ابزارهایی مانند ابر زمینی برای اجرای زمین خود این خدمات متمرکز مدیریت، ممیزی و تایید تغییرات زمین را آسان می کند.

تست نمی نویسی؟

مهندسان تشخیص می دهند که کد نیاز به آزمایش دارد، اما خودشان اغلب هنگام کار با Terraform آزمایش را فراموش می کنند. برای زیرساخت ها، این مملو از لحظات خائنانه است. توصیه من این است که پشته‌هایی را «تست» یا «نمونه ایجاد کنید» با استفاده از ماژول‌هایی که می‌توانند به درستی برای آزمایش در طول CI/CD مستقر شوند.

Terraform و microservices

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

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

منبع: www.habr.com