وقتی برای اولین بار استفاده از Terraform را شروع کردم، فکر می‌کردم بخش سخت کار یادگیری سینتکس HCL و درک ارائه‌دهندگان است. اما معلوم شد چالش واقعی چیز کاملاً متفاوتی است: مدیریت زیرساخت یکسان در طول توسعه، مرحله‌بندی و تولید بدون ایجاد رانش یا خرابی تصادفی محصول.

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

چرا زیرساخت کپی-پیست با شکست مواجه می‌شود؟

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

تا اولین تغییر واقعی کار می‌کرد. یک قانون فایروال نیاز به به‌روزرسانی داشت. من dev را اصلاح کردم، سپس staging را، و prod را فراموش کردم. دو هفته بعد، prod قوانین امنیتی متفاوتی داشت و هیچ‌کس نمی‌توانست دلیل آن را توضیح دهد.

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

زیرساخت کپی-پیست در ابتدا همیشه بی‌ضرر به نظر می‌رسد. اما به محض اینکه سیستم‌های شما شروع به تغییر می‌کنند، به بدهی فنی تبدیل می‌شوند.

فایل‌های جداگانه‌ی ایالتی الزامی هستند

یک درسی که خیلی زود یاد گرفتم این بود که هر محیطی به فایل وضعیت (state file) مخصوص به خود نیاز دارد. به اشتراک گذاشتن وضعیت بین محیط‌ها اتفاقی است که در شرف وقوع است.

من تیم‌هایی را دیده‌ام که از فضاهای کاری Terraform با یک backend واحد برای صرفه‌جویی در زمان یا فضای ذخیره‌سازی استفاده می‌کنند. این روش تا زمانی که کسی terraform apply را اجرا کند و فکر کند در مرحله توسعه است، در حالی که در واقع هدفش تولید است، کار می‌کند. این اشتباه غیرقابل برگشت است.

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

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

ماژول‌های مختص محیط، منطق شرطی را شکست می‌دهند

بزرگترین تغییر ذهنی برای من پذیرش این بود که محیط‌ها باید ثابت باشند، اما نه یکسان.

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

چیزی که جواب داد، جدا کردن دغدغه‌ها بود:

ماژول‌های پایه، منابع و منطق مشترک را تعریف می‌کنند.

بسته‌بندی‌های محیطی، مقیاس، دوام و تحمل ریسک را تعریف می‌کنند.

وقتی رفتار هسته تغییر می‌کند، من یک بار ماژول پایه را به‌روزرسانی می‌کنم. وقتی نیازهای محیط متفاوت باشد، من بسته‌بندی را تغییر می‌دهم. این کار ماژول‌ها را قابل خواندن و محیط‌ها را صریح نگه می‌دارد.

فایل‌های متغیر، پیاده‌سازی‌ها را صریح می‌کنند

برای تفاوت‌های پیکربندی که ماژول‌های جداگانه را توجیه نمی‌کنند، فایل‌های متغیر برای هر محیط به خوبی کار می‌کنند.

هر محیط فایل .tfvars مخصوص به خود را دارد و استقرارها همیشه آن را به صراحت مشخص می‌کنند. این امر ابهام را از بین می‌برد. شما نمی‌توانید بدون دقت زیاد، تنظیمات dev را به طور تصادفی روی prod اعمال کنید.

وقتی سیستم‌های واقعی در معرض خطر هستند، این صراحت بیش از راحتی اهمیت دارد.

مدیریت اسرار اختیاری نیست

نزدیک‌ترین چیزی که به یک حادثه امنیتی جدی نزدیک شدیم، کشف اعتبارنامه‌های عملیاتی ثبت‌شده در یک فایل متغیر Terraform بود. این امر باعث چرخش فوری اعتبارنامه‌ها در تمام محیط‌ها شد.

پس از آن، ما یک قانون سختگیرانه را اجرا کردیم: اسرار هرگز در فایل‌های Terraform وجود ندارند.

در Oracle Cloud، ما برای کنترل دسترسی به IAM، برای اطلاعات محرمانه به OCI Vault و برای دریافت اطلاعات محرمانه در زمان اجرا به منابع داده Terraform متکی هستیم. Terraform به اطلاعات محرمانه ارجاع می‌دهد، اما هرگز مالک آنها نیست. کنترل منبع تمیز می‌ماند و چرخش داده‌ها قابل مدیریت می‌شود.

چرا از فضاهای کاری Terraform اجتناب می‌کنیم؟

فضاهای کاری Terraform روی کاغذ جذاب به نظر می‌رسند. کد یکسان، محیط‌های چندگانه، تغییر آسان.

در عمل، سوءاستفاده از آنها بسیار آسان است. فضای کاری فعال نامرئی است، مگر اینکه آن را به طور فعال بررسی کنید. ما چندین مورد نزدیک به خطا داشتیم که در آنها منابع تولید تقریباً ناخواسته تغییر داده شدند.

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

ساختاری که واقعاً پابرجا می‌ماند

تنظیماتی که ما را سرحال نگه داشته ساده است:

ماژول‌های مشترک برای زیرساخت‌های قابل استفاده مجدد

دایرکتوری‌های محیطی جداگانه

بک‌اندهای ایزوله شده‌ی وضعیت

فایل‌های متغیر صریح در هر محیط

وقتی شما در محیط تولید (prod) مستقر می‌شوید، مسیر (path)، بک‌اند (backend) و متغیرها همگی این موضوع را که شما در حال کار بر روی محیط تولید (production) هستید، تقویت می‌کنند. هیچ ابهامی وجود ندارد.

چرا مرحله‌بندی وجود دارد؟

هر تغییری از یک مسیر پیروی می‌کند:

در بخش توسعه‌دهندگان اعمال شود

اعمال در مرحله‌بندی و اجرای تست‌های یکپارچه‌سازی

در طول یک پنجره کنترل شده، در محصول اعمال کنید

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

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

درس واقعی

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

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

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

درباره نویسنده: مهندس ارشد نرم‌افزار با ۱۴ سال سابقه در ساخت و بهره‌برداری از زیرساخت‌های ابری در مقیاس بزرگ. در حال حاضر در Oracle Cloud Infrastructure. پیش از این در آمازون، Salesforce، IBM و Tableau فعالیت داشته است.

تست مسدودسازی تبلیغات