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

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

راه اندازی سرورهای جدید به شدت با یک مهلت تعیین شده بود. و انتقال آن به معنای به خطر انداختن حمل و نقل یک میلیارد هدیه و مهاجرت سیستم ها بود. حتی یک تیم متشکل از پدر فراست و بابا نوئل نمی تواند تاریخ را تغییر دهد - شما می توانید سیستم SAP را برای مدیریت انبار تنها یک بار در سال منتقل کنید. از 31 دسامبر تا 1 ژانویه، انبارهای بزرگ خرده فروش، در مجموع به وسعت 20 زمین فوتبال، به مدت 15 ساعت کار خود را متوقف می کنند. و این تنها بازه زمانی برای جابجایی سیستم است. هنگام معرفی سرورها جایی برای خطا نداشتیم.

بگذارید واضح بگویم: داستان من نشان دهنده ابزارها و فرآیند مدیریت پیکربندی است که تیم ما از آن استفاده می کند.

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

مدیریت نصب سیستم عامل

سطح اول سیستمی برای مدیریت نصب سیستم عامل بر روی سرورهای فیزیکی و مجازی است. این تنظیمات اولیه سیستم عامل را ایجاد می کند و عامل انسانی را حذف می کند.

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

وظیفه "حداکثر" برای سیستم مدیریت نصب، پیکربندی خودکار سرورها از سطح BIOS/Firmware به سیستم عامل است. در اینجا خیلی به تجهیزات و وظایف راه اندازی بستگی دارد. برای تجهیزات ناهمگن، می توانید در نظر بگیرید REDFISH API. اگر تمام سخت افزار از یک فروشنده باشد، اغلب استفاده از ابزارهای مدیریتی آماده (به عنوان مثال HP ILO Amplifier، DELL OpenManage و غیره) راحت تر است.

برای نصب سیستم عامل بر روی سرورهای فیزیکی، از Cobbler معروف استفاده کردیم که مجموعه ای از پروفایل های نصب توافق شده با سرویس عملیات را تعریف می کند. هنگام افزودن یک سرور جدید به زیرساخت، مهندس آدرس MAC سرور را به نمایه مورد نیاز در Cobbler گره زد. هنگام بوت شدن از طریق شبکه برای اولین بار، سرور یک آدرس موقت و یک سیستم عامل جدید دریافت کرد. سپس به آدرس دهی VLAN/IP هدف منتقل شد و کار در آنجا ادامه یافت. بله، تغییر VLAN زمان می برد و نیاز به هماهنگی دارد، اما محافظت اضافی در برابر نصب تصادفی سرور در محیط تولید فراهم می کند.

ما سرورهای مجازی را بر اساس الگوهای تهیه شده با استفاده از HashiСorp Packer ایجاد کردیم. دلیل آن یکی بود: جلوگیری از خطاهای انسانی احتمالی هنگام نصب سیستم عامل. اما برخلاف سرورهای فیزیکی، Packer نیاز به PXE، بوت شدن شبکه و تغییرات VLAN را از بین می برد. این امر ایجاد سرورهای مجازی را آسانتر و آسانتر کرده است.

برنج. 1. مدیریت نصب سیستم عامل.

مدیریت اسرار

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

اگر از همان ابتدا تعیین نکنید که کجا و چگونه این اسرار را ذخیره کنید، بسته به شدت الزامات امنیت اطلاعات، روش های ذخیره سازی زیر محتمل است:

• به طور مستقیم در کد کنترل پیکربندی یا در فایل های موجود در مخزن؛
• در ابزارهای تخصصی مدیریت پیکربندی (به عنوان مثال، Ansible Vault)؛
• در سیستم های CI/CD (Jenkins/TeamCity/GitLab/و غیره) یا در سیستم های مدیریت پیکربندی (Ansible Tower/Ansible AWX)؛
• اسرار را می توان "به صورت دستی" نیز منتقل کرد. به عنوان مثال، آنها در یک مکان مشخص قرار می گیرند و سپس توسط سیستم های مدیریت پیکربندی استفاده می شوند.
• ترکیبات مختلف موارد فوق

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

ما از ذخیره سازی مخفی متمرکز HashiCorp Vault استفاده کردیم. این به ما اجازه داد:

