O National Environmental Satellite Data Information Service (NESDIS) reduciu os seus custos de xestión de configuración para Red Hat Enterprise Linux (RHEL) nun 35% ao migrar de Puppet Enterprise a Ansible Tower. Neste vídeo de "como o fixemos", o enxeñeiro de sistemas Michael Rau explica o caso desta migración, compartindo consellos útiles e leccións aprendidas ao pasar dun SCM a outro.
Con este vídeo aprenderás:
- como xustificar ante a dirección a viabilidade do cambio de Puppet Enterprise a Ansible Tower;
- que estratexias utilizar para facer a transición o máis suave posible;
- consellos para transcodificar os manifestos PE en Ansible Playbook;
- Recomendacións para a instalación óptima de Ansible Tower.
Ola a todos, chámome Michael Rau, son enxeñeiro de sistemas senior en ActioNet, que traballa para o servizo NESDIS da Administración Nacional Oceánica e Atmosférica (NOAA). Hoxe falaremos sobre o recorte de cordas: a miña propia experiencia de migrar de Puppet Enterprise a Ansible Tower. O tema desta presentación é "botar unha ollada ás miñas cicatrices" que me deixaron despois de facer esta transición a principios de ano. Quero compartir o que aprendín a través deste proceso. Entón, cando asumes algo así, usando a miña experiencia, podes facer a transición sen ningún traballo extra.
Ves diapositivas similares a esta ao comezo de cada presentación no Ansible Fest. Esta diapositiva describe a historia da automatización da miña empresa. Non son novo nisto porque levo usando Puppet/Puppet Enterprise desde 2007. Comecei a traballar con Ansible en 2016 e, como moitos outros usuarios deste produto, atraeume a posibilidade de "trucos" usando a liña de comandos e scripts sinxelos (playbooks). A finais de 2017, achegueime á miña dirección sobre as fortes razóns para mudarme a Ansible Tower. Nun minuto contareivos os motivos que me impulsaron a dar este paso. Despois de recibir o consentimento da dirección, tardou varios meses en completar o plan, e fixen a transición en xaneiro-febreiro deste ano. Entón, abandonamos por completo Puppet en favor de Ansible, e é unha gran cousa.
O que máis me atrae de Ansible é a capacidade de escribir e usar papeis e libros de xogo. Os roles son excelentes para crear tarefas distintas pero relacionadas e poñer todos os datos relacionados con esas tarefas nun só lugar. Un playbook é unha sintaxe YAML, ficheiro de script que describe accións para un ou máis hosts. Falo aos usuarios destas funcións, principalmente aos desenvolvedores de software. Ansible Tower ofrécelle a posibilidade de dicir: "non, non tes acceso ao shell, pero podo executar todos os procesos da Torre e reiniciar o servizo cando o necesites". Falarei do ambiente de traballo e dos equipos que utilizamos.
Esta é unha LAN federal, 7 sitios físicos conectados mediante MPLS na nube, 140 servidores RHEL, o 99% dos cales son virtuais (vSphere), hardware SuperMicro, almacenamento en rede NexentaStore, un conxunto de switches Cisco, Arista e Cumulus e xestión unificada de ameazas de Fortinet UTM. ferramentas en cada sitio.
A rede federal significa que debo utilizar todas as medidas de seguridade da información previstas pola lei. Debes ter en conta que Puppet Enterprise non admite a maior parte do hardware que usamos. Vémonos obrigados a utilizar hardware orzamentario porque as axencias gobernamentais teñen problemas para financiar esta partida de gasto. É por iso que compramos hardware SuperMicro e montamos os nosos equipos a partir de pezas individuais, cuxo mantemento está garantido por contratos gobernamentais. Usamos Linux e esta é unha das razóns importantes para cambiar a Ansible.
A nosa historia con Puppet é a seguinte.
En 2007, tiñamos unha pequena rede de 20-25 nodos, na que despregamos Puppet. Basicamente, estes nós eran só "caixas" de RedHat. En 2010, comezamos a usar a interface web Puppet Dashboard para 45 nós. A medida que a rede seguía expandíndose, pasamos a PE 2014 en 3.3, realizando unha transición completa cunha reescritura de manifesto para 75 nodos. Isto tivo que facelo porque a Puppet gústalle cambiar as regras do xogo, e neste caso cambiaron completamente o idioma. Un ano despois, cando rematou o soporte para a versión 3 de Puppet Enterprise, vímonos obrigados a migrar a PE 2015.2. Tivemos que reescribir o manifesto de novo para os novos servidores e adquirir unha licenza cunha reserva de 100 nodos, aínda que naquel momento só tiñamos 85 nodos.
Só pasaron 2 anos, e de novo tivemos que facer moito traballo para migrar á nova versión PE 2016.4. Compramos unha licenza para 300 nodos, con só 130. De novo tivemos que facer grandes cambios no manifesto porque a nova versión da linguaxe tiña unha sintaxe diferente á da versión de 2015. Como resultado, o noso SCM pasou do control de versión SVN a Bitbucket (Git). Esta foi a nosa "relación" con Puppet.
Entón, tiven que explicar á dirección por que necesitabamos pasar a un SCM diferente usando os seguintes argumentos. O primeiro é o alto prezo do servizo. Falei cos mozos de RedHat e dixeron que o custo de executar unha rede de 300 nodos con Ansible Tower é a metade do custo de Puppet Enterprise. Se tamén compras Ansible Engine, o custo será aproximadamente o mesmo, pero obterás moitas máis funcións que PE. Xa que somos unha empresa estatal financiada con cargo ao orzamento federal, este é un argumento bastante poderoso.
O segundo argumento é a versatilidade. Puppet só admite hardware que teña un axente Puppet. Isto significa que debe estar instalado un axente en todos os interruptores e debe ser a versión máis recente. E se algúns dos teus conmutadores admiten unha versión e algúns admiten outra, terás que instalar neles unha nova versión do axente PE para que todos poidan funcionar no mesmo sistema SCM.
O sistema Ansible Tower funciona de forma diferente porque non ten axentes, pero si ten módulos que admiten conmutadores Cisco e todos os demais. Este SCM admite Qubes OS, Linux e 4.NET UTM. Ansible Tower tamén admite controladores de almacenamento en rede NexentaStore baseados no núcleo Illumos, un sistema operativo baseado en Unix de código aberto. Este é moi pouco apoio, pero Ansible Tower faino de todos os xeitos.
O terceiro argumento, moi importante tanto para min como para a nosa administración, é a facilidade de uso. Pasei 10 anos dominando os módulos de Puppet e o código manifesto, pero aprendín Ansible nunha semana porque este SCM é moito máis fácil de traballar. Se executas ficheiros executables, por suposto, a non ser que o fagas innecesariamente, entón funcionan con eles controladores intelixentes e sensibles. Os libros de xogo baseados en YAML son fáciles de aprender e rápidos de usar. Aqueles que nunca oíron falar de YAML poden simplemente ler os guións e comprender facilmente como funciona.
Para ser honesto, Puppet dificulta moito o teu traballo como programador porque se basea no uso de Puppet Master. É a única máquina autorizada para comunicarse cos axentes de Puppet. Se fixeches algún cambio no manifesto e queres probar o teu código, debes reescribir o código para Puppet Master, é dicir, configurar o ficheiro /etc/hosts de Puppet Master para conectar todos os clientes e iniciar o servizo Puppet Server. Só despois diso poderás probar o funcionamento do equipo de rede nun servidor. Este é un procedemento bastante doloroso.
Todo é moito máis sinxelo en Ansible. Todo o que cómpre facer é desenvolver código para unha máquina que poida comunicarse mediante SSH co host en proba. Isto é moito máis doado de traballar.
A seguinte gran vantaxe de Ansible Tower é a capacidade de aproveitar o seu sistema de soporte existente e manter a súa configuración de hardware existente. Este SCM utiliza toda a información dispoñible sobre a súa infraestrutura e hardware, máquinas virtuais, servidores, etc. sen ningún paso adicionais. Pode falar cos teus servidores RH Satellite, se tes un, e ofréceche integracións que nunca conseguirás con Puppet.
Outra cousa importante é o control detallado. Sabes que Puppet é un sistema modular, é unha aplicación cliente-servidor, polo que debes definir os aspectos existentes de todas as túas máquinas nun longo manifesto. Neste caso, o estado de cada elemento individual do sistema debe ser probado cada media hora - este é o período predeterminado. Así funciona Puppet.
A torre sálvache diso. Pode executar unha variedade de procesos en diversos equipos sen restricións; pode facer traballo básico, executar outros procesos importantes, configurar un sistema de seguridade e traballar con bases de datos. Podes facer todo o que sexa difícil en Puppet Enterprise. Polo tanto, se o configuraches nun host, os cambios tardarán en ter efecto nos hosts restantes. En Ansible, todos os cambios entran en vigor ao mesmo tempo.
Finalmente, vexamos o módulo de seguridade. Ansible Tower implementao de forma sinxela, con gran precisión e coidado. Podes conceder aos usuarios acceso a servizos específicos ou a hosts específicos. Fágoo cos meus empregados que están afeitos a traballar en Windows, limitando o seu acceso ao shell de Linux. Aseguro que teñen acceso á Torre para que só poidan facer o traballo e executar só os servizos que lles sexan relevantes.
Vexamos as cousas que debes facer con antelación para facilitar a túa transición a Ansible Tower. Primeiro de todo, debes preparar o teu equipo. Se algúns elementos da súa infraestrutura aínda non están na base de datos, cómpre engadilos alí. Hai sistemas que non cambian as súas características e polo tanto non están na base de datos de Puppet, pero se non os engades alí antes de pasar a Tower, perderás unha serie de vantaxes. Esta pode ser unha base de datos preliminar "sucia", pero debe conter información sobre todos os equipos que tes. Polo tanto, debes escribir un script de hardware dinámico que introduza automaticamente todos os cambios de infraestrutura na base de datos, entón Ansible saberá que hosts deben estar presentes no novo sistema. Non terá que dicirlle a este SCM que hosts engadiu e cales xa non existen, porque saberá todo isto automaticamente. Cantos máis datos haxa na base de datos, máis útil e flexible será Ansible. Funciona coma se simplemente le o código de barras de estado do hardware dunha base de datos.
Pase algún tempo familiarizándose coa liña de comandos en Ansible. Executa algúns comandos personalizados para probar o script de hardware, escribe e executa algúns scripts de playbook sinxelos pero útiles, usa modelos Jinja2 cando corresponda. Proba a escribir un rol e un guión para un proceso complexo de varios pasos utilizando unha configuración de hardware común e habitual. Xoga con estas cousas, proba como funciona. Deste xeito, aprenderás a utilizar as ferramentas de creación de bibliotecas que se usan en Tower. Xa dixen que tardei uns 3 meses en prepararme para a transición. Creo que, segundo a miña experiencia, poderás facelo máis rápido. Non consideres este tempo perdido, porque máis adiante experimentarás todos os beneficios do traballo realizado.
A continuación, debes decidir o que esperas de Ansible Tower, o que debería facer exactamente este sistema por ti.
Necesitas implementar o sistema en hardware simple, en máquinas virtuais simples? Ou quere manter as condicións de funcionamento e a configuración orixinais dos equipos existentes? Este é un aspecto moi importante para as empresas públicas, polo que debes estar seguro de que poderás migrar e implementar Ansible na túa configuración existente. Identifique os procesos administrativos rutineiros que quere automatizar. Descubra se precisa implantar aplicacións e servizos específicos no novo sistema. Fai unha lista do que queres facer e priorízao.
A continuación, comeza a escribir código de guión e roles que permitirán as tarefas que planeas completar. Combínaos en Proxectos, unha colección lóxica de libros de xogos relevantes. Cada proxecto pertencerá a un repositorio Git separado ou a un repositorio diferente dependendo do xestor de código que use. Podes xestionar scripts e directorios de playbooks colocándoos manualmente na ruta base do proxecto no servidor Tower ou colocando o playbook en calquera sistema de xestión de código fonte (SCM) compatible con Tower, incluídos Git, Subversion, Mercurial e Red Hat. Insights. Dentro dun proxecto podes colocar tantos scripts como queiras. Por exemplo, creei un proxecto básico no que coloquei un script para os elementos básicos de RedHat, un script para o núcleo Linux e scripts para o resto das liñas de base. Así, nun proxecto había unha variedade de roles e escenarios que se xestionaban desde un repositorio de Git.
Executar todas estas cousas a través da liña de comandos é unha boa forma de probar a súa funcionalidade. Isto prepararache para a instalación da Torre.
Imos falar un pouco sobre a transcodificación do manifesto de Puppet, porque pasei moito tempo nisto ata que descubrín o que realmente había que facer.
Como dixen antes, Puppet almacena todas as opcións de configuración e hardware nun longo manifesto, e este manifesto almacena todo o que debería facer este SCM. Ao facer a transición, non necesitas agrupar todas as túas tarefas nunha soa lista; en cambio, pensa na estrutura do novo sistema: roles, guións, etiquetas, grupos e o que debería ir alí. Algúns dos elementos da rede autónoma deberían agruparse en grupos para os que se poden crear scripts. Os elementos de infraestrutura máis complexos que implican un gran número de recursos, incluídas as clases autónomas, pódense combinar en roles. Antes de migrar, debes decidir sobre isto. Se estás creando grandes roles ou escenarios que non encaixan nunha pantalla, debes usar etiquetas para poder capturar partes específicas da infraestrutura.
18:00
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com