U National Environmental Satellite Data Information Service (NESDIS) hà riduciutu i so costi di gestione di cunfigurazione per Red Hat Enterprise Linux (RHEL) da 35% migrando da Puppet Enterprise à Ansible Tower. In questu video "cumu l'avemu fattu", l'ingegnere di sistemi Michael Rau spiega u casu per questa migrazione, spartendu cunsiglii utili è lezioni amparate da u muvimentu da un SCM à l'altru.
Da stu video ampararete:
- cumu ghjustificà à a gestione a fattibilità di cambià da Puppet Enterprise à Ansible Tower;
- chì strategie à aduprà per fà a transizione u più liscia pussibule;
- cunsiglii per trascodificà i manifesti PE in Ansible Playbook;
- Raccomandazioni per a stallazione ottimali di Ansible Tower.
Ciao à tutti, mi chjamu Michael Rau, sò un Ingegnere di Sistemi Senior in ActioNet, chì travaglia per u serviziu NESDIS di l'Amministrazione Naziunale di Oceani è Atmosferichi (NOAA). Oghje parlemu di a string trimming - a mo propria sperienza di migrazione da Puppet Enterprise à Ansible Tower. U tema di sta presentazione hè di "fighjate i mo cicatrici" lasciate dopu avè fattu sta transizione prima di l'annu. Vogliu sparte ciò chì aghju amparatu à traversu stu prucessu. Allora quandu pigliate qualcosa cusì, usendu a mo sperienza, pudete fà a transizione senza travagliu extra.
Vede diapositive simili à questu à u principiu di ogni presentazione in Ansible Fest. Questa slide delinea a storia di l'automatizazione di a mo cumpagnia. Ùn sò micca novu in questu perchè aghju utilizatu Puppet / Puppet Enterprise da u 2007. Aghju cuminciatu à travaglià cù Ansible in 2016, è cum'è parechji altri utilizatori di stu pruduttu, aghju statu attrattu da a pussibilità di "trucchi" cù a linea di cummanda è scripts simplici (playbooks). À a fine di 2017, aghju avvicinatu à a mo gestione nantu à i motivi forti per traslassi à Ansible Tower. In un minutu vi dicu nantu à i mutivi chì m'hà purtatu à fà stu passu. Dopu avè ricivutu l'accunsentu di a gestione, hà pigliatu parechji mesi più per compie u pianu, è aghju fattu a transizione in ghjennaghju-ferraghju di questu annu. Dunque, avemu completamente abbandunatu Puppet in favore di Ansible, è hè una grande cosa.
Ciò chì mi piace più di Ansible hè a capacità di scrive è aduprà roli è playbooks. I roli sò fantastichi per creà compiti distinti, ma cunnessi, è mette tutte e dati in relazione à questi compiti in un locu. Un playbook hè una sintassi YAML, un schedariu di script chì descrive l'azzioni per unu o più ospiti. Parlu di sti funziunalità à l'utilizatori, principalmente i sviluppatori di software. Ansible Tower vi dà l'abilità di dì "no, ùn avete micca accessu à a cunchiglia, ma vi dugnu a capacità di eseguisce tutti i prucessi di a Torre è riavvia u serviziu quandu avete bisognu". Vi diceraghju di l'ambiente di travagliu è l'equipaggiu chì usemu.
Questa hè una LAN federale, 7 siti fisici cunnessi via nuvola MPLS, 140 servitori RHEL, 99% di i quali sò virtuali (vSphere), hardware SuperMicro, almacenamiento di rete NexentaStore, un set di switch Cisco, Arista è Cumulus è Fortinet UTM gestione unificata di minaccia. arnesi nantu à ogni situ.
A rete federale significa chì deve aduprà tutte e misure di sicurità di l'infurmazioni furnite da a lege. Avete da tene in mente chì Puppet Enterprise ùn sustene micca a maiò parte di u hardware chì usemu. Semu furzati à aduprà hardware di bilanciu perchè l'agenzii di u guvernu anu prublemi à finanzià sta spesa. Hè per quessa chì cumpramu hardware SuperMicro è assemblemu u nostru equipamentu da parti individuali, u mantenimentu di quale hè garantitu da cuntratti di u guvernu. Usemu Linux è questu hè unu di i mutivi impurtanti per cambià à Ansible.
A nostra storia cù Puppet hè a siguenti.
In 2007, avemu avutu una piccula reta di nodi 20-25, in quale avemu implementatu Puppet. In fondu, sti nodi eranu solu "boxes" di RedHat. In 2010, avemu cuminciatu à aduprà l'interfaccia web Puppet Dashboard per 45 nodi. Quandu a reta cuntinuava à espansione, avemu trasfirutu à PE 2014 in 3.3, facendu una transizione cumpleta cù una riscrittura manifesta per 75 nodi. Questu hà da esse fattu perchè Puppet piace à cambià e regule di u ghjocu, è in questu casu anu cambiatu completamente a lingua. Un annu dopu, quandu u supportu per a versione 3 di Puppet Enterprise hà finitu, avemu statu obligatu à migrà à PE 2015.2. Avemu avutu à riscrive u manifestu novu per i novi servitori è cumprà una licenza cù una riserva di 100 nodes, ancu s'è in quellu tempu avemu avutu solu 85 nodes.
Solu 2 anni sò passati, è avemu avutu di novu à fà assai travagliu per migrà à a nova versione PE 2016.4. Avemu compru una licenza per i nodi 300, avendu solu 130. Avemu torna à fà cambiamenti maiò à u manifestu perchè a nova versione di a lingua avia una sintassi diversa da a lingua di a versione 2015. In u risultatu, u nostru SCM hà cambiatu da u cuntrollu di versione SVN à Bitbucket (Git). Questa era a nostra "relazione" cù Puppet.
Allora, aghju avutu à spiegà à a gestione perchè avemu bisognu di passà à un SCM diversu utilizendu i seguenti argumenti. U primu hè u prezzu altu di u serviziu. Aghju parlatu cù i picciotti di RedHat è anu dettu chì u costu di gestisce una rete di nodi 300 cù Ansible Tower hè a mità di u costu di Puppet Enterprise. Sè ancu cumprà Ansible Engine, u costu serà quasi u listessu, ma uttene parechje più funzioni di PE. Siccomu simu una cumpagnia statale finanziata da u budget federale, questu hè un argumentu abbastanza putente.
U sicondu argumentu hè a versatilità. Puppet supporta solu hardware chì hà un agente Puppet. Questu significa chì un agentu deve esse installatu in tutti i switches, è deve esse l'ultima versione. È se alcuni di i vostri switches supportanu una versione, è alcuni supportanu l'altru, avete bisognu di installà una nova versione di l'agente PE nantu à elli per ch'elli ponu tutti travaglià in u stessu sistema SCM.
U sistema Ansible Tower funziona in modu diversu perchè ùn hà micca agenti, ma hà moduli chì supportanu i switch Cisco è tutti l'altri switch. Stu SCM supporta Qubes OS, Linux è 4.NET UTM. Ansible Tower supporta ancu i controller di almacenamento di rete NexentaStore basati nantu à u kernel Illumos, un sistema operatore open-source basatu in Unix. Questu hè assai pocu supportu, ma Ansible Tower face in ogni modu.
U terzu argumentu, chì hè assai impurtante per mè è per a nostra amministrazione, hè a facilità d'usu. Aghju passatu 10 anni à maestru di i moduli Puppet è u codice manifestu, ma aghju amparatu Ansible in una settimana perchè stu SCM hè assai più faciule per travaglià. Se eseguite i fugliali eseguibili, sicuru, salvu chì ùn fate micca inutilmente, allora i gestori intelligenti è responsivi travaglianu cun elli. I playbooks basati in YAML sò faciuli à amparà è veloci à aduprà. Quelli chì ùn anu mai intesu parlà di YAML prima ponu simpricimenti leghje i scripts è capisce facilmente cumu funziona.
Per esse onesto, Puppet rende u vostru travagliu cum'è sviluppatore assai più difficiule perchè hè basatu annantu à l'usu di Puppet Master. Hè l'unica macchina permessa di cumunicà cù l'agenti Puppet. Sè avete fattu cambiamenti à u manifestu è vulete pruvà u vostru codice, duvete riscrive u codice per Puppet Master, vale à dì, cunfigurà u Puppet Master /etc/hosts file per cunnette tutti i clienti è inizià u serviziu Puppet Server. Solu dopu à questu puderà pruvà l'operazione di l'equipaggiu di rete in un host. Questa hè una prucedura piuttostu dolorosa.
Tuttu hè assai più simplice in Ansible. Tuttu ciò chì duvete fà hè di sviluppà codice per una macchina chì pò cumunicà via SSH cù l'ospiti sottu test. Questu hè assai più faciule per travaglià.
U prossimu grande vantaghju di Ansible Tower hè a capacità di sfruttà u vostru sistema di supportu esistente è mantene a vostra cunfigurazione hardware esistente. Stu SCM usa tutte l'infurmazioni dispunibuli nantu à a vostra infrastruttura è hardware, macchine virtuali, servitori, etc. senza alcunu passu supplementu. Puderà parlà à i vostri servitori RH Satellite, se ne avete unu, è vi dà integrazioni chì ùn avete mai uttene cù Puppet.
Un'altra cosa impurtante hè u cuntrollu detallatu. Sapete chì Puppet hè un sistema modulare, hè una applicazione cliente-servitore, cusì deve definisce l'aspettu esistenti di tutte e vostre macchine in un manifestu longu. In questu casu, u statu di ogni elementu individuale di u sistema deve esse pruvatu ogni meza ora - questu hè u periodu predeterminatu. Questu hè cumu funziona Puppet.
Tower vi salva da quessa. Pudete eseguisce una varietà di prucessi nantu à una varietà di l'equipaggiu senza restrizioni; pudete fà u travagliu basicu, eseguisce altri prucessi impurtanti, stabilisce un sistema di sicurezza, è travaglià cù basa di dati. Pudete fà tuttu ciò chì hè difficiule in Puppet Enterprise. Dunque, se l'avete cunfiguratu nantu à un òspite, ci vulerà tempu per i cambiamenti per avè effettu nantu à l'ospiti rimanenti. In Ansible, tutti i cambiamenti entranu in vigore à u stessu tempu.
Infine, fighjemu u modulu di sicurità. Ansible Tower l'implementa in modu simpliciamente maravigghiusu, cun grande precisione è cura. Pudete cuncede à l'utilizatori l'accessu à servizii specifichi o à ospiti specifichi. Facciu questu cù i mo impiegati chì sò abituati à travaglià in Windows, limitendu u so accessu à a cunchiglia Linux. Aghju assicuratu ch'elli anu accessu à a Torre per ch'elli ponu solu fà u travagliu è eseguisce solu i servizii chì sò pertinenti per elli.
Fighjemu e cose chì duvete fà in anticipu per fà a vostra transizione à Ansible Tower più faciule. Prima di tuttu, avete bisognu di preparà u vostru equipamentu. Se certi elementi di a vostra infrastruttura ùn sò micca digià in a basa di dati, avete bisognu di aghjunghje quì. Ci sò sistemi chì ùn cambianu micca e so caratteristiche è per quessa ùn sò micca in a basa di dati Puppet, ma s'ellu ùn l'aghjunghje micca prima di trasfurmà in Tower, perderà una quantità di vantaghji. Questu pò esse una basa di dati "sprazza", prelimiunale, ma deve cuntene infurmazioni nantu à tutti l'equipaggiu chì avete. Dunque, duvete scrive un script di hardware dinamicu chì spinghjerà automaticamente tutti i cambiamenti di l'infrastruttura in a basa di dati, allora Ansible saperà quale l'ospiti deve esse prisenti nantu à u novu sistema. Ùn averete micca bisognu di dì à questu SCM chì l'ospiti chì avete aghjustatu è chì l'ospiti ùn esistenu più, perchè cunnosce tuttu questu automaticamente. Più dati ci sò in a basa di dati, u più utile è flexible serà Ansible. Funziona cum'è s'ellu si leghje solu u codice à barre di statutu di hardware da una basa di dati.
Passate un pocu di tempu per familiarizà cù a linea di cummanda in Ansible. Eseguite alcuni cumandamenti persunalizati per pruvà l'script hardware, scrive è eseguite alcuni scripts di playbook simplici ma utili, utilizate mudelli Jinja2 induve apprupriati. Pruvate à scrive un rolu è un script per un prucessu cumplessu è multi-passu utilizendu una cunfigurazione hardware cumuna, cumuna. Ghjucate cù queste cose, pruvate cumu funziona. In questu modu, amparate cumu utilizà l'arnesi di creazione di biblioteca utilizati in Tower. Aghju digià dettu chì mi pigliò circa 3 mesi per preparà a transizione. Pensu chì basatu nantu à a mo spirienza, puderà fà questu più veloce. Ùn cunsiderà micca stu tempu perdu, perchè dopu vi sperimentà tutti i benefici di u travagliu fattu.
Dopu, avete bisognu di decide ciò chì aspetta da Ansible Tower, ciò chì esattamente stu sistema duverà fà per voi.
Avete bisognu di implementà u sistema in hardware nudu, in macchine virtuali nude? O vulete mantene e cundizioni di u funziunamentu originale è i paràmetri di l'equipaggiu esistenti? Questu hè un aspettu assai impurtante per l'imprese publiche, cusì avete bisognu à esse sicuru chì puderete migrà è implementà Ansible nantu à a vostra cunfigurazione esistente. Identificà i prucessi amministrativi di rutina chì vulete automatizà. Scuprite s'ellu avete bisognu di implementà applicazioni è servizii specifichi nantu à u novu sistema. Fate una lista di ciò chì vulete fà è priurità.
Allora cuminciate à scrive u codice di scrittura è i roli chì permettenu i travaglii chì pensa à compie. Combinali in Projects, una cullizzioni logica di playbooks pertinenti. Ogni Prughjettu appartene à un repository Git separatu o un repository differente secondu u gestore di codice chì utilizate. Pudete gestisce scripts di playbook è repertorii di playbook mettenduli manualmente in u Path Base di Prughjettu nantu à u servitore di a Torre, o mettendu u playbook in qualsiasi sistema di gestione di codice fonte (SCM) supportatu da Tower, cumprese Git, Subversion, Mercurial è Red Hat. Insights. Dentru un Prughjettu pudete mette quante scripts chì vulete. Per esempiu, aghju creatu un Prughjettu di basa in u quale aghju postu un script per l'elementi core RedHat, un script per u core Linux, è scripts per u restu di e basi. Cusì, in un prughjettu ci era una varietà di roli è scenarii chì sò stati gestiti da un repository Git.
Eseguisce tutte queste cose attraversu a linea di cumanda hè un bonu modu per pruvà a so funziunalità. Questu vi prepararà per a stallazione di a Torre.
Parlemu un pocu di trascodificà u manifestu Puppet, perchè aghju passatu assai tempu nantu à questu finu à chì aghju capitu ciò chì in realtà deve esse fattu.
Comu dissi prima, Puppet guarda tutte e paràmetri è l'opzioni di hardware in un manifestu longu, è questu manifestu guarda tuttu ciò chì questu SCM deve fà. Quandu fate a transizione, ùn avete micca bisognu di chjappà tutte e vostre attività in una sola lista; invece, pensate à a struttura di u novu sistema: roli, scripts, tags, gruppi è ciò chì deve andà. Arcuni di l'elementi di a rete autònuma deve esse raggruppati in gruppi per quale script ponu esse creati. Elementi infrastrutturali più cumplessi chì implicanu un gran numaru di risorse, cumprese classi autonome, ponu esse cumminati in roli. Prima di a migrazione, avete bisognu di decide nantu à questu. Sè vo site criendu grandi roles o scenarii chì ùn si adattanu micca à una schermu, duvete aduprà tag per pudè catturà parti specifiche di l'infrastruttura.
18:00
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com