Get best of the week

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

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 confirma la implementación de esta migración, comparte consejos útiles y la experiencia adquirida 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.



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



Tengo etiquetas para la implementación inicial que se ejecutan todas. Tengo etiquetas que comprueban los cambios en el 20% de la infraestructura que ocurren en el 80% del tiempo de trabajo. Una situación similar con los roles. Hay un código de mantenimiento, un segundo código que organiza el despliegue y un tercero que lanza el equipo, por ejemplo, una vez al día. El rol verifica los cambios en todos los equipos que se implementarán, y se realizan verificaciones cada dos horas para los equipos que están sujetos a cambios. Esto se aplica al firewall, algunas cosas administrativas y similares.

Use los buenos hábitos que adquirió al escribir código para Puppet, porque serán útiles para Ansible. Por ejemplo, una idempotencia es una propiedad de un objeto u operación cuando se aplica nuevamente la operación al objeto para obtener el mismo resultado que el primero. En nuestro caso, esto significa que cuando ejecutas el mismo script de libro de jugadas nuevamente, nada cambia y el sistema te dice que nada ha cambiado. Si los cambios se confirman, significa que algo está mal con su código. Es decir, la idempotencia lo ayudará a detectar cuándo algo sale mal al iniciar las mismas operaciones de rutina.
Use hechos y patrones, evite datos codificados. Ansible le permite hacer esto con scripts, manipulando de manera flexible un conjunto de datos y captando cambios sobre la marcha. No existe tal cosa en Puppet, debe colocar todos los datos importantes dentro del código fuente. Por lo tanto, use roles, esto facilitará enormemente su tarea.

Utilice controladores de eventos causados ​​por un cambio de configuración. Lo bueno es que los controladores pueden trabajar con secuencias protegidas. Documenta todo lo que haces. Odio cuando me encuentro con un código que escribí hace seis meses, sin documentar nada en ese momento, y no puedo recordar por qué lo escribí en absoluto. Por lo tanto, cualquier tarea debe tener una descripción. Cada rol y guión que escriba debe tener su propio archivo Léame, que registrará cómo usarlos y qué hacen. Créeme, luego esto te será muy útil.



Debe aprovechar las nuevas libertades que proporciona Ansible. Puede afectar el mismo archivo varias veces si es necesario. Por ejemplo, si necesita cambiar varios parámetros del archivo sshd_config en un script que contiene parámetros importantes para otros scripts, puede hacerlo. Puppet no permite esto.
Con Ansible, obtienes una ejecución predecible del programa. Funcionan exactamente como espera de ellos, y no necesita supervisar los errores de ejecución del código. Si trabaja con EXEC, tenga en cuenta que los controladores de Ansible son más inteligentes que los controladores de Puppet. Usar trucos Ansible como mi función de delegación favorita. Por ejemplo, comenzó un libro de jugadas para el servidor A, pero parte de los pasos de este script deben realizarse de forma independiente en el servidor B. Utilicé la función de delegación para migrar de puppet a Ansible. Con esta función, puede configurar la ejecución de la tarea en un host diferente y no en el que se configuró con la tecla delegate_to. El módulo aún se ejecutará una vez para cada máquina, pero en lugar de trabajar en la máquina de destino, funcionará en un host delegado,Además, todos los datos disponibles serán aplicables al host actual. Esto reducirá significativamente la cantidad de configuraciones manuales del sistema.

Los datos de su biblioteca de Puppet Hiera se pueden usar como hechos de Ansible, que son información sobre nodos conectados. Datos: esto es lo que recopila el módulo de datos de recopilación durante la ejecución: la cantidad de espacio en disco, la versión y el tipo de sistema operativo, el nombre de host, la cantidad de memoria disponible, la arquitectura del procesador, las direcciones IP, las interfaces de red y su estado. No me refiero a la información de servicio oculta en el fondo de los datos, solo use los scripts de su equipo para formar grupos y nodos variables. Mi script de hardware le dice al sistema qué sitios físicos contiene. Más tarde uso roles, por ejemplo, uno de los roles contiene datos de infraestructura para cada sitio físico, como recursos NTP, servidores DNS, direcciones IP de equipos modulares, escáneres Nessus y similares.Recopile variables comunes en un rol si las coloca en más de un lugar y las coloca en el host como el archivo /etc/ansible/facts.d/.

Por lo tanto, consideraremos en realidad el proceso de migración. Repito: para mí me llevó mucho tiempo, pero puedes reducirlo. En primer lugar, debes comprar y desplegar la Torre. Este es un proceso muy comprensible, solo siga la documentación de instalación.



Después de instalar Tower, obtendrá acceso inmediato a la interfaz web. A continuación, debe instalar un script de inventario y crear una lista de equipos. Puede copiar y pegar los scripts existentes en la Torre.

A continuación, configure los permisos y permisos de Git dando a Tower acceso directo al repositorio de Git donde almacena libros de jugadas. Por lo tanto, le permitirá a Tower recibir instantáneamente información de los scripts sobre los cambios e implementarlos de inmediato. No necesita decirle nada a Tower, simplemente comprobará el estado del sistema y ejecutará la última versión de la configuración.

Instale una cuenta estándar de Tower para SSH en sus hosts. Uso acceso remoto, por lo que uso la cuenta estándar y el programa de administración del sistema SUDO para establecer privilegios. Por supuesto, Tower tiene una contraseña, por lo que no arriesga la seguridad con la contraseña SUDO.

