Il National Environmental Satellite Data Information Service (NESDIS) ha ridotto i costi di gestione della configurazione per Red Hat Enterprise Linux (RHEL) del 35% migrando da Puppet Enterprise ad Ansible Tower. In questo video "come l'abbiamo fatto", l'ingegnere di sistema Michael Rau spiega il motivo di questa migrazione, condividendo suggerimenti utili e lezioni apprese dal passaggio da un SCM all'altro.
Da questo video imparerai:
- come giustificare al management la fattibilità del passaggio da Puppet Enterprise ad Ansible Tower;
- quali strategie utilizzare per rendere la transizione il più agevole possibile;
- suggerimenti per la transcodifica dei manifest PE in Ansible Playbook;
- Consigli per l'installazione ottimale di Ansible Tower.
Ciao a tutti, mi chiamo Michael Rau, sono un ingegnere di sistema senior presso ActioNet, che lavora per il servizio NESDIS della National Oceanic and Atmospheric Administration (NOAA). Oggi parleremo del taglio delle corde: la mia esperienza di migrazione da Puppet Enterprise ad Ansible Tower. Il tema di questa presentazione è “dare un’occhiata alle mie cicatrici” rimaste dopo aver effettuato questa transizione all’inizio dell’anno. Voglio condividere ciò che ho imparato attraverso questo processo. Quindi, quando intraprendi qualcosa di simile, usando la mia esperienza, puoi effettuare la transizione senza alcun lavoro aggiuntivo.
Puoi vedere diapositive simili a questa all'inizio di ogni presentazione all'Ansible Fest. Questa diapositiva delinea la storia dell'automazione della mia azienda. Non sono nuovo a questo perché utilizzo Puppet/Puppet Enterprise dal 2007. Ho iniziato a lavorare con Ansible nel 2016 e, come molti altri utenti di questo prodotto, sono stato attratto dalla possibilità di “trucchi” utilizzando la riga di comando e semplici script (playbook). Alla fine del 2017 ho contattato il mio management spiegandogli le valide ragioni per passare ad Ansible Tower. Tra un minuto vi racconterò i motivi che mi hanno spinto a fare questo passo. Dopo aver ricevuto il consenso della direzione, ci sono voluti diversi mesi per completare il piano e ho effettuato la transizione tra gennaio e febbraio di quest'anno. Quindi abbiamo abbandonato completamente Puppet in favore di Ansible, ed è una cosa grandiosa.
Ciò che mi attrae di più di Ansible è la capacità di scrivere e utilizzare ruoli e playbook. I ruoli sono ottimi per creare attività distinte ma correlate e mettere tutti i dati relativi a tali attività in un unico posto. Un playbook è una sintassi YAML, un file di script che descrive le azioni per uno o più host. Parlo di queste funzionalità agli utenti, principalmente agli sviluppatori di software. Ansible Tower ti dà la possibilità di dire "no, non hai accesso alla shell, ma ti do la possibilità di eseguire tutti i processi Tower e riavviare il servizio quando ne hai bisogno". Ti parlerò dell'ambiente di lavoro e delle attrezzature che utilizziamo.
Si tratta di una LAN federale, 7 siti fisici collegati tramite cloud MPLS, 140 server RHEL di cui il 99% virtuali (vSphere), hardware SuperMicro, storage di rete NexentaStore, un set di switch Cisco, Arista e Cumulus e gestione unificata delle minacce Fortinet UTM strumenti su ciascun sito.
La rete federale implica che devo utilizzare tutte le misure di sicurezza informatica previste dalla legge. Dovresti tenere presente che Puppet Enterprise non supporta la maggior parte dell'hardware che utilizziamo. Siamo costretti a utilizzare hardware budget perché le agenzie governative hanno problemi a finanziare questa voce di spesa. Ecco perché acquistiamo hardware SuperMicro e assembliamo le nostre apparecchiature da singole parti, la cui manutenzione è garantita da contratti governativi. Usiamo Linux e questo è uno dei motivi importanti per passare ad Ansible.
La nostra storia con Puppet è la seguente.
Nel 2007 avevamo una piccola rete di 20-25 nodi in cui abbiamo implementato Puppet. Fondamentalmente, questi nodi erano semplicemente “scatole” RedHat. Nel 2010, abbiamo iniziato a utilizzare l'interfaccia web Puppet Dashboard per 45 nodi. Poiché la rete continuava ad espandersi, nel 2014 siamo passati a PE 3.3, effettuando una transizione completa con una riscrittura del manifest per 75 nodi. Questo è stato necessario perché a Puppet piace cambiare le regole del gioco, e in questo caso hanno cambiato completamente il linguaggio. Un anno dopo, quando è terminato il supporto per la versione 3 di Puppet Enterprise, siamo stati costretti a migrare a PE 2015.2. Abbiamo dovuto riscrivere nuovamente il manifest per i nuovi server e acquistare una licenza con una riserva di 100 nodi, anche se a quel tempo avevamo solo 85 nodi.
Sono passati solo 2 anni e ancora una volta abbiamo dovuto lavorare molto per migrare alla nuova versione PE 2016.4. Abbiamo acquistato una licenza per 300 nodi, avendone solo 130. Abbiamo dovuto apportare nuovamente importanti modifiche al manifest perché la nuova versione del linguaggio aveva una sintassi diversa rispetto al linguaggio della versione 2015. Di conseguenza, il nostro SCM è passato dal controllo della versione SVN a Bitbucket (Git). Questa era la nostra “relazione” con Puppet.
Quindi, ho dovuto spiegare al management perché dovevamo passare a un SCM diverso utilizzando i seguenti argomenti. Il primo è il prezzo elevato del servizio. Ho parlato con i ragazzi di RedHat e hanno detto che il costo di gestione di una rete da 300 nodi con Ansible Tower è la metà del costo di Puppet Enterprise. Se acquisti anche Ansible Engine, il costo sarà più o meno lo stesso, ma otterrai molte più funzionalità rispetto a PE. Dato che siamo un’azienda statale finanziata dal bilancio federale, questo è un argomento piuttosto potente.
Il secondo argomento è la versatilità. Puppet supporta solo l'hardware dotato di un agente Puppet. Ciò significa che un agente deve essere installato su tutti gli switch e deve essere la versione più recente. E se alcuni dei tuoi switch supportano una versione e alcuni ne supportano un'altra, dovrai installare su di essi una nuova versione dell'agente PE in modo che possano funzionare tutti nello stesso sistema SCM.
Il sistema Ansible Tower funziona in modo diverso perché non dispone di agenti, ma dispone di moduli che supportano gli switch Cisco e tutti gli altri switch. Questo SCM supporta il sistema operativo Qubes, Linux e 4.NET UTM. Ansible Tower supporta anche i controller di archiviazione di rete NexentaStore basati sul kernel Illumos, un sistema operativo open source basato su Unix. Questo è pochissimo supporto, ma Ansible Tower lo fa comunque.
Il terzo argomento, molto importante sia per me che per la nostra amministrazione, è la facilità d'uso. Ho trascorso 10 anni a padroneggiare i moduli Puppet e il codice manifest, ma ho imparato Ansible in una settimana perché è molto più facile lavorare con questo SCM. Se esegui file eseguibili, ovviamente, a meno che non lo faccia inutilmente, allora gestori intelligenti e reattivi funzioneranno con essi. I playbook basati su YAML sono facili da imparare e veloci da usare. Coloro che non hanno mai sentito parlare di YAML prima possono semplicemente leggere gli script e capire facilmente come funziona.
Ad essere onesti, Puppet rende il tuo lavoro di sviluppatore molto più difficile perché si basa sull'utilizzo di Puppet Master. È l'unica macchina autorizzata a comunicare con gli agenti Puppet. Se hai apportato modifiche al manifest e desideri testare il tuo codice, devi riscrivere il codice per Puppet Master, ovvero configurare il file Puppet Master /etc/hosts per connettere tutti i client e avviare il servizio Puppet Server. Solo dopo sarai in grado di testare il funzionamento delle apparecchiature di rete su un host. Questa è una procedura piuttosto dolorosa.
Tutto è molto più semplice in Ansible. Tutto quello che devi fare è sviluppare codice per una macchina in grado di comunicare tramite SSH con l'host sotto test. Questo è molto più facile da lavorare.
Il prossimo grande vantaggio di Ansible Tower è la capacità di sfruttare il sistema di supporto esistente e mantenere la configurazione hardware esistente. Questo SCM utilizza tutte le informazioni disponibili sulla tua infrastruttura e hardware, macchine virtuali, server, ecc. senza passaggi aggiuntivi. Può comunicare con i tuoi server RH Satellite, se ne hai uno, e ti offre integrazioni che non otterrai mai con Puppet.
Un'altra cosa importante è il controllo dettagliato. Sai che Puppet è un sistema modulare, è un'applicazione client-server, quindi devi definire gli aspetti esistenti di tutte le tue macchine in un lungo manifest. In questo caso, lo stato di ogni singolo elemento del sistema deve essere testato ogni mezz'ora: questo è il periodo predefinito. Ecco come funziona Puppet.
La torre ti salva da questo. Puoi eseguire una varietà di processi su una varietà di apparecchiature senza restrizioni; puoi svolgere lavori di base, eseguire altri processi importanti, impostare un sistema di sicurezza e lavorare con i database. Puoi fare tutto ciò che è difficile in Puppet Enterprise. Pertanto, se lo hai configurato su un host, ci vorrà del tempo affinché le modifiche abbiano effetto sugli host rimanenti. In Ansible, tutte le modifiche hanno effetto contemporaneamente.
Infine, diamo un'occhiata al modulo di sicurezza. Ansible Tower lo implementa in modo semplicemente sorprendente, con grande precisione e cura. Puoi concedere agli utenti l'accesso a servizi specifici o a host specifici. Lo faccio con i miei dipendenti che sono abituati a lavorare su Windows, limitando il loro accesso alla shell Linux. Mi assicuro che abbiano accesso a Tower in modo che possano svolgere solo il lavoro e gestire solo i servizi che sono rilevanti per loro.
Diamo un'occhiata alle cose che devi fare in anticipo per rendere più semplice la transizione ad Ansible Tower. Prima di tutto, devi preparare la tua attrezzatura. Se alcuni elementi della tua infrastruttura non sono già presenti nel database, devi aggiungerli lì. Esistono sistemi che non cambiano le loro caratteristiche e quindi non sono nel database Puppet, ma se non li aggiungi lì prima di passare a Tower, perderai una serie di vantaggi. Potrebbe trattarsi di un database preliminare "sporco", ma dovrebbe contenere informazioni su tutta l'attrezzatura di cui disponi. Pertanto, dovresti scrivere uno script hardware dinamico che invierà automaticamente tutte le modifiche all'infrastruttura nel database, quindi Ansible saprà quali host dovrebbero essere presenti sul nuovo sistema. Non avrai bisogno di dire a questo SCM quali host hai aggiunto e quali host non esistono più, perché saprà tutto questo automaticamente. Più dati sono presenti nel database, più Ansible sarà utile e flessibile. Funziona come se leggesse semplicemente il codice a barre dello stato dell'hardware da un database.
Dedica un po' di tempo a familiarizzare con la riga di comando di Ansible. Esegui alcuni comandi personalizzati per testare lo script hardware, scrivi ed esegui alcuni script di playbook semplici ma utili, utilizza i modelli Jinja2 ove appropriato. Prova a scrivere un ruolo e uno script per un processo complesso in più passaggi utilizzando una configurazione hardware comune e comunemente riscontrata. Gioca con queste cose, prova come funziona. In questo modo imparerai come utilizzare gli strumenti di creazione della libreria utilizzati in Tower. Ho già detto che mi ci sono voluti circa 3 mesi per prepararmi alla transizione. Penso che in base alla mia esperienza, sarai in grado di farlo più velocemente. Non considerare questo tempo sprecato, perché in seguito potrai sperimentare tutti i benefici del lavoro svolto.
Successivamente, devi decidere cosa ti aspetti da Ansible Tower, cosa dovrebbe fare esattamente questo sistema per te.
Hai bisogno di distribuire il sistema su hardware nudo, su macchine virtuali nude? Oppure vuoi mantenere le condizioni operative e le impostazioni originali delle apparecchiature esistenti? Questo è un aspetto molto importante per le aziende pubbliche, quindi devi essere sicuro di poter migrare e distribuire Ansible sulla tua configurazione esistente. Identifica i processi amministrativi di routine che desideri automatizzare. Scopri se è necessario distribuire applicazioni e servizi specifici sul nuovo sistema. Fai un elenco di ciò che vuoi fare e stabilisci la priorità.
Quindi inizia a scrivere il codice dello script e i ruoli che consentiranno le attività che intendi completare. Combinali in Progetti, una raccolta logica di playbook pertinenti. Ogni progetto apparterrà a un repository Git separato o a un repository diverso a seconda del gestore di codice utilizzato. Puoi gestire gli script e le directory dei playbook inserendoli manualmente nel percorso di base del progetto sul server Tower o inserendo il playbook in qualsiasi sistema di gestione del codice sorgente (SCM) supportato da Tower, inclusi Git, Subversion, Mercurial e Red Hat Approfondimenti. All'interno di un progetto puoi inserire tutti gli script che desideri. Ad esempio, ho creato un progetto di base in cui ho inserito uno script per gli elementi core di RedHat, uno script per il core Linux e script per il resto delle linee di base. Pertanto, in un progetto c'erano una varietà di ruoli e scenari gestiti da un unico repository Git.
Eseguire tutte queste cose tramite la riga di comando è un buon modo per testarne la funzionalità. Questo ti preparerà per l'installazione della Torre.
Parliamo un po' della transcodifica del manifest di Puppet, perché ci ho dedicato molto tempo finché non ho capito cosa effettivamente occorreva fare.
Come ho detto prima, Puppet memorizza tutte le impostazioni e le opzioni hardware in un lungo manifest e questo manifest memorizza tutto ciò che dovrebbe fare questo SCM. Quando effettui la transizione, non è necessario stipare tutte le tue attività in un unico elenco; pensa invece alla struttura del nuovo sistema: ruoli, script, tag, gruppi e cosa dovrebbe esserci. Alcuni degli elementi autonomi della rete dovrebbero essere raggruppati in gruppi per i quali è possibile creare script. Elementi infrastrutturali più complessi che coinvolgono un gran numero di risorse, comprese classi autonome, possono essere combinati in ruoli. Prima di effettuare la migrazione, devi decidere in merito. Se stai creando ruoli o scenari di grandi dimensioni che non rientrano in una schermata, dovresti utilizzare i tag per poter acquisire parti specifiche dell'infrastruttura.
18:00
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com