زیرساخت به عنوان کد: اولین آشنایی

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

ادامه سلسله مقالاتی که بر اساس سخنرانی در رویداد داخلی ما نوشته شده است DevForum:

1. گربه شرودینگر بدون جعبه: مشکل اجماع در سیستم های توزیع شده.
2. زیرساخت به عنوان کد. (تو اینجایی)
3. تولید قراردادهای Typescript با استفاده از مدل های C#. (در حال پیش رفت...)
4. مقدمه ای بر الگوریتم اجماع Raft. (در حال پیش رفت...)
...

ما تصمیم گرفتیم یک تیم SRE ایجاد کنیم و ایده ها را پیاده سازی کنیم گوگل sre. آنها برنامه نویسانی را از بین توسعه دهندگان خود جذب کردند و آنها را برای چند ماه برای آموزش فرستادند.

این تیم وظایف تمرینی زیر را داشت:

• زیرساخت ما را توضیح دهید که بیشتر در Microsoft Azure به صورت کد (Terraform و همه چیز اطراف) است.
• به توسعه دهندگان نحوه کار با زیرساخت ها را آموزش دهید.
• توسعه دهندگان را برای انجام وظیفه آماده کنید.

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

در مدل معمول جهان (اداره کلاسیک)، دانش در مورد زیرساخت در دو مکان قرار دارد:

1. یا به صورت دانش در سران خبرگان.
2. یا این اطلاعات روی برخی از ماشین‌های تحریر است که برخی از آنها برای متخصصان شناخته شده است. اما این یک واقعیت نیست که یک فرد خارجی (در صورتی که کل تیم ما به طور ناگهانی بمیرد) بتواند بفهمد چه چیزی و چگونه کار می کند. ممکن است اطلاعات زیادی در مورد یک ماشین وجود داشته باشد: لوازم جانبی، cronjobs، intridated (نگاه کنید به. نصب دیسک) دیسک و فقط یک لیست بی پایان از آنچه ممکن است اتفاق بیفتد. درک اینکه واقعاً چه اتفاقی می افتد دشوار است.

در هر دو مورد، ما خود را در دام وابسته شدن می یابیم:

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

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

بنابراین، زیرساخت به عنوان کد (Incfastructure as Code - IaC) توصیفی از کل زیرساخت موجود در قالب کد و همچنین ابزارهای مرتبط برای کار با آن و پیاده سازی زیرساخت واقعی از آن است.

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

مهندسان جدید SRE از کجا می آیند؟بنابراین، ما تصمیم گرفتیم مهندسان جدید SRE را استخدام کنیم، اما آنها را از کجا تهیه کنیم؟ کتاب با پاسخ های صحیح (کتاب Google SRE) به ما می گوید: از توسعه دهندگان. بالاخره آنها با کد کار می کنند و شما به حالت ایده آل می رسید.

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

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

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

کد مثال از Terraforma.

کد نمونه از Ansible.

آقایان، اگر اینقدر ساده بود! ما در دنیای واقعی هستیم و همیشه آماده است تا شما را غافلگیر کند، شگفتی ها و مشکلات را به شما ارائه دهد. اینجا هم بدون آنها نمی توانم کار کنم.

1. اولین مشکل این است که در اکثر موارد IaC نوعی dsl است.

و DSL نیز به نوبه خود شرحی از ساختار است. به طور دقیق تر، آنچه باید داشته باشید: Json، Yaml، تغییراتی از برخی شرکت های بزرگ که dsl خود را ارائه کردند (HCL در terraform استفاده می شود).

مشکل این است که ممکن است به راحتی حاوی موارد آشنا نباشد:

• متغیرها؛
• شرایط؛
• در جایی هیچ نظری وجود ندارد، به عنوان مثال، در Json، به طور پیش فرض آنها ارائه نمی شوند.
• کارکرد؛
• و من حتی در مورد چیزهای سطح بالایی مانند کلاس ها، ارث و همه چیز صحبت نمی کنم.

2. مشکل دوم چنین کدی این است که اغلب یک محیط ناهمگن است. معمولا شما با سی شارپ می نشینید و کار می کنید، یعنی. با یک زبان، یک پشته، یک اکوسیستم. و در اینجا شما تنوع زیادی از فناوری ها را دارید.

زمانی که bash با پایتون فرآیندی را راه‌اندازی می‌کند که Json در آن قرار می‌گیرد، یک وضعیت بسیار واقعی است. شما آن را تجزیه و تحلیل می کنید، سپس یک ژنراتور دیگر 30 فایل دیگر تولید می کند. برای همه اینها، متغیرهای ورودی از Azure Key Vault دریافت می‌شوند که توسط افزونه‌ای برای drone.io که در Go نوشته شده است به هم متصل می‌شوند و این متغیرها از یامل عبور می‌کنند که در نتیجه تولید از موتور قالب jsonnet ایجاد شده است. وقتی چنین محیط متنوعی دارید، داشتن کد کاملاً خوب و دقیق بسیار دشوار است.

