El Servicio Nacional de Información de Datos Satélites Ambientales (NESDIS) ha reducido sus costos de gestión de configuración para Red Hat Enterprise Linux (RHEL) en un 35 % al migrar de Puppet Enterprise a Ansible Tower. En este vídeo sobre "cómo lo hicimos", el ingeniero de sistemas Michael Rau explica los argumentos a favor de esta migración y comparte consejos útiles y lecciones aprendidas al pasar de un SCM a otro.
De este vídeo aprenderás:
- cómo justificar ante la dirección la viabilidad de cambiar de Puppet Enterprise a Ansible Tower;
- qué estrategias utilizar para que la transición sea lo más fluida posible;
- consejos para transcodificar manifiestos de PE en Ansible Playbook;
- Recomendaciones para una instalación óptima de Ansible Tower.
Hola a todos, mi nombre es Michael Rau, soy ingeniero de sistemas senior en ActioNet, que trabaja para el servicio NESDIS de la Administración Nacional Oceánica y Atmosférica (NOAA). Hoy hablaremos sobre el corte de hilos: mi propia experiencia al migrar de Puppet Enterprise a Ansible Tower. El tema de esta presentación es “echar un vistazo a mis cicatrices” que quedaron después de que hice esta transición a principios de año. Quiero compartir lo que aprendí a través de este proceso. Entonces, cuando asumes algo como esto, usando mi experiencia, puedes hacer la transición sin ningún trabajo adicional.
Verá diapositivas similares a esta al comienzo de cada presentación en Ansible Fest. Esta diapositiva describe la historia de la automatización de mi empresa. No soy nuevo en esto 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 realizar "trucos" utilizando la línea de comandos y scripts simples (playbooks). A finales de 2017, me comuniqué con mi gerencia sobre las razones de peso para mudarme a Ansible Tower. En un minuto os contaré los motivos que me impulsaron a dar este paso. Después de recibir el consentimiento de la gerencia, me tomó varios meses más completar el plan e hice la transición en enero-febrero de este año. Entonces, abandonamos por completo Puppet en favor de Ansible, y es algo grandioso.
Lo que más me atrae de Ansible es la capacidad de escribir y utilizar roles y manuales. Los roles son excelentes para crear tareas distintas pero relacionadas y poner todos los datos relacionados con esas tareas en un solo lugar. Un libro de estrategias es un archivo de script de sintaxis YAML que describe acciones para uno o más hosts. Hablo de estas funciones con los usuarios, principalmente con los desarrolladores de software. Ansible Tower le brinda la posibilidad de decir: "no, no tiene acceso al shell, pero le doy la posibilidad de ejecutar todos los procesos de Tower y reiniciar el servicio cuando lo necesite". Les contaré sobre el ambiente de trabajo y los equipos que utilizamos.
Se trata de una LAN federal, 7 sitios físicos conectados a través de MPLS en la nube, 140 servidores RHEL, el 99% de los cuales son virtuales (vSphere), hardware SuperMicro, almacenamiento en red NexentaStore, un conjunto de conmutadores Cisco, Arista y Cumulus y gestión unificada de amenazas Fortinet UTM. herramientas en cada sitio.
La red federal significa que debo utilizar todas las medidas de seguridad de la información previstas por la ley. Debes tener en cuenta que Puppet Enterprise no es compatible con la mayoría del hardware que utilizamos. Nos vemos obligados a utilizar hardware presupuestario porque las agencias gubernamentales tienen problemas para financiar este gasto. Por eso compramos hardware 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 la siguiente.
En 2007, teníamos una pequeña red de 20 a 25 nodos, en la que implementamos Puppet. Básicamente, estos nodos eran simplemente “cajas” de RedHat. En 2010, comenzamos a utilizar la interfaz web de Puppet Dashboard para 45 nodos. A medida que la red continuó expandiéndose, pasamos a PE 2014 en 3.3, realizando una transición completa con una 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 finalizó el soporte para la versión 3 de Puppet Enterprise, nos vimos obligados a migrar a PE 2015.2. Tuvimos que reescribir el manifiesto nuevamente para los nuevos servidores y comprar una licencia con una reserva de 100 nodos, aunque en ese momento solo teníamos 85 nodos.
Solo han pasado 2 años y nuevamente tuvimos que trabajar mucho para migrar a la nueva versión PE 2016.4. Compramos una licencia para 300 nodos, cuando solo teníamos 130. Nuevamente tuvimos que hacer cambios importantes en el manifiesto porque la nueva versión del lenguaje tenía una sintaxis diferente a la de la versión 2015. Como resultado, nuestro SCM cambió del control de versiones SVN a Bitbucket (Git). Esta era nuestra “relación” con Puppet.
Entonces, tuve que explicarle a la gerencia por qué necesitábamos pasar a un SCM diferente usando los siguientes argumentos. El primero es el elevado precio del servicio. Hablé con los chicos de RedHat y me dijeron que el costo de ejecutar una red de 300 nodos con Ansible Tower es la mitad del costo de Puppet Enterprise. Si también compra Ansible Engine, el costo será aproximadamente el mismo, pero obtendrá muchas más funciones que PE. Dado que somos una empresa estatal financiada con cargo al presupuesto federal, este es un argumento bastante poderoso.
El segundo argumento es la versatilidad. Puppet solo admite hardware que tenga un agente Puppet. Esto significa que se debe instalar un agente en todos los conmutadores y debe ser la última versión. Y si algunos de sus conmutadores admiten una versión y otros admiten otra, 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 ningún agente, pero sí tiene 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 controladores de almacenamiento en red NexentaStore basados en el kernel 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 uso. Pasé 10 años dominando los módulos de Puppet y el código de manifiesto, pero aprendí Ansible en una semana porque es mucho más fácil trabajar con este SCM. Si ejecuta archivos ejecutables, por supuesto, a menos que lo haga innecesariamente, entonces los controladores inteligentes y receptivos trabajarán con ellos. Los manuales basados en YAML son fáciles de aprender y rápidos de usar. Aquellos que nunca antes hayan oído hablar de YAML pueden simplemente leer los scripts y comprender fácilmente cómo funciona.
Para ser honesto, Puppet hace que tu trabajo como desarrollador sea mucho más difícil porque se basa en el uso de Puppet Master. Es la única máquina a la que se le permite comunicarse con los agentes Puppet. Si ha realizado algún cambio en el manifiesto y desea probar su código, debe reescribir el código para Puppet Master, es decir, configurar el archivo Puppet Master /etc/hosts para conectar todos los clientes e iniciar el servicio Puppet Server. Sólo después de esto podrá probar el funcionamiento del equipo de red en un host. Este es un procedimiento bastante doloroso.
Todo es mucho más sencillo en Ansible. Todo lo que necesita hacer es desarrollar código para una máquina que pueda comunicarse vía SSH con el host bajo prueba. Es mucho más fácil trabajar con esto.
La siguiente gran ventaja de Ansible Tower es la capacidad de aprovechar su sistema de soporte existente y mantener su configuración de hardware existente. Este SCM utiliza toda la información disponible sobre su infraestructura y hardware, máquinas virtuales, servidores, etc. sin ningún paso adicional. Puede comunicarse con sus servidores RH Satellite, si tiene uno, y le brinda integraciones que nunca obtendrá 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 de todas tus máquinas en un manifiesto largo. En este caso, el estado de cada elemento individual del sistema debe comprobarse cada media hora; este es el período predeterminado. Así funciona Puppet.
Tower te salva de eso. Puede ejecutar una variedad de procesos en una variedad de equipos sin restricciones; puede realizar trabajos básicos, ejecutar otros procesos importantes, configurar un sistema de seguridad y trabajar con bases de datos. Puedes hacer todo lo difícil en Puppet Enterprise. Por lo tanto, si lo configuró en un host, los cambios tardarán un tiempo en surtir efecto en los hosts restantes. En Ansible, todos los cambios entran en vigor al mismo tiempo.
Finalmente, veamos el módulo de seguridad. Ansible Tower lo implementa de manera sencilla y sorprendente, con gran precisión y cuidado. Puede otorgar 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, limitando su acceso al shell de Linux. Me aseguro de que tengan acceso a Tower para que solo puedan hacer el trabajo y ejecutar únicamente los servicios que sean relevantes para ellos.
Veamos las cosas que debe hacer con anticipación para facilitar su transición a Ansible Tower. En primer lugar, debes preparar tu equipo. Si algunos elementos de su infraestructura aún no están en la base de datos, deberá agregarlos allí. Hay sistemas que no cambian sus características y por tanto no están en la base de datos de Puppet, pero si no los añades allí antes de pasar a Tower, perderás 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 un script de hardware dinámico que automáticamente enviará todos los cambios de infraestructura a la base de datos, luego Ansible sabrá qué hosts deben estar presentes en el nuevo sistema. No necesitará decirle a este SCM qué hosts agregó y cuáles ya no existen, porque sabrá todo esto automáticamente. Cuantos más datos 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 de una base de datos.
Dedique algún tiempo a familiarizarse con la línea de comando en Ansible. Ejecute algunos comandos personalizados para probar el script de hardware, escriba y ejecute algunos scripts de manual simples pero útiles, use plantillas Jinja2 cuando corresponda. Intente escribir una función y un script para un proceso complejo de varios pasos utilizando una configuración de hardware común y común. Juega con estas cosas, prueba cómo funciona. De esta manera aprenderá a utilizar las herramientas de creación de bibliotecas que se utilizan en Tower. Ya he dicho que me llevó unos 3 meses prepararme para la transición. Creo que, según mi experiencia, podrás hacer esto más rápido. No consideres este tiempo perdido, porque más adelante experimentarás todos los beneficios del trabajo realizado.
A continuación, debe decidir qué espera de Ansible Tower, qué debería hacer exactamente este sistema por usted.
¿Necesita implementar el sistema en hardware básico, en máquinas virtuales básicas? ¿O desea mantener las condiciones de funcionamiento y la configuración originales del equipo existente? Este es un aspecto muy importante para las empresas públicas, por lo que debe asegurarse de poder migrar e implementar Ansible en su configuración existente. Identifique los procesos administrativos de rutina que desea automatizar. Descubra si necesita implementar aplicaciones y servicios específicos en el nuevo sistema. Haz una lista de lo que quieres hacer y priorízalo.
Luego comience a escribir código de script y roles que permitan las tareas que planea completar. Combínalos en Proyectos, una colección lógica de guías relevantes. Cada proyecto pertenecerá a un repositorio Git separado o a un repositorio diferente según el administrador de código que utilice. Puede administrar los scripts y los directorios del libro de estrategias colocándolos manualmente en la ruta base del proyecto en el servidor Tower, o colocando el libro de estrategias en cualquier sistema de administración de código fuente (SCM) compatible con Tower, incluidos Git, Subversion, Mercurial y Red Hat. Perspectivas. Dentro de un Proyecto puedes colocar tantos scripts como quieras. Por ejemplo, creé un proyecto básico en el que coloqué un script para los elementos centrales de RedHat, un script para el núcleo de Linux y scripts para el resto de las líneas base. Por lo tanto, en un proyecto había una variedad de roles y escenarios que se administraban desde un repositorio Git.
Ejecutar todas estas cosas a través de la línea de comando es una buena manera de probar su funcionalidad. Esto lo preparará para la instalación de la Torre.
Hablemos un poco sobre la transcodificación del manifiesto Puppet, porque dediqué mucho tiempo a esto hasta que descubrí lo que realmente había que hacer.
Como dije antes, Puppet almacena todas las configuraciones y opciones de hardware en un manifiesto largo, y este manifiesto almacena todo lo que este SCM debería hacer. Al realizar la transición, no es necesario agrupar todas las tareas en una lista; en su lugar, piense en la estructura del nuevo sistema: roles, scripts, etiquetas, grupos y lo que debería ir allí. Algunos de los elementos de la red autónoma deben agruparse en grupos para los cuales se puedan crear scripts. Los elementos de infraestructura más complejos que involucran una gran cantidad de recursos, incluidas clases autónomas, se pueden combinar en roles. Antes de migrar, debes decidir esto. Si está creando roles o escenarios grandes que no caben en una pantalla, debe usar etiquetas para poder capturar partes específicas de la infraestructura.
18:00
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible 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 aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com