El National Environmental Satellite Data Information Service (NESDIS) ha reduït els seus costos de gestió de configuració per a Red Hat Enterprise Linux (RHEL) en un 35% mitjançant la migració de Puppet Enterprise a Ansible Tower. En aquest vídeo "com ho vam fer", l'enginyer de sistemes Michael Rau explica el cas d'aquesta migració, compartint consells útils i lliçons apreses en passar d'un SCM a un altre.
En aquest vídeo aprendràs:
- com justificar a la direcció la viabilitat de canviar de Puppet Enterprise a Ansible Tower;
- quines estratègies utilitzar per fer la transició el més fluida possible;
- consells per transcodificar manifests PE a Ansible Playbook;
- Recomanacions per a una instal·lació òptima d'Ansible Tower.
Hola a tots, em dic Michael Rau, sóc enginyer sènior de sistemes a ActioNet, que treballa per al servei NESDIS de l'Administració Nacional Oceànica i Atmosfèrica (NOAA). Avui parlarem del retall de cordes: la meva pròpia experiència de migrar de Puppet Enterprise a Ansible Tower. El tema d'aquesta presentació és "fer una ullada a les meves cicatrius" després de fer aquesta transició a principis d'any. Vull compartir el que he après amb aquest procés. Així, quan assumis alguna cosa com aquesta, utilitzant la meva experiència, pots fer la transició sense cap treball addicional.
Veu diapositives semblants a aquesta al començament de cada presentació a Ansible Fest. Aquesta diapositiva descriu la història de l'automatització de la meva empresa. No sóc nou en això perquè faig servir Puppet/Puppet Enterprise des del 2007. Vaig començar a treballar amb Ansible l'any 2016 i, com molts altres usuaris d'aquest producte, em va atreure la possibilitat de "trucs" mitjançant la línia d'ordres i scripts senzills (playbooks). A finals de 2017, em vaig acostar a la meva direcció sobre els motius forts per traslladar-me a Ansible Tower. En un minut us explicaré els motius que em van impulsar a fer aquest pas. Després de rebre el consentiment de la direcció, va trigar uns quants mesos més a completar el pla, i vaig fer la transició entre gener-febrer d'enguany. Així doncs, vam abandonar completament Puppet a favor d'Ansible, i és una gran cosa.
El que més m'atrau d'Ansible és la capacitat d'escriure i utilitzar rols i llibres de joc. Els rols són excel·lents per crear tasques diferents però relacionades i posar totes les dades relacionades amb aquestes tasques en un sol lloc. Un llibre de jocs és una sintaxi YAML, un fitxer d'script que descriu accions per a un o més amfitrions. Parlo als usuaris d'aquestes característiques, principalment als desenvolupadors de programari. Ansible Tower us ofereix la possibilitat de dir: "no, no teniu accés al shell, però us dono la possibilitat d'executar tots els processos de Tower i reiniciar el servei quan ho necessiteu". Us explicaré l'entorn de treball i els equips que fem servir.
Es tracta d'una LAN federal, 7 llocs físics connectats mitjançant MPLS al núvol, 140 servidors RHEL, el 99% dels quals són virtuals (vSphere), maquinari SuperMicro, emmagatzematge de xarxa NexentaStore, un conjunt de commutadors Cisco, Arista i Cumulus i gestió unificada d'amenaces Fortinet UTM eines a cada lloc.
La xarxa federal significa que he d'utilitzar totes les mesures de seguretat de la informació previstes per la llei. Heu de tenir en compte que Puppet Enterprise no admet la majoria del maquinari que fem servir. Ens veiem obligats a utilitzar maquinari pressupostari perquè les agències governamentals tenen problemes per finançar aquesta partida de despesa. És per això que comprem maquinari SuperMicro i muntem els nostres equips a partir de peces individuals, el manteniment de les quals està garantit per contractes governamentals. Utilitzem Linux i aquesta és una de les raons importants per canviar a Ansible.
La nostra història amb Puppet és la següent.
El 2007, teníem una petita xarxa de 20-25 nodes, en la qual vam desplegar Puppet. Bàsicament, aquests nodes eren només "caixes" de RedHat. El 2010, vam començar a utilitzar la interfície web de Puppet Dashboard per a 45 nodes. A mesura que la xarxa va continuar expandint-se, el 2014 vam passar a PE 3.3, fent una transició completa amb una reescriptura de manifest per a 75 nodes. Això s'havia de fer perquè a Puppet li agrada canviar les regles del joc, i en aquest cas van canviar completament l'idioma. Un any més tard, quan va acabar el suport per a la versió 3 de Puppet Enterprise, ens vam veure obligats a migrar a PE 2015.2. Vam haver de tornar a escriure el manifest per als nous servidors i comprar una llicència amb una reserva de 100 nodes, tot i que en aquell moment només teníem 85 nodes.
Només han passat 2 anys i vam tornar a haver de fer molta feina per migrar a la nova versió PE 2016.4. Vam comprar una llicència per a 300 nodes, amb només 130. De nou vam haver de fer canvis importants al manifest perquè la nova versió de l'idioma tenia una sintaxi diferent a la de la versió de 2015. Com a resultat, el nostre SCM va canviar del control de versions SVN a Bitbucket (Git). Aquesta va ser la nostra "relació" amb Puppet.
Per tant, vaig haver d'explicar a la direcció per què havíem de passar a un SCM diferent utilitzant els arguments següents. El primer és l'alt preu del servei. Vaig parlar amb els nois de RedHat i em van dir que el cost d'executar una xarxa de 300 nodes amb Ansible Tower és la meitat del cost de Puppet Enterprise. Si també compreu Ansible Engine, el cost serà aproximadament el mateix, però obtindreu moltes més funcions que PE. Com que som una empresa estatal finançada amb el pressupost federal, aquest és un argument força potent.
El segon argument és la versatilitat. Puppet només admet maquinari que tingui un agent Puppet. Això vol dir que s'ha d'instal·lar un agent a tots els commutadors i ha de ser la versió més recent. I si alguns dels vostres commutadors admeten una versió i alguns en admeten una altra, haureu d'instal·lar-hi una nova versió de l'agent PE perquè tots puguin funcionar al mateix sistema SCM.
El sistema Ansible Tower funciona de manera diferent perquè no té cap agent, però té mòduls que admeten commutadors Cisco i tots els altres commutadors. Aquest SCM és compatible amb Qubes OS, Linux i 4.NET UTM. Ansible Tower també admet controladors d'emmagatzematge de xarxa NexentaStore basats en el nucli Illumos, un sistema operatiu de codi obert basat en Unix. Això és molt poc suport, però Ansible Tower ho fa igualment.
El tercer argument, que és molt important tant per a mi com per a la nostra administració, és la facilitat d'ús. Vaig passar 10 anys dominant els mòduls de Puppet i el codi manifest, però vaig aprendre Ansible en una setmana perquè aquest SCM és molt més fàcil de treballar. Si executeu fitxers executables, per descomptat, tret que ho feu innecessàriament, els controladors intel·ligents i sensibles funcionen amb ells. Els llibres de jugades basats en YAML són fàcils d'aprendre i ràpids d'utilitzar. Aquells que mai no han sentit a parlar de YAML abans poden simplement llegir els scripts i entendre fàcilment com funciona.
Per ser honest, Puppet fa que la teva feina com a desenvolupador sigui molt més difícil perquè es basa en utilitzar Puppet Master. És l'única màquina permesa per comunicar-se amb els agents Puppet. Si heu fet algun canvi al manifest i voleu provar el vostre codi, heu de reescriure el codi del Puppet Master, és a dir, configurar el fitxer /etc/hosts del Puppet Master per connectar tots els clients i iniciar el servei Puppet Server. Només després d'això podreu provar el funcionament de l'equip de xarxa en un host. Aquest és un procediment bastant dolorós.
Tot és molt més senzill a Ansible. Tot el que heu de fer és desenvolupar codi per a una màquina que es pugui comunicar mitjançant SSH amb l'amfitrió en prova. Això és molt més fàcil de treballar.
El següent gran avantatge d'Ansible Tower és la capacitat d'aprofitar el vostre sistema de suport existent i mantenir la vostra configuració de maquinari existent. Aquest SCM utilitza tota la informació disponible sobre la vostra infraestructura i maquinari, màquines virtuals, servidors, etc. sense cap pas addicional. Pot parlar amb els vostres servidors RH Satellite, si en teniu un, i us ofereix integracions que mai obtindreu amb Puppet.
Una altra cosa important és el control detallat. Ja sabeu que Puppet és un sistema modular, és una aplicació client-servidor, així que heu de definir els aspectes existents de totes les vostres màquines en un llarg manifest. En aquest cas, l'estat de cada element individual del sistema s'ha de provar cada mitja hora; aquest és el període predeterminat. Així és com funciona Puppet.
La torre us salva d'això. Podeu executar una varietat de processos en diversos equips sense restriccions; podeu fer treballs bàsics, executar altres processos importants, configurar un sistema de seguretat i treballar amb bases de dades. Podeu fer tot el que és difícil a Puppet Enterprise. Per tant, si l'heu configurat en un amfitrió, els canvis trigaran a tenir efecte als hosts restants. A Ansible, tots els canvis tenen efecte al mateix temps.
Finalment, mirem el mòdul de seguretat. Ansible Tower ho implementa de manera senzilla i sorprenent, amb gran precisió i cura. Podeu concedir als usuaris accés a serveis específics o a amfitrions específics. Ho faig amb els meus empleats que estan acostumats a treballar a Windows, limitant el seu accés a l'intèrpret d'ordres de Linux. Asseguro que tenen accés a Tower perquè només puguin fer el treball i executar només els serveis que els siguin rellevants.
Vegem les coses que heu de fer amb antelació per facilitar la vostra transició a Ansible Tower. En primer lloc, heu de preparar el vostre equip. Si alguns elements de la vostra infraestructura encara no es troben a la base de dades, haureu d'afegir-los allà. Hi ha sistemes que no canvien les seves característiques i, per tant, no es troben a la base de dades de Puppet, però si no els hi afegeixes abans de passar a Tower, perdràs una sèrie d'avantatges. Aquesta pot ser una base de dades preliminar "bruta", però hauria de contenir informació sobre tots els equips que teniu. Per tant, hauríeu d'escriure un script de maquinari dinàmic que introdueixi automàticament tots els canvis d'infraestructura a la base de dades, llavors Ansible sabrà quins amfitrions haurien d'estar presents al nou sistema. No haureu de dir a aquest SCM quins amfitrions heu afegit i quins ja no existeixen, perquè ho sabrà tot automàticament. Com més dades hi hagi a la base de dades, més útil i flexible serà Ansible. Funciona com si simplement llegís el codi de barres d'estat del maquinari d'una base de dades.
Dediqueu una estona a familiaritzar-vos amb la línia d'ordres a Ansible. Executeu algunes ordres personalitzades per provar l'script de maquinari, escriviu i executeu alguns scripts de llibre de jocs senzills però útils, utilitzeu plantilles Jinja2 quan correspongui. Proveu d'escriure una funció i un script per a un procés complex i de diversos passos mitjançant una configuració de maquinari comuna i habitual. Juga amb aquestes coses, prova com funciona. D'aquesta manera aprendràs a utilitzar les eines de creació de biblioteques utilitzades a Tower. Ja he dit que em va costar uns 3 mesos preparar-me per a la transició. Crec que, segons la meva experiència, ho podreu fer més ràpidament. No consideris perdut aquest temps, perquè més endavant experimentaràs tots els beneficis de la feina feta.
A continuació, heu de decidir què espereu d'Ansible Tower, què hauria de fer exactament aquest sistema per vosaltres.
Necessiteu desplegar el sistema en maquinari nu, en màquines virtuals nues? O voleu mantenir les condicions de funcionament originals i la configuració dels equips existents? Aquest és un aspecte molt important per a les empreses públiques, de manera que heu d'assegurar-vos que podreu migrar i desplegar Ansible a la vostra configuració existent. Identifiqueu els processos administratius rutinaris que voleu automatitzar. Esbrineu si necessiteu desplegar aplicacions i serveis específics al nou sistema. Feu una llista del que voleu fer i prioritzeu-lo.
A continuació, comenceu a escriure codi de script i rols que permetran les tasques que voleu completar. Combineu-los en Projectes, una col·lecció lògica de llibres de jocs rellevants. Cada projecte pertanyirà a un repositori Git independent o a un repositori diferent en funció del gestor de codi que utilitzeu. Podeu gestionar scripts i directoris de llibres de jugades col·locant-los manualment al Projecte Base Path al servidor de la torre o col·locant el llibre de jocs en qualsevol sistema de gestió de codi font (SCM) compatible amb Tower, inclosos Git, Subversion, Mercurial i Red Hat. Insights. Dins d'un projecte podeu col·locar tants scripts com vulgueu. Per exemple, vaig crear un projecte bàsic en el qual vaig col·locar un script per als elements bàsics de RedHat, un script per al nucli Linux i scripts per a la resta de línies de base. Així, en un projecte hi havia una varietat de rols i escenaris que es gestionaven des d'un dipòsit de Git.
Executar totes aquestes coses a través de la línia d'ordres és una bona manera de provar la seva funcionalitat. Això us prepararà per a la instal·lació de la torre.
Parlem una mica de la transcodificació del manifest de Puppet, perquè hi vaig dedicar molt de temps fins que vaig descobrir què calia fer.
Com he dit abans, Puppet emmagatzema totes les opcions de configuració i maquinari en un manifest llarg, i aquest manifest emmagatzema tot el que hauria de fer aquest SCM. Quan feu la transició, no cal que aplegueu totes les vostres tasques en una llista; en canvi, penseu en l'estructura del nou sistema: rols, scripts, etiquetes, grups i què hi hauria d'anar. Alguns dels elements de la xarxa autònoma s'han d'agrupar en grups per als quals es poden crear scripts. Els elements d'infraestructura més complexos que impliquen un gran nombre de recursos, incloses les classes autònomes, es poden combinar en rols. Abans de migrar, heu de decidir-ho. Si esteu creant grans rols o escenaris que no encaixen en una pantalla, hauríeu d'utilitzar etiquetes per poder capturar parts específiques de la infraestructura.
18:00
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com