چگونه می توان در شش ماه یا کمتر از آن مهندس DevOps شد قسمت دوم پیکربندی

برداشت کوتاه

در قسمت 1 ، اشاره شد كه كار مهندسی DevOps ساخت خطوط موازی دیجیتالی كاملاً خودکار است كه كدها را از دستگاه توسعه دهنده به تولید منتقل می كند.
حال ، انجام این کار به طور مؤثر نیاز به درک کاملی از اصول دارد

و همچنین درک خوبی از ابزارها و مهارتها (نمودار زیر را در زیر مشاهده می کنید) که بر پایه این اصول بنا شده است.

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

بررسی اجمالی

در مرحله پیکربندی چه اتفاقی می افتد؟

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

در گذشته تأمین زیرساخت ها یک مصیبت طولانی و پر فشار بود و مستعد خطا بود.

حال ، به دلیل اینکه ما ابر عالی خود را داریم ، کلیه تهیه ها با کلیک یک دکمه قابل انجام است. یا حداقل بسیاری از کلیک ها با این حال ، به نظر می رسد کلیک دکمه ها برای انجام این کارها یک ایده بد است.چرا؟

به دلیل اینکه کلیک دکمه است

۱- مستعد خطا (انسان اشتباه می کند) ،

۲- نسخه (نسخه قابل ذخیره در git نیست) ،

۳- قابل تکرار نیست (ماشین های بیشتر = کلیک بیشتر) ،

۴- و قابل آزمایش نیست (هیچ ایده ای نیست که اگر کلیک های من واقعاً کار کنند یا چیزهای آشفتگی ایجاد کنند).

به عنوان مثال ، به تمام کارهایی که برای تأمین محیط توسعه خود نیاز دارید ، فکر کنید … محیط تست … محیط واقعی محضول … کیفیت محصول … استقرار در یکی از دیتاسنتر های امریکا … و دوباره تکرار تمامی فرایندها در دیتاسنتری در اروپا … خیلی زود خسته کننده وآزاد دهنده میشود.

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

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

توجه: با “محاسبه منابع” منظور من همه چیز برای اجرای صحیح یک برنامه در محصولات: محاسبه ، ذخیره سازی ، شبکه سازی ، پایگاه داده ها و غیره است.

علاوه بر این ، به این معنی است که به جای اینکه استفاده از کلیک برای ایجاد زیر ساخت ، در عوض خواهیم پذیرفت

۱- وضعیت زیرساخت های مورد نظر را در Terraform بنویسید ،

۲- آن را در کنترل کد منبع ما ذخیره کنید ،

۳- برای درخواست بازخورد ، یک فرایند رسمی Pull Request را انجام دهید ،

۴- تست کنید

۵- منابع مورد نیاز را اجرا کنید

حال ، سوال بارز این است که ، “چرا Terraform؟

۱- بسیار مرسوم است ، بنابراین فرصت های شغلی فراوان است
۲- آموختن آن تا حدودی آسانتر از دیگران است
۳- پلت فرم متوسط است

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

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

با این وجود ، Ansible می تواند کارهایی انجام دهد (اگر نه همه) که Terraform می تواند انجام دهد. برعکس نیز بیشتر صادق است.

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

در حقیقت ، تخصص Terraform + AWS یکی از داغترین مجموعه های مهارت در حال حاضر است!

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

لازم نیست!

استقرارهای تغییر ناپذیر

در واقع ، من پیش بینی می کنم که ابزارهای مدیریت پیکربندی مانند Ansible از اهمیت کاسته می شوند ، در حالی که ابزارهای تأمین زیرساخت هایی مانند Terraform یا CloudFormation از اهمیت بالایی برخوردار خواهند شد.

چرا؟

به دلیل چیزی به نام “استقرار غیر قابل تغییر”

به بیان ساده تر ، استقرارهای تغییرناپذیر به عمل تغییر نکردن زیرساختهای مستقر شده شما اشاره دارد. به عبارت دیگر واحد استقرار شما یک VM یا یک کانتیر Docker است ، نه یک تکه کد.بنابراین ، شما کد را به مجموعه ای از ماشین های مجازی استاتیک مستقر نمی کنید ، کل VM ها را مستقر می کنید.

شما نحوه پیکربندی VM را تغییر نمی دهید ، VM های جدید را با پیکربندی مورد نظر در جای خود مستقر می کنید.

شما ماشینهای تولیدی را به روز رسانی نمیکنید ، ماشینهای جدیدی را نصب می کنید ، قبلاً به روزرسانی شده است.

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

در صورت استفاده صحیح ، این یک الگوی بسیار قدرتمند است و من اکیداً توصیه می کنم!

توجه: پياده سازي هاي قابل تغيير دستورالعمل پيكربندي از كد شما جداست.

جداشدن کد از پیکربندی بسیار مهم است – شما نمی خواهید هر بار که می خواهید رمزهای عبور داده های خود را بچرخانید ، کل برنامه را دوباره مستقر کنید. در عوض ، اطمینان حاصل کنید که برنامه ها آن را از فروشگاه پیکربندی خارجی (SSM / Consul / etc.) بیرون می کشند.

علاوه بر این ، به راحتی می توانید ببینید که با توجه به افزایش استقرارهای تغییرناپذیر ، ابزارهایی مانند Ansible شروع به بازی کردن کمتر از نقش برجسته می کنند.

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

یا اگر شما در حال انجام ایجاد کانتینر هستید ، مطمئناً استقرارهای غیرقابل تغییر را تقریباً می خواهید.

شما نمی خواهید کانتینر dev شما با کانتینر QA متفاوت باشد و از محصول متفاوت باشد.

شما می توانید کانتینر هایی دقیقاً یکسان در تمام محیط های خود داشته باشید. این مانع از تنظیمات پیکربندی شده و در صورت بروز مشکلات ، rollback را ساده می کند.

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

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

در حقیقت ، پست های مفصلی درباره نحوه استقرار یک پشته ELK در AWS نوشتند – اگر می خواهید ببینید که چگونه این کار در عمل انجام شده است ، آن را بخوانید.

باز هم ، می توانید دسترسی از راه دور را به طور کلی غیرفعال کنید و نسبت به بیشتر افراد آنجا احساس امنیت بیشتری کنید!

به طور خلاصه ، سفر “DevOps” کاملاً خودکار ما با تهیه منابع محاسباتی مورد نیاز برای اجرای کد – مرحله پیکربندی – آغاز می شود. و بهترین راه برای تحقق این امر از طریق استقرار غیرقابل تغییر است.

سرانجام اگر کنجکاو هستید که دقیقاً از کجا شروع کنید ، دسته کوچک موسیقی جاز Terraform + AWS مکانی مناسب برای شروع سفر شما است!

این همه برای مرحله “پیکربندی” است.

منبع

قسمت سوم