Il Servizio Nazionale di Informazione sui Dati Satellitari Ambientali (NESDIS) ha ridotto del 35% i suoi costi di gestione della configurazione di Red Hat Enterprise Linux (RHEL) passando da Puppet Enterprise ad Ansible Tower. In questo video della categoria 'come l'abbiamo fatto', l'ingegnere di sistema Michael Rau giustifica l'esecuzione di questa migrazione, condividendo consigli utili ed esperienze acquisite durante il passaggio da un SCM all'altro.
In questo video scoprirai:
- come giustificare al management la validità del passaggio da Puppet Enterprise ad Ansible Tower;
- quali strategie utilizzare per un passaggio il più fluido possibile;
- consigli per la transcodifica dei manifesti PE in Ansible Playbook;
- raccomandazioni per una installazione ottimale di Ansible Tower.
Salve a tutti, mi chiamo Michael Rau e sono un ingegnere di sistema senior presso ActioNet, che collabora con il National Oceanic and Atmospheric Administration (NOAA) all'interno del servizio NESDIS. Oggi parleremo di trimming strings – la mia personale esperienza di migrazione da Puppet Enterprise a Ansible Tower. Il tema di questa presentazione è "guardare le mie cicatrici", rimaste dopo aver effettuato questa transizione all'inizio dell'anno. Voglio condividere ciò che ho imparato durante questo processo. Quindi, quando intraprenderete un'operazione simile, utilizzando la mia esperienza, sarete in grado di effettuare il passaggio senza troppe difficoltà.
Vedi diapositive come questa all'inizio di ogni presentazione di Ansible Fest. In questa diapositiva è raccontata la storia dell'automazione della mia azienda. Non sono nuovo in questo campo, poiché 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" tramite la riga di comando e semplici script (playbook). Alla fine del 2017, ho contattato la mia direzione riguardo a motivazioni solide per passare a Ansible Tower. Tra un minuto condividerò i motivi che mi hanno spinto a questo passo. Dopo aver ottenuto l'approvazione della direzione, ci sono voluti ancora alcuni mesi per completare l'implementazione e ho effettuato la transizione a gennaio-febbraio di quest'anno. Quindi, abbiamo completamente abbandonato Puppet a favore di Ansible, ed è un grande risultato.
Quello che mi affascina di più di Ansible è la possibilità di scrivere e utilizzare ruoli (roles) e playbook. I ruoli sono ideali per creare vari task interconnessi e centralizzare tutte le informazioni relative a questi task in un unico luogo. Un playbook è un file di script in sintassi YAML che descrive le azioni da eseguire su uno o più host. Comunico queste funzionalità agli utenti, in particolare agli sviluppatori software. Ansible Tower offre la possibilità di dire: "no, non hai accesso alla shell, ma ti fornisco l'opzione di avviare tutti i processi di Tower e riavviare il servizio quando ne hai bisogno". Ti parlerò dell'ambiente di lavoro e dell'hardware che utilizziamo.
Si tratta di una LAN federale, con 7 siti fisici connessi tramite MPLS in cloud, 140 server RHEL, di cui il 99% virtuali (vSphere), hardware SuperMicro, storage di rete NexentaStore, una serie di switch Cisco, Arista e Cumulus, e strumenti di gestione unificata delle minacce Fortinet UTM in ogni sito.
La rete federale significa che devo utilizzare tutte le misure di sicurezza informatica previste dalla legislazione. È importante tenere presente che Puppet Enterprise non supporta la maggior parte dell'hardware che utilizziamo. Siamo costretti a utilizzare hardware economico poiché le organizzazioni governative affrontano problemi di finanziamento in questa area. Pertanto, acquistiamo hardware di classe SuperMicro e montiamo il nostro equipaggiamento da parti separate, la cui manutenzione è garantita da contratti governativi. Utilizziamo Linux, e questa è una delle ragioni principali per passare ad Ansible.
La nostra storia di collaborazione con Puppet è la seguente.
Nel 2007 avevamo una piccola rete di 20-25 nodi, su cui abbiamo implementato Puppet. Questi nodi erano principalmente semplici 'box' RedHat. Nel 2010 abbiamo iniziato a utilizzare l'interfaccia web Puppet Dashboard per 45 nodi. Con l'espansione della rete, nel 2014 siamo passati a PE 3.3, effettuando una transizione completa riscrivendo il manifesto per 75 nodi. Questo è stato necessario perché Puppet ama cambiare le regole del gioco, e in questo caso hanno completamente cambiato il linguaggio. Un anno dopo, quando il supporto per la terza versione di Puppet Enterprise è terminato, siamo stati costretti a migrare a PE 2015.2. Abbiamo dovuto riscrivere nuovamente il manifesto per i nuovi server e acquisire una licenza sufficiente per 100 nodi, anche se all'epoca avevamo solo 85 nodi.
Sono trascorsi solo 2 anni, e siamo stati costretti a eseguire nuovamente un grande lavoro di transizione alla nuova versione PE 2016.4. Abbiamo acquistato una licenza per 300 nodi, avendo solo 130. Abbiamo nuovamente dovuto apportare modifiche significative al manifesto, poiché la nuova versione del linguaggio aveva una sintassi diversa rispetto a quella del 2015. Alla fine, la nostra SCM è passata da SVN a Bitbucket (Git). Questi sono stati i nostri 'rapporti' con Puppet.
Quindi, ho dovuto spiegare alla direzione perché dobbiamo passare a un altro SCM, utilizzando i seguenti argomenti. Il primo è il costo elevato del servizio. Ho parlato con i ragazzi di RedHat, e mi hanno detto che il costo di gestione di una rete di 300 nodi tramite Ansible Tower è la metà rispetto al costo di Puppet Enterprise. Se si acquista anche Ansible Engine, il costo sarà più o meno lo stesso, ma si otterranno molte più funzionalità rispetto a PE. Poiché siamo una società pubblica finanziata dal bilancio federale, questo è un argomento abbastanza significativo.
Il secondo argomento è l'universalità. Puppet supporta solo l'hardware su cui è installato l'agente Puppet. Questo significa che su tutti gli switch è necessario installare l'agente, e deve essere l'ultima versione. E se parte dei vostri switch supporta una versione mentre un'altra parte ne supporta un'altra, sarà necessario installare su di essi una nuova versione dell'agente PE in modo che tutti possano lavorare all'interno di un'unico sistema SCM.
Il sistema Ansible Tower funziona in modo diverso poiché non ha agenti, ma dispone di moduli che supportano gli switch Cisco e tutti gli altri switch. Questo SCM supporta Qubes OS, Linux e 4.NET UTM. Ansible Tower supporta anche i controller di storage di rete NexentaStore, basati sul kernel Illumos – un sistema operativo open-source basato su Unix. Si tratta di un supporto piuttosto limitato, ma Ansible Tower lo fornisce comunque.
Il terzo argomento, molto importante sia per me che per la nostra amministrazione, è la facilità di apprendimento. Ho impiegato 10 anni per familiarizzare con i moduli e il codice dei manifesti Puppet, ma ho imparato Ansible in una settimana, perché è molto più semplice da usare con questo SCM. Se esegui file eseguibili, a meno che tu non faccia ciò senza necessità, lavorano con gestori intelligenti e reattivi. Gli script playbook, basati su YAML, sono caratterizzati da una facile imparabilità e rapidità d'uso. Anche coloro che non hanno mai sentito parlare di YAML possono semplicemente leggere gli script e comprendere facilmente come funziona.
A dire il vero, Puppet rende il tuo lavoro come sviluppatore molto più complicato, poiché si basa sull'uso di Puppet Master. Questa è l'unica macchina con il diritto di comunicare con gli agenti Puppet. Se apporti modifiche al manifesto e desideri testare il tuo codice, devi riscrivere il codice per il Puppet Master, ovvero configurare il file Puppet-master /etc/hosts per connettere tutti i client e avviare il servizio Puppet Server. Solo allora potrai testare il funzionamento dell'hardware di rete su un host. È una procedura piuttosto dolorosa.
In Ansible è tutto molto più semplice. Tutto ciò che devi fare è sviluppare il codice per una macchina che può connettersi al host di test tramite il protocollo SSH. È molto più facile da gestire.
Un altro grande vantaggio di Ansible Tower è la possibilità di utilizzare il sistema di supporto esistente e mantenere la configurazione hardware attuale. Questo SCM sfrutta senza ulteriori azioni tutte le informazioni disponibili sulla tua infrastruttura e sull'hardware, sulle macchine virtuali, sui server, ecc. Può comunicare con i tuoi server RH Satellite, se presenti, e ti offre un'integrazione che non otterrai mai lavorando con Puppet.
Un'altra cosa importante è il controllo dettagliato. Sai che Puppet è un sistema modulare, un'applicazione client-server, quindi devi definire i vari aspetti di funzionamento di tutte le tue macchine in un lungo manifesto. Inoltre, lo stato di ogni singolo elemento del sistema deve essere testato ogni mezz'ora – questo è il periodo predefinito. Ecco come funziona Puppet.
Tower ti libera da questo. Puoi eseguire senza limitazioni i processi più diversi su attrezzature varie, svolgere il lavoro principale, avviare altri processi importanti, configurare il sistema di sicurezza, lavorare con i database. Puoi fare tutto ciò che in Puppet Enterprise comporta determinate difficoltà. Così, se hai configurato un host, ci vorrà tempo prima che le modifiche abbiano effetto sugli altri host. In Ansible tutte le modifiche hanno effetto simultaneamente.
Infine, consideriamo il modulo di sicurezza. In Ansible Tower è implementato in modo semplicemente straordinario, con grande precisione e attenzione. Puoi concedere agli utenti accesso a servizi specifici o a host specifici. Io faccio così con i miei collaboratori, abituati a lavorare su Windows, limitando il loro accesso alla shell Linux. Fornisco loro tale accesso a Tower, affinché possano eseguire solo il lavoro e avviare solo i servizi che rientrano nelle loro competenze.
Esaminiamo le cose da fare in anticipo per facilitare la transizione a Ansible Tower. In primo luogo, è necessario preparare l'hardware. Se alcuni elementi della vostra infrastruttura non sono ancora presenti nel database, è necessario aggiungerli. Ci sono sistemi che non cambiano le loro caratteristiche e quindi mancano nel database di Puppet, ma se non li inserite prima di passare a Tower, perderete una serie di vantaggi. Questo potrebbe essere un database preliminare "sporco", ma deve contenere informazioni su tutta l'attrezzatura che possedete. Pertanto, dovreste scrivere uno script dinamico per l'hardware, che aggiornerà automaticamente tutte le modifiche all'infrastruttura nel database, affinché Ansible sappia quali host devono essere presenti nel nuovo sistema. Non sarà necessario comunicarlo a questa SCM, quali host avete aggiunto e quali non esistono più, perché tutto questo lo apprenderà automaticamente. Più dati saranno presenti nel database, più utile e flessibile sarà Ansible. Funziona come se stesse semplicemente leggendo il codice a barre dello stato dell'attrezzatura dal database.
Dedica del tempo a familiarizzare con il funzionamento della riga di comando di Ansible. Esegui alcuni comandi specifici per verificare il funzionamento dello script hardware, scrivi e avvia semplici ma utili playbook, utilizza i template Jinja2 dove è appropriato. Prova a scrivere un ruolo e uno script per un processo complesso in più fasi, utilizzando una configurazione hardware standard e frequentemente utilizzata. Sperimenta con queste cose e testa come funzionano. In questo modo, apprenderai a utilizzare gli strumenti per creare le librerie utilizzate in Tower. Ho già menzionato che la mia preparazione per la transizione ha richiesto circa 3 mesi. Penso che, basandoti sulla mia esperienza, tu possa farlo più velocemente. Non considerare questo tempo come perso, poiché in seguito apprezzerai tutti i vantaggi del lavoro svolto.
Successivamente, devi decidere cosa ti aspetti da Ansible Tower e cosa dovrebbe fare concretamente questo sistema per te.
Hai bisogno di distribuire un sistema su hardware vuoto, su macchine virtuali vuote? Oppure desideri mantenere le condizioni di lavoro esistenti e la configurazione dell'hardware attuale? Questo è un aspetto molto importante per il funzionamento delle aziende pubbliche, quindi devi essere sicuro di poter effettuare la migrazione e distribuire Ansible sulla configurazione esistente. Definisci i processi amministrativi di routine che desideri automatizzare. Scopri se hai bisogno di distribuire applicazioni e servizi specifici sul nuovo sistema. Redigi un elenco di ciò che desideri fare e ordina le priorità.
Iniziate a scrivere il codice degli script e dei ruoli che garantiranno l'esecuzione delle attività che avete pianificato. Raggruppateli in Projects, una collezione logica di script playbook correlati. Ogni Project sarà associato a un repository Git separato o a un altro repository a seconda del gestore di codice che utilizzate. Potete gestire gli script playbook e le directory playbook posizionandoli manualmente nel Project Base Path sul server Tower, oppure collocando i playbook in qualsiasi sistema di gestione del codice sorgente (SCM) supportato da Tower, inclusi Git, Subversion, Mercurial e Red Hat Insights. All'interno di un Project, potete inserire quanti più script desiderate. Ad esempio, ho creato un Project di base in cui ho collocato uno script per i componenti principali di RedHat, uno script per le fondamenta di Linux, e script per altri indicatori base. In questo modo, in un progetto erano presenti ruoli e script diversi gestiti da un unico repository Git.
Eseguite tutte queste operazioni tramite il terminale, è un buon modo per verificarne il funzionamento. In questo modo sarete pronti per l'installazione di Tower.
Parliamo un po' del tranciamento del manifesto di Puppet, perché ho speso molto tempo su questo prima di capire cosa fosse veramente necessario fare.
Come ho già detto, Puppet memorizza tutte le configurazioni e i parametri hardware in un lungo manifesto, e in questo manifesto c'è tutto ciò che il tuo SCM deve fare. Quando fai la transizione, non è necessario inserire tutte le tue attività in un unico elenco; invece, considera la struttura del nuovo sistema: ruoli, scenari, tag, gruppi e cosa dovrebbe esserne incluso. Alcuni degli elementi autonomi della rete dovrebbero essere raggruppati in gruppi per i quali è possibile creare scenari. Gli elementi infrastrutturali più complessi, che richiedono molte risorse, compresi classi autonome, possono essere raggruppati in ruoli. Prima di migrare, è necessario definire tutto ciò. Se stai creando ruoli o scenari di grandi dimensioni che non si adattano a uno schermo, dovresti utilizzare i tag per poter catturare parti specifiche dell'infrastruttura.
18:00
Un po' di pubblicità 🙂
Grazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, , un'alternativa unica ai server entry-level, che abbiamo creato per te: (disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Scopri di più su
Fonte: habr.com
