Toto je prepis prejavu z и .
Toto je príbeh projektu, ktorý využíval vlastný systém správy konfigurácie a prečo migrácia na Ansible trvala 18 mesiacov.
Deň č. -ХХХ: Pred začiatkom
Infraštruktúra spočiatku pozostávala z viacerých samostatných hostiteľov s technológiou Hyper-V. Vytvorenie virtuálneho počítača si vyžadovalo množstvo krokov: umiestnenie diskov na správne miesta, nastavenie DNS, rezerváciu DHCP a umiestnenie konfigurácie virtuálneho počítača do repozitára Git. Tento proces bol čiastočne mechanizovaný, ale virtuálne počítače boli medzi hostiteľmi distribuované manuálne. Vývojári však mohli napríklad upraviť konfiguráciu virtuálneho počítača v Gite a použiť ju reštartovaním virtuálneho počítača.
Riešenie správy konfigurácie na mieru
Pôvodná myšlienka bola, predpokladám, koncipovaná ako IaC: viacero bezstavových virtuálnych počítačov, ktoré by po reštarte resetovali svoj stav. Ako vyzerala správa konfigurácie virtuálnych počítačov? Schematicky to vyzerá jednoducho:
- Pre virtuálny počítač bola nastavená statická MAC adresa.
- K virtuálnemu počítaču bol pripojený ISO súbor s CoreOS a bootovací disk.
- CoreOS spúšťa prispôsobovací skript stiahnutím z webového servera na základe jeho IP adresy.
- Skript stiahne konfiguráciu virtuálneho počítača cez SCP na základe IP adresy.
- Spustil sa port súborov jednotiek systemd a port skriptov bash.
Toto riešenie malo mnoho zjavných problémov:
- ISO v CoreOS je zastarané.
- Množstvo zložitých automatizovaných akcií a mágie počas migrácie/vytvárania virtuálnych počítačov.
- Aktualizácia a vydanie konkrétnej verzie softvéru je náročné. Moduly jadra sú ešte náročnejšie.
- Virtuálne počítače neboli úplne bezdátové, t. j. objavili sa virtuálne počítače, ktoré mali disk s pripojenými ďalšími používateľskými údajmi.
- Niekto neustále rušil závislosti jednotiek systemd, čo spôsobovalo zamrznutie CoreOS po reštarte. Bolo ťažké to zistiť pomocou nástrojov dostupných v CoreOS.
- Správa tajomstiev.
- Prakticky neexistovalo žiadne CM. Boli tam konfigurácie bash a CoreOS YML.
Ak chcete použiť konfiguráciu virtuálneho počítača, musíte ho reštartovať, ale možno sa nereštartuje. Zdá sa to ako zrejmý problém, ale nie sú k dispozícii žiadne trvalé disky, takže nie je kam ukladať protokoly. Dobre, skúsme pridať možnosti bootovania jadra na preposielanie protokolov. Ale nie, toto je všetko také komplikované.
Deň č. 0: Rozpoznanie problému
Bola to typická vývojová infraštruktúra: Jenkins, testovacie prostredia, monitorovanie a register. CoreOS bol navrhnutý na hosťovanie klastrov K8S, takže problémom bolo, ako sa CoreOS používal. Prvým krokom bol výber stacku. Rozhodli sme sa pre:
- CentOS ako základná distribúcia, pretože je najbližšie k produkčným prostrediam.
- Ansible pre správu konfigurácií, keďže v tejto oblasti existovali rozsiahle odborné znalosti.
- Jenkins ako rámec pre automatizáciu existujúcich procesov, keďže sa už aktívne používal pre vývojové procesy
- Hyper-V ako virtualizačná platforma. Existuje niekoľko dôvodov, ktoré presahujú rámec tohto článku, ale skrátka, nemôžeme používať cloud; musíme používať vlastný hardvér.
Deň 30: Dokumentovanie existujúcich dohôd – Dohody ako kódex
Keď bol zásobník vyčistený, začali sa prípravy na presun. Zaznamenávanie existujúcich dohôd do kódu (Dohody ako kódexPrechod manuálna práca -> mechanizácia -> automatizácia.
1. Konfigurácia virtuálnych počítačov
Ansible túto úlohu zvláda perfektne. S minimálnym úsilím môžete spravovať konfigurácie virtuálnych počítačov:
- Vytvorme si git repozitár.
- Zoznam virtuálnych počítačov sme vložili do inventára, konfigurácie do playbookov a rolí.
- Nastavili sme špeciálny Jenkins slave, z ktorého môžeme spúšťať Ansible.
- Vytvoríme úlohu a nakonfigurujeme Jenkinsa.
Prvá skúška je pripravená. Dohody boli finalizované.
2. Vytvorte nový virtuálny počítač
Veci tu neboli veľmi užívateľsky prívetivé. Vytváranie virtuálnych počítačov na Hyper-V z Linuxu nie je veľmi pohodlné. Jeden pokus o mechanizáciu tohto procesu bol:
- Ansbile sa pripája k hostiteľskému systému Windows cez WinRM.
- Ansible spúšťa skript v PowerShelle.
- Skript Powershell vytvorí nový virtuálny počítač.
- Pri vytváraní virtuálneho počítača v hosťujúcom operačnom systéme sa názov hostiteľa konfiguruje pomocou Hyper-V/ScVMM.
- Pri obnovení prenájmu DHCP odošle virtuálny počítač svoj názov hostiteľa.
- Štandardná integrácia ddns a dhcp na strane radiča domény konfiguruje záznam DNS.
- Virtuálne počítače môžete pridať do svojho inventára a nakonfigurovať ich pomocou Ansible.
3. Vytvorte šablónu virtuálneho počítača
Nič tu nevymysleli - vzali si packera.
- Packer a konfiguráciu kickstartu sme vložili do git repozitára.
- Nastavili sme vyhradený server Jenkins s Hyper-V a Packerom.
- Vytvoríme úlohu a nakonfigurujeme Jenkinsa.
Ako toto prepojenie funguje:
- Packer vytvorí prázdny virtuálny počítač a pripojí ISO súbor.
- Virtuálny počítač sa spustí, Packer zadá do bootloaderu príkaz na použitie nášho kickstart súboru z diskety alebo http.
- Anaconda sa spustí s našou konfiguráciou a vykoná sa počiatočné nastavenie operačného systému.
- Packer čaká na sprístupnenie virtuálneho počítača.
- Packer spúšťa Ansible v lokálnom režime vo vnútri virtuálneho počítača.
- Ansible pracuje s použitím presne rovnakých rolí ako v kroku č. 1.
- Packer exportuje šablónu virtuálneho počítača.
Deň č. 75: Refaktoring dohôd bez ich porušenia = Test Ansible + Testkitchen
Dohody o kódovaní nemusia stačiť. Koniec koncov, ak chcete niečo zmeniť na pozadí, môžete niečo pokaziť. Preto v prípade infraštruktúry prichádza na rad testovanie práve tejto infraštruktúry. Aby sme synchronizovali znalosti v rámci tímu, začali sme testovať role Ansible. Nebudem zachádzať do detailov, pretože existuje článok, ktorý opisuje udalosti v tom čase. (upozornenie na spoiler: toto nebola finálna verzia a veci sa neskôr skomplikovali) ).
Deň č. 130: Možno CentOSNepotrebuješ +ansible? Možno openshift?
Je dôležité pochopiť, že proces implementácie infraštruktúry nebol jediný a existovali aj vedľajšie projekty. Napríklad prišla požiadavka na spustenie našej aplikácie v OpenShifte, čo viedlo k týždňom výskumu. Čo spomalilo proces migrácie. Ukázalo sa, že OpenShift nepokrýva všetky potreby; je potrebný skutočný hardvér, alebo aspoň schopnosť hrať sa s jadrom.
Deň #170: Openshift nie je vhodný, poďme to risknúť Windows Azure balíček?
Hyper-V nie je veľmi užívateľsky prívetivý a SCVMM ho veľmi nevylepšuje. Ale aj taká vec existuje. Windows Azure Pack, čo je doplnok k SCVMM a napodobňuje Azure. V skutočnosti sa produkt javí ako opustený: dokumentácia je riedka a plná nefunkčných odkazov. Pozreli sme sa naň však aj pri hľadaní možností, ako si zjednodušiť život v cloude.
Deň č. 250: Windows Azure Pack nie je skvelý. Držíme sa SCVMM.
Windows Azure Pack vyzeral sľubne, ale bolo rozhodnuté nepriniesť do systému WAP s jeho zložitosťami kvôli zbytočným funkciám a zostalo sa pri SCVMM.
Deň č. 360: Jedenie slona kus po kuse
Až o rok neskôr bola platforma pripravená na presun a začal sa proces migrácie. Na to bola stanovená úloha SMART. Odhlásili sme všetky virtuálne počítače a začali sme postupne prepracovávať konfiguráciu, popisovať ju v Ansible a pokrývať ju testami.
Deň č. 450: S akým systémom si nakoniec skončil?
Samotný proces je nezaujímavý. Je to rutina. Stojí za zmienku, že väčšina konfigurácií bola relatívne jednoduchá alebo izomorfná a podľa Paretovho princípu 80 % konfigurácií trvalo 20 % času. Rovnako tak sa 80 % času venovalo príprave na presun a iba 20 % samotnému presunu.
Deň č. 540: Finále
Čo sa teda stalo za 18 mesiacov?
- Dohody sa stali kódexom.
- Manuálna práca -> Mechanizácia -> automatizácia.
Odkazy
Zdroj: hab.com
