از یک "راه اندازی" تا هزاران سرور در ده ها مرکز داده. چگونه رشد زیرساخت لینوکس را تعقیب کردیم

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

البته NSPK یک استارت آپ نیست، اما چنین فضایی در سال های اول تاسیس این شرکت حاکم بود و سال های بسیار جالبی بود. اسم من هست کورنیاکوف دیمیتری، من بیش از 10 سال است که از زیرساخت لینوکس با نیازهای دسترسی بالا پشتیبانی می کنم. او در ژانویه 2016 به تیم NSPK ملحق شد و متأسفانه اوایل وجود این شرکت را ندید، اما در مرحله تغییرات بزرگ قرار گرفت.

به طور کلی می توان گفت که تیم ما 2 محصول را برای شرکت تامین می کند. اولین مورد زیرساخت است. ایمیل باید کار کند، DNS باید کار کند، و کنترل‌کننده‌های دامنه باید به شما اجازه ورود به سرورهایی را بدهند که نباید خراب شوند. چشم انداز فناوری اطلاعات این شرکت بسیار بزرگ است! اینها سیستم‌های حیاتی تجاری و مأموریتی هستند، الزامات در دسترس بودن برای برخی 99,999 است. محصول دوم خود سرورها فیزیکی و مجازی هستند. موارد موجود نیاز به نظارت دارند و موارد جدید باید به طور منظم به مشتریان بسیاری از بخش ها تحویل داده شوند. در این مقاله می‌خواهم بر روی چگونگی توسعه زیرساختی که چرخه عمر سرور را بر عهده دارد تمرکز کنم.

آغاز سفر

در ابتدای سفر ما، پشته فناوری ما به این شکل بود:
سیستم عامل CentOS 7
کنترل کننده های دامنه FreeIPA
اتوماسیون - Ansible(+Tower)، Cobbler

همه اینها در 3 دامنه قرار داشتند که در چندین مرکز داده پخش شده بودند. در یک مرکز داده سیستم های اداری و سایت های تست وجود دارد، در بقیه PROD وجود دارد.

ایجاد سرورها در یک نقطه به شکل زیر بود:

در قالب VM، CentOS حداقل است و حداقل مورد نیاز مانند /etc/resolv.conf صحیح است، بقیه از طریق Ansible می آید.

CMDB - Excel.

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

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

در آن زمان، بسیاری از ما Ansible را به عنوان یک پسوند راحت Bash درک می‌کردیم و از طراحی‌هایی که از پوسته و sed استفاده می‌کردند کوتاهی نکردیم. به طور کلی Bashsible. این در نهایت منجر به این واقعیت شد که اگر playbook به دلایلی روی سرور کار نمی کرد، حذف سرور، تعمیر کتاب پخش و اجرای مجدد آن آسان تر بود. اساساً هیچ نسخه‌سازی از اسکریپت‌ها و قابلیت حمل پیکربندی‌ها وجود نداشت.

به عنوان مثال، ما می خواستیم برخی از تنظیمات را در همه سرورها تغییر دهیم:

1. ما پیکربندی سرورهای موجود را در بخش منطقی/مرکز داده تغییر می دهیم. گاهی اوقات نه در یک روز - الزامات دسترسی و قانون اعداد زیاد اجازه نمی دهد همه تغییرات به یکباره اعمال شوند. و برخی تغییرات به طور بالقوه مخرب هستند و نیاز به راه اندازی مجدد چیزی دارند - از خدمات گرفته تا خود سیستم عامل.
2. رفع آن در Ansible
3. ما آن را در Cobbler تعمیر می کنیم
4. N بار برای هر بخش منطقی/مرکز داده تکرار کنید

برای اینکه همه تغییرات به آرامی پیش برود، باید عوامل زیادی را در نظر گرفت و تغییرات دائما رخ می دهد.

• Refactoring کد ansible، فایل های پیکربندی
• تغییر بهترین شیوه های داخلی
• تغییرات بر اساس نتایج تجزیه و تحلیل حوادث/حوادث
• تغییر استانداردهای امنیتی، داخلی و خارجی. به عنوان مثال، PCI DSS هر سال با نیازهای جدید به روز می شود

رشد زیرساخت ها و آغاز سفر

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

