Il Servizio Nazionale di Informazione sui Dati Satellitari Ambientali (NESDIS) ha ridotto i propri costi di gestione della configurazione di Red Hat Enterprise Linux (RHEL) del 35%, passando da Puppet Enterprise ad Ansible Tower. In questo video della categoria 'come lo abbiamo fatto', l'ingegnere di sistema Michael Rau giustifica l'esecuzione di questa migrazione, condivide suggerimenti utili e l'esperienza acquisita a seguito del passaggio da un SCM all'altro.
In questo video scoprirai:
- come giustificare alla direzione la ragionevolezza della transizione 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 un'installazione ottimale di Ansible Tower.
Salve a tutti, mi chiamo Michael Rau, sono un ingegnere di sistema senior presso ActioNet, che lavora per la National Oceanic and Atmospheric Administration (NOAA) del servizio NESDIS. Oggi parleremo della migrazione con Puppet – la mia personale esperienza nel passaggio da Puppet Enterprise ad Ansible Tower. L'argomento di questa presentazione è 'guardare le mie cicatrici', quelle rimaste dopo aver effettuato questo passaggio all'inizio dell'anno. Voglio condividere ciò che ho imparato durante questo processo. Così, quando ti cimenterai in qualcosa di simile, potrai sfruttare la mia esperienza per effettuare la transizione senza troppi problemi.
Vedete diapositive simili a questa all'inizio di ogni presentazione di Ansible Fest. In questa diapositiva è raccontata la storia dell'automazione della mia azienda. Non sono un novizio 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 'trucchetti' tramite la riga di comando e semplici script (playbooks). Alla fine del 2017, ho parlato con la mia direzione riguardo a motivi solidi per la transizione a Ansible Tower. Tra un minuto racconterò i motivi che mi hanno spinto verso questa scelta. Dopo aver ricevuto l'approvazione della direzione, ci sono voluti ancora alcuni mesi per mettere in atto il piano, e ho effettuato la transizione tra gennaio e febbraio di quest'anno. Pertanto, abbiamo completamente abbandonato Puppet a favore di Ansible, e questo è un grande traguardo.
Ciò che mi attrae di più in Ansible è la possibilità di scrivere e utilizzare ruoli (roles) e playbook. I ruoli sono perfetti per creare compiti (tasks) diversi ma correlati e per raggruppare tutti i dati pertinenti in un unico luogo. Un playbook è un file di script in sintassi YAML che descrive le azioni da eseguire su uno o più host. Presento queste funzionalità agli utenti, principalmente sviluppatori software. Ansible Tower offre la possibilità di dire: "no, non hai accesso alla shell, ma ti fornisco la possibilità 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.
Questa è una LAN federale, 7 siti fisici connessi tramite MPLS cloud, 140 server RHEL, il 99% dei quali sono 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 protezione delle informazioni previste dalla legislazione. Devi tenere presente che Puppet Enterprise non supporta gran parte dell'hardware che utilizziamo. Siamo costretti a utilizzare hardware economico, poiché le strutture governative affrontano problemi di finanziamento per queste spese. Pertanto, acquistiamo hardware di classe SuperMicro e assemblamo il nostro sistema da pezzi singoli, la cui manutenzione è garantita da contratti governativi. Utilizziamo Linux, e questa è una delle ragioni importanti per cui siamo passati ad Ansible.
La nostra esperienza con Puppet è la seguente.
Nel 2007 avevamo una piccola rete di 20-25 nodi, in cui abbiamo implementato Puppet. Principalmente, questi nodi erano semplici "scatole" RedHat. Nel 2010 abbiamo iniziato a utilizzare l'interfaccia web Puppet Dashboard per 45 nodi. Poiché la rete continuava a espandersi, nel 2014 siamo passati a PE 3.3, effettuando una migrazione completa riscrivendo il manifesto per 75 nodi. Questo era necessario perché Puppet ama cambiare le regole del gioco, e in questo caso hanno completamente cambiato il linguaggio. Un anno dopo, quando è terminato il supporto per la terza versione di Puppet Enterprise, abbiamo dovuto migrare a PE 2015.2. Abbiamo dovuto riscrivere nuovamente il manifesto per i nuovi server e acquistare una licenza con una copertura per 100 nodi, anche se in quel momento avevamo solo 85 nodi.
Sono passati solo 2 anni e abbiamo dovuto nuovamente svolgere un grande lavoro per passare alla nuova versione PE 2016.4. Abbiamo acquistato una licenza per 300 nodi, avendo solo 130. Abbiamo dovuto apportare nuovamente cambiamenti significativi al manifesto, poiché la nuova versione del linguaggio aveva una sintassi diversa rispetto a quella della versione del 2015. Alla fine, la nostra SCM è passata dal sistema di controllo versioni SVN a Bitbucket (Git). Questi sono stati i nostri "rapporti" con Puppet.
Quindi ho dovuto spiegare alla direzione perché dovevamo passare a una diversa SCM, utilizzando i seguenti argomenti. Il primo è l'alto costo del servizio. Ho parlato con le persone di RedHat e mi hanno detto che il costo di gestione di una rete di 300 nodi con Ansible Tower è la metà del costo di Puppet Enterprise. Se acquistiamo anche Ansible Engine, il costo sarebbe più o meno lo stesso, ma riceveremmo molte più funzionalità rispetto a PE. Poiché siamo un'azienda pubblica finanziata dal bilancio federale, questo è un argomento piuttosto significativo.
Il secondo argomento è la versatilità. Puppet supporta solo l'hardware su cui è installato l'agente Puppet. Ciò significa che su tutti gli switch è necessario installare un agente, e deve essere l'ultima versione. E se parte dei tuoi switch supporta una versione e parte un'altra, dovrai installare su di essi la nuova versione dell'agente PE, affinché tutti possano lavorare in 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 archiviazione di rete NexentaStore, basati sul kernel Illumos – un sistema operativo open-source basato su Unix. Questo 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 trascorso 10 anni a imparare i moduli e il codice dei manifesti Puppet, ma ho imparato Ansible in una settimana, perché con questo SCM è molto più semplice lavorare. Se esegui file eseguibili, ovviamente, se non lo fai senza necessità, ci sono gestori ragionevoli e reattivi che lavorano con loro. Gli script playbook, basati su YAML, sono caratterizzati da un apprendimento facile e da un utilizzo rapido. Chi non ha mai sentito parlare di YAML può semplicemente leggere gli script e capire facilmente come funziona.
A essere sinceri, Puppet complica molto il lavoro dello sviluppatore, poiché è basato sull'uso di Puppet Master. Questa è l'unica macchina che ha il diritto di comunicare con gli agenti Puppet. Se hai apportato modifiche a un manifesto e vuoi testare il tuo codice, devi riscrivere il codice per il Puppet Master, cioè configurare il file Puppet-master /etc/hosts per connettere tutti i client e avviare il servizio Puppet Server. Solo dopo puoi testare il funzionamento dell'hardware di rete su un singolo host. È una procedura piuttosto dolorosa.
In Ansible è tutto molto più semplice. Tutto ciò che devi fare è sviluppare il codice per una macchina in grado di comunicare tramite il protocollo SSH con l'host di test. È molto più facile lavorare con questo.
Il prossimo grande vantaggio di Ansible Tower è la possibilità di utilizzare il sistema di supporto già in tuo possesso e mantenere la configurazione esistente dell'hardware. Questa SCM utiliza senza azioni aggiuntive tutte le informazioni disponibili sulla tua infrastruttura e attrezzatura, macchine virtuali, server, ecc. Può comunicare con i tuoi server RH Satellite, se ce ne sono, e ti offre un'integrazione che non otterrai mai lavorando con Puppet.
Un'altra cosa importante è il controllo dettagliato. Sapete che Puppet è un sistema modulare, è un'applicazione client-server, quindi dovete definire gli aspetti esistenti del funzionamento di tutte le vostre macchine in un lungo manifesto. Lo stato di ciascun componente del sistema deve essere testato ogni mezz'ora: questo è il periodo predefinito. Ecco come funziona Puppet.
Tower vi solleva da questo. Potete eseguire senza limiti il più vario insieme di processi su hardware molto diverso, potete fare il lavoro principale, avviare altri processi importanti, configurare la sicurezza del sistema, lavorare con i database. Potete fare tutto ciò che in Puppet Enterprise è accompagnato da alcune difficoltà. Ad esempio, se avete fatto configurazioni su un host, ci vorrà del tempo affinché 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 straordinario, con grande precisione e cura. Potete fornire agli utenti accesso a servizi specifici o a determinati host. Faccio così con i miei dipendenti che sono abituati a lavorare su Windows, limitando loro l'accesso alla shell di Linux. Assicuro loro un accesso a Tower tale da permettere loro di eseguire solo il lavoro e avviare solo i servizi che rientrano nella loro competenza.
Consideriamo le cose che devono essere fatte in anticipo per facilitare la transizione a Ansible Tower. Prima di tutto, è necessario preparare l'hardware. Se alcuni elementi della vostra infrastruttura non sono ancora presenti nel database, devono essere aggiunti. Ci sono sistemi che non cambiano le proprie caratteristiche e pertanto non sono presenti nel database Puppet, ma se non li inserite prima di passare a Tower, perderete diversi vantaggi. Questo può sembrare un database preliminare 'sporco', ma deve contenere informazioni su tutto l'hardware di cui siete in possesso. Pertanto, dovreste scrivere uno script dinamico per l'hardware che apporterà automaticamente tutte le modifiche all'infrastruttura nel database, affinché Ansible sappia quali host devono essere presenti nel nuovo sistema. Non sarà necessario comunicare a questo SCM quali host avete aggiunto e quali non esistono più, poiché tutto ciò verrà rilevato automaticamente. Maggiore è la quantità di dati nel database, più utile e flessibile sarà Ansible. Funziona come se semplicemente leggesse il codice a barre dello stato dell'hardware dal database.
Dedicate del tempo a familiarizzare con l'utilizzo della linea di comando in Ansible. Eseguite alcuni comandi speciali per testare l'operatività dello script per l'hardware, scrivete e eseguite alcuni semplici ma utili playbook, utilizzate i template Jinja2 dove opportuno. Provate a scrivere un ruolo e un playbook per un processo complesso in più fasi, utilizzando una configurazione hardware standard e frequentemente incontrata. Sperimentate con queste cose, testate come funzionano. In questo modo, imparerete a utilizzare gli strumenti per la creazione di librerie usate in Tower. Ho già detto che la mia preparazione per la transizione ha richiesto circa 3 mesi. Penso che basandosi sulla mia esperienza, potrete farlo più velocemente. Non considerate questo tempo sprecato, poiché più tardi percepirà tutti i vantaggi del lavoro svolto.
In seguito, è necessario decidere cosa vi aspettate da Ansible Tower, cosa dovrebbe fare per voi questo sistema.
Hai bisogno di implementare il sistema su hardware vuoto o su macchine virtuali vuote? O desideri mantenere le condizioni operative e le impostazioni dell'hardware esistente? Questo è un aspetto molto importante per il funzionamento delle aziende pubbliche, quindi devi essere certo di poter effettuare la migrazione e implementare Ansible sulla configurazione esistente. Identifica i processi amministrativi di routine che desideri automatizzare. Scopri se hai bisogno di implementare applicazioni e servizi specifici sul nuovo sistema. Crea un elenco di ciò che desideri fare e stabilisci le priorità.
Successivamente, inizia a scrivere il codice degli script e dei ruoli che garantiranno l'esecuzione delle attività pianificate. Raggruppali in Progetti, una collezione logica di script playbook correlati. Ogni Progetto sarà relativo a un singolo repository Git o un altro repository a seconda di quale gestore di codice utilizzi. Puoi gestire gli script playbook e le directory playbook, posizionandoli manualmente nel Project Base Path sul server Tower, oppure posizionando il playbook in qualsiasi sistema di controllo versione (SCM) supportato da Tower, incluso Git, Subversion, Mercurial e Red Hat Insights. All'interno di un singolo Progetto puoi inserire quanti più script vuoi. Ad esempio, ho creato un Progetto di base in cui ho collocato uno script per i componenti principali di RedHat, uno script per le basi di Linux, gli script per le altre metriche di base. In questo modo, un progetto presentava ruoli e script molto diversi, gestiti da un unico repository Git.
Esegui tutte queste operazioni tramite la riga di comando, è un buon modo per verificarne la funzionalità. In questo modo ti preparerai all'installazione del Tower.
Parliamo un po' della transcodifica del manifesto Puppet, perché ho speso molto tempo su questo prima di rendermi conto di cosa fosse realmente necessario fare.
Come ho già detto, Puppet memorizza tutte le impostazioni e i parametri delle apparecchiature in un lungo manifesto, e in questo manifesto è presente tutto ciò che deve fare questo SCM. Durante la transizione non è necessario inserire tutti i propri compiti in un unico elenco, invece, considerate la struttura del nuovo sistema: ruoli, scenari, tag, gruppi e ciò che deve farne parte. Alcuni degli elementi autonomi della rete dovrebbero essere raggruppati in gruppi, per i quali possono essere creati scenari. Elementi più complessi dell'infrastruttura, che utilizzano un gran numero di risorse, inclusi corsi autonomi, possono essere raggruppati nei ruoli. Prima della migrazione, è necessario prendere una decisione su questo. Se si stanno creando ruoli o scenari sostanziali che non possono essere visualizzati su un unico schermo, è consigliabile utilizzare i tag per poter catturare singole parti dell'infrastruttura.
18:00
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono 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! Leggi di
Fonte: habr.com
