Pokud vaše IT infrastruktura roste příliš rychle, budete dříve nebo později postaveni před volbu: lineárně navyšovat lidské zdroje na její podporu nebo spustit automatizaci. Do určité chvíle jsme žili v prvním paradigmatu a pak začala dlouhá cesta k Infrastruktura jako kód.
NSPK samozřejmě není startup, ale taková atmosféra ve firmě vládla v prvních letech její existence a byly to velmi zajímavé roky. Jmenuji se , Již více než 10 let podporuji infrastrukturu Linuxu s požadavky na vysokou dostupnost. Do týmu NSPK nastoupil v lednu 2016 a bohužel nezaznamenal úplný začátek existence společnosti, ale přišel ve fázi velkých změn.
Obecně lze říci, že náš tým dodává pro společnost 2 produkty. První je infrastruktura. Pošta by měla fungovat, DNS by měla fungovat a řadiče domény by vás měly pustit na servery, které by neměly padat. IT prostředí společnosti je obrovské! Toto jsou business&mission kritické systémy, požadavky na dostupnost některých jsou 99,999. Druhým produktem jsou servery samotné, fyzické a virtuální. Stávající je třeba sledovat a nové je třeba pravidelně dodávat zákazníkům z mnoha oddělení. V tomto článku se chci zaměřit na to, jak jsme vyvinuli infrastrukturu, která je zodpovědná za životní cyklus serveru.
Začátek cesty
Na začátku naší cesty vypadal náš technologický zásobník takto:
OS CentOS 7
Ovladače domén FreeIPA
Automatizace - Ansible(+Tower), Cobbler
To vše bylo umístěno ve 3 doménách, rozmístěných v několika datových centrech. V jednom datovém centru jsou kancelářské systémy a testovací místa, ve zbytku je PROD.
Vytvoření serverů v jednom okamžiku vypadalo takto:
V šabloně VM je CentOS minimální a požadované minimum je jako správný /etc/resolv.conf, zbytek přichází přes Ansible.
CMDB - Excel.
Pokud je server fyzický, pak místo zkopírování virtuálního počítače byl na něj nainstalován OS pomocí Cobbler - MAC adresy cílového serveru se přidají do konfigurace Cobbler, server obdrží IP adresu přes DHCP a poté OS je přidáno.
Zpočátku jsme se dokonce pokusili udělat nějaký druh správy konfigurace v Cobbleru. To ale postupem času začalo přinášet problémy s přenositelností konfigurací jak do jiných datových center, tak do kódu Ansible pro přípravu VM.
V té době mnozí z nás vnímali Ansible jako pohodlné rozšíření Bash a nešetřili na návrzích využívajících shell a sed. Celkově Bashsible. To nakonec vedlo k tomu, že pokud playbook z nějakého důvodu na serveru nefungoval, bylo jednodušší server smazat, opravit playbook a znovu spustit. V podstatě neexistovalo žádné verzování skriptů, žádná přenositelnost konfigurací.
Chtěli jsme například změnit některé konfigurace na všech serverech:
- Změníme konfiguraci na stávajících serverech v logickém segmentu/datovém centru. Někdy ne za jeden den – požadavky na přístupnost a zákon velkého počtu neumožňují uplatnit všechny změny najednou. A některé změny jsou potenciálně destruktivní a vyžadují restart něčeho – od služeb až po samotný OS.
- Oprava v Ansible
- Opravujeme to v Cobbleru
- Opakujte N-krát pro každý logický segment/datové centrum
Aby všechny změny proběhly hladce, bylo nutné vzít v úvahu mnoho faktorů a ke změnám dochází neustále.
- Refaktoring ansible kódu, konfigurační soubory
- Změna interních osvědčených postupů
- Změny na základě výsledků analýzy incidentů/nehod
- Změna bezpečnostních standardů, interních i externích. Například PCI DSS je každý rok aktualizován o nové požadavky
Růst infrastruktury a začátek cesty
Rostl počet serverů/logických domén/datových center a s nimi i počet chyb v konfiguracích. V určitém okamžiku jsme dospěli ke třem směrům, ve kterých je třeba vyvinout správu konfigurace:
- Automatizace. Je třeba se co nejvíce vyvarovat lidských chyb při opakujících se operacích.
- Opakovatelnost. Je mnohem jednodušší spravovat infrastrukturu, když je předvídatelná. Konfigurace serverů a nástrojů pro jejich přípravu by měla být všude stejná. To je důležité i pro produktové týmy – po testování musí být zaručeno, že aplikace skončí v produkčním prostředí nakonfigurovaném podobně jako testovací prostředí.
- Jednoduchost a transparentnost provádění změn ve správě konfigurace.
Zbývá přidat pár nástrojů.
Jako úložiště kódu jsme zvolili GitLab CE, v neposlední řadě pro jeho vestavěné moduly CI/CD.
Trezor tajemství - Hashicorp Vault, vč. pro skvělé API.
Testování konfigurací a dostupných rolí – Molecule+Testinfra. Testy probíhají mnohem rychleji, pokud se připojíte k ansible mitogenu. Zároveň jsme začali psát vlastní CMDB a orchestrátor pro automatické nasazení (na obrázku výše Cobbler), ale to je úplně jiný příběh, který v budoucnu vypráví můj kolega a hlavní vývojář těchto systémů.
Naše volba:
Molekula + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (vlastní vývoj)
Švec
Gitlab + GitLab runner
Hashicorp Vault
Mimochodem, o ansible rolích. Nejprve byl jen jeden, ale po několika refaktoringech jich bylo 17. Důrazně doporučuji rozdělit monolit na idempotentní role, které lze následně spouštět samostatně, navíc můžete přidávat značky. Role jsme rozdělili podle funkčnosti – síť, protokolování, balíčky, hardware, molekula atd. Obecně jsme postupovali podle níže uvedené strategie. Netvrdím, že je to jediná pravda, ale u nás to fungovalo.
- Kopírování serverů ze „zlatého obrazu“ je zlo!Hlavní nevýhodou je, že přesně nevíte, v jakém stavu jsou nyní obrazy, a že všechny změny se projeví u všech obrazů ve všech virtualizačních farmách.
- Používejte výchozí konfigurační soubory na minimum a dohodněte se s ostatními odděleními, že jste odpovědní za hlavní systémové soubory, Například:
- /etc/sysctl.conf ponechte prázdné, nastavení by mělo být pouze v /etc/sysctl.d/. Vaše výchozí nastavení v jednom souboru, vlastní pro aplikaci v jiném.
- K úpravě jednotek systemd použijte přepisovací soubory.
- Vytvořte šablonu všech konfigurací a zahrňte je úplně; pokud je to možné, žádný sed ani jeho analogy v příručkách
- Refaktorování kódu systému správy konfigurace:
- Rozdělte úkoly na logické entity a přepište monolit do rolí
- Použijte lintry! Ansible-lint, yaml-lint atd
- Změňte svůj přístup! Žádné ošklivé. Je nutné popsat stav systému
- Pro všechny role Ansible musíte jednou denně psát testy v molekule a generovat zprávy.
- V našem případě bylo po přípravě testů (kterých je více než 100) nalezeno cca 70000 XNUMX chyb. Trvalo několik měsíců, než se to opravilo.
Naše realizace
Takže ansible role byly připraveny, šablonovány a zkontrolovány lintry. A dokonce se všude množí gitary. Otázka spolehlivého doručování kódu do různých segmentů však zůstala otevřená. Rozhodli jsme se pro synchronizaci se skripty. Vypadá to takto:
Po příchodu změny je spuštěna CI, je vytvořen testovací server, role jsou zavedeny a testovány molekulou. Pokud je vše v pořádku, kód přejde do větve prod. Neaplikujeme však nový kód na existující servery ve stroji. Jedná se o jakousi zátku, která je nezbytná pro vysokou dostupnost našich systémů. A když se infrastruktura stane obrovskou, vstupuje do hry zákon velkých čísel – i když jste si jisti, že změna je neškodná, může to vést k hrozným následkům.
Existuje také mnoho možností pro vytváření serverů. Nakonec jsme vybrali vlastní Python skripty. A pro CI možné:
- 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}}"To je to, k čemu jsme dospěli, systém nadále žije a vyvíjí se.
- 17 Možné role pro nastavení serveru. Každá z rolí je navržena tak, aby řešila samostatný logický úkol (protokolování, auditování, autorizace uživatelů, monitorování atd.).
- Testování rolí. Molekula + TestInfra.
- Vlastní vývoj: CMDB + Orchestrator.
- Čas vytvoření serveru je ~ 30 minut, je automatizovaný a prakticky nezávislý na frontě úloh.
- Stejný stav/pojmenování infrastruktury ve všech segmentech – playbooky, repozitáře, virtualizační prvky.
- Denní kontrola stavu serveru s generováním hlášení o nesrovnalostech se standardem.
Doufám, že můj příběh bude užitečný pro ty, kteří jsou na začátku své cesty. Jaký automatizační zásobník používáte?
Zdroj: www.habr.com