بسیاری از مردم Terraform را می شناسند و در کارهای روزانه خود از آن استفاده می کنند، اما بهترین روش ها برای آن هنوز شکل نگرفته است. هر تیمی باید رویکردها و روش های خود را ابداع کند.
تقریباً مطمئناً زیرساخت شما ساده شروع می شود: چند منبع + چند توسعه دهنده. با گذشت زمان، در همه جهات رشد می کند. آیا راه‌هایی برای گروه‌بندی منابع در ماژول‌های Terraform، سازمان‌دهی کدها در پوشه‌ها، و چه چیز دیگری ممکن است اشتباه کند پیدا می‌کنید؟ (کلمات آخر معروف)
زمان می گذرد و شما احساس می کنید زیرساخت شما حیوان خانگی جدید شماست، اما چرا؟ شما نگران تغییرات غیرقابل توضیح در زیرساخت هستید، می ترسید زیرساخت و کد را لمس کنید - در نتیجه عملکرد جدید را به تاخیر می اندازید یا کیفیت را کاهش می دهید ...
پس از سه سال مدیریت مجموعه ای از ماژول های جامعه Terraform برای AWS در Github و نگهداری طولانی مدت Terraform در تولید، آنتون بابنکو آماده است تا تجربه خود را به اشتراک بگذارد: چگونه ماژول های TF را بنویسیم تا در آینده آسیبی به آن وارد نشود.
در پایان سخنرانی، شرکت کنندگان با اصول مدیریت منابع در Terraform، بهترین شیوه های مرتبط با ماژول ها در Terraform و برخی از اصول یکپارچه سازی مداوم مرتبط با مدیریت زیرساخت بیشتر آشنا خواهند شد.
سلب مسئولیت: متذکر می شوم که تاریخ این گزارش نوامبر 2018 است—دو سال از آن گذشته است. نسخه Terraform 2 مورد بحث در گزارش دیگر پشتیبانی نمی شود. در طول 0.11 سال گذشته، 2 نسخه جدید منتشر شده است که شامل نوآوری ها، پیشرفت ها و تغییرات زیادی است. لطفا به این توجه کنید و مستندات را بررسی کنید.
لینک ها:
- +
- - کد و مستندات قالب‌بندی خودکار
- - تولید کننده ماژول های Terraform (WIP)
- - تولید کننده کد Terraform از نمودارهای بصری (WIP)
- www.terraform-best-practices.com
- (پست های جدید در وب سایت شخصی من www.antonbabenko.com/ قرار دارند)
- @antonbabenko - توییتر، و یک سری Slacks مختلف
نام من آنتون بابنکو است. برخی از شما احتمالا از کدی که من نوشتم استفاده کرده اید. اکنون با اطمینان بیشتر از همیشه در مورد این موضوع صحبت خواهم کرد، زیرا به آمار دسترسی دارم.
من روی Terraform کار می کنم و از سال 2015 در تعداد زیادی از پروژه های منبع باز مرتبط با Terraform و Amazon شرکت کننده و مشارکت کننده فعال بوده ام.
از آن زمان تاکنون به اندازه کافی کد نوشته ام تا بتوانم آن را به شیوه ای جالب قرار دهم. و اکنون سعی می کنم در این مورد به شما بگویم.
من در مورد پیچیدگی ها و ویژگی های کار با Terraform صحبت خواهم کرد. اما این واقعاً موضوع HighLoad نیست. و حالا خواهید فهمید که چرا.
با گذشت زمان، شروع به نوشتن ماژول های Terraform کردم. کاربران سوالاتی را نوشتند، من آنها را بازنویسی کردم. سپس من ابزارهای مختلفی را نوشتم تا کد را با استفاده از یک قلاب پیش کامیت و غیره قالب بندی کنم.
پروژه های جالب زیادی وجود داشت. من تولید کد را دوست دارم زیرا دوست دارم رایانه کارهای بیشتری را برای من و برنامه نویس انجام دهد، بنابراین در حال حاضر روی یک تولید کننده کد Terraform از نمودارهای بصری کار می کنم. شاید برخی از شما آنها را دیده باشید. اینها جعبه های زیبا با فلش هستند. و من فکر می کنم عالی است اگر بتوانید روی دکمه "صادرات" کلیک کنید و همه آن را به عنوان کد دریافت کنید.
من اهل اوکراین هستم. من سالها در نروژ زندگی می کنم.
همچنین اطلاعات این گزارش از افرادی که نام مرا می دانند و در شبکه های اجتماعی پیدا کرده اند جمع آوری شده است. من تقریبا همیشه همین نام مستعار را دارم.
همانطور که اشاره کردم، من نگهدارنده اصلی ماژول های Terraform AWS هستم، که یکی از بزرگترین مخازن در GitHub است که در آن ماژول ها را برای رایج ترین وظایف میزبانی می کنیم: VPC، Autoscaling، RDS.
و آنچه اکنون شنیدید ابتدایی ترین آنهاست. اگر شک دارید که Terraform چیست، پس بهتر است وقت خود را در جای دیگری بگذرانید. در اینجا اصطلاحات فنی زیادی وجود خواهد داشت. و دریغ نکردم که سطح گزارش را بالاترین اعلام کنم. این بدان معنی است که من می توانم با استفاده از تمام اصطلاحات ممکن بدون توضیح زیاد صحبت کنم.
Terraform در سال 2014 به عنوان ابزاری ظاهر شد که به شما امکان نوشتن، برنامه ریزی و مدیریت زیرساخت به عنوان کد را می داد. مفهوم کلیدی در اینجا "زیرساخت به عنوان کد" است.
تمام مستندات همانطور که گفتم به داخل نوشته شده است . امیدوارم اکثر مردم درباره این سایت بدانند و مستندات آن را خوانده باشند. اگر چنین است، پس شما در جای درستی هستید.
این همان چیزی است که یک فایل پیکربندی معمولی Terraform به نظر می رسد، جایی که ابتدا چند متغیر را تعریف می کنیم.
در این مورد ما "aws_region" را تعریف می کنیم.
سپس توضیح می دهیم که چه منابعی را می خواهیم ایجاد کنیم.
ما برخی از دستورات را اجرا می کنیم، به ویژه "terraform init" به منظور بارگیری وابستگی ها و ارائه دهندگان.
و دستور "terraform application" را اجرا می کنیم تا بررسی کنیم که آیا پیکربندی مشخص شده با منابعی که ایجاد کرده ایم مطابقت دارد یا خیر. از آنجایی که ما قبلا چیزی ایجاد نکرده‌ایم، Terraform از ما می‌خواهد این منابع را ایجاد کنیم.
ما این را تایید می کنیم. بنابراین ما یک سطل به نام seasnail ایجاد می کنیم.
چندین ابزار مشابه نیز وجود دارد. بسیاری از شما که از آمازون استفاده می کنید، AWS CloudFormation یا Google Cloud Deployment Manager یا Azure Resource Manager را می شناسید. هر یک از آنها پیاده سازی خاص خود را برای مدیریت منابع در هر یک از این ارائه دهندگان ابر عمومی دارند. Terraform به ویژه مفید است زیرا به شما امکان می دهد بیش از 100 ارائه دهنده را مدیریت کنید. (جزئیات بیشتر )
اهدافی که Terraform از همان ابتدا دنبال کرده است:
- Terraform یک نمای واحد از منابع ارائه می دهد.
- به شما امکان می دهد از تمام سیستم عامل های مدرن پشتیبانی کنید.
- و Terraform از همان ابتدا به عنوان ابزاری طراحی شده بود که به شما امکان می دهد زیرساخت را به صورت ایمن و قابل پیش بینی تغییر دهید.
در سال 2014، کلمه "قابل پیش بینی" در این زمینه بسیار غیرعادی به نظر می رسید.
Terraform یک ابزار جهانی است. اگر یک API دارید، می توانید کاملاً همه چیز را کنترل کنید:
- شما می توانید از بیش از 120 ارائه دهنده برای مدیریت هر چیزی که می خواهید استفاده کنید.
- به عنوان مثال، می توانید از Terraform برای توصیف دسترسی به مخازن GitHub استفاده کنید.
- حتی می توانید باگ هایی را در Jira ایجاد و ببندید.
- می توانید معیارهای New Relic را مدیریت کنید.
- حتی اگر واقعاً بخواهید می توانید فایل هایی را در دراپ باکس ایجاد کنید.
همه اینها با استفاده از ارائه دهندگان Terraform، که یک API باز دارند که می تواند در Go توضیح داده شود، به دست می آید.
فرض کنید ما شروع به استفاده از Terraform کردیم، برخی از اسناد را در سایت خواندیم، چند ویدیو را تماشا کردیم و شروع به نوشتن main.tf کردیم، همانطور که در اسلایدهای قبلی نشان دادم.
و همه چیز عالی است، شما یک فایل دارید که یک VPC ایجاد می کند.
اگر می خواهید یک VPC ایجاد کنید، تقریباً این 12 خط را مشخص می کنید. توضیح دهید که در کدام منطقه می خواهید ایجاد کنید، از کدام cidr_block از آدرس های IP استفاده کنید. همین.
طبیعتا این پروژه به تدریج رشد خواهد کرد.
و شما تعداد زیادی چیزهای جدید را به آنجا اضافه خواهید کرد: منابع، منابع داده، با ارائه دهندگان جدید ادغام خواهید شد، ناگهان می خواهید از Terraform برای مدیریت کاربران در حساب GitHub خود و غیره استفاده کنید. ممکن است بخواهید از آن استفاده کنید. ارائه دهندگان DNS مختلف، از همه چیز عبور کنید. Terraform این کار را آسان می کند.
بیایید به مثال زیر نگاه کنیم.
شما به تدریج internet_gateway را اضافه می کنید زیرا می خواهید منابع VPC خود به اینترنت دسترسی داشته باشند. این ایده خوبی است.
نتیجه این main.tf است:
این قسمت بالای main.tf است.
این قسمت پایین main.tf است.
سپس زیر شبکه را اضافه می کنید. تا زمانی که بخواهید دروازه‌های NAT، مسیرها، جداول مسیریابی و تعدادی زیرشبکه دیگر را اضافه کنید، 38 خط ندارید، بلکه تقریباً 200-300 خط خواهید داشت.
یعنی فایل main.tf شما کم کم در حال رشد است. و اغلب مردم همه چیز را در یک فایل قرار می دهند. 10-20 کیلوبایت در main.tf ظاهر می شود. تصور کنید که 10-20 کیلوبایت محتوای متنی است. و همه چیز به همه چیز متصل است. این به تدریج کار کردن با آن دشوار می شود. 10-20 کیلوبایت یک مورد کاربری خوب است، گاهی اوقات بیشتر. و مردم همیشه فکر نمی کنند که این بد است.
همانطور که در برنامه نویسی معمولی، یعنی نه زیرساخت به عنوان کد، ما به استفاده از دسته ای از کلاس ها، بسته ها، ماژول ها، گروه بندی های مختلف عادت کرده ایم. Terraform به شما این امکان را می دهد که تقریباً همان کار را انجام دهید.
- کد در حال رشد است.
- وابستگی بین منابع نیز در حال افزایش است.
و ما یک نیاز بزرگ و بزرگ داریم. ما درک می کنیم که دیگر نمی توانیم اینگونه زندگی کنیم. کد ما در حال تبدیل شدن بسیار زیاد است. البته 10-20 کیلوبایت خیلی وسیع نیست، اما ما فقط در مورد پشته شبکه صحبت می کنیم، یعنی شما فقط منابع شبکه را اضافه کرده اید. ما در مورد Application Load Balancer، Deployment ES Cluster، Kubernetes و غیره صحبت نمی کنیم، جایی که 100 Kb می تواند به راحتی در آن بافته شود. اگر همه این ها را یادداشت کنید، خیلی زود متوجه خواهید شد که Terraform ماژول های Terraform را ارائه می دهد.
ماژول های Terraform یک پیکربندی Terraform مستقل هستند که به عنوان یک گروه مدیریت می شوند. این تنها چیزی است که باید در مورد ماژول های Terraform بدانید. آنها به هیچ وجه باهوش نیستند، آنها به شما اجازه نمی دهند بسته به چیزی ارتباط پیچیده برقرار کنید. همه اینها بر دوش توسعه دهندگان است. یعنی این فقط نوعی پیکربندی Terraform است که قبلاً نوشته اید. و شما به سادگی می توانید آن را به عنوان یک گروه تماس بگیرید.
بنابراین ما سعی می کنیم بفهمیم که چگونه 10-20-30 کیلوبایت کد خود را بهینه می کنیم. ما به تدریج متوجه می شویم که باید از برخی ماژول ها استفاده کنیم.
اولین نوع ماژول هایی که با آن مواجه می شوید ماژول های منبع هستند. آنها نمی دانند زیرساخت شما چیست، کسب و کار شما چیست، کجا و چه شرایطی دارد. اینها دقیقاً ماژول‌هایی هستند که من، همراه با جامعه متن‌باز، مدیریت می‌کنیم، و ما آنها را به عنوان بلوک‌های اولیه برای زیرساخت شما معرفی می‌کنیم.
نمونه ای از یک ماژول منبع.
وقتی یک ماژول منبع را فراخوانی می کنیم، مشخص می کنیم که محتوای آن را از کدام مسیر بارگذاری کنیم.
ما نشان می دهیم که کدام نسخه را می خواهیم دانلود کنیم.
ما یکسری استدلال را آنجا رد می کنیم. همین. این تمام چیزی است که باید در هنگام استفاده از این ماژول بدانیم.
بسیاری از مردم فکر می کنند که اگر از آخرین نسخه استفاده کنند، همه چیز پایدار خواهد بود. اما نه. زیرساخت باید نسخه شود؛ ما باید به وضوح پاسخ دهیم که این یا آن مؤلفه در کدام نسخه مستقر شده است.
در اینجا کدی که در داخل این ماژول قرار دارد آمده است. ماژول گروه امنیتی در اینجا طومار به خط 640 می رود. ایجاد یک منبع امنیتی در آمازون در هر پیکربندی ممکن، یک کار بسیار بی اهمیت است. تنها ایجاد یک گروه امنیتی و گفتن اینکه چه قوانینی باید به آن منتقل شود کافی نیست. بسیار ساده خواهد بود. میلیون ها محدودیت مختلف در داخل آمازون وجود دارد. مثلا اگر استفاده می کنید نقطه پایانی VPC، لیست پیشوندها، API های مختلف و سعی می کند همه اینها را با هر چیز دیگری ترکیب کند، سپس Terraform به شما اجازه این کار را نمی دهد. و API آمازون نیز این اجازه را نمی دهد. بنابراین، ما باید تمام این منطق وحشتناک را در یک ماژول پنهان کنیم و به کاربر کدی بدهیم که دقیقاً شبیه این است.
کاربر نیازی به دانستن نحوه ساخت داخل آن ندارد.
ماژول‌های نوع دوم، که از ماژول‌های منبع تشکیل شده‌اند، مشکلاتی را حل می‌کنند که برای کسب‌وکار شما کاربرد بیشتری دارند. اغلب این مکانی است که توسعه Terraform است و مقادیر سفت و سختی را برای برچسب ها، برای استانداردهای شرکت تعیین می کند. همچنین می‌توانید قابلیت‌هایی را اضافه کنید که Terraform در حال حاضر به شما اجازه استفاده از آن را نمی‌دهد. این در حال حاضر است. در حال حاضر نسخه 0.11، که در شرف تبدیل شدن به چیزی از گذشته است. اما با این حال، پیش پردازشگرها، jsonnet، کوکی‌کاتر و یک سری چیزهای دیگر مکانیسم کمکی هستند که باید برای کار تمام عیار مورد استفاده قرار گیرند.
در ادامه چند نمونه از این را نشان خواهم داد.
ماژول زیرساخت دقیقاً به همین روش فراخوانی می شود.
منبعی که از کجا می توان محتوا را دانلود کرد ذکر شده است.
دسته ای از مقادیر به این ماژول منتقل می شوند و به آن منتقل می شوند.
در مرحله بعد، در داخل این ماژول، دسته ای از ماژول های منبع برای ایجاد VPC یا Application Load Balancer یا ایجاد یک گروه امنیتی یا برای یک خوشه Elastic Container Service فراخوانی می شوند.
دو نوع ماژول وجود دارد. درک این موضوع مهم است زیرا بیشتر اطلاعاتی که در این گزارش گروه بندی کرده ام در مستندات نوشته نشده است.
و مستندات موجود در Terraform در حال حاضر کاملاً مشکل ساز است زیرا فقط می گوید این ویژگی ها وجود دارد، می توانید از آنها استفاده کنید. اما او نمی گوید چگونه از این ویژگی ها استفاده کنیم، چرا بهتر است از آنها استفاده کنیم. بنابراین، تعداد بسیار زیادی از مردم چیزی می نویسند که نمی توانند با آن زندگی کنند.
بیایید نگاهی به نحوه نوشتن این ماژول ها بیندازیم. سپس نحوه فراخوانی آنها و نحوه کار با کد را خواهیم دید.
Terraform Registry -
نکته شماره 0 این است که ماژول های منبع را ننویسید. اکثر این ماژول ها قبلاً برای شما نوشته شده اند. همانطور که گفتم، آنها متن باز هستند، هیچ منطق تجاری شما را شامل نمی شوند، مقادیر کدگذاری شده برای آدرس های IP، رمز عبور و غیره ندارند. ماژول بسیار انعطاف پذیر است. و به احتمال زیاد قبلاً نوشته شده است. ماژول های زیادی برای منابع از آمازون وجود دارد. حدود 650. و اکثرا کیفیت خوبی دارند.
در این مثال، شخصی نزد شما آمد و گفت: «من می‌خواهم بتوانم یک پایگاه داده را مدیریت کنم. یک ماژول ایجاد کنید تا بتوانم یک پایگاه داده ایجاد کنم." شخص از جزئیات پیاده سازی آمازون یا Terraform اطلاعی ندارد. او به سادگی می گوید: "من می خواهم MSSQL را مدیریت کنم." یعنی منظور ما این است که ماژول ما را صدا بزند، نوع موتور را در آنجا پاس کند و منطقه زمانی را نشان دهد.
و شخص نباید بداند که ما دو منبع مختلف را در داخل این ماژول ایجاد خواهیم کرد: یکی برای MSSQL، دومی برای هر چیز دیگری، فقط به این دلیل که در Terraform 0.11 نمی توانید مقادیر منطقه زمانی را به عنوان اختیاری تعیین کنید.
و در خروج از این ماژول، یک شخص قادر خواهد بود به سادگی یک آدرس دریافت کند. او نمی داند که ما از کدام پایگاه داده، از کدام منبع این همه را در داخل ایجاد می کنیم. این یک عنصر بسیار مهم پنهان کاری است. و این نه تنها در مورد آن دسته از ماژول هایی که در متن باز عمومی هستند، بلکه در مورد ماژول هایی که در پروژه ها و تیم های خود می نویسید نیز صدق می کند.
این استدلال دوم است که اگر مدتی است از Terraform استفاده می کنید بسیار مهم است. شما یک مخزن دارید که تمام ماژول های Terraform خود را برای شرکت خود در آن قرار می دهید. و این کاملا طبیعی است که با گذشت زمان این پروژه به حجم یک یا دو مگابایت برسد. این خوبه.
اما مشکل این است که Terraform چگونه این ماژول ها را صدا می کند. به عنوان مثال، اگر شما یک ماژول را برای ایجاد هر کاربر جداگانه فراخوانی کنید، Terraform ابتدا کل مخزن را بارگیری می کند و سپس به پوشه ای که آن ماژول خاص در آن قرار دارد هدایت می شود. به این ترتیب هر بار یک مگابایت دانلود خواهید کرد. اگر 100 یا 200 کاربر را مدیریت کنید، 100 یا 200 مگابایت دانلود می کنید و سپس به آن پوشه می روید. بنابراین طبیعتاً نمی‌خواهید هر بار که «Terraform init» را فشار می‌دهید، مجموعه‌ای از موارد را دانلود کنید.
دو راه حل برای این مشکل وجود دارد. اولین مورد استفاده از مسیرهای نسبی است. به این ترتیب در کد نشان می دهید که پوشه محلی (./) است. و قبل از راه اندازی هر چیزی، یک کلون Git از این مخزن را به صورت محلی انجام می دهید. به این ترتیب شما یک بار این کار را انجام می دهید.
البته معایب زیادی هم دارد. به عنوان مثال، شما نمی توانید از نسخه سازی استفاده کنید. و گاهی اوقات زندگی با آن دشوار است.
راه حل دوم اگر زیر ماژول‌های زیادی دارید و قبلاً نوعی خط لوله ایجاد شده دارید، پروژه MBT وجود دارد که به شما امکان می‌دهد بسته‌های مختلف زیادی را از یک مخزن تکی جمع‌آوری کرده و آنها را در S3 آپلود کنید. این یک راه بسیار خوب است. بنابراین، فایل iam-user-1.0.0.zip تنها 1 کیلوبایت وزن خواهد داشت، زیرا کد ایجاد این منبع بسیار کوچک است. و خیلی سریعتر کار خواهد کرد.
بیایید در مورد آنچه که نمی توان در ماژول ها استفاده کرد صحبت کنیم.
چرا این شر در ماژول ها وجود دارد؟ بدترین چیز این است که کاربر را فرض کنید. فرض کنید کاربر یک گزینه تأیید هویت ارائه دهنده است که می تواند توسط افراد مختلف استفاده شود. به عنوان مثال، همه ما نقش را جذب خواهیم کرد. این بدان معناست که Terraform این نقش را بر عهده خواهد گرفت. و سپس با این نقش اقدامات دیگری را انجام خواهد داد.
و بد این است که اگر واسیا دوست دارد به یک روش به آمازون وصل شود، مثلاً با استفاده از متغیر محیط پیش فرض، و پتیا دوست دارد از کلید مشترک خود که در یک مکان مخفی دارد استفاده کند، نمی توانید هر دو را در یک مکان مشخص کنید. Terraform. و برای اینکه آنها رنج را تجربه نکنند، نیازی به نشان دادن این بلوک در ماژول نیست. این باید در سطح بالاتر نشان داده شود. یعنی ما یک ماژول منبع، یک ماژول زیرساخت و یک ترکیب در بالا داریم. و این باید در جایی بالاتر نشان داده شود.
شر دوم، روزی دهنده است. در اینجا شر آنقدرها هم پیش پا افتاده نیست، زیرا اگر کد می نویسید و برای شما کار می کند، ممکن است فکر کنید که اگر کار می کند، پس چرا آن را تغییر دهید.
بد این است که شما همیشه کنترل نمی کنید که این تامین کننده در ابتدا چه زمانی راه اندازی شود. و ثانیاً، شما کنترل نمی کنید که aws ec2 به چه معناست، یعنی الان در مورد لینوکس یا ویندوز صحبت می کنیم. بنابراین شما نمی توانید چیزی بنویسید که در سیستم عامل های مختلف یا برای موارد کاربری مختلف یکسان عمل کند.
رایج ترین مثال، که در مستندات رسمی نیز ذکر شده است، این است که اگر aws_instance را بنویسید و دسته ای از آرگومان ها را مشخص کنید، اگر ارائه دهنده "local-exec" را در آنجا مشخص کنید و ansible- خود را اجرا کنید اشکالی ندارد. کتاب بازی .
در واقع، بله، هیچ اشکالی در این مورد وجود ندارد. اما به معنای واقعی کلمه به زودی متوجه خواهید شد که این چیز محلی-exec، به عنوان مثال، در launch_configuration وجود ندارد.
و هنگامی که از launch_configuration استفاده می کنید و می خواهید یک گروه مقیاس پذیر خودکار از یک نمونه ایجاد کنید، در launch_configuration مفهومی از "provisioner" وجود ندارد. مفهوم "داده های کاربر" وجود دارد.
بنابراین، یک راه حل جهانی تر، استفاده از داده های کاربر است. و یا در خود نمونه، هنگامی که نمونه روشن است، یا در همان داده های کاربر، زمانی که گروه مقیاس خودکار از این launch_configuration استفاده می کند، راه اندازی می شود.
اگر هنوز هم می‌خواهید ارائه‌دهنده را اجرا کنید، چون یک جزء چسبنده است، وقتی یک منبع ایجاد می‌شود، در آن لحظه باید ارائه‌دهنده، فرمان خود را اجرا کنید. از این قبیل موقعیت ها زیاد است.
و صحیح ترین منبع برای این کار null_resource نام دارد. Null_resource یک منبع ساختگی است که هرگز واقعاً ایجاد نمی شود. هیچ چیزی را لمس نمی کند، نه API، نه مقیاس خودکار. اما به شما امکان می دهد زمان اجرای دستور را کنترل کنید. در این حالت دستور در حین ایجاد اجرا می شود.
پیوند
چندین نشانه وجود دارد. من به همه نشانه ها با جزئیات زیاد نمی پردازم. مقاله ای در این مورد وجود دارد. اما اگر با Terraform کار کرده‌اید یا از ماژول‌های دیگران استفاده کرده‌اید، اغلب متوجه شده‌اید که بسیاری از ماژول‌ها، مانند اکثر کدهای متن باز، توسط افراد برای نیازهای خودشان نوشته شده‌اند. مردی نوشت و مشکلش را حل کرد. من آن را در GitHub گیر کردم، بگذارید زنده بماند. زنده خواهد ماند، اما اگر هیچ سند و نمونه ای وجود نداشته باشد، هیچ کس از آن استفاده نخواهد کرد. و اگر هیچ عملکردی وجود نداشته باشد که به شما امکان می دهد کمی بیشتر از وظیفه خاص خود را حل کنید ، هیچ کس نیز از آن استفاده نخواهد کرد. راه های زیادی برای از دست دادن کاربران وجود دارد.
اگر می خواهید چیزی بنویسید تا مردم از آن استفاده کنند، توصیه می کنم این علائم را دنبال کنید.
این ها عبارتند از:
- مستندات و نمونه ها
- عملکرد کامل.
- پیش فرض های معقول
- کد پاک
- آزمایشات
تست ها وضعیت متفاوتی دارند زیرا نوشتن آنها بسیار دشوار است. من بیشتر به مستندات و مثال ها اعتقاد دارم.
بنابراین، ما نحوه نوشتن ماژول ها را بررسی کردیم. دو استدلال وجود دارد. اولین مورد، که مهمترین آن است، این است که اگر می توانید ننویسید، زیرا یک سری افراد قبلاً این وظایف را قبل از شما انجام داده اند. و ثانیاً، اگر هنوز تصمیم دارید، سعی کنید از ارائه دهندگان در ماژول ها و ارائه دهندگان استفاده نکنید.
این قسمت خاکستری مستندات است. اکنون ممکن است فکر کنید: «چیزی نامشخص است. متقاعد نشده است." اما شش ماه دیگر خواهیم دید.
حالا بیایید در مورد نحوه فراخوانی این ماژول ها صحبت کنیم.
ما درک می کنیم که کد ما در طول زمان رشد می کند. ما دیگر یک فایل نداریم، ما در حال حاضر 20 فایل داریم. همه آنها در یک پوشه هستند. یا شاید در پنج پوشه. شاید ما به نوعی شروع به تجزیه آنها بر اساس منطقه، بر اساس برخی مؤلفه ها کرده ایم. سپس می‌فهمیم که اکنون مقدماتی از هماهنگ‌سازی و ارکستراسیون داریم. یعنی باید بفهمیم که اگر منابع شبکه را تغییر دادیم باید چه کنیم، با بقیه منابعمان چه کنیم، چگونه این وابستگی ها را ایجاد کنیم و غیره.
دو افراط وجود دارد. افراط اول همه در یک است. ما یک فایل اصلی داریم. در حال حاضر، این بهترین تمرین رسمی در وب سایت Terraform بود.
اما اکنون به عنوان منسوخ نوشته شده و حذف شده است. با گذشت زمان، جامعه Terraform متوجه شد که این با بهترین روش فاصله دارد، زیرا مردم شروع به استفاده از پروژه به روش‌های مختلف کردند. و مشکلاتی وجود دارد. به عنوان مثال، وقتی همه وابستگی ها را در یک مکان فهرست می کنیم. شرایطی وجود دارد که روی "طرح Terraform" کلیک می کنیم و تا زمانی که Terraform وضعیت همه منابع را به روز کند، زمان زیادی می گذرد.
زمان زیادی برای مثال 5 دقیقه است. برای برخی این زمان زیادی است. من مواردی را دیده ام که 15 دقیقه طول کشیده است. API AWS 15 دقیقه صرف تلاش کرد تا بفهمد با وضعیت هر منبع چه اتفاقی می‌افتد. این یک منطقه بسیار بزرگ است.
و طبیعتاً وقتی می‌خواهید چیزی را در یک مکان تغییر دهید، یک مشکل مرتبط ظاهر می‌شود، سپس 15 دقیقه صبر می‌کنید و یک بوم از برخی تغییرات به شما می‌دهد. تف انداختی، نوشتی «بله» و مشکلی پیش آمد. این یک مثال بسیار واقعی است. Terraform سعی نمی کند شما را در برابر مشکلات محافظت کند. یعنی هر چه می خواهی بنویس. مشکلاتی وجود خواهد داشت - مشکلات شما. در حالی که Terraform 0.11 به هیچ وجه سعی نمی کند به شما کمک کند. مکان های جالب خاصی در 0.12 وجود دارد که به شما امکان می دهد بگویید: "واسیا، تو واقعاً این را می خواهی، آیا می توانی به خود بیایی؟"
راه دوم کاهش این ناحیه است، یعنی تماس ها از یک مکان کمتر می توانند از مکان دیگر وصل شوند.
تنها مشکل این است که باید کد بیشتری بنویسید، یعنی باید متغیرها را در تعداد زیادی فایل توصیف کنید و این را به روز کنید. برخی از مردم آن را دوست ندارند. این برای من عادی است. و برخی از مردم فکر می کنند: "چرا این را در مکان های مختلف بنویسم، من همه آن را در یک مکان قرار می دهم." این ممکن است، اما این افراط دوم است.
چه کسی این همه زندگی را در یک مکان دارد؟ یک، دو، سه نفر، یعنی یک نفر از آن استفاده می کند.
و چه کسی یک جزء خاص، یک بلوک یا یک ماژول زیرساخت را فراخوانی می کند؟ پنج تا هفت نفر. این باحاله
رایج ترین پاسخ جایی در وسط است. اگر پروژه بزرگ باشد، اغلب در موقعیتی قرار می گیرید که هیچ راه حلی مناسب نیست و همه چیز در آنجا کار نمی کند، بنابراین در نهایت با یک مخلوط مواجه می شوید. این هیچ اشکالی ندارد، به شرطی که بدانید هر دو مزیت هایی دارند.
اگر چیزی در پشته VPC تغییر کرد و می‌خواستید این تغییرات را در EC2 اعمال کنید، یعنی می‌خواهید گروه مقیاس‌بندی خودکار را به‌روزرسانی کنید زیرا یک زیرشبکه جدید دارید، آنگاه من به این نوع ارکستراسیون وابستگی می‌گویم. چند راه حل وجود دارد: چه کسی از چه چیزی استفاده می کند؟
می توانم پیشنهاد کنم چه راه حل هایی وجود دارد. می توانید از Terraform برای انجام جادو استفاده کنید یا می توانید از makefiles برای استفاده از Terraform استفاده کنید. و ببینید آیا چیزی در آنجا تغییر کرده است، می توانید آن را در اینجا راه اندازی کنید.
این تصمیم را چگونه دوست دارید؟ آیا کسی معتقد است که این یک راه حل جالب است؟ من لبخندی می بینم، ظاهراً شک و تردید در وجودم رخنه کرده است.
البته این را در خانه امتحان نکنید. Terraform هرگز برای اجرا از Terraform طراحی نشده است.
در یک گزارش آنها به من گفتند: "نه، این کار نمی کند." نکته این است که نباید کار کند. اگر چه زمانی که می‌توانید Terraform را از Terraform و سپس Terraform را راه‌اندازی کنید بسیار چشمگیر به نظر می‌رسد، نباید این کار را انجام دهید. Terraform همیشه باید خیلی راحت شروع شود.
اگر زمانی که چیزی در یک مکان تغییر کرده است به ارکستراسیون تماس نیاز دارید، Terragrunt وجود دارد.
Terragrunt ابزاری است، افزونه‌ای برای Terraform، که به شما امکان می‌دهد تماس‌ها را با ماژول‌های زیرساخت هماهنگ و هماهنگ کنید.
یک فایل پیکربندی Terraform معمولی شبیه این است.
شما مشخص می کنید که کدام ماژول خاص را می خواهید فراخوانی کنید.
ماژول چه وابستگی هایی دارد؟
و این ماژول چه استدلال هایی را می پذیرد. این تمام چیزی است که درباره Terragrunt باید بدانید.
اسناد موجود است و 1 ستاره در GitHub وجود دارد. اما در بیشتر موارد این چیزی است که باید بدانید. و این در شرکت هایی که تازه شروع به کار با Terraform کرده اند بسیار آسان است.
بنابراین ارکستراسیون Terragrunt است. گزینه های دیگری نیز وجود دارد.
حالا بیایید در مورد نحوه کار با کد صحبت کنیم.
اگر نیاز به افزودن ویژگی های جدید به کد خود دارید، در بیشتر موارد این کار آسان است. شما در حال نوشتن یک منبع جدید هستید، همه چیز ساده است.
اگر منبعی دارید که از قبل ایجاد کرده اید، به عنوان مثال، پس از باز کردن یک حساب AWS با Terraform آشنا شده اید و می خواهید از منابعی که در حال حاضر دارید استفاده کنید، پس مناسب است که ماژول خود را به این روش گسترش دهید، به طوری که استفاده از منابع موجود را پشتیبانی می کند.
و از ایجاد منابع جدید با استفاده از منبع بلوک پشتیبانی کرد.
در خروجی، بسته به آنچه استفاده شده است، همیشه شناسه خروجی را برمی گردانیم.
دومین مشکل بسیار مهم در Terraform 0.11 کار با لیست ها است.
مشکل این است که اگر چنین لیستی از کاربران داشته باشیم.
و وقتی این کاربران را با استفاده از منبع بلوک ایجاد می کنیم، همه چیز خوب پیش می رود. کل لیست را مرور می کنیم و برای هر کدام یک فایل ایجاد می کنیم. همه چیز خوب است. و بعد مثلا user3 که وسط هست باید از اینجا حذف بشه بعد همه منابعی که بعد از اون ایجاد شده دوباره ایجاد میشه چون ایندکس عوض میشه.
کار با لیست ها در یک محیط حالت دار محیط دولتی چیست؟ این وضعیتی است که با ایجاد این منبع یک مقدار جدید ایجاد می شود. به عنوان مثال، AWS Access Key یا AWS Secret Key، یعنی وقتی کاربر ایجاد می کنیم، یک Access یا Secret Key جدید دریافت می کنیم. و هر بار که یک کاربر را حذف می کنیم، این کاربر یک کلید جدید خواهد داشت. اما این فنگ شویی نیست، زیرا کاربر نمی خواهد با ما دوست شود اگر هر بار که فردی تیم را ترک می کند یک کاربر جدید برای او ایجاد کنیم.
این راه حل است. این کد در Jsonnet نوشته شده است. Jsonnet یک زبان قالب از گوگل است.
این دستور به شما این امکان را می دهد که این قالب را بپذیرید و به عنوان خروجی یک فایل json را که مطابق با قالب شما ساخته شده است، برمی گرداند.
قالب به این شکل است.
Terraform به شما این امکان را می دهد که با HCL و Json به طور یکسان کار کنید، بنابراین اگر توانایی تولید Json را دارید، می توانید آن را در Terraform قرار دهید. فایل با پسوند .tf.json با موفقیت دانلود می شود.
و سپس طبق معمول با آن کار می کنیم: terraform init، terramorm application. و دو کاربر ایجاد می کنیم.
حالا اگر کسی از تیم برود نمی ترسیم. ما فقط فایل json را ویرایش می کنیم. واسیا پوپکین رفت، پتیا پیاتوچکین ماند. پتیا پیاتوچکین کلید جدیدی دریافت نخواهد کرد.
ادغام Terraform با ابزارهای دیگر واقعاً کار Terraform نیست. Terraform به عنوان بستری برای ایجاد منابع ایجاد شد و بس. و هر چیزی که بعداً مطرح می‌شود، دغدغه Terraform نیست. و نیازی به بافتن آن در آنجا نیست. Ansible وجود دارد که هر کاری را که نیاز دارید انجام می دهد.
اما موقعیت‌هایی پیش می‌آیند که می‌خواهیم Terraform را گسترش دهیم و پس از اتمام کار، دستوری را فراخوانی کنیم.
راه اول ما یک خروجی ایجاد می کنیم که در آن این دستور را می نویسیم.
و سپس این دستور را از خروجی shell terraform فراخوانی می کنیم و مقدار مورد نظر خود را مشخص می کنیم. بنابراین، دستور با تمام مقادیر جایگزین اجرا می شود. خیلی راحت است.
راه دوم این استفاده از null_resource بسته به تغییرات در زیرساخت ما است. به محض تغییر شناسه برخی منابع، می توانیم همان local-exe را فراخوانی کنیم.
به طور طبیعی، همه اینها روی کاغذ صاف است، زیرا آمازون، مانند سایر ارائه دهندگان عمومی، دسته ای از موارد لبه خود را دارد.
رایج ترین مورد لبه این است که وقتی یک حساب AWS باز می کنید، مهم است که از کدام مناطق استفاده می کنید. آیا این ویژگی در آنجا فعال است؟ شاید بعد از دسامبر 2013 آن را باز کردید. شاید شما از پیش فرض در VPC و غیره استفاده می کنید. محدودیت های زیادی وجود دارد. و آمازون آنها را در سراسر اسناد پراکنده کرد.
چند چیز وجود دارد که توصیه می کنم از آنها اجتناب کنید.
برای شروع، از همه استدلال‌های غیرمحرمانه در طرح Terraform یا Terraform CLI اجتناب کنید. همه اینها را می توان در یک فایل tfvars یا در یک متغیر محیطی قرار داد.
اما لازم نیست کل این دستور جادویی را به خاطر بسپارید. طرح Terraform – var و ما می رویم. متغیر اول var، متغیر دوم var، متغیر سوم، چهارم است. مهمترین اصل زیرساخت به عنوان کد که من اغلب از آن استفاده می کنم این است که فقط با نگاه کردن به کد، باید درک روشنی از آنچه در آنجا مستقر شده است، در چه وضعیتی و با چه مقادیری وجود دارد داشته باشم. و بنابراین من مجبور نیستم اسناد را بخوانم یا از واسیا بپرسم که از چه پارامترهایی برای ایجاد خوشه ما استفاده کرده است. من فقط باید یک فایل با پسوند tfvars که اغلب با محیط مطابقت دارد باز کنم و همه چیز را آنجا نگاه کنم.
همچنین، از آرگومان های هدف برای کاهش دامنه استفاده نکنید. برای این کار استفاده از ماژول های زیرساخت کوچک بسیار ساده تر است.
همچنین نیازی به محدودیت و افزایش موازی سازی نیست. اگر من 150 منبع داشته باشم و بخواهم موازی سازی آمازون را از 10 به 100 افزایش دهم، به احتمال زیاد مشکلی پیش خواهد آمد. یا ممکن است اکنون به خوبی پیش برود، اما وقتی آمازون می گوید که شما بیش از حد تماس می گیرید، با مشکل مواجه خواهید شد.
Terraform سعی می کند بیشتر این مشکلات را دوباره راه اندازی کند، اما تقریباً به هیچ چیز نخواهید رسید. Parallelism=1 نکته مهمی است که اگر در داخل API AWS یا داخل ارائه دهنده Terraform به اشکالی برخورد کردید باید از آن استفاده کنید. و سپس باید مشخص کنید: parallelism=1 و منتظر بمانید تا Terraform یک تماس، سپس دوم و سپس سوم را تمام کند. او آنها را یکی یکی راه اندازی خواهد کرد.
مردم اغلب از من می پرسند، "چرا فکر می کنم فضاهای کاری Terraform بد هستند؟" من معتقدم که اصل زیرساخت به عنوان کد این است که ببینیم چه زیرساختی و با چه ارزش هایی ایجاد شده است.
فضاهای کاری توسط کاربران ایجاد نشده است. این بدان معنا نیست که کاربران در مسائل GitHub نوشته اند که ما نمی توانیم بدون فضاهای کاری Terraform زندگی کنیم. نه اینجوری نیست Terraform Enterprise یک راه حل تجاری است. Terraform از HashiCorp به این نتیجه رسید که ما به فضای کاری نیاز داریم، بنابراین آن را حذف کردیم. برای من خیلی راحت تر است که آن را در یک پوشه جداگانه قرار دهم. سپس فایل های کمی بیشتر خواهد بود، اما واضح تر خواهد بود.
چگونه با کد کار کنیم؟ در واقع کار با لیست ها تنها درد است. و Terraform را آسان تر کنید. این چیزی نیست که همه چیز را برای شما عالی انجام دهد. نیازی نیست همه چیزهایی که در اسناد نوشته شده است را به آنجا بریزید.
موضوع گزارش "برای آینده" نوشته شده است. من در این مورد خیلی کوتاه صحبت می کنم. برای آینده، این بدان معنی است که 0.12 به زودی منتشر خواهد شد.
0.12 تعداد زیادی چیز جدید است. اگر از برنامه‌نویسی معمولی آمده‌اید، انواع بلوک‌های پویا، حلقه‌ها، عملیات مقایسه‌ای صحیح و شرطی را از دست می‌دهید، جایی که سمت چپ و راست به طور همزمان محاسبه نمی‌شوند، اما بسته به موقعیت. شما خیلی آن را از دست می دهید، بنابراین 0.12 آن را برای شما حل می کند.
ولی! اگر با استفاده از ماژول های آماده و راه حل های شخص ثالث کمتر و ساده تر می نویسید، دیگر لازم نیست منتظر بمانید و امیدوار باشید که 0.12 بیاید و همه چیز را برای شما درست کند.
با تشکر از گزارش! شما در مورد زیرساخت به عنوان کد صحبت کردید و به معنای واقعی کلمه یک کلمه در مورد تست ها گفتید. آیا تست در ماژول ها لازم است؟ این مسئولیت کیست؟ آیا باید خودم آن را بنویسم یا این به عهده ماژول ها است؟
سال آینده پر از گزارش هایی خواهد بود که ما تصمیم گرفته ایم همه چیز را آزمایش کنیم. چه چیزی را تست کنیم بزرگترین سوال است. وابستگی های زیادی وجود دارد، محدودیت های زیادی از سوی ارائه دهندگان مختلف وجود دارد. وقتی من و شما در حال صحبت هستیم و می گویید: "من به آزمایش نیاز دارم"، سپس می پرسم: "چه چیزی را آزمایش خواهید کرد؟" شما می گویید که در منطقه خود تست خواهید کرد. بعد می گویم این در منطقه من کار نمی کند. یعنی ما حتی نمی توانیم در این مورد به توافق برسیم. ناگفته نماند که مشکلات فنی زیادی وجود دارد. یعنی چگونه این تست ها را بنویسیم تا به اندازه کافی باشند.
من به طور فعال در حال تحقیق در مورد این موضوع هستم، یعنی چگونه می توان به طور خودکار آزمایش ها را بر اساس زیرساختی که نوشتید تولید کرد. یعنی اگر شما این کد را نوشته اید، پس من باید آن را اجرا کنم، بر این اساس می توانم تست هایی ایجاد کنم.
یکی از کتابخانه هایی است که اغلب ذکر شده است که به شما امکان می دهد تست های یکپارچه سازی برای Terraform بنویسید. این یکی از برنامه های کاربردی است. من نوع DSL را ترجیح می دهم، به عنوان مثال، rspec.
آنتون، ممنون از گزارش! اسم من والری است. اجازه بدهید یک سوال فلسفی کوچک بپرسم. وجود دارد، مشروط، تامین، استقرار وجود دارد. تدارک زیرساخت من را ایجاد می کند، در هنگام استقرار آن را با چیزهای مفید پر می کنیم، به عنوان مثال، سرورها، برنامه ها و غیره. و در ذهن من است که Terraform بیشتر برای تامین است، و Ansible بیشتر برای استقرار است، زیرا Ansible برای زیرساخت فیزیکی نیز است. به شما اجازه می دهد تا nginx، Postgres را نصب کنید. اما در عین حال، به نظر می‌رسد که Ansible اجازه می‌دهد تا مثلاً منابع آمازون یا گوگل را تأمین کند. اما Terraform همچنین به شما اجازه می دهد تا برخی از نرم افزارها را با استفاده از ماژول های خود مستقر کنید. از نظر شما، آیا نوعی مرز بین Terraform و Ansible وجود دارد، از کجا و چه چیزی بهتر است استفاده شود؟ یا مثلاً فکر می کنید که Ansible قبلاً زباله است ، باید سعی کنید از Terraform برای همه چیز استفاده کنید؟
سوال خوبی است، والری. من معتقدم که Terraform از نظر هدف از سال 2014 تغییر نکرده است. برای زیرساخت ایجاد شد و برای زیرساخت مرد. ما هنوز نیاز به مدیریت پیکربندی Ansible داشتیم و خواهیم داشت. چالش این است که داده های کاربر در launch_configuration وجود دارد. و در آنجا Ansible و غیره را می کشید. این تمایز استانداردی است که من بیشتر دوست دارم.
اگر در مورد زیرساخت های زیبا صحبت می کنیم، پس ابزارهایی مانند Packer وجود دارند که این تصویر را جمع آوری می کنند. و سپس Terraform از منبع داده برای یافتن این تصویر و به روز رسانی launch_configuration آن استفاده می کند. یعنی به این ترتیب خط لوله به این صورت است که ابتدا Tracker را می کشیم سپس Terraform را می کشیم. و اگر build رخ دهد، آنگاه تغییر جدیدی رخ می دهد.
سلام! با تشکر از گزارش! نام من میشا، شرکت RBS است. هنگام ایجاد یک منبع می توانید از طریق Provisioner با Ansible تماس بگیرید. Ansible همچنین موضوعی به نام موجودی پویا دارد. و می توانید ابتدا Terraform را فراخوانی کنید و سپس Ansible را فراخوانی کنید که منابع را از حالت گرفته و اجرا می کند. چی بهتره؟
مردم از هر دو با موفقیت یکسان استفاده می کنند. به نظر من اگر در مورد گروه مقیاس خودکار صحبت نکنیم، موجودی پویا در Ansible چیز مناسبی است. زیرا در گروه مقیاس خودکار ما قبلاً جعبه ابزار خود را داریم که به آن launch_configuration می گویند. در launch_configuration ما هر چیزی را که باید هنگام ایجاد یک منبع جدید راه اندازی شود ضبط می کنیم. بنابراین، با آمازون، استفاده از موجودی پویا و خواندن فایل Terraform ts، به نظر من، بیش از حد است. و اگر از ابزارهای دیگری استفاده می کنید که در آن مفهوم "گروه مقیاس خودکار" وجود ندارد، به عنوان مثال، از DigitalOcean یا ارائه دهنده دیگری استفاده می کنید که در آن گروه مقیاس خودکار وجود ندارد، در آنجا باید به صورت دستی API را بکشید، آدرس های IP را پیدا کنید، ایجاد کنید. یک فایل موجودی پویا، و Ansible از قبل در آن سرگردان خواهد بود. یعنی برای آمازون launch_configuration وجود دارد و برای هر چیز دیگری موجودی پویا وجود دارد.
منبع: www.habr.com