Questa è la trascrizione dell'intervento a e .
Questa è la storia del progetto che ha utilizzato un sistema di gestione delle configurazioni sviluppato internamente e il motivo per cui la migrazione su Ansible ha impiegato 18 mesi.
Giorno № -XXX: Prima dell'inizio
Inizialmente, l'infrastruttura consisteva in un gran numero di host indipendenti gestiti da Hyper-V. La creazione di una macchina virtuale richiedeva molte operazioni: posizionare i dischi nel luogo giusto, configurare il DNS, prenotare il DHCP e inserire la configurazione della VM in un repository Git. Questo processo era parzialmente meccanizzato, ma ad esempio le VM venivano distribuite tra gli host manualmente. Tuttavia, per esempio, gli sviluppatori potevano modificare la configurazione della VM in Git e applicarla riavviando la VM.
Soluzione di gestione delle configurazioni personalizzata
L'idea iniziale, suppongo, era concepita come IaC: molte VM stateless, che azzeravano il loro stato al riavvio. Come appariva la gestione delle configurazioni delle VM? Schematicamente sembra semplice:
- Per le VM veniva assegnato un MAC statico.
- Alle VM veniva collegato un ISO con 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 avviata una serie di file di unità systemd e una serie di script bash.
Questa soluzione presentava molti problemi evidenti:
- L'ISO in CoreOS era deprecato.
- Numerose azioni e magie difficilmente automatizzabili durante la migrazione/creazione delle VM.
- Difficoltà con l'aggiornamento e quando era necessario del software di una certa versione. Ancora più divertente con i moduli del kernel.
- Le VM non risultavano così prive di dati, ovvero apparvero VM con un disco montato contenente dati utente aggiuntivi.
- Qualcuno combinava sempre guai con le dipendenze delle unità systemd e al riavvio CoreOS si bloccava. Era problematico catturarlo con i mezzi a disposizione in CoreOS.
- Gestione dei segreti.
- Non c'era un vera e propria CM. C'era bash e i config YML di CoreOS.
Per applicare la configurazione della VM era necessario riavviarla, ma a volte non si riavviava. Sembra un problema ovvio, ma non ci sono dischi persistenti – non c’è dove salvare i log. Va bene, proviamo ad aggiungere opzioni di avvio del kernel in modo da inviare i log. Ma no, quanto è complicato tutto ciò.
Giorno №0: Riconoscimento del problema
Questa era un'infrastruttura di sviluppo abituale: jenkins, ambienti di test, monitoraggi, registry. CoreOS era pensato per l'hosting di cluster k8s, cioè il problema stava nel modo in cui veniva utilizzato CoreOS. Il primo passo è stato la scelta della stack.
- CentOS come distribuzione base, poiché è la distribuzione più vicina agli ambienti di produzione.
- Ansible per la gestione delle configurazioni, poiché si aveva una vasta esperienza a riguardo.
- Jenkins come framework di automazione dei processi esistenti, poiché era già attivamente utilizzato per i processi di sviluppo.
- Hyper-V come piattaforma di virtualizzazione. Ci sono diverse ragioni al di là di quanto descritto, ma per farla breve — non possiamo utilizzare cloud e dobbiamo utilizzare il nostro hardware.
Giorno n. 30: Fissiamo gli accordi esistenti — Agreements as Code
Quando la stack era chiara, è iniziata la preparazione per il 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 bene di quest'attività. Con un minimo di sforzi, è possibile gestire le configurazioni delle VM:
- Creiamo un repository git.
- Archiviare l'elenco delle VM nell'inventory, le configurazioni nei playbook e nei ruoli.
- Configurare un slave Jenkins speciale da cui sarà possibile eseguire Ansible.
- Creiamo un job, configurando Jenkins.
Il primo processo è pronto. Gli accordi sono formalizzati.
2. Creare una nuova VM
Qui le cose non erano molto comode. Era difficile creare VM su Hyper-V da Linux. Uno dei tentativi di meccanizzare questo processo è stato:
- Ansible si connette tramite WinRM all'host Windows.
- Ansible esegue uno script PowerShell.
- Lo script PowerShell crea una nuova VM.
- Con gli strumenti Hyper-V/ScVMM durante la creazione della VM nel guest OS viene configurato il hostname.
- La VM, durante l'aggiornamento del lease DHCP, invia il suo hostname.
- L'integrazione standard ddns & dhcp sul lato del Domain Controller configura il record DNS.
- È possibile aggiungere la VM all'inventory e configurarla con Ansible.
3. Creare un template VM
Qui non abbiamo inventato nulla — abbiamo usato packer.
- Archiviamosi nel repository git la configurazione di packer, kickstart.
- Configurare un slave Jenkins speciale con hyper-v e Packer.
- Creiamo un job, configurando Jenkins.
Come funziona questa combinazione:
- Packer crea una VM vuota, attacca l'ISO.
- La VM si avvia, Packer inserisce nel bootloader il comando per utilizzare il nostro file kickstart da floppy o http.
- Si avvia Anaconda con la nostra configurazione, si esegue la configurazione iniziale del sistema operativo.
- Packer attende la disponibilità della VM.
- Packer all'interno della VM esegue Ansible in modalità locale.
- Ansible utilizza esattamente gli stessi ruoli di cui al passo n. 1.
- Packer esporta il modello della VM.
Giorno n. 75: Rifattorizziamo gli accordi senza rompere = Test ansible + Testkitchen
Fissare gli accordi nel codice potrebbe non essere sufficiente. Infatti, se nel profondo del processo vuoi cambiare qualcosa, potresti rompere qualcosa. Ecco perché, per l'infrastruttura, entra in gioco il test di quella stessa infrastruttura. Per sincronizzare le conoscenze all'interno del team, abbiamo iniziato a testare i ruoli di Ansible. Non approfondirò poiché esiste un articolo che descrive gli eventi di quel momento. (spoiler: questa non era la versione finale e in seguito tutto è diventato più complicato) ).
Giorno n. 130: E se CentOS+ansible non fosse necessario? Magari Openshift?
Bisogna capire che il processo di implementazione dell'infrastruttura non è stato l'unico e ci sono stati progetti secondari. Ad esempio, è arrivata una richiesta per avviare la nostra applicazione in Openshift e questo si è tradotto in ricerche non inferiori a una settimana. cosa ha rallentato il processo di migrazione. Il risultato è stato che Openshift non soddisfa tutte le esigenze; è necessario hardware reale, o almeno la possibilità di giocare con il kernel.
Giorno n. 170: Openshift non è adatto, rischiamo con Windows Azure Pack?
Hyper-V non è molto amichevole, SCVMM non lo migliora significativamente. Ma c'è una cosa chiamata Windows Azure Pack, che è un'add-on di SCVMM e si mimetizza come Azure. Ma in realtà il prodotto appare abbandonato: documentazione con link rotti e piuttosto scarsa. Tuttavia, nel contesto della ricerca di opzioni per semplificare la vita della nostra cloud, lo abbiamo esaminato.
Giorno n. 250: Windows Azure Pack non è molto promettente. Rimaniamo su SCVMM.
Windows Azure Pack sembrava promettente, ma è stato deciso di non introdurre WAP con le sue complessità nel sistema per caratteristiche non necessarie e siamo rimasti su SCVMM.
Giorno n. 360: Mangiamo un elefante a pezzi.
Solo dopo un anno la piattaforma in cui migrare era pronta e iniziò il processo di migrazione. Per questo è stato stabilito un obiettivo S.M.A.R.T. Abbiamo elencato tutte le VM e abbiamo iniziato a analizzare una per una le configurazioni, descriverle su Ansible, coprirle di test.
Giorno n. 450: Quale sistema è stato realizzato?
Il processo stesso 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. Secondo lo stesso principio, l'80% del tempo è stato speso per la preparazione del trasloco e solo il 20% per il trasloco stesso.
Giorno №540: Finale
Cosa è successo in 18 mesi?
- Le intese sono diventate codice.
- Lavoro manuale -> Meccanizzazione -> Automazione.
Links
Fonte: habr.com