• اسرار را ایمن نگه دارید آنها رمزگذاری شده اند و حتی اگر شخصی به پایگاه داده Vault دسترسی پیدا کند (مثلاً با بازیابی آن از یک نسخه پشتیبان)، نمی تواند اسرار ذخیره شده در آنجا را بخواند.
• سازماندهی سیاست ها برای دسترسی به اسرار. فقط اسرار "تخصیص داده شده" به آنها در دسترس کاربران و برنامه های کاربردی است.
• دسترسی ممیزی به اسرار هر گونه اقدام با اسرار در گزارش حسابرسی Vault ثبت می شود.
• یک "چرخه زندگی" تمام عیار از کار با اسرار سازماندهی کنید. می توان آنها را ایجاد کرد، باطل کرد، تاریخ انقضا تعیین کرد و غیره.
• ادغام آسان با سایر سیستم هایی که نیاز به دسترسی به اسرار دارند.
• و همچنین از رمزگذاری end-to-end، رمزهای عبور یک بار مصرف برای سیستم عامل و پایگاه داده، گواهی مراکز مجاز و غیره استفاده کنید.

حالا بیایید به سیستم احراز هویت و مجوز مرکزی برویم. بدون آن امکان پذیر بود، اما مدیریت کاربران در بسیاری از سیستم های مرتبط بسیار بی اهمیت است. ما احراز هویت و مجوز را از طریق سرویس LDAP پیکربندی کرده ایم. در غیر این صورت، Vault باید به طور مداوم توکن های احراز هویت را برای کاربران صادر و پیگیری کند. و حذف و افزودن کاربران به یک جستجو تبدیل می‌شود: «آیا این حساب کاربری را همه جا ایجاد/حذف کردم؟»

ما سطح دیگری را به سیستم خود اضافه می کنیم: مدیریت اسرار و احراز هویت مرکزی/مجوز:

برنج. 2. مدیریت اسرار.

مدیریت پیکربندی

ما به هسته اصلی رسیدیم - سیستم CMS. در مورد ما، این ترکیبی از Ansible و Red Hat Ansible AWX است.

به جای Ansible، Chef، Puppet، SaltStack می توان استفاده کرد. ما Ansible را بر اساس چندین معیار انتخاب کردیم.

• اولاً، تطبیق پذیری است. مجموعه ای از ماژول های آماده برای کنترل قابل توجه است. و اگر به اندازه کافی آن را ندارید، می توانید در GitHub و Galaxy جستجو کنید.
• ثانیاً، نیازی به نصب و پشتیبانی عوامل بر روی تجهیزات مدیریت شده، اثبات عدم تداخل آنها با بار و تأیید عدم وجود "نشانک ها" نیست.
• ثالثاً، Ansible مانع ورود کمی دارد. یک مهندس ماهر به معنای واقعی کلمه در اولین روز کار با محصول، یک کتاب راهنما می نویسد.

اما Ansible به تنهایی در یک محیط تولید برای ما کافی نبود. در غیر این صورت، مشکلات زیادی با محدود کردن دسترسی و ممیزی اقدامات مدیران ایجاد می شود. چگونه دسترسی را محدود کنیم؟ از این گذشته، برای هر بخش لازم بود که مجموعه سرورهای "خود" را مدیریت کند (بخوانید: کتاب بازی Ansible را اجرا کنید). چگونه به کارمندان خاصی اجازه می‌دهیم کتاب‌های بازی خاص Ansible را اجرا کنند؟ یا چگونه می توان بدون تنظیم اطلاعات محلی زیادی روی سرورها و تجهیزات در حال اجرا Ansible، ردیابی کرد که چه کسی کتاب بازی را راه اندازی کرده است؟

سهم شیر از این قبیل مسائل توسط کلاه قرمزی حل می شود برج Ansible، یا پروژه منبع باز بالادستی او Ansible AWX. به همین دلیل آن را برای مشتری ترجیح دادیم.

و یک لمس دیگر به پرتره سیستم CMS ما. کتاب بازی Ansible باید در سیستم های مدیریت مخزن کد ذخیره شود. ما داریمش GitLab CE.

