Ha az informatikai infrastruktúra túl gyorsan növekszik, akkor előbb-utóbb választás elé kell állítania: lineárisan növeli az emberi erőforrásokat a támogatásához, vagy kezdi el az automatizálást. Egy bizonyos pontig az első paradigmában éltünk, majd elkezdődött a hosszú út az Infrastructure-as-Code felé.
Az NSPK persze nem startup, de ilyen légkör uralkodott a cégben fennállásának első éveiben, és ezek nagyon érdekes évek voltak. A nevem , Több mint 10 éve támogatom a Linux infrastruktúrát magas rendelkezésre állási követelményekkel. 2016 januárjában csatlakozott az NSPK csapatához, és sajnos nem látta a cég létezésének legelejét, de nagy változások stádiumába érkezett.
Általánosságban elmondható, hogy csapatunk 2 terméket szállít a cég számára. Az első az infrastruktúra. A levelezésnek működnie kell, a DNS-nek működnie kell, és a tartományvezérlőknek be kell engedniük olyan kiszolgálókra, amelyeknek nem szabad összeomlani. Óriási a cég IT-világa! Ezek üzleti és küldetéskritikus rendszerek, egyesek rendelkezésre állási követelményei 99,999. A második termék maguk a fizikai és virtuális szerverek. A meglévőket figyelni kell, és számos részlegről rendszeresen újakat kell szállítani az ügyfeleknek. Ebben a cikkben arra szeretnék koncentrálni, hogyan fejlesztettük ki a szerver életciklusáért felelős infrastruktúrát.
Elején az utazás
Utunk elején a technológiai halmazunk így nézett ki:
OS CentOS 7
FreeIPA tartományvezérlők
Automatizálás - Ansible(+Tower), Cobbler
Mindez 3 tartományban volt elhelyezve, több adatközpontban elosztva. Az egyik adatközpontban irodai rendszerek és teszthelyek, a többiben PROD található.
A szerverek létrehozása egy ponton így nézett ki:
A virtuálisgép-sablonban a CentOS minimális, a szükséges minimum pedig olyan, mint a helyes /etc/resolv.conf, a többi az Ansible-n keresztül érkezik.
CMDB - Excel.
Ha a szerver fizikai, akkor a virtuális gép másolása helyett az operációs rendszert Cobbler segítségével telepítették rá - a célszerver MAC-címei hozzáadódnak a Cobbler konfigurációjához, a szerver DHCP-n keresztül kap egy IP-címet, majd az operációs rendszert. hozzáadva.
Eleinte még a Cobblerben is próbálkoztunk valamiféle konfigurációkezeléssel. Idővel azonban ez problémákat okozott a konfigurációk más adatközpontokba és a virtuális gépek előkészítésére szolgáló Ansible-kóddal való hordozhatóságával kapcsolatban.
Akkoriban sokan az Ansible-t a Bash kényelmes kiterjesztésének tekintettük, és nem spóroltunk a shell és sed használatával. Összességében Bashsible. Ez végül oda vezetett, hogy ha a játékkönyv valamilyen oknál fogva nem működött a szerveren, könnyebb volt törölni a szervert, kijavítani és újra futtatni. Lényegében nem volt a szkriptek verziószáma, a konfigurációk hordozhatósága.
Például meg akartunk változtatni néhány konfigurációt az összes szerveren:
- A logikai szegmensben/adatközpontban módosítjuk a konfigurációt a meglévő szervereken. Néha nem egy nap alatt – a hozzáférhetőségi követelmények és a nagy számok törvénye nem teszi lehetővé, hogy minden változtatást egyszerre alkalmazzanak. Néhány változtatás pedig potenciálisan romboló hatású, és újra kell indítani valamit – a szolgáltatásoktól magáig az operációs rendszerig.
- Javítása az Ansible-ben
- Megjavítjuk Cobblerben
- Ismételje meg N-szer minden logikai szegmenshez/adatközponthoz
Ahhoz, hogy minden változás zökkenőmentesen menjen végbe, sok tényezőt kellett figyelembe venni, a változások folyamatosan történnek.
- Refaktorálás lehetséges kód, konfigurációs fájlok
- A belső legjobb gyakorlatok megváltoztatása
- Változások az események/balesetek elemzésének eredményei alapján
- Változó biztonsági szabványok, belső és külső egyaránt. Például a PCI DSS minden évben új követelményekkel frissül
Az infrastruktúra növekedése és az utazás kezdete
A szerverek/logikai tartományok/adatközpontok száma nőtt, és ezzel együtt a konfigurációkban előforduló hibák száma is. Valamikor három olyan irányba jutottunk el, ahol a konfigurációkezelést fejleszteni kell:
- Automatizálás. Amennyire csak lehetséges, kerülni kell az ismétlődő műveletek során elkövetett emberi hibákat.
- Ismételhetőség. Sokkal könnyebb kezelni az infrastruktúrát, ha az kiszámítható. A szerverek és az előkészítésükhöz szükséges eszközök konfigurációja mindenhol azonos legyen. Ez a termékcsapatok számára is fontos – a tesztelés után garantálni kell, hogy az alkalmazás a tesztkörnyezethez hasonlóan konfigurált éles környezetbe kerüljön.
- A konfigurációkezelés módosításának egyszerűsége és átláthatósága.
Még néhány eszközt kell hozzáadni.
A GitLab CE-t választottuk kódtárunknak, nem utolsósorban a beépített CI/CD moduljai miatt.
A titkok tárháza - Hashicorp Vault, beleértve a nagyszerű API-ért.
Tesztkonfigurációk és lehetséges szerepkörök – Molecule+Testinfra. A tesztek sokkal gyorsabban mennek végbe, ha csatlakozik egy lehetséges mitogénhez. Ezzel egy időben elkezdtük írni a saját CMDB-t és a hangszerelőt az automatikus telepítéshez (a fenti képen Cobbler), de ez egy teljesen más történet, amit kollégám és ezen rendszerek fő fejlesztője mesél majd el a jövőben.
Választásunk:
Molekula + Testinfra
Ansible + Tower + AWX
Szerverek világa + DITNET (saját fejlesztés)
Suszter
Gitlab + GitLab futó
Hashicorp Vault
Amúgy a lehetséges szerepekről. Eleinte csak egy volt, de többszöri átalakítás után már 17. Nyomatékosan javaslom a monolit idempotens szerepekre bontását, amelyek aztán külön-külön indíthatók, illetve címkék hozzáadásával. Felosztottuk a szerepeket funkcionalitás szerint - hálózat, naplózás, csomagok, hardver, molekula stb. Általában az alábbi stratégiát követtük. Nem ragaszkodom ahhoz, hogy ez az egyetlen igazság, de nekünk bevált.
- Szervereket másolni az „aranyképről” gonosz!A fő hátrány az, hogy nem tudja pontosan, milyen állapotban vannak a képek most, és hogy minden változás az összes virtualizációs farm összes képére vonatkozik.
- Használja minimálisra az alapértelmezett konfigurációs fájlokat, és állapodjon meg más részlegekkel, hogy Ön felelős a fő rendszerfájlokért, például:
- Hagyja üresen az /etc/sysctl.conf fájlt, a beállítások csak az /etc/sysctl.d/ fájlban legyenek. Az egyik fájlban az alapértelmezett, a másikban az alkalmazáshoz egyedi.
- Használjon felülbíráló fájlokat a rendszeregységek szerkesztéséhez.
- Sablonozza meg az összes konfigurációt, és tartalmazza azokat teljes egészében; ha lehetséges, ne sed vagy annak analógjai a játékkönyvekben
- A konfigurációkezelő rendszer kódjának újrafaktorálása:
- Bontsa le a feladatokat logikai entitásokra, és írja át a monolitot szerepekre
- Használj lintereket! Ansible-lint, yaml-lint stb
- Változtass a megközelítéseden! Nem szégyenlős. Le kell írni a rendszer állapotát
- Minden Ansible szerepkörhöz teszteket kell írnia molekulában, és naponta egyszer jelentéseket kell készítenie.
- Esetünkben a tesztek elkészítése után (amelyből több mint 100 darab van) mintegy 70000 ezer hibát találtak. Több hónapig tartott a javítás.
A mi megvalósításunk
Így a lehetséges szerepek készen voltak, sablonokat kaptak és linterek ellenőrizték. És még gitteket is nevelnek mindenhol. A különböző szegmensek számára történő megbízható kódküldés kérdése azonban nyitva maradt. Úgy döntöttünk, hogy szinkronizáljuk a szkriptekkel. így néz ki:
A változás megérkezése után elindul a CI, létrejön egy tesztkiszolgáló, a szerepek megjelennek, és a molekula teszteli. Ha minden rendben van, a kód a prod ágba kerül. De nem alkalmazunk új kódot a gép meglévő szervereire. Ez egyfajta ütköző, amely rendszereink magas rendelkezésre állásához szükséges. Amikor pedig az infrastruktúra hatalmassá válik, a nagy számok törvénye lép életbe – még ha biztos abban is, hogy a változás ártalmatlan, az súlyos következményekkel járhat.
A szerverek létrehozására is számos lehetőség kínálkozik. Végül egyéni Python szkripteket választottunk. És a CI lehetséges:
- 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}}"Ide jutottunk, a rendszer tovább él és fejlődik.
- 17 Lehetséges szerepek a szerver beállításához. A szerepek mindegyike külön logikai feladat megoldására szolgál (naplózás, auditálás, felhasználói jogosultság, figyelés stb.).
- Szerepvizsgálat. Molekula + TestInfra.
- Saját fejlesztés: CMDB + Orchestrator.
- A szerver létrehozási ideje ~30 perc, automatizált és gyakorlatilag független a feladatsortól.
- Az infrastruktúra ugyanaz az állapota/elnevezése minden szegmensben - játékkönyvek, adattárak, virtualizációs elemek.
- A szerver állapotának napi ellenőrzése a szabványtól való eltérésekről szóló jelentések generálásával.
Remélem, hogy történetem hasznos lesz azoknak, akik útjuk elején járnak. Milyen automatizálási stacket használsz?
Forrás: will.com