Questa è la trascrizione dell'intervento su e .
Questa è la storia di un progetto in cui è stata utilizzata un sistema di gestione delle configurazioni personalizzato e perché il trasferimento ad Ansible è durato 18 mesi.
Giorno № -XXX: Prima dell'inizio
Inizialmente, l'infrastruttura era composta da numerosi host separati gestiti da Hyper-V. Creare una macchina virtuale richiedeva molte operazioni: posizionare i dischi nel giusto posto, configurare DNS, riservare DHCP e inserire la configurazione della VM nel repository git. Questo processo era parzialmente meccanizzato, ma ad esempio le VM venivano distribuite tra gli host manualmente. Tuttavia, gli sviluppatori potevano modificare la configurazione della VM nel git e applicarla riavviando la VM.
Soluzione di gestione delle configurazioni personalizzata
L'idea iniziale, sospetto, era concepita come IaC: numerose VM stateless che annullavano il loro stato al riavvio. Com'era gestita la configurazione delle VM? Schemamaticamente, sembra semplice:
- Per le VM veniva fissato un MAC statico.
- Alla VM veniva collegato un ISO di CoreOS e un disco di avvio.
- CoreOS esegue uno script di personalizzazione scaricandolo da un server WEB in base al proprio IP.
- Lo script recupera tramite SCP la configurazione della VM basandosi sull'indirizzo IP.
- Viene avviato un insieme di file di unità systemd e un insieme di script bash.
Questa soluzione presentava numerosi problemi evidenti:
- L'ISO in CoreOS era deprecato.
- Molte azioni complesse da automatizzare e magie durante la migrazione/creazione delle VM.
- Difficoltà con gli aggiornamenti e quando è necessario un software di una certa versione. Ancora più complicato con i moduli del kernel.
- Le VM non erano così vuote di dati; ci sono VM che avevano montato un disco con dati utente aggiuntivi.
- Qualcuno commetteva continuamente errori con le dipendenze delle unità systemd e CoreOS si bloccava al riavvio. Era problematico catturarlo con i mezzi disponibili in CoreOS.
- Gestione dei segreti.
- Non c'era una vera gestione della configurazione. C'erano script bash e configurazioni YML per CoreOS.
Per applicare la configurazione della VM è necessario riavviarla, ma potrebbe non riavviarsi. Sembra un problema ovvio, ma non ci sono dischi persistenti — non c'è posto dove salvare i log. Ok, proviamo ad aggiungere opzioni di avvio del kernel per inviare i log. Ma no, è tutto così complicato.
Giorno n. 0: Riconoscimento del problema
Si trattava di un'infrastruttura di sviluppo standard: jenkins, ambienti di test, monitoraggio, registry. CoreOS è stata progettata per l'hosting di cluster k8s, quindi il problema riguardava l'uso di CoreOS. Il primo passo è stata la scelta dello stack. Ci siamo orientati su:
- CentOS come distribuzione di base, poiché è la distribuzione più vicina agli ambienti di produzione.
- Ansible per la gestione delle configurazioni, vista l'ampia esperienza disponibile.
- Jenkins come framework di automazione dei processi esistenti, poiché era già attivamente utilizzato nei processi di sviluppo.
- Hyper-V come piattaforma di virtualizzazione. Ci sono diverse ragioni che esulano dall'argomento, ma in breve — non possiamo usare il cloud, dobbiamo utilizzare il nostro hardware.
Giorno n. 30: Fissiamo gli accordi esistenti — Agreements as Code
Una volta compreso lo stack, è iniziata la preparazione al trasferimento. La formalizzazione degli accordi esistenti sotto forma di codice (Agreements as Code!). Il passaggio lavoro manuale -> meccanizzazione -> automazione.
1. Configurare le VM
Ansible si occupa perfettamente di questo compito. Con il minimo sforzo, è possibile gestire le configurazioni delle VM:
- Creiamo un repository git.
- Colleghiamo l'elenco delle VM all'inventario, le configurazioni ai playbook e ai ruoli.
- Impostiamo uno slave Jenkins speciale da cui sarà possibile avviare Ansible.
- Creiamo un job e configuriamo Jenkins.
Il primo processo è pronto. Gli accordi sono stati confermati.
2. Crea una nuova VM
Qui non era molto comodo. Creare VM su Hyper-V da Linux era poco pratico. Una delle tentativi di meccanizzare questo processo è stata:
- Ansible si connette al host Windows tramite WinRM.
- Ansible avvia uno script PowerShell.
- Lo script PowerShell crea una nuova VM.
- Utilizzando Hyper-V/ScVMM, quando crei una VM, puoi configurare il hostname nel sistema operativo guest.
- La VM invia il proprio hostname quando aggiorna il lease DHCP.
- L'integrazione standard di DDNS & DHCP sul Domain Controller configura il record DNS.
- Puoi aggiungere VM all'inventario e configurarle con Ansible.
3. Crea un template VM
Qui non abbiamo inventato nulla — abbiamo usato Packer.
- Nel repository Git mettiamo la configurazione di Packer e kickstart.
- Configuriamo uno slave Jenkins speciale con Hyper-V e Packer.
- Creiamo un job e configuriamo Jenkins.
Come funziona questa combinazione:
- Packer crea una VM vuota e collega un file ISO.
- La VM si avvia, Packer inserisce nel bootloader il comando per usare il nostro file kickstart da dischetto o http.
- Anaconda si avvia con la nostra configurazione e esegue la configurazione iniziale del sistema operativo.
- Packer attende la disponibilità della VM.
- Il Packer all'interno della VM esegue ansible in modalità locale.
- Ansible utilizza esattamente gli stessi ruoli del passo n. 1.
- Il Packer esporta il modello VM.
Giorno n. 75: Ristrutturiamo gli accordi senza rompere = Test ansible + Testkitchen.
Fissare gli accordi nel codice potrebbe non essere sufficiente. Infatti, se durante il processo sottostante desideri cambiare qualcosa, potresti rompere qualcosa. Pertanto, nel caso dell'infrastruttura, è necessario testare tale infrastruttura. Per sincronizzare le conoscenze all'interno del team, abbiamo iniziato a testare i ruoli di Ansible. Non approfondirò poiché c'è un articolo che descrive gli eventi in quel momento. (spoiler: questa non era la versione finale e in seguito è diventato tutto più complicato. ).
Giorno n. 130: E se CentOS + ansible non fosse necessario? Magari openshift?
È importante capire che il processo di introduzione dell'infrastruttura non è stato l'unico e ci sono stati sottoprogetti collaterali. Ad esempio, abbiamo ricevuto una richiesta per eseguire la nostra applicazione in openshift e questo si è trasformato in ricerche che sono durate più di una settimana. ciò che ha rallentato il processo di migrazione. Alla fine, si è scoperto che openshift non soddisfa tutte le esigenze; è necessario un hardware reale, o almeno la possibilità di giocare con il kernel.
Giorno n. 170: Openshift non è adatto, proviamo con Windows Azure Pack?
Hyper-V non è molto amichevole, SCVMM non lo migliora molto. Tuttavia, esiste Windows Azure Pack, che è un'estensione di SCVMM e si mimetizza come Azure. Ma in realtà, il prodotto sembra trascurato: la documentazione contiene link rotti ed è piuttosto scarsa. Tuttavia, nell'ambito della ricerca di opzioni per semplificare la vita al nostro cloud, lo abbiamo preso in considerazione.
Giorno n. 250: Windows Azure Pack non è molto. Rimaniamo su SCVMM
Windows Azure Pack sembrava promettente, ma si è deciso di non portare WAP con le sue complessità nel sistema per funzionalità non necessarie, quindi siamo rimasti su SCVMM.
Giorno n. 360: Mangiamo l'elefante a pezzi
Solo dopo un anno è stata pronta la piattaforma su cui migrare e ha avuto inizio il processo di migrazione. Per questo è stato impostato un compito S.M.A.R.T. Abbiamo elencato tutte le VM e abbiamo iniziato a esaminare una ad una la configurazione, documentandola in Ansible e coprendola con test.
Giorno n. 450: Quale sistema è stato realizzato?
Il processo in sé non è interessante. È routinario; si può notare che la maggior parte delle configurazioni era relativamente semplice o isomorfa, e secondo il principio di Pareto, l'80% delle configurazioni ha richiesto il 20% del tempo. Allo stesso modo, l'80% del tempo è stato speso per la preparazione del trasferimento e solo il 20% per il trasferimento stesso.
Giorno n. 540: Finale
Cosa è successo in 18 mesi?
- Gli accordi sono diventati codice.
- Lavoro manuale -> Meccanizzazione -> Automazione.
Links
Fonte: habr.com
