El Servicio Nacional de Datos Satelitales sobre el Medio Ambiente (NESDIS) redujo en un 35% sus costos de gestión de configuración de Red Hat Enterprise Linux (RHEL) al hacer la transición de Puppet Enterprise a Ansible Tower. En este video de la categoría 'cómo lo hicimos', el ingeniero de sistemas Michael Rau justifica la realización de esta migración, comparte consejos útiles y la experiencia adquirida de pasar de un SCM a otro.
En este video aprenderás:
- cómo justificar a la dirección la viabilidad de la transición de Puppet Enterprise a Ansible Tower;
- qué estrategias utilizar para una transición lo más fluida posible;
- consejos sobre la transcodificación de manifiestos de PE a Playbooks de Ansible;
- recomendaciones para la instalación óptima de Ansible Tower.
Hola 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) del servicio NESDIS. Hoy hablaremos sobre cortar hilos: mi propia experiencia de migración de Puppet Enterprise a Ansible Tower. El tema de esta presentación es 'mirar mis cicatrices', que quedaron después de llevar a cabo esta transición a principios de año. Quiero contarles lo que aprendí durante este proceso. Así que cuando se enfrenten a algo así, usando mi experiencia, podrán hacer la transición sin problemas.
Ves diapositivas como esta al comienzo de cada presentación en Ansible Fest. Esta diapositiva presenta la historia de la automatización de mi empresa. No soy nuevo en esto, ya que 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 hacer 'trucos' mediante la línea de comandos y los sencillos scripts (playbooks). A finales de 2017, hablé con mi dirección sobre la necesidad urgente de hacer la transición a Ansible Tower. En un minuto hablaré sobre las razones que me llevaron a dar este paso. Después de conseguir la aprobación de la dirección, pasaron unos meses más para llevar a cabo lo planeado y hice la transición en enero-febrero de este año. Así que, abandonamos por completo Puppet a favor de Ansible, y es algo grandioso.
Lo que más me atrae de Ansible es la posibilidad de escribir y usar roles y playbooks. Los roles son ideales para crear tareas diversas pero interrelacionadas y para almacenar todos los datos relacionados con dichas tareas en un solo lugar. Un playbook es un archivo de script en sintaxis YAML que describe acciones para uno o varios hosts. Comunico estas posibilidades a los usuarios, principalmente desarrolladores de software. Ansible Tower permite decir: 'no, no tienes acceso a shell, pero te ofrezco la oportunidad de ejecutar todos los procesos de Tower y reiniciar el servicio cuando lo necesites'. Les hablaré sobre el entorno de trabajo y el equipo que utilizamos.
Esta es una LAN federal, con 7 sitios físicos conectados a través de MPLS en la nube, 140 servidores RHEL, de los cuales el 99% son virtuales (vSphere), hardware SuperMicro, almacenamiento en red NexentaStore, un conjunto de switches Cisco, Arista y Cumulus, y herramientas de gestión unificada de amenazas Fortinet UTM en cada sitio.
La red federal significa que debo utilizar todas las medidas de protección de la información requeridas por la legislación. Debe tener en cuenta que Puppet Enterprise no es compatible con gran parte del hardware que utilizamos. Nos vemos obligados a usar hardware económico, ya que las entidades gubernamentales enfrentan problemas con la financiación de este artículo. Por lo tanto, compramos hardware de clase SuperMicro y ensamblamos nuestro equipo a partir de piezas individuales, cuyo mantenimiento está garantizado por contratos gubernamentales. Usamos Linux, y esta es una de las razones importantes para migrar a Ansible.
Nuestra historia con Puppet es la siguiente.
En 2007 teníamos una pequeña red de 20-25 nodos, donde implementamos Puppet. Principalmente, estos nodos eran simplemente «cajas» RedHat. En 2010 comenzamos a usar la interfaz web Puppet Dashboard para 45 nodos. A medida que la red seguía creciendo, en 2014 migramos a PE 3.3, realizando una transición completa reescribiendo el manifiesto para 75 nodos. Esto fue necesario porque Puppet tiende a cambiar las reglas del juego, y en este caso cambiaron por completo el lenguaje. Un año después, cuando se interrumpió el soporte para la versión 3 de Puppet Enterprise, nos vimos obligados a migrar a PE 2015.2. Tuvimos que reescribir nuevamente el manifiesto para los nuevos servidores y adquirir una licencia de sobra para 100 nodos, aunque en ese momento solo teníamos 85 nodos.
Pasaron solo 2 años y nuevamente tuvimos que hacer un gran trabajo para migrar a la nueva versión PE 2016.4. Compramos una licencia para 300 nodos, teniendo solo 130. Nuevamente tuvimos que realizar cambios significativos en el manifiesto, porque la nueva versión del lenguaje tenía una sintaxis diferente a la de la versión de 2015. Como resultado, nuestro SCM migró de un sistema de control de versiones SVN a Bitbucket (Git). Así fueron nuestras «relaciones» con Puppet.
Así que tuve que explicarle a la dirección por qué necesitábamos migrar a otro SCM, utilizando los siguientes argumentos. Primero, el alto costo del servicio. Hablé con los chicos de RedHat y me dijeron que el costo de mantener una red de 300 nodos con Ansible Tower es la mitad del costo de Puppet Enterprise. Si adquirimos también Ansible Engine, el costo será aproximadamente el mismo, pero obtendremos muchas más funciones que con PE. Dado que somos una empresa estatal financiada por el presupuesto federal, este es un argumento bastante sólido.
El segundo argumento es la versatilidad. Puppet solo soporta el hardware en el que hay un agente Puppet instalado. Esto significa que es necesario instalar un agente en todos los switches, y debe ser la última versión. Y si parte de tus switches soporta una versión y parte otra, necesitarás instalar la nueva versión del agente PE en ellos para que todos puedan funcionar en un mismo sistema SCM.
El sistema Ansible Tower funciona de manera diferente porque no tiene agentes, pero sí cuenta con módulos que son compatibles con los switches de Cisco y otros switches. Este SCM admite Qubes OS, Linux y .NET UTM. Ansible Tower también es compatible con controladores de almacenamiento en red NexentaStore, basados en el núcleo Illumos, un sistema operativo de código abierto basado en Unix. Este soporte es bastante limitado, pero Ansible Tower lo ofrece de todos modos.
El tercer argumento, muy importante tanto para mí como para nuestra administración, es la facilidad de aprendizaje. He estado aprendiendo módulos y el código de manifiestos de Puppet durante 10 años, pero aprendí Ansible en una semana, porque es mucho más sencillo trabajar con este SCM. Si ejecutas archivos ejecutables, claro, a menos que lo hagas sin necesidad, son manejados por controladores inteligentes y receptivos. Los scripts de playbooks basados en YAML se caracterizan por ser fáciles de aprender y rápidos de usar. Aquellos que nunca han oído hablar de YAML pueden simplemente leer los scripts y entender fácilmente cómo funcionan.
Honestamente, Puppet complica mucho tu trabajo como desarrollador, ya que se basa en el uso de Puppet Master. Esta es la única máquina que tiene permiso para comunicarse con los agentes de Puppet. Si realizas cambios en un manifiesto y deseas probar tu código, debes reescribir el código para Puppet Master, es decir, configurar el archivo Puppet-master /etc/hosts para conectar todos los clientes y ejecutar el servicio Puppet Server. Solo después de esto podrás probar el funcionamiento del hardware de red en un solo host. Es un procedimiento bastante doloroso.
Con Ansible todo es mucho más sencillo. Solo necesitas desarrollar el código para una máquina que pueda comunicarse a través del protocolo SSH con el host que estás probando. Es mucho más fácil trabajar de esta manera.
Otra gran ventaja de Ansible Tower es la capacidad de aprovechar el sistema de soporte que ya tienes y mantener la configuración existente del hardware. Este SCM utiliza toda la información disponible sobre tu infraestructura y hardware, máquinas virtuales, servidores, etc., sin necesidad de acciones adicionales. Puede comunicarse con tus servidores RH Satellite, si los tienes, y te ofrece una integración que nunca obtendrás trabajando con Puppet.
Otra cosa importante es el control detallado. Sabes que Puppet es un sistema modular, es una aplicación cliente-servidor, por lo que debes definir los aspectos existentes del funcionamiento de todas tus máquinas en un solo manifiesto largo. Además, el estado de cada elemento individual del sistema debe ser probado cada media hora, que es el período por defecto. Así es como funciona Puppet.
Tower te libera de esto. Puedes ejecutar sin restricciones los procesos más diversos en el equipo más variado, realizar el trabajo básico, iniciar otros procesos importantes, configurar el sistema de seguridad y trabajar con bases de datos. Puedes hacer todo lo que en Puppet Enterprise está asociado con ciertas complicaciones. Así, si realizaste la configuración en un host, tomará tiempo para que los cambios se efectúen en los otros hosts. En Ansible, todos los cambios se aplican simultáneamente.
Por último, consideremos el módulo de seguridad. En Ansible Tower, se implementa de manera increíble, con gran precisión y cuidado. Puedes otorgar a los usuarios acceso a servicios específicos o a hosts concretos. Yo hago esto con mis empleados, que están acostumbrados a trabajar en Windows, limitando su acceso a la terminal de Linux. Les proporciono acceso a Tower de modo que solo puedan realizar el trabajo y ejecutar los servicios que están dentro de su competencia.
Analicemos las cosas que debes hacer con anticipación para facilitar la transición a Ansible Tower. En primer lugar, es necesario preparar tu equipo. Si hay elementos en tu infraestructura que aún no están en la base de datos, debes añadirlos. Existen sistemas que no cambian sus características y, por lo tanto, no están en la base de datos de Puppet, pero si no los incorporas antes de la transición a Tower, perderás varias ventajas. Puede ser una base de datos preliminar "sucia", pero debe contener información sobre todo el equipamiento que tienes. Por lo tanto, deberías escribir un script dinámico de hardware que automáticamente haga todos los cambios en la infraestructura en la base de datos, de modo que Ansible sepa qué hosts deben estar en el nuevo sistema. No necesitarás informar a este SCM qué hosts has añadido y cuáles ya no existen, porque todo esto lo conocerá automáticamente. Cuanta más información haya en la base de datos, más útil y flexible será Ansible. Funciona como si simplemente leyera el código de barras del estado del hardware.
Dedica un tiempo a familiarizarte con el uso de la línea de comandos en Ansible. Ejecuta algunos comandos especiales para verificar el funcionamiento del script de hardware, escribe y ejecuta algunos sencillos pero útiles guiones de playbook, utiliza plantillas Jinja2 donde sea adecuado. Intenta escribir un rol y un guion para un proceso complejo de múltiples etapas, utilizando una configuración estándar y común de hardware. Juega con estas cosas, prueba cómo funcionan. De esta manera, aprenderás a trabajar con las herramientas para crear bibliotecas utilizadas en Tower. Ya mencioné que mi preparación para la transición tomó aproximadamente 3 meses. Creo que, basándote en mi experiencia, podrás hacerlo más rápido. No consideres este tiempo como perdido, ya que luego sentirás todas las ventajas del trabajo realizado.
A continuación, es necesario decidir qué esperas de Ansible Tower, qué es lo que esta sistema debe hacer específicamente por ti.
¿Necesita implementar el sistema en hardware vacío o en máquinas virtuales vacías? ¿O desea mantener las condiciones originales de trabajo y la configuración del hardware existente? Este es un aspecto muy importante para el funcionamiento de las empresas gubernamentales, por lo que debe estar seguro de que podrá realizar la migración e implementar Ansible en la configuración existente. Defina los procesos administrativos rutinarios que desea automatizar. Averigüe si necesita implementar aplicaciones y servicios específicos en el nuevo sistema. Haga una lista de lo que desea hacer y establezca prioridades.
Luego, comience a escribir el código de los scripts y roles que garantizarán la ejecución de las tareas que ha planificado. Reúnalos en Proyectos, una colección lógica de scripts playbooks relacionados. Cada Proyecto estará vinculado a un repositorio Git separado u otro repositorio dependiendo del gestor de código que esté utilizando. Puede administrar los scripts playbook y las carpetas playbook colocándolos manualmente en la Ruta Base del Proyecto en el servidor Tower, o colocándolos en cualquier sistema de gestión de código fuente (SCM) compatible con Tower, incluyendo Git, Subversion, Mercurial y Red Hat Insights. Dentro de un Proyecto, puede colocar tantos scripts como desee. Por ejemplo, he creado un Proyecto básico en el que incluí un script para los elementos básicos de RedHat, un script para la base de Linux y scripts para los demás indicadores básicos. De este modo, en un mismo proyecto había roles y scripts muy diversos que se gestionaban desde un solo repositorio Git.
Ejecútelos todos a través de la línea de comandos, es una buena manera de comprobar su funcionamiento. De este modo, se preparará para la instalación de Tower.
Hablemos un poco sobre la transcodificación del manifiesto Puppet, porque pasé mucho tiempo en esto hasta que comprendí lo que realmente era necesario hacer.
Como ya mencioné, Puppet almacena todas las configuraciones y parámetros del hardware en un largo manifiesto, y en este manifiesto se guarda todo lo que debe hacer este SCM. Al migrar, no necesitas meter todas tus tareas en una sola lista; en su lugar, considera la estructura del nuevo sistema: roles, escenarios, etiquetas, grupos y qué debe incluirse allí. Algunos de los elementos de la red se deben agrupar en grupos para los que se pueden crear escenarios. Los elementos más complejos de la infraestructura que consumen muchos recursos, incluidos los que contienen clases autónomas, se pueden agrupar en roles. Antes de la migración, necesitas resolver esto. Si estás creando roles o escenarios voluminosos que no caben en una pantalla, deberías usar etiquetas para poder capturar partes individuales de la infraestructura.
18:00
Un poco de publicidad 🙂
Gracias por permanecer con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendando a tus conocidos, , un análogo único de servidores entry-level que hemos diseñado para Ti: (disponibles opciones con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
¿Dell R730xd a mitad de precio en el centro de datos Equinix Tier IV en Ámsterdam? Solo aquí ¡en los Países Bajos! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ¡desde $99! Lee sobre cómo
Fuente: habr.com