توسعه سنتی در چارچوب یک کار با یک زبان همراه است. در اینجا ما با تعداد زیادی زبان کار می کنیم.

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

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

در زمان نگارش این مطلب افزونه vscode-terraform هنوز برای پشتیبانی از نسخه 0.12 منتشر نشده اند، اگرچه 3 ماه است که منتشر شده است.

وقت آن است که فراموش کنیم ...

1. اشکال زدایی.
2. ابزار بازسازی.
3. تکمیل خودکار
4. تشخیص خطاها در حین کامپایل.

خنده دار است، اما این همچنین زمان توسعه را افزایش می دهد و تعداد خطاهایی را که به طور اجتناب ناپذیر رخ می دهد افزایش می دهد.

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

به عنوان یک مبتدی، شما در حال یادگیری Terraforms هستید و IDE به هیچ وجه به شما کمک نمی کند. وقتی مدارک وجود دارد، وارد شوید و نگاه کنید. اما اگر شما یک زبان برنامه نویسی جدید را وارد می کردید، IDE به شما می گفت که چنین نوعی وجود دارد، اما چنین چیزی وجود ندارد. حداقل در سطح int یا string. این اغلب مفید است.

در مورد آزمایشات چطور؟

شما می‌پرسید: «آقایان برنامه‌نویسان، در مورد تست‌ها چطور؟» بچه های جدی همه چیز را روی تولید آزمایش می کنند، و این سخت است. در اینجا نمونه ای از تست واحد برای یک ماژول terraform از وب سایت آورده شده است مایکروسافت.

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

مشکل واحد تست این است که من و شما می توانیم صحت خروجی Json را بررسی کنیم. من در 5 پارامتر پرتاب کردم و یک پاپوش جیسون با 2000 خط به من دادند. من می توانم آنچه را که در اینجا اتفاق می افتد تجزیه و تحلیل کنم، نتیجه آزمایش را تأیید کنم ...

تجزیه Json در Go دشوار است. و باید در Go بنویسید، زیرا terraform in Go تمرین خوبی برای تست زبانی است که به آن می نویسید. سازماندهی خود کد بسیار ضعیف است. در عین حال، این بهترین کتابخانه برای آزمایش است.

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

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

بیایید ادامه دهیم. اگر هیچ آزمایشی در IaC وجود ندارد، IDE و تنظیم بد هستند، حداقل باید بهترین روش‌ها وجود داشته باشد. من فقط به Google Analytics رفتم و دو عبارت جستجو را مقایسه کردم: Terraform best practices و c# best practices.

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

در مورد درخواست IaC: در اینجا شما سعی می کنید اطلاعات را ذره ذره از گزارش های Highload یا HashiConf، از اسناد رسمی و مسائل متعدد در Github جمع آوری کنید. چگونه این ماژول ها را به طور کلی توزیع کنیم، با آنها چه کنیم؟ به نظر می رسد که این یک مشکل واقعی است ... یک انجمن وجود دارد، آقایان، که برای هر سوالی به شما 10 نظر در Github داده می شود. اما دقیقا اینطور نیست.

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

این همه به کجا می رود و چه باید کرد

می توانید همه چیز را رها کنید و به سی شارپ بازگردید، به دنیای سوار. اما نه. چرا حتی اگر نمی توانید راه حلی پیدا کنید، این کار را به خود زحمت می دهید. در زیر نتیجه گیری ذهنی خود را ارائه می کنم. می توانید در نظرات با من بحث کنید، جالب خواهد بود.

من شخصاً روی چند چیز شرط می بندم:

1. توسعه در این زمینه بسیار سریع اتفاق می افتد. در اینجا برنامه ای از درخواست ها برای DevOps آمده است.

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

   اگر چیزی به این سرعت رشد کند، قطعاً افراد باهوشی ظاهر می شوند که به شما می گویند چه کاری انجام دهید و چه کاری انجام ندهید. افزایش محبوبیت منجر به این واقعیت می شود که شاید کسی فرصت داشته باشد تا بالاخره یک پلاگین را برای vscode به jsonnet اضافه کند، که به شما امکان می دهد به جای جستجوی آن از طریق ctrl+shift+f، به پیاده سازی عملکرد بروید. با تکامل همه چیز، مواد بیشتری ظاهر می شوند. انتشار کتابی از گوگل در مورد SRE نمونه بسیار خوبی از این موضوع است.

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

   یک مثال بی اهمیت: همکاری از طریق برنامه نویسی زوجی. برای فهمیدن آن کمک زیادی می کند. وقتی در نزدیکی همسایه ای دارید که سعی می کند چیزی را بفهمد، با هم بهتر متوجه خواهید شد.

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

نتیجه

علیرغم این واقعیت که استدلال من ممکن است بدبینانه به نظر برسد، من با امید به آینده نگاه می کنم و صمیمانه امیدوارم که همه چیز برای ما (و شما) درست شود.

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

منبع: www.habr.com