Configure la autenticación de Tower de acuerdo con la estructura de acceso de su organización. Decida el acceso para departamentos, equipos, distribución de acceso a roles, maneje permisos especiales. Esta es una tarea muy voluminosa, dependiendo del tamaño de su organización, pero recuerde que desde el punto de vista de administrar la Torre, gracias a la configuración flexible de los accesos, puede simplificar enormemente su vida.

Ahora que tiene el repositorio Git implementado, instale y configure plantillas de trabajo para libros de jugadas. Prueba el rendimiento de todo lo que haces con Tower. Después de verificar que sus scripts están en perfecto orden, puede continuar con la migración del host. Use Ansible para eliminar el agente Puppet y "limpiar" el nodo del servidor Puppet usando un script especial. Es muy simple.



Creé un grupo llamado Tower, lo agregué al script de Ansible y lo envié a todos los hosts. Después de eso, este libro de jugadas detuvo los servicios de Puppet, desinstaló todos los paquetes de Puppet Enterprise y borró los directorios. También eliminó a los usuarios de Puppet: dado que eliminamos PE, también eliminamos a los usuarios de PE.

Vemos la función Delegación en acción. Ahora puedo ingresar al Puppet Master y usar los comandos 2-3 para borrar el registro, y luego tomar una captura de pantalla que muestre que este SCM ha sido eliminado. Servirá como evidencia documental de que ya no usamos PE.

Ahora echemos un vistazo a lo que debe recibir la máxima atención: mis errores que deben evitarse. Esto se relaciona principalmente con la dependencia de los escenarios entre sí. Es posible que las variables de un libro de jugadas dependan de las variables de otro libro de jugadas. Recuerde que puede insertar requisitos en cada escenario que permitan el uso de un escenario o rol diferente. Creé roles para las variables de todos nuestros sitios, y cada uno de estos roles contenía muchas variables. Por lo tanto, utilicé el archivo require.yml para centralizar variables comunes. Le permite instalar múltiples colecciones de contenido Ansible con un equipo.



Si cambiamos la puerta de enlace predeterminada o el servidor NTP, estos cambios se reflejarán inmediatamente en todos los elementos de la infraestructura.

Evite el uso de roles y scripts masivos y voluminosos. Los escenarios y roles cortos para tareas específicas son más eficientes y confiables, más fáciles de administrar y más fáciles de rastrear.

Preste atención a una cosa más: cuando inicie Tower y vaya a su página, verá una pantalla de muchos parámetros en rojo. Este color es una alarma, pero aquí está la cosa. Usted inicia el proceso en cientos de hosts, y si 99 de ellos funcionan con éxito, y uno no, Tower informará un error en el proceso. Colocará un marcador rojo brillante en la pantalla que ilustra este trabajo. No entre en pánico, pero trate de descubrir por qué este nodo único no funciona. Cuando miras la pantalla de Puppet Master y ves 99 luces verdes y una roja, crees que todo está en orden, el sistema funciona bien. La torre es más estricta, pero menos informativa sobre los mensajes de error. Quizás en futuras versiones de Ansible se elimine esta deficiencia, pero por ahora solo trate de descubrir la causa de la alarma, recordandoque tal alarma no puede llevar nada crítico en sí mismo, solo de esta manera el sistema informa una falla en un host.

Tenga cuidado si tiene hosts temporales que no siempre están en línea. Por ejemplo, mi sistema tiene varias computadoras portátiles. Los administramos utilizando Ansible Tower de la misma manera que los hosts permanentes, pero como se trata de dispositivos móviles, no siempre están presentes en la red. Si usa hosts temporales cuando realiza procesos estándar, pero la Torre no los detecta en la red cuando se inicia el sistema, aparecerá inmediatamente en su pantalla una alarma y un mensaje de falla del proceso. Tower no sabe que estas computadoras portátiles están actualmente apagadas. No hay ningún problema con esto, solo tenga en cuenta que tal situación puede causar un mensaje de alarma.

Hay una buena forma de usar la API de Tower. Cuando la computadora portátil se inicia como parte del procedimiento estándar de inicio del sistema, utiliza la API para decirle a Tower: "oye, estoy aquí, ¿hay algún trabajo para mí?", Después de lo cual la Torre comprueba las tareas para esta máquina en particular ahora, porque sabe que ella está en línea.

Otra cosa con la que inicialmente tuvimos problemas fue la ejecución de operaciones paralelas. Por defecto, Ansible usa 5 hosts paralelos para hacer un trabajo. Por lo tanto, el lanzamiento del mismo trabajo programado para 100 máquinas toma hasta 20 minutos por host al verificar los parámetros de la configuración principal. Por lo tanto, primero comenzamos la configuración en 5 hosts, luego otros 5, otros 5 y así sucesivamente. Al principio, esta circunstancia nos puso muy nerviosos, porque la implementación del sistema en 50 hosts tuvo lugar en 2 horas. La solución a este problema es la siguiente.
Simplemente configure el número de hosts paralelos en el servidor de Ansible Tower para que sea diferente a 5. Como tengo 150 hosts ejecutándose simultáneamente, configuré este valor en 25. Después de eso, 6 parches, por ejemplo, se instalaron con bastante rapidez. Si lo desea, puede establecer este parámetro en 50; todo depende de la potencia informática y la cantidad de RAM que tenga. De esta forma, Tower le permite personalizar la ejecución de procesos paralelos para satisfacer sus necesidades.



Si tiene alguna pregunta sobre el tema del informe, no dude en ponerse en contacto con los contactos indicados. Verá la dirección de correo electrónico donde puede enviar un correo electrónico describiendo el problema que ocurrió al cambiar de Puppet a Ansible, e intentaré responderle lo antes posible. ¡Les agradezco su participación y les deseo una migración exitosa!

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