بنابراین، پیکربندی‌ها توسط ترکیبی از Ansible/Ansible AWX/GitLab مدیریت می‌شوند (شکل 3 را ببینید). البته، AWX/GitLab با یک سیستم احراز هویت واحد و کتاب بازی Ansible با HashiCorp Vault یکپارچه شده است. تنظیمات فقط از طریق Ansible AWX وارد محیط تولید می شوند، که در آن تمام "قوانین بازی" مشخص شده است: چه کسی می تواند چه چیزی را پیکربندی کند، کجا می تواند کد مدیریت پیکربندی برای CMS را دریافت کند و غیره.

برنج. 3. مدیریت پیکربندی.

مدیریت آزمون

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

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

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

توسعه کد و مدیریت پیکربندی آرام تر و قابل پیش بینی تر شده است. برای سازماندهی آزمایش مداوم، از جعبه ابزار GitLab CI/CD استفاده کردیم و گرفتیم مولکول قابل تحمل.

هرگاه تغییری در کد مدیریت پیکربندی ایجاد شود، GitLab CI/CD Molecule را فراخوانی می‌کند:

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

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

برنج. 4. تست خودکار نقش ها در GitLab CI/CD.

همچنین مشکلی در عملکرد سیستم های تولید وجود دارد. در زندگی واقعی، ایجاد تغییرات پیکربندی تنها از طریق کد CMS بسیار دشوار است. موقعیت‌های اضطراری زمانی ایجاد می‌شوند که یک مهندس باید پیکربندی را «اینجا و اکنون» تغییر دهد، بدون اینکه منتظر ویرایش کد، آزمایش، تأیید و غیره باشد.

در نتیجه، به دلیل تغییرات دستی، اختلافات در پیکربندی روی همان نوع تجهیزات ظاهر می شود (به عنوان مثال، تنظیمات sysctl در گره های خوشه HA به طور متفاوتی پیکربندی می شوند). یا پیکربندی واقعی روی تجهیزات با پیکربندی مشخص شده در کد CMS متفاوت است.

بنابراین، ما علاوه بر آزمایش مداوم، محیط های تولید را برای عدم تطابق پیکربندی بررسی می کنیم. ما ساده ترین گزینه را انتخاب کردیم: اجرای کد پیکربندی CMS در حالت "اجرای خشک"، یعنی بدون اعمال تغییرات، اما با اطلاع از تمام اختلافات بین پیکربندی برنامه ریزی شده و واقعی. ما این کار را با اجرای دوره‌ای همه کتاب‌های بازی Ansible با گزینه «چک» در سرورهای تولید اجرا کردیم. مثل همیشه، Ansible AWX مسئول راه‌اندازی و به‌روز نگه‌داشتن کتاب بازی است (شکل 5 را ببینید):

برنج. 5. عدم تطابق پیکربندی در Ansible AWX را بررسی می کند.

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

اکنون یک لایه آزمایش مهم داریم که از Ansible AWX/GitLab/Molecule تشکیل شده است (شکل 6).

برنج. 6. مدیریت آزمون.

دشوار؟ من بحث نمی کنم. اما چنین مجموعه ای از مدیریت پیکربندی به پاسخی جامع برای بسیاری از سؤالات مربوط به اتوماسیون پیکربندی سرور تبدیل شده است. اکنون سرورهای استاندارد یک خرده فروش همیشه یک پیکربندی کاملاً تعریف شده دارند. CMS برخلاف یک مهندس، افزودن تنظیمات لازم، ایجاد کاربران و انجام ده ها یا صدها تنظیمات مورد نیاز را فراموش نخواهد کرد.

امروزه هیچ "دانش سری" در تنظیمات سرورها و محیط ها وجود ندارد. تمام ویژگی های لازم در کتاب بازی منعکس شده است. دیگر خبری از خلاقیت و دستورالعمل های مبهم نیست:آن را مانند Oracle معمولی نصب کنید، اما باید چند تنظیمات sysctl را مشخص کنید و کاربرانی با UID مورد نیاز اضافه کنید. از بچه های در حال عملیات بپرس، آنها می دانند'.

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

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

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

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

نویسنده: سرگئی آرتموف، معمار بخش راه حل های DevOps "جت اینفوسیستمز"

منبع: www.habr.com