Get best of the week

Recortar hilos: migrar de Puppet Enterprise a Ansible Tower. Parte 1

El Servicio Nacional de Información Satelital Ambiental (NESDIS) ha reducido sus costos de administración de configuración de Red Hat Enterprise Linux (RHEL) en un 35% al ​​pasar de Puppet Enterprise a Ansible Tower. En este video de la categoría "cómo lo hicimos", el ingeniero de sistemas Michael Rau corrobora la implementación de esta migración, comparte consejos útiles y la experiencia adquirida como resultado de la transición de un SCM a otro.

De este video aprenderás:

  • Cómo justificar la gestión de la viabilidad de pasar de Puppet Enterprise a Ansible Tower;
  • qué estrategias usar para la transición más suave;
  • consejos para transcodificar manifiestos de educación física en Ansible Playbook;
  • Mejores prácticas para instalar Ansible Tower.



Saludos a todos, mi nombre es Michael Rau, soy ingeniero de sistemas senior en ActioNet, que trabaja para la Administración Nacional Oceánica y Atmosférica (NOAA) de NESDIS. Hoy hablaremos sobre el recorte de línea: mi propia experiencia migrando de Puppet Enterprise a Ansible Tower. El tema de esta presentación es "mirar mis cicatrices" que quedan después de que hice esta transición a principios de año. Quiero contar lo que aprendí durante este proceso. Entonces, cuando haces esto, usando mi experiencia, puedes hacer la transición sin demasiada dificultad.

Verá diapositivas similares a esta al comienzo de cada presentación en Ansible Fest. Esta diapositiva muestra la historia de la automatización de mi empresa. No soy nuevo en este negocio porque he estado usando Puppet / Puppet Enterprise desde 2007. Comencé a trabajar con Ansible en 2016 y, como muchos otros usuarios de este producto, me atrajo la posibilidad de "trucos" usando la línea de comandos y scripts simples (libros de jugadas). A fines de 2017, recurrí a mi liderazgo sobre las buenas razones para mudarme a Ansible Tower. En un minuto hablaré sobre los motivos que me llevaron a dar este paso. Después de obtener el consentimiento de la gerencia, me llevó varios meses más cumplir con el plan, e hice la transición en enero-febrero de este año. Entonces, abandonamos por completo a Puppet a favor de Ansible, y esto es una gran cosa.



Lo que más me atrae de Ansible es la capacidad de escribir y usar roles y guiones (libros de jugadas). Los roles son excelentes para crear tareas (tareas) diferentes pero interrelacionadas y colocar todos los datos relacionados con estas tareas en un solo lugar. Playbook es la sintaxis YAML, un archivo de script que describe acciones para uno o más hosts. Hablo de estas características a los usuarios, principalmente a los desarrolladores de software. Ansible Tower permite decir: "no, no tiene acceso al acceso de shell, pero le doy la oportunidad de iniciar todos los procesos de Tower y reiniciar el servicio cuando lo necesite". Te contaré sobre el entorno de trabajo y el equipo que utilizamos.



Esta es una LAN federal, 7 sitios físicos conectados a través de MPLS basados ​​en la nube, 140 servidores RHEL, el 99% de los cuales son virtuales (vSphere), hardware SuperMicro, NexentaStore NAS, un conjunto de conmutadores Cisco, Arista y Cumulus y herramientas de gestión de amenazas unificadas Fortinet UTM en cada sitio .

La red federal significa que debo usar todos los medios de protección de la información previstos por los actos legislativos. Debe tener en cuenta que Puppet Enterprise no es compatible con la mayoría de los equipos que utilizamos. Nos vemos obligados a usar hardware presupuestario porque las agencias gubernamentales están teniendo problemas para financiar esta partida de gastos. Por lo tanto, compramos hardware de clase SuperMicro y ensamblamos nuestros equipos a partir de piezas individuales, cuyo mantenimiento está garantizado por contratos gubernamentales. Usamos Linux, y esta es una de las razones importantes para cambiar a Ansible.

Nuestra historia con Puppet es esta.



En 2007, teníamos una pequeña red de 20-25 nodos, en la que implementamos Puppet. Básicamente, estos nodos eran solo "cajas" de RedHat. En 2010, comenzamos a usar la interfaz web Puppet Dashboard para 45 nodos. A medida que la red continuó expandiéndose, en 2014 cambiamos a PE 3.3, haciendo una transición completa con la reescritura del manifiesto para 75 nodos. Esto tuvo que hacerse porque a Puppet le gusta cambiar las reglas del juego, y en este caso cambiaron completamente el idioma. Un año después, cuando se detuvo el soporte para la versión 3 de Puppet Enterprise, nos vimos obligados a migrar a PE 2015.2. Nuevamente tuve que reescribir el manifiesto para los nuevos servidores y comprar una licencia con una reserva de 100 nodos, aunque en ese momento solo teníamos 85 nodos.