1. اتوماسیون. تا حد امکان باید از خطاهای انسانی در عملیات های تکراری اجتناب شود.
2. تکرارپذیری وقتی زیرساخت قابل پیش بینی باشد، مدیریت آن بسیار ساده تر است. پیکربندی سرورها و ابزارهای آماده سازی آنها باید در همه جا یکسان باشد. این برای تیم های محصول نیز مهم است - پس از آزمایش، برنامه باید تضمین شود که در یک محیط تولیدی که مشابه محیط آزمایش پیکربندی شده است، پایان یابد.
3. سادگی و شفافیت ایجاد تغییرات در مدیریت پیکربندی.

باقی مانده است که چند ابزار اضافه کنیم.

ما GitLab CE را به عنوان مخزن کد خود انتخاب کردیم، به ویژه برای ماژول های داخلی CI/CD آن.

طاق اسرار - Hashicorp Vault، شامل. برای API عالی

تست پیکربندی ها و نقش های قابل تشخیص - Molecule+Testinfra. اگر به میتوژن قابل تشخیص متصل شوید، آزمایش‌ها بسیار سریع‌تر انجام می‌شوند. در همان زمان، ما شروع به نوشتن CMDB و ارکستراتور خودمان برای استقرار خودکار (در تصویر بالا Cobbler) کردیم، اما این داستان کاملاً متفاوتی است که همکار من و توسعه دهنده اصلی این سیستم ها در آینده بیان خواهد کرد.

انتخاب ما:

مولکول + Testinfra
Ansible + Tower + AWX
دنیای سرورها + DITNET (توسعه شخصی)
کوبلر
Gitlab + GitLab runner
Hashicorp Vault

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

• کپی کردن سرورها از "تصویر طلایی" شیطانی است!عیب اصلی این است که شما دقیقاً نمی دانید که تصاویر در چه وضعیتی هستند و همه تغییرات در تمام تصاویر در همه مزارع مجازی سازی اعمال می شود.
• حداقل از فایل های پیکربندی پیش فرض استفاده کنید و با سایر بخش ها موافقت کنید که مسئولیت فایل های اصلی سیستم را بر عهده دارید، برای مثال:
  1. /etc/sysctl.conf را خالی بگذارید، تنظیمات فقط باید در /etc/sysctl.d/ باشد. پیش فرض شما در یک فایل، سفارشی برای برنامه در دیگری.
  2. از فایل های override برای ویرایش واحدهای systemd استفاده کنید.
• همه پیکربندی ها را الگو قرار دهید و آنها را به طور کامل درج کنید؛ در صورت امکان، sed یا آنالوگ های آن در کتاب های بازی وجود نداشته باشد
• بازسازی کد سیستم مدیریت پیکربندی:
  1. وظایف را به موجودیت های منطقی تقسیم کنید و یکپارچه را به نقش ها بازنویسی کنید
  2. از لینتر استفاده کنید! Ansible-lint، Yaml-lint و غیره
  3. رویکرد خود را تغییر دهید! نه خشن توضیح وضعیت سیستم ضروری است
• برای همه نقش‌های Ansible باید تست‌هایی را در مولکول بنویسید و یک بار در روز گزارش تهیه کنید.
• در مورد ما، پس از آماده سازی تست ها (که بیش از 100 مورد وجود دارد)، حدود 70000 خطا پیدا شد. چند ماه طول کشید تا آن را درست کنیم.

اجرای ما

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

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

همچنین گزینه های زیادی برای ایجاد سرور وجود دارد. ما در نهایت اسکریپت های پایتون سفارشی را انتخاب کردیم. و برای CI ansible:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

این چیزی است که ما به آن رسیده ایم، سیستم به حیات و توسعه خود ادامه می دهد.

• 17 نقش قابل قبول برای راه اندازی سرور. هر یک از نقش‌ها برای حل یک کار منطقی جداگانه (ثبت‌نام، ممیزی، مجوز کاربر، نظارت و غیره) طراحی شده‌اند.
• تست نقش. مولکول + TestInfra.
• توسعه شخصی: CMDB + ارکستراتور.
• زمان ایجاد سرور 30 ​​دقیقه است، به صورت خودکار و عملاً مستقل از صف کار است.
• وضعیت/نام‌گذاری یکسان زیرساخت در همه بخش‌ها - کتاب‌های بازی، مخازن، عناصر مجازی‌سازی.
• بررسی روزانه وضعیت سرور با تولید گزارش در مورد مغایرت با استاندارد.

امیدوارم داستان من برای کسانی که در ابتدای راه هستند مفید باشد. از چه پشته اتوماسیون استفاده می کنید؟

منبع: www.habr.com