Ако вашата ИТ инфраструктура расте премногу брзо, порано или подоцна ќе се соочите со избор: линеарно да ги зголемите човечките ресурси за да ја поддржите или да започнете со автоматизација. До одреден момент живеевме во првата парадигма, а потоа започна долгиот пат до Infrastructure-as-Code.
Се разбира, NSPK не е стартап, но таква атмосфера владееше во компанијата во првите години од нејзиното постоење, а тоа беа многу интересни години. Моето име е , Ја поддржувам инфраструктурата на Линукс со високи барања за достапност повеќе од 10 години. Тој се приклучи на тимот на NSPK во јануари 2016 година и, за жал, не го виде самиот почеток на постоењето на компанијата, но дојде во фаза на големи промени.
Генерално, можеме да кажеме дека нашиот тим испорачува 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 за подготовка на VM.
Во тоа време, многумина од нас го доживуваа Ansible како погодно продолжение на Bash и не штедеа на дизајни користејќи школка и сед. Севкупно Bashsible. Ова на крајот доведе до фактот дека ако книгата за игри поради некоја причина не работи на серверот, полесно е да се избрише серверот, да се поправи книгата за репродукција и да се стартува повторно. Во суштина немаше верзии на скрипти, немаше преносливост на конфигурации.
На пример, сакавме да промениме одредена конфигурација на сите сервери:
- Ја менуваме конфигурацијата на постоечките сервери во логичкиот сегмент/центар за податоци. Понекогаш не во еден ден - барањата за пристапност и законот за големи броеви не дозволуваат сите промени да се применат одеднаш. И некои промени се потенцијално деструктивни и бараат рестартирање на нешто - од услуги до самиот ОС.
- Поправање во Ansible
- Го поправаме во Cobbler
- Повторете N пати за секој логички сегмент/центар на податоци
За да се одвиваат непречено сите промени, потребно беше да се земат предвид многу фактори, а промените се случуваат постојано.
- Рефакторирање на ансибилен код, конфигурациски датотеки
- Промена на внатрешните најдобри практики
- Промени врз основа на резултатите од анализата на инциденти/несреќи
- Промена на безбедносните стандарди, внатрешни и надворешни. На пример, PCI DSS се ажурира со нови барања секоја година
Растот на инфраструктурата и почетокот на патувањето
Расте бројот на сервери/логички домени/центри за податоци, а со нив и бројот на грешки во конфигурациите. Во одреден момент, дојдовме до три насоки во кои треба да се развие управувањето со конфигурацијата:
- Автоматизација. Човечката грешка во повторливите операции треба да се избегнува колку што е можно повеќе.
- Повторливост. Многу е полесно да се управува со инфраструктурата кога е предвидлива. Конфигурацијата на серверите и алатките за нивна подготовка треба да биде насекаде иста. Ова е исто така важно за тимовите за производи - по тестирањето, мора да се гарантира дека апликацијата ќе заврши во производствена средина конфигурирана слично на околината за тестирање.
- Едноставност и транспарентност при правење промени во управувањето со конфигурациите.
Останува да додадете неколку алатки.
Го избравме GitLab CE како наше складиште за кодови, не само за неговите вградени CI/CD модули.
Свод на тајни - Hashicorp Vault, вкл. за одличното API.
Тестирање на конфигурации и одговорни улоги – Molecule+Testinfra. Тестовите одат многу побрзо ако се поврзете со чувствителен митоген. Во исто време, почнавме да пишуваме сопствен CMDB и оркестратор за автоматско распоредување (на сликата над Cobbler), но ова е сосема друга приказна, која мојот колега и главниот развивач на овие системи ќе ја раскаже во иднина.
Наш избор:
Молекула + Тестинфра
Ansible + Tower + AWX
World of Servers + DITNET (сопствен развој)
Калдрма
Gitlab + GitLab тркач
Хашикорп свод
Патем, за можни улоги. Отпрвин имаше само една, но по неколку рефакторирања имаше 17. Силно препорачувам да се разбие монолитот во идемпотентни улоги, кои потоа може да се лансираат одделно; дополнително, можете да додадете ознаки. Ги поделивме улогите по функционалност - мрежа, логирање, пакети, хардвер, молекула итн. Во принцип, ја следевме стратегијата подолу. Не инсистирам дека ова е единствената вистина, но ни успеа.
- Копирањето сервери од „златната слика“ е зло!Главниот недостаток е тоа што не знаете точно во каква состојба се сликите сега и дека сите промени ќе дојдат на сите слики во сите фарми за виртуелизација.
- Користете стандардни конфигурациски датотеки на минимум и договорете се со другите одделенија дека сте одговорни за главните системски датотеки, на пример:
- Оставете го /etc/sysctl.conf празно, поставките треба да бидат само во /etc/sysctl.d/. Ваше стандардно во една датотека, приспособено за апликацијата во друга.
- Користете ги датотеките за префрлување за да уредувате системски единици.
- Обраснете ги сите конфигурации и вклучете ги целосно; ако е можно, без sed или неговите аналози во Playbooks
- Рефакторирање на кодот на системот за управување со конфигурација:
- Поделете ги задачите на логички ентитети и препишете го монолитот во улоги
- Користете линтери! Ansible-lint, yaml-lint, итн
- Променете го вашиот пристап! Без беш. Неопходно е да се опише состојбата на системот
- За сите улоги на Ansible треба да пишувате тестови во молекула и да генерирате извештаи еднаш дневно.
- Во нашиот случај, по подготовката на тестовите (од кои ги има повеќе од 100), беа пронајдени околу 70000 грешки. Беа потребни неколку месеци за да се поправи.
Нашата имплементација
Значи, улогите беа подготвени, шаблони и проверени со линтери. Па дури и gits се креваат насекаде. Но, прашањето за сигурна испорака на код до различни сегменти остана отворено. Решивме да се синхронизираме со скрипти. Изгледа вака:
Откако ќе пристигне промената, се активира CI, се создава тест-сервер, се пуштаат улоги и се тестираат од молекулата. Ако сè е во ред, кодот оди во гранката prod. Но, ние не применуваме нов код на постоечките сервери во машината. Ова е еден вид затка што е неопходен за висока достапност на нашите системи. И кога инфраструктурата станува огромна, законот за големи броеви стапува во игра - дури и ако сте сигурни дека промената е безопасна, може да доведе до страшни последици.
Исто така, постојат многу опции за креирање сервери. Завршивме со изборот на сопствени скрипти за Python. И за 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 Достапни улоги за поставување на серверот. Секоја од улогите е дизајнирана да реши посебна логичка задача (логирање, ревизија, овластување на корисникот, следење итн.).
- Тестирање на улоги. Молекула + ТестИнфра.
- Сопствен развој: CMDB + оркестратор.
- Времето на креирање на серверот е ~ 30 минути, автоматизирано и практично независно од редот за задачи.
- Истата состојба/именување на инфраструктурата во сите сегменти - тетратки, складишта, елементи за виртуелизација.
- Секојдневна проверка на статусот на серверот со генерирање извештаи за неусогласеност со стандардот.
Се надевам дека мојата приказна ќе биде корисна за оние кои се на почетокот на своето патување. Кој стек за автоматизација го користите?
Извор: www.habr.com