Toto je přepis projevu и .
Toto je příběh projektu, který používal vlastní systém správy konfigurace a proč přechod na Ansible trval 18 měsíců.
Den č. -ХХХ: Před začátkem
Zpočátku se infrastruktura skládala z mnoha samostatných hostitelů se systémem Hyper-V. Vytvoření virtuálního stroje vyžadovalo mnoho kroků: umístění disků na správné místo, registrace DNS, rezervace DHCP, umístění konfigurace VM do úložiště git. Tento proces byl částečně mechanizován, ale například VM byly distribuovány mezi hostitele ručně. Ale například vývojáři by mohli opravit konfiguraci virtuálního počítače v git a použít ji restartováním virtuálního počítače.
Vlastní řešení pro správu konfigurace
Původní myšlenka, tuším, byla koncipována jako IaC: mnoho bezstavových virtuálních počítačů, které po restartu resetují svůj stav na nulu. Co byla správa konfigurace virtuálního počítače? Schematicky to vypadá jednoduše:
- Pro virtuální počítač byl přibit statický MAC.
- K VM bylo připojeno ISO s CoreOS a spouštěcí disk.
- CoreOS spustí skript přizpůsobení jeho stažením z WEB serveru na základě jeho IP adresy.
- Skript stáhne konfiguraci VM přes SCP na základě IP adresy.
- Spustí se základní deska souborů systemd unit a základní deska bash skriptů.
Toto řešení mělo mnoho zjevných problémů:
- ISO CoreOS bylo zastaralé.
- Spousta složitých automatických akcí a kouzel při migraci/vytváření VM.
- Potíže s aktualizací a když je potřeba určitá verze softwaru. Ještě více zábavy s moduly jádra.
- VM nebyly takto získány bez dat, tzn. Virtuální počítače se objevily s diskem s připojenými dalšími uživatelskými daty.
- Někdo neustále šrouboval závislosti na systemd unit a CoreOS při restartu zamrzal. Bylo těžké to zachytit pomocí dostupných nástrojů v CoreOS.
- Správa tajemství.
- Nebyl tam žádný CM. Pro CoreOS existovaly konfigurace bash a YML.
Chcete-li použít konfiguraci virtuálního počítače, musíte jej restartovat, ale nemusí se restartovat. Vypadá to jako zřejmý problém, ale neexistují žádné trvalé disky – protokoly není kam ukládat. Dobře, zkusíme přidat možnost načítání jádra, aby se protokoly posílaly. Ale ne, jak je to všechno složité.
Den #0: Rozpoznejte problém
Byla to obvyklá vývojová infrastruktura: jenkins, testovací prostředí, monitorování, registr. CoreOS byl navržen pro hostování clusterů k8s, tzn. problém byl ve způsobu použití CoreOS. Prvním krokem byl výběr zásobníku. Dohodli jsme se na:
- CentOS jako základní distribuce, protože Toto je distribuce nejbližší produkčnímu prostředí.
- Možná pro správu konfigurace, protože bylo na to rozsáhlé zkoumání.
- Jenkins jako rámec pro automatizaci existujících procesů, protože již byl aktivně využíván pro vývojové procesy
- Hyper-V jako virtualizační platforma. Důvodů, které přesahují rámec příběhu, je celá řada, ale stručně řečeno – nemůžeme používat mraky, musíme používat vlastní hardware.
Den č. 30: Oprava stávajících dohod - Smlouvy jako kodex
Když byl zásobník čistý, začaly přípravy na přesun. Oprava stávajících dohod ve formě kódu (Dohody jako kodex!). Přechod ruční práce -> mechanizace -> automatizace.
1. Nakonfigurujte virtuální počítače
Ansible to dělá skvěle. S minimem pohybů těla můžete převzít kontrolu nad konfiguracemi VM:
- Vytvořte úložiště git.
- Umístili jsme seznam virtuálních počítačů do inventáře, konfigurace do playbooků a rolí.
- Nastavujeme speciálního otroka Jenkins, ze kterého můžete spustit Ansible.
- Vytvoříme zakázku a nakonfigurujeme Jenkinse.
První proces je připraven. Dohody jsou pevně dané.
2. Vytvořte nový virtuální počítač
Všechno zde nebylo příliš pohodlné. Vytvářet virtuální počítače na Hyper-V z Linuxu není příliš pohodlné. Jeden z pokusů mechanizovat tento proces byl:
- Ansbile se připojuje přes WinRM k hostiteli Windows.
- Ansible spustí skript powershell.
- Skript Powershell vytvoří nový virtuální počítač.
- Pomocí Hyper-V/ScVMM se při vytváření virtuálního počítače v hostujícím OS nakonfiguruje název hostitele.
- Při aktualizaci zapůjčení DHCP odešle virtuální počítač svůj název hostitele.
- Standardní integrace ddns a dhcp na straně řadiče domény konfiguruje záznam DNS.
- Můžete přidat virtuální počítač do svého inventáře a nakonfigurovat jej pomocí Ansible.
3. Vytvořte šablonu VM
Tady nic nevymysleli - vzali baličku.
- Přidejte packer, kickstart config do úložiště git.
- Nastavení speciálního otroka Jenkins s hyper-v a Packerem.
- Vytvoříme zakázku a nakonfigurujeme Jenkinse.
Jak tento odkaz funguje:
- Packer vytvoří prázdný virtuální počítač a převezme ISO.
- VM se spustí, Packer zadá příkaz do zavaděče, aby použil náš soubor kickstart z diskety nebo http.
- Anaconda je spuštěna s naší konfigurací a je dokončena počáteční konfigurace OS.
- Packer čeká, až bude virtuální počítač k dispozici.
- Packer uvnitř virtuálního počítače běží v místním režimu.
- Ansible používá přesně stejné role, jaké funguje v kroku #1.
- Packer exportuje šablonu virtuálního počítače.
Den #75: Refaktorujte dohodu bez porušení = Test ansible + Testkitchen
Zachycení konvencí v kódu nemusí stačit. Koneckonců, pokud v průběhu procesu chcete něco změnit, můžete něco porušit. Proto se v případě infrastruktury objevuje testování právě této infrastruktury. Abychom synchronizovali znalosti v rámci týmu, začali jsme testovat role Ansible. Nebudu zacházet do hloubky, protože... existuje článek popisující události v té době (spoiler to nebyla finální verze a později se vše zkomplikovalo ).
Den #130: Možná není potřeba CentOS+ansible? možná openshift?
Musíme pochopit, že proces zavádění infrastruktury nebyl jediný a existovaly vedlejší dílčí projekty. Například přišel požadavek na spuštění naší aplikace v openshiftu, což vedlo k výzkumu po dobu delší než jeden týden což zpomalilo proces pohybu. Výsledek ukázal, že openshift nepokrývá všechny potřeby, potřebujete skutečný hardware nebo alespoň schopnost hrát si s jádrem.
Den #170: Openshift není vhodný, pojďme to zkusit s Windows Azure Pack?
Hyper-V není moc přívětivé, SCVMM to moc nevylepšuje. Existuje ale něco jako Windows Azure Pack, což je doplněk k SCVMM a napodobuje Azure. Ve skutečnosti však produkt vypadá opuštěně: dokumentace má nefunkční odkazy a je velmi řídká. V rámci studia možností, jak zjednodušit život našeho cloudu, se ale podívali i na něj.
Den #250: Windows Azure Pack není moc dobrý. Zůstáváme na SCVMM
Windows Azure Pack vypadal slibně, ale bylo rozhodnuto nezavádět WAP s jeho složitostí do systému kvůli zbytečným funkcím a zůstalo u SCVMM.
360. den: Požírání slona kousek po kousku
Teprve o rok později byla platforma pro stěhování připravena a proces stěhování začal. Za tímto účelem byla nastavena úloha SMART. Zkontrolovali jsme všechny virtuální počítače a začali jsme zjišťovat konfiguraci jeden po druhém, popisovat ji v Ansible a pokrývat ji testy.
Den #450: Jaký druh systému jste získali?
Samotný proces není zajímavý. Je to rutina, lze poznamenat, že většina konfigurací byla relativně jednoduchá nebo izomorfní a podle Paretova principu 80 % konfigurací VM vyžadovalo 20 % času. Podle stejného principu bylo 80 % času věnováno přípravě stěhování a pouze 20 % samotnému stěhování.
Den #540: Finále
Co se stalo za 18 měsíců?
- Dohody se staly kodexem.
- Ruční práce -> Mechanizace -> Automatizace.
Zdroj: www.habr.com