Questa è una trascrizione del discorso и .
Questa è la storia di un progetto che utilizzava un sistema di gestione della configurazione autoprodotto e spiega perché il passaggio ad Ansible ha richiesto 18 mesi.
Giorno n. -ХХХ: Prima dell'inizio
Inizialmente, l'infrastruttura era costituita da molti host separati che eseguivano Hyper-V. La creazione di una macchina virtuale ha richiesto molti passaggi: mettere i dischi nel posto giusto, registrare il DNS, riservare il DHCP, inserire la configurazione della VM nel repository git. Questo processo era parzialmente meccanizzato, ma, ad esempio, le VM venivano distribuite manualmente tra gli host. Ma, ad esempio, gli sviluppatori potrebbero correggere la configurazione della VM in git e applicarla riavviando la VM.
Soluzione di gestione della configurazione personalizzata
L'idea originale, sospetto, è stata concepita come IaC: molte VM senza stato che ripristinano il loro stato a zero al riavvio. Cos'era la gestione della configurazione delle VM? Schematicamente sembra semplice:
- È stato inchiodato un MAC statico per la VM.
- Alla VM erano collegati un ISO con CoreOS e un disco di avvio.
- CoreOS avvia lo script di personalizzazione scaricandolo dal server WEB in base al suo IP.
- Lo script scarica la configurazione della VM tramite SCP in base all'indirizzo IP.
- Vengono avviati il footcloth dei file systemd unit e il footcloth degli script bash.
Questa soluzione presentava molti problemi evidenti:
- L'ISO CoreOS è stato deprecato.
- Molte azioni automatizzate complesse e magie durante la migrazione/creazione di VM.
- Difficoltà con l'aggiornamento e quando è necessaria una determinata versione del software. Ancora più divertente con i moduli del kernel.
- Le VM non sono state così ottenute senza dati, ad es. Le macchine virtuali apparivano con un disco con dati utente aggiuntivi montati.
- Qualcuno rovinava costantemente le dipendenze dell'unità systemd e CoreOS si bloccava al riavvio. È stato difficile rilevarlo utilizzando gli strumenti disponibili in CoreOS.
- Gestione dei segreti.
- Non c'era CM. C'erano configurazioni bash e YML per CoreOS.
Per applicare la configurazione della VM, è necessario riavviarla, ma potrebbe non riavviarsi. Sembra un problema ovvio, ma non ci sono dischi permanenti: non c'è nessun posto dove salvare i registri. Bene, ok, proviamo ad aggiungere l'opzione di caricamento del kernel in modo che i log vengano inviati. Ma no, quanto è complicato tutto.
Giorno n. 0: riconoscere il problema
Era la solita infrastruttura di sviluppo: Jenkins, ambienti di test, monitoraggio, registro. CoreOS è stato progettato per ospitare cluster k8s, ad es. il problema era il modo in cui veniva utilizzato CoreOS. Il primo passo è stato scegliere uno stack. Abbiamo optato per:
- CentOS come distribuzione di base, perché Questa è la distribuzione più vicina agli ambienti di produzione.
- ansible per la gestione della configurazione, perché c'è stato un esame approfondito su di esso.
- Jenkins come framework per automatizzare i processi esistenti, perché è già stato utilizzato attivamente per i processi di sviluppo
- Hyper-V come piattaforma di virtualizzazione. Ci sono una serie di ragioni che vanno oltre lo scopo della storia, ma in breve: non possiamo usare le nuvole, dobbiamo usare il nostro hardware.
Giorno n. 30: Correzione degli accordi esistenti - Accordi come codice
Quando la pila fu sgombrata, iniziarono i preparativi per il trasloco. Fissazione degli accordi esistenti sotto forma di codice (Accordi come codice!). Transizione lavoro manuale -> meccanizzazione -> automazione.
1. Configurare le VM
Ansible fa un ottimo lavoro in questo. Con minimi movimenti del corpo puoi prendere il controllo delle configurazioni della VM:
- Crea un repository git.
- Inseriamo l'elenco delle VM nell'inventario, le configurazioni nei playbook e nei ruoli.
- Stiamo creando uno speciale Jenkins Slave da cui puoi eseguire Ansible.
- Creiamo un lavoro e configuriamo Jenkins.
Il primo processo è pronto. Gli accordi sono fissi.
2. Crea una nuova VM
Qui non era tutto molto conveniente. Non è molto conveniente creare VM su Hyper-V da Linux. Uno dei tentativi di meccanizzare questo processo è stato:
- Ansbile si connette tramite WinRM all'host Windows.
- Ansible esegue uno script PowerShell.
- Lo script PowerShell crea una nuova VM.
- Utilizzando Hyper-V/ScVMM, quando si crea una macchina virtuale nel sistema operativo guest, il nome host viene configurato.
- Durante l'aggiornamento del lease DHCP, la VM invia il proprio nome host.
- L'integrazione standard DNS e DHCP sul lato controller di dominio configura il record DNS.
- Puoi aggiungere una VM al tuo inventario e configurarla con Ansible.
3.Crea modello VM
Non hanno inventato nulla qui: hanno preso un imballatore.
- Aggiungi il packer, kickstart config al repository git.
- Impostazione di uno speciale Jenkins Slave con Hyper-V e Packer.
- Creiamo un lavoro e configuriamo Jenkins.
Come funziona questo collegamento:
- Packer crea una VM vuota e preleva l'ISO.
- La VM si avvia, Packer inserisce il comando nel bootloader per utilizzare il nostro file kickstart da un floppy disk o http.
- Anaconda viene avviato con la nostra configurazione e la configurazione iniziale del sistema operativo è completata.
- Packer attende che la VM diventi disponibile.
- Packer all'interno della VM esegue ansible in modalità locale.
- Ansible utilizza esattamente gli stessi ruoli utilizzati nel passaggio n. 1.
- Packer esporta il modello VM.
Giorno #75: Rifattorizzare l'accordo senza romperlo = Test ansible + Testkitchen
Catturare le convenzioni nel codice potrebbe non essere sufficiente. Dopotutto, se nei dettagli del processo vuoi cambiare qualcosa, puoi rompere qualcosa. Pertanto, nel caso dell'infrastruttura, appare il test di questa stessa infrastruttura. Per sincronizzare le conoscenze all'interno del team, abbiamo iniziato a testare i ruoli Ansible. Non entro nel dettaglio perché... c'è un articolo che descrive gli eventi in quel momento (spoiler questa non era la versione finale e poi tutto è diventato più complicato ).
Giorno n. 130: forse CentOS+ansible non è necessario? magari openshift?
Dobbiamo capire che il processo di introduzione delle infrastrutture non è stato l'unico e c'erano sottoprogetti collaterali. Ad esempio, è arrivata una richiesta per lanciare la nostra applicazione in openshift e questo ha comportato una ricerca per più di una settimana che ha rallentato il processo di spostamento. Il risultato è che openshift non copre tutte le esigenze; è necessario un vero hardware, o almeno la capacità di giocare con il kernel.
Giorno #170: Openshift non è adatto, rischiamo con Windows Azure Pack?
Hyper-V non è molto amichevole, SCVMM non lo rende molto migliore. Ma esiste qualcosa come Windows Azure Pack, che è un componente aggiuntivo di SCVMM e imita Azure. Ma in realtà il prodotto sembra abbandonato: la documentazione ha collegamenti interrotti ed è molto scarsa. Ma nell'ambito dello studio delle opzioni per semplificare la vita del nostro cloud, hanno esaminato anche questo.
Giorno 250: Windows Azure Pack non molto buono. Rimaniamo su SCVMM
Windows Azure Pack sembrava promettente, ma si è deciso di non introdurre il WAP con le sue complessità nel sistema per motivi di funzionalità non necessarie e si è mantenuto con SCVMM.
Giorno #360: Mangiare l'elefante pezzo per pezzo
Solo un anno dopo la piattaforma per il trasloco era pronta ed è iniziato il processo di trasloco. A questo scopo è stato impostato un compito SMART. Abbiamo controllato tutte le VM e abbiamo iniziato a capire la configurazione una per una, descriverla in Ansible e coprirla con i test.
Giorno #450: Che tipo di sistema hai ottenuto?
Il processo in sé non è interessante. È routine, si può notare che la maggior parte delle configurazioni erano relativamente semplici o isomorfe e secondo il principio di Pareto, l'80% delle configurazioni VM richiedevano il 20% del tempo. Per lo stesso principio, l’80% del tempo è stato dedicato alla preparazione del trasloco e solo il 20% al trasloco stesso.
Giorno n. 540: finale
Cosa è successo in 18 mesi?
- Gli accordi sono diventati un codice.
- Lavoro manuale -> meccanizzazione -> Automazione.
Link
Fonte: habr.com