Solo pasaron 2 años, y nuevamente tuvimos que hacer mucho trabajo para cambiar a la nueva versión de PE 2016.4. Compramos una licencia para 300 nodos, con un total de 130. Nuevamente tuvimos que hacer cambios importantes en el manifiesto, porque la nueva versión del idioma tenía una sintaxis diferente del idioma de la versión 2015. Como resultado, nuestro SCM cambió de un sistema de control de versiones SVN a Bitbucket (Git). Esa fue nuestra "relación" con Puppet.

Entonces, tuve que explicarle a la gerencia por qué necesitamos cambiar a otro SCM usando los siguientes argumentos. El primero es el alto precio del servicio. Hablé con los muchachos de RedHat y me dijeron que el costo de mantener una red de 300 nodos usando Ansible Tower es la mitad del costo de Puppet Enterprise. Si compra otro Ansible Engine, el costo será casi el mismo, pero obtendrá muchas más funciones que PE. Como somos una empresa estatal financiada por el presupuesto federal, este es un argumento bastante importante.



El segundo argumento es la versatilidad. Puppet solo admite hardware con un agente Puppet. Esto significa que necesita instalar un agente en todos los conmutadores, y debe ser la última versión. Y si parte de sus conmutadores admite una versión y otra parte, deberá instalar una nueva versión del agente PE en ellos para que todos puedan funcionar en el mismo sistema SCM.

El sistema Ansible Tower funciona de manera diferente porque no tiene agentes, pero hay módulos que admiten conmutadores Cisco y todos los demás conmutadores. Este SCM es compatible con Qubes OS, Linux y 4.NET UTM. Ansible Tower también es compatible con los NAS NexentaStore basados ​​en el núcleo Illumos, un sistema operativo de código abierto basado en Unix. Esto es muy poco soporte, pero Ansible Tower lo hace de todos modos.

El tercer argumento, que es muy importante tanto para mí como para nuestra administración, es la facilidad de desarrollo. Dominé el código y los módulos de manifiesto de Puppet durante 10 años, pero estudié Ansible durante una semana, porque es mucho más fácil trabajar con este SCM. Si ejecuta archivos ejecutables, por supuesto, si no lo hace innecesariamente, los manejadores razonables y receptivos trabajarán con ellos. Los scripts de playbooks basados ​​en YAML son fáciles de aprender y rápidos de usar. Aquellos que nunca antes han oído hablar de YAML pueden simplemente leer los guiones y comprender fácilmente cómo funciona.

Honestamente, Puppet complica tu trabajo como desarrollador, porque se basa en el uso de Puppet Master. Esta es la única máquina autorizada para comunicarse con los agentes de Puppet. Si realizó algún cambio en el manifiesto y desea probar su código, debe volver a escribir el código para Puppet Master, es decir, configurar el archivo maestro de Puppet / etc / hosts para conectar todos los clientes e iniciar el servicio Puppet Server. Solo entonces puede probar el funcionamiento del equipo de red en un host. Este es un procedimiento bastante doloroso.
En Ansible, todo es mucho más simple. Todo lo que hay que hacer es desarrollar un código para una máquina que pueda comunicarse a través de SSH con el host bajo prueba. Es mucho más fácil trabajar con esto.

La próxima gran ventaja de Ansible Tower es la capacidad de aprovechar su sistema de soporte existente y guardar su configuración de hardware existente. Este SCM sin ninguna acción adicional utiliza toda la información disponible sobre su infraestructura y equipo, máquinas virtuales, servidores, etc. Puede comunicarse con sus servidores RH Satellite, si los hay, y le proporciona una integración que nunca obtendrá cuando trabaje con Puppet.

Otra cosa importante es el control detallado. Usted sabe que Puppet es un sistema modular, es una aplicación cliente-servidor, por lo que debe determinar los aspectos existentes del funcionamiento de todas sus máquinas en un manifiesto largo. En este caso, el estado de cada elemento individual del sistema debe probarse cada media hora; este es el período predeterminado. Así es como funciona Puppet.

La torre te salva de esto. Puede realizar varios procesos en una amplia variedad de equipos sin restricciones, puede hacer el trabajo principal, iniciar otros procesos importantes, configurar el sistema de seguridad, trabajar con bases de datos. Puede hacer todo lo que viene con ciertas dificultades en Puppet Enterprise. Por lo tanto, si ha configurado en un host, tomará tiempo para que los cambios surtan efecto en los otros hosts. En Ansible, todos los cambios surten efecto simultáneamente.

Finalmente, considere el módulo de seguridad. En Ansible Tower, se implementa de manera simplemente sorprendente, con gran precisión y minuciosidad. Puede proporcionar a los usuarios acceso a servicios específicos o a hosts específicos. Hago esto con mis empleados que están acostumbrados a trabajar en Windows, restringiéndoles el acceso al shell de Linux. Les proporciono acceso a la Torre para que solo puedan hacer el trabajo y ejecutar solo aquellos servicios que son de su competencia.



Echemos un vistazo a las cosas que debe hacer de antemano para facilitar la transición a Ansible Tower. En primer lugar, es necesario preparar su equipo. Si algún elemento de su infraestructura aún no está en la base de datos, debe agregarlo allí. Hay sistemas que no cambian sus características y, por lo tanto, están ausentes en la base de datos de Puppet, pero si no los agrega allí antes de pasar a la Torre, perderá una serie de ventajas. Esta puede ser una base de datos preliminar "sucia", pero debe contener información sobre todo el equipo que tiene. Por lo tanto, debe escribir una secuencia de comandos de hardware dinámico que realice automáticamente todos los cambios de infraestructura en la base de datos, luego Ansible sabrá qué hosts deben estar en el nuevo sistema. No necesitará informar a este SCM,qué hosts agregó y qué hosts ya no existen, porque ella sabrá todo esto automáticamente. Cuantos más datos haya en la base de datos, Ansible será más útil y flexible. Funciona como si simplemente leyera un código de barras del estado del equipo de la base de datos.

Dedique un tiempo a conocer la línea de comando en Ansible. Ejecute algunos comandos especiales para probar la secuencia de comandos de hardware, escriba y ejecute algunas secuencias de comandos de libro de jugadas simples pero útiles, use plantillas Jinja2 cuando corresponda. Intente escribir un rol y un script para un proceso complejo de varias etapas utilizando una configuración de hardware estándar que se encuentra con frecuencia. Juega con estas cosas, prueba cómo funciona. De esta manera, aprenderá a trabajar con las herramientas para crear bibliotecas utilizadas en la Torre. Ya dije que me llevó unos 3 meses prepararme para la transición. Creo que, según mi experiencia, podrás hacerlo más rápido. No considere perder este tiempo, porque más adelante sentirá todas las ventajas del trabajo realizado.

A continuación, debe decidir qué espera de Ansible Tower, qué debe hacer exactamente este sistema por usted.



¿Necesita implementar el sistema en hardware vacío, en máquinas virtuales vacías? ¿O desea mantener las condiciones originales de trabajo y la configuración de los equipos existentes? Este es un aspecto muy importante para el trabajo de las empresas estatales, por lo que debe estar seguro de que podrá migrar e implementar Ansible en su configuración existente. Identifique los procesos administrativos de rutina que desea automatizar. Averigüe si necesita implementar aplicaciones y servicios específicos en el nuevo sistema. Haga una lista de lo que quiere hacer y priorice.

Luego comience a escribir código para scripts y roles que lo ayudarán a completar sus tareas planificadas. Combínelos en Proyectos, una colección lógica de guiones de libros de jugadas relevantes. Cada proyecto se relacionará con un repositorio Git separado u otro repositorio dependiendo del administrador de código que use. Puede administrar los scripts del libro de jugadas y los directorios del libro de jugadas colocándolos manualmente en Project Base Path en el servidor Tower, o colocando el libro de jugadas en cualquier sistema de administración de código fuente de torre (SCM), incluidos Git, Subversion, Mercurial y Red Hat Insights. Dentro de un proyecto, puede colocar tantos scripts como desee. Por ejemplo, creé un proyecto básico, en el que coloqué un script para los elementos principales de RedHat, un script para los conceptos básicos de Linux,Escenarios para las líneas de base restantes. Por lo tanto, en un proyecto había una gran variedad de roles y scripts que se administraban desde un repositorio de Git.

Ejecute todas estas cosas a través de la línea de comando, esta es una buena manera de probar su rendimiento. De esta manera te preparas para la instalación de la Torre.

Hablemos un poco sobre la transcodificación del manifiesto de Puppet, porque pasé mucho tiempo en ello hasta que descubrí lo que realmente debía hacerse.



Como dije antes, Puppet almacena todas las configuraciones y parámetros del equipo en un manifiesto largo, y este manifiesto contiene todo lo que este SCM debería hacer. Durante la transición, no necesita incluir todas sus tareas en una lista, sino pensar en la estructura del nuevo sistema: roles, scripts, etiquetas, grupos y lo que debería ir allí. Algunos de los elementos de red independientes deben agruparse en grupos para los que puede crear scripts. Los elementos de infraestructura más complejos que involucran una gran cantidad de recursos, incluidas las clases autónomas, se pueden combinar en roles. Antes de la migración, debe decidir sobre esto. Si crea roles voluminosos o scripts que no caben en una pantalla, debe usar etiquetas para poder capturar partes individuales de la infraestructura.

18:00

Hilos de recorte: migración de Puppet Enterprise a Ansible Tower. Parte 2

Un poco de publicidad :)


Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? ¡Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

More articles:


All Articles