Ansible vs títere

Ansible y Puppet son los sistemas de gestión de configuración (SCM) necesarios para construir infraestructuras repetitivas.

Ansible es fácil de usar, tiene una arquitectura sin agente (no requiere la instalación de un agente / cliente en el sistema de destino) y un DSL similar a YAML, escrito en Python y expandido fácilmente por módulos. Por lo general, administra configuraciones de Linux.

Puppet tiene una arquitectura cliente-servidor (sondea periódicamente el servidor para realizar cambios en la configuración realizada por el administrador de la red), está escrito en Ruby y tiene un DSL similar a Ruby. Esta aplicación le permite administrar de forma centralizada la configuración del software instalado en varias computadoras.

El artículo compara las ventajas y desventajas de estos SCM.



En comparación con los años 90, hoy en día los administradores y desarrolladores de sistemas tienen que administrar un número significativamente mayor de servidores que alojan muchas más aplicaciones. La razón de esto es el crecimiento exponencial de la informática para organizaciones y empresas asociadas con el advenimiento de nuevas tecnologías como la virtualización y la computación en la nube.

Por lo tanto, herramientas como Puppet y Ansible se convierten rápidamente en componentes necesarios para administrar una gran cantidad de servidores, por ejemplo, en centros de datos. Se llaman Herramientas de administración de configuración (CM) y Ejecución remota (RE) y a menudo se usan con herramientas de actualización de software. Estas aplicaciones útiles permiten, por ejemplo, que un administrador de red realice acciones en varios servidores al mismo tiempo, implemente varias aplicaciones con un solo clic, lo que simplifica enormemente la configuración y el mantenimiento de decenas, cientos o incluso miles de servidores.

Ansible vs. Puppet: una breve reseña


Puppet es una de las marcas más famosas en el mercado de CM. Existe desde 2005, lo que para las herramientas CM es equivalente a la existencia desde el inicio de la humanidad. Muchos grandes nombres como Google, Reddit, Dell, PayPal, Oracle, Los Alamos Labs y la Universidad de Stanford administran sus centros de datos con Puppet. Tener tales clientes a bordo siempre le da al producto un cierto nivel de confianza. Puppet también cuenta con la interfaz más madura y funciona en todos los principales sistemas operativos: Linux, Windows, Unix e incluso Mac OS X. Siguiendo el modelo creado por varias versiones de Linux, esta aplicación de código abierto se desarrolla en Ruby. Sin embargo, existe una compañía sólida y bien establecida de apoyo y patrocinio de PuppetLabs,ofreciendo soporte profesional y una versión comercial comercial del software.

Puppet también ofrece un procedimiento de instalación simple y varias herramientas para tareas como la implementación rápida en los servidores del cliente. Además de la GUI, hay una CLI basada en Ruby. De hecho, para las tareas más avanzadas, lo más probable es que tenga que depender de la CLI, y la GUI es la interfaz para ver, administrar y monitorear. Esto significa que, además de trabajar como administrador del sistema, deberá aprender Ruby.



Puede pensar: “¡Todo suena genial! ¿Hay algún inconveniente o vale la pena comprar Puppet ahora mismo? ”. El debate sobre el uso de este SCM en foros CM especializados es que Puppet, como muchos otros gigantes de software, ha sido víctima de su propio éxito y tamaño. "Nimble" y "ágil" no son palabras que pueden usarse para describir el trabajo de Puppet. Los usuarios informan de errores que tardan demasiado en solucionarse e ignoran nuevas solicitudes. También hay cierta insatisfacción con el hecho de que PuppetLabs está presionando persistentemente a sus clientes para que acepten la versión comercial. Finalmente, aunque Puppet admite Ruby puro y su DSL configurado en la CLI, el soporte para Ruby solo está en desuso. Estas son malas noticias para aquellos que solo estudiaron Ruby, no DSL.

Ansible omitió Puppet, capturando la mayor participación de mercado en la industria de gestión de configuración: 26.5%. Le siguen Microsoft System Center CM (21.8%) y Puppet (12%).



También es un producto de código abierto que se lanzó en 2012 y desde entonces ha sido respaldado por AnsibleWorks. Fue desarrollado en Python en lugar de Ruby, lo que lo hace espiritualmente más cerca de Salt (otra nueva herramienta CM) que Puppet. Otra ventaja de Python es que está integrado en la mayoría de las aplicaciones de Unix y Linux, por lo que SCM escrito en este lenguaje se instala y funciona más rápido.

La estratagema de marketing única de Ansible radica en su implementación fácil y rápida. De hecho, este sistema ni siquiera utiliza agentes desplegados para comunicarse con el cliente maestro; en cambio, todas las funciones se realizan a través de SSH. Para aquellas configuraciones que no admiten SSH raíz, Ansible puede ejecutar "sudo" como root. Ansible se puede iniciar desde la CLI sin usar archivos de configuración para tareas simples, como verificar el funcionamiento del servicio o iniciar actualizaciones y reinicios. Para tareas más complejas, la configuración Ansible se maneja utilizando la sintaxis YAML en los archivos de configuración llamados "libros de jugadas". Los comandos de Ansible pueden escribirse en casi cualquier lenguaje de programación y distribuirse como módulos JSON universales, lo cual es claramente una ventaja sobre la elección de un lenguaje específico.

Ansible se ha vuelto más popular con un nuevo enfoque para las tareas de configuración tradicionales, y muchas compañías lo usan para implementar grandes centros de datos.

La comunidad de entusiastas de Ansible está trabajando arduamente para aprovechar su éxito aumentando la cantidad de dispositivos compatibles, integrando un mejor soporte de Windows, mejorando el ecosistema, etc.

Ansible vs. Puppet: diferencia de instalación


Las diferencias entre Ansible o Puppet se hacen evidentes desde el momento en que se instalan los sistemas. Dado que siguen diferentes paradigmas arquitectónicos, su configuración es significativamente diferente. Entonces, Ansible tiene el objetivo explícito de hacer que el proceso de configuración sea lo más simple posible, lo que se refleja en la experiencia del usuario.



Para configurar Ansible, primero debe designar un nodo como nodo de control. De hecho, cualquiera de sus nodos puede ser un nodo de gestión. Puede instalar Ansible en este nodo utilizando el último paquete Ansible de los repositorios de paquetes de su distribución, sin necesidad de configurar el software del cliente en otros nodos. Simplemente cree un par de claves SSH en su nodo de administración y luego cópielos a los otros nodos. Luego, cree un archivo de inventario para los nodos Ansible, generalmente en sistemas operativos Linux como Red Hat Linux, Ubuntu y Debian, esto sucede en / etc / ansible / hosts. Ahora está listo para usar Ansible para iniciar PlayBook tanto en su host como en el resto de la infraestructura de red.Ansible usará conexiones SSH con su nodo de control para activar la gestión de configuración basada en PlayBook.

La configuración de Puppet parece un poco más complicada, pero hay mucha documentación en Internet que ayudará en un caso difícil. Primero, deberá configurar los nodos maestro y agente para que tengan la misma hora y zona horaria. Luego debe ir al servidor maestro con privilegios de root e instalar el software del servidor Puppet. A continuación, debe configurar el archivo del asistente de Puppet / etc / hosts para conectar todos los clientes administrados, iniciar el servicio PuppetServer y ponerlo en modo "habilitar" para recibir conexiones del cliente en el puerto 8140. Dado que Puppet se basa en el software del cliente, deberá instalar los agentes del software Puppet en cada uno de ellos

Además, deberá agregar la dirección IP del servidor maestro en / etc / hosts para que el cliente pueda conectarse a él. Para hacer esto, debe iniciar y habilitar el servicio del agente Puppet en cada cliente, y luego generar certificados SSL, ya que este sistema CM utiliza HTTPS para la comunicación del cliente maestro.

En ambos casos, será necesario fortalecer la seguridad del servidor para excluir la posibilidad de conexiones no autorizadas.

Ansible vs. Puppet: escalabilidad y mecanismo de transporte de configuración


Ambos SCM escalan bien, pero utilizan diferentes mecanismos de transporte de configuración para lograr esto. De hecho, independientemente de si necesita administrar varios cientos o decenas de miles de nodos, existen trucos y estrategias que puede usar en cada plataforma para escalar convenientemente al nivel deseado.



Ansible utiliza el mecanismo de transporte inteligente de forma predeterminada, que se basa en certificados SSH de confianza. Ansible primero analizará PlayBooks e identificará los elementos de infraestructura afectados. Luego abrirá una conexión SSH y creará un directorio temporal. Después de cerrar esta conexión, Ansible abre una segunda conexión para copiar el código del módulo Ansible y el código de la plantilla Ansible. Ansible cerrará esta conexión antes de abrir la tercera conexión final para ejecutar el código. Esta configuración servirá para la mayoría de los propósitos, pero se puede cambiar a medida que se escala la infraestructura.

La primera función que Ansible puede usar se llama ControlPersist, y se basa en sockets persistentes y persistentes para reducir el tiempo que lleva intercambiar apretones de manos que son necesarios para múltiples conexiones. Ansible también admite canalización, una configuración que reduce el número de conexiones requeridas de tres a uno. Finalmente, Ansible se puede configurar para manejar más nodos de inventario al mismo tiempo configurando la variable de horquillas en la configuración de este sistema. De forma predeterminada, este valor es 5, pero puede establecer un valor más alto para acelerar el procesamiento.



El mecanismo de transporte de Puppet es HTTPS, que se administra mediante certificados SSL. Un servidor Puppet maneja las solicitudes de configuración para una lista completa de clientes Puppet. Cada cliente envía hechos de Puppet al servidor maestro junto con una solicitud al directorio de Puppet, después de lo cual el servidor maestro envía este directorio en respuesta. Luego, el cliente procesa el directorio, verificando cada recurso de software con el estado de configuración requerido especificado en el directorio. Si el recurso no está en el estado deseado, el cliente Puppet actualizará el recurso en esta computadora y, una vez completada la actualización, enviará un informe sobre el cambio de configuración completado al servidor Puppet.



En particular, el modelo de procesamiento de Puppet asigna un subproceso JRuby del grupo de subprocesos para manejar cada conexión de cliente entrante. A medida que aumenta el número de nodos, el escalado de Puppet se puede optimizar aumentando el número de subprocesos JRuby disponibles en el grupo. Esto se puede hacer estableciendo el parámetro de configuración Puppet "max-active-instancia" más alto que el valor predeterminado, que es 1. Como regla general, se supone que este valor es igual al número de núcleos de procesador de su computadora, pero tenga en cuenta que esto requerirá más La memoria de la CPU utiliza RAM RAM. Como regla general, también deberá establecer un "tamaño de almacenamiento dinámico máximo" más alto para la JVM de su servidor Puppet para garantizarque sus subprocesos JRuby adicionales se pueden asignar sin un error de falta de memoria de Java. Se requiere precaución al realizar esta configuración, ya que esto puede provocar una pérdida de rendimiento.

Ejemplo de código de CM Ansible


Para el trabajo de configuración diario, escribir código Ansible es sorprendentemente simple debido a una combinación de dos factores: el uso del formato YAML para PlayBooks y el estilo declarativo de gestión de configuración que corta las "esquinas afiladas". Esto es importante para mejorar rápidamente el rendimiento de los comandos de DevOps y garantizar que su código sea manejable incluso para tareas de configuración complejas.

El código de respuesta es idempotente. Esto significa que puede ejecutar PlayBook de forma segura para los componentes del sistema una y otra vez sin dañar sus servidores. Ansible solo cambiará la configuración de los recursos de software en los servidores donde está fuera del estado deseado. Por ejemplo, si su PlayBook necesita instalar un paquete y crear un archivo de configuración específico en el disco, Ansible instalará solo ese paquete y creará el archivo de configuración que se especificó cuando PlayBook se lanzó por primera vez en el host. Los lanzamientos posteriores de PlayBook dejan automáticamente el paquete intacto hasta que haya algún cambio que elimine o modifique el archivo especificado o la configuración del paquete. Esto mantiene sus nodos en un estado predecible y determinista con muy poca o ninguna posibilidad de deriva de configuración.

El siguiente es un ejemplo de código Ansible PlayBook que instala el servidor web Tomcat en sus sitios. Este ejemplo está tomado del repositorio oficial de ejemplos de Ansible, que debe consultar para familiarizarse mejor con el estilo idiomático de Ansible:

---
- name: Install Java 1.7
yum: name=java-1.7.0-openjdk state=present

- name: add group "tomcat"
group: name=tomcat

- name: add user "tomcat"
user: name=tomcat group=tomcat home=/usr/share/tomcat createhome=no
become: True
become_method: sudo

- name: Download Tomcat
get_url: url=http://archive.apache.org/dist/tomcat/tomcat-7/v7.0.61/bin/apache-tomcat-7.0.61.tar.gz dest=/opt/apache-tomcat-7.0.61.tar.gz

- name: Extract archive
command: chdir=/usr/share /bin/tar xvf /opt/apache-tomcat-7.0.61.tar.gz -C /opt/ creates=/opt/apache-tomcat-7.0.61

- name: Symlink install directory
file: src=/opt/apache-tomcat-7.0.61 path=/usr/share/tomcat state=link

- name: Change ownership of Tomcat installation
file: path=/usr/share/tomcat/ owner=tomcat group=tomcat state=directory recurse=yes

- name: Configure Tomcat server
template: src=server.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Configure Tomcat users
template: src=tomcat-users.xml dest=/usr/share/tomcat/conf/
notify: restart tomcat

- name: Install Tomcat init script
copy: src=tomcat-initscript.sh dest=/etc/init.d/tomcat mode=0755

- name: Start Tomcat
service: name=tomcat state=started enabled=yes

- name: deploy iptables rules
template: src=iptables-save dest=/etc/sysconfig/iptables
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '6'"
notify: restart iptables

- name: insert firewalld rule for tomcat http port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: insert firewalld rule for tomcat https port
firewalld: port=/tcp permanent=true state=enabled immediate=yes
when: "ansible_os_family == 'RedHat' and ansible_distribution_major_version == '7'"

- name: wait for tomcat to start
wait_for: port=

Esta tarea específica de Ansible descarga e instala Apache Tomcat junto con el Java JDK 1.7 dependiente, y luego configura, inicia e instala Tomcat. Como puede ver en este ejemplo, los archivos controlados por Ansible pueden contener plantillas Jinja, lo que simplifica el cálculo de valores y hace que su configuración sea más flexible. El código YAML es fácil de leer y escribir tanto para los administradores del sistema como para los desarrolladores. Esto lleva al hecho de que Ansible se está convirtiendo en un sistema de gestión de configuración asequible para usuarios avanzados y novatos.

Ejemplo de código de marioneta CM


El lenguaje orientado a temas Puppet se basa en Ruby, pero su sintaxis está mucho más cerca de los imperativos lenguajes de estilo C como Perl, Java y C ++. Este enfoque es un intermediario entre los desarrolladores familiarizados con Ruby y aquellos que pueden no estar familiarizados con este lenguaje. Como resultado, es posible que no necesite conocer a Ruby para aprender y usar Puppet DSL productivamente.
Este es un ejemplo de un manifiesto de Puppet del repositorio PuppetLabs MySQL Puppet Module que instala y configura el paquete del cliente MySQL:

# @summary
#     Installs and configures the MySQL client.
#
# @example Install the MySQL client
#     class {'::mysql::client':
#         package_name => 'mysql-client',
#         package_ensure => 'present',
#         bindings_enable => true,
#     }
#
# @param bindings_enable
#     Whether to automatically install all bindings. Valid values are `true`, `false`. Default to `false`.
# @param install_options
#     Array of install options for managed package resources. You must pass the appropriate options for the package manager.
# @param package_ensure
#     Whether the MySQL package should be present, absent, or a specific version. Valid values are 'present', 'absent', or 'x.y.z'.
# @param package_manage
#     Whether to manage the MySQL client package. Defaults to `true`.
# @param package_name
#     The name of the MySQL client package to install.
#
class mysql::client (
    $bindings_enable = $mysql::params::bindings_enable,
    $install_options = undef,
    $package_ensure = $mysql::params::client_package_ensure,
    $package_manage = $mysql::params::client_package_manage,
    $package_name = $mysql::params::client_package_name,
)  inherits mysql::params {
    
    include '::mysql::client::install'

    if $bindings_enable {
        class { 'mysql::bindings':
            java_enable => true,
            perl_enable => true,
            php_enable => true,
            python_enable => true,
            ruby_enable => true,
        }
    }

# Anchor pattern workaround to avoid resources of mysql::client::install to
# "float off" outside mysql::client
anchor { 'mysql::client::start': }
-> Class['mysql::client::install']
-> anchor { 'mysql::client::end': }
}

Una ventaja importante de Puppet es que, a diferencia de los lenguajes de programación imperativos enumerados anteriormente, Puppet DSL es declarativo, de alguna manera similar a XML, así como el código YAML del ejemplo de código Ansible anterior. El enfoque declarativo de Puppet y Ansible se traza realmente en ambos ejemplos de código. En términos de codificación, son similares y más cercanos entre sí que herramientas como Chef. Sin embargo, el lenguaje declarativo Puppet también proporciona construcciones similares a Ruby, como expresiones e iteraciones condicionales, lo que nuevamente es un compromiso para los usuarios de Ruby y aquellos que no hablan el idioma.

Ansible vs. Puppet: facilidad de uso


Para el equipo de desarrollo, la facilidad de uso debería ser una parte importante de la evaluación de SCM. Dado que los desarrolladores de Ansible están centrando mucho esfuerzo en la facilidad de uso del sistema, no hay competidores en esto. La configuración, programación y gestión de los nodos proporciona una interfaz muy sencilla tanto para los ingenieros de desarrollo como para los administradores de sistemas.

Esto no significa que Puppet sea difícil de usar, es solo que este sistema se comporta con confianza mientras sigue el método propuesto de automatización de su infraestructura. En esta área, Puppet es bastante fuerte, modela explícitamente cada recurso y proporciona a los usuarios módulos con un comportamiento estándar que se utilizan de manera eficiente en sus manifiestos.

En términos de aprendizaje del usuario, ambas plataformas son fáciles de usar, pero Ansible tiene una ligera ventaja. Es fácil lograr un estilo YAML declarativo, por lo que el código Ansible nunca es demasiado complicado. Mientras tanto, Puppet ha llegado a reconocer algunos de los problemas asociados con la combinación de datos y código en los mismos archivos fuente. Esto llevó a la llegada de Puppet Hiera, una solución de almacenamiento que utiliza el formato YAML para almacenar pares de datos de configuración de clave-valor. Hiera contribuye en gran medida a simplificar y optimizar la experiencia de Puppet DevOps. El formato YAML ha demostrado ser bastante popular para la gestión de la configuración, y Salt de SaltStack también utiliza este formato.
Ambos SCM tienen la capacidad de validar y probar su CM, desde la verificación de sintaxis hasta la integración de infraestructura como código.

Ansible vs. Puppet: costos de licencia e implementación





Como herramientas de código abierto, Ansible y Puppet tienen mucho en común en sus políticas de licencia.

El lanzamiento de código abierto de Ansible es completamente gratuito. Se alienta a las empresas que necesitan más garantías de seguridad, estabilidad y confiabilidad a actualizar a Ansible Engine, el producto de clase empresarial que se incluye con Red Hat Linux. Los costos de la licencia de Ansible Engine generalmente varían de $ 47.50 a $ 70 por año por nodo y dependen de su configuración preferida.

Si necesita soporte técnico con solución rápida de problemas, debe usar la versión corporativa. La herramienta de administración de Ansible Tower para grandes empresas está disponible como un paquete de servicios y le brinda a su empresa más capacidades de capacitación, administración y programación de trabajos mediante un panel de control gráfico.

Al igual que Ansible, el lanzamiento de código abierto de Puppet está disponible de forma gratuita. Para funciones corporativas adicionales y soporte técnico, las organizaciones pueden actualizar a Puppet Enterprise, que cuesta de $ 112 a $ 199 por año por nodo. Puppet Enterprise ofrece un paquete de varias herramientas, que incluyen informes y monitoreo del estado de la infraestructura empresarial.

Ansible vs Puppet: Comunidad


Puppet, lanzado en 2005, es una herramienta antigua de DevOps, por lo que tuvo más tiempo para crear su propia comunidad y base de usuarios. Sin embargo, Ansible, lanzado en 2012, gracias a su nuevo enfoque, pudo atraer una audiencia aún mayor y crear una comunidad muy dinámica de entusiastas y usuarios de desarrolladores. Los usuarios de Puppet incluyen compañías como Uber, Salesforce y Paypal, mientras que la comunidad Ansible incluye compañías como Digital Ocean, 9GAG y TypeForm.

Si comparamos un indicador tan importante del desarrollo de productos de código abierto como el número de contribuyentes que participan en el desarrollo en GitHub, Ansible con más de 4,800 contribuyentes es muy superior a Puppet con sus 527 contribuyentes al desarrollo del producto. El desarrollo de Ansible en los últimos años ha sido tan rápido que ha generado la creación de un repositorio "galáctico" separado de Ansible Galaxy . Esto significa que la comunidad Ansible se esfuerza por compartir su código, contribuyendo así al desarrollo posterior del producto.

Mientras tanto, la comunidad Puppet, que se está desarrollando de manera más lenta y constante, ha creado una infraestructura para facilitar la búsqueda de soluciones para satisfacer sus necesidades de SCM. Puppet Forge proporciona módulos para tareas comunes de administración de configuración para la comunidad Puppet.

Ambos sistemas tienen herramientas de primera clase para monitorear el ciclo de vida de un proyecto de administración de configuración a través de la línea de comando. Tanto Puppet como Ansible se integran bien con otros sistemas DevOps ampliamente utilizados, como Docker, Kubernetes y Jenkins, y las plataformas de computación en la nube AWS y Azure.

Ansible vs Puppet: ¿cuál es mejor?


En este asunto, la elección es tuya. El estilo declarativo de Ansible y Puppet significa que estas herramientas tienen mucho más en común que otros sistemas de gestión de configuración. Sin embargo, para tomar la mejor decisión, debe prestar especial atención a cómo se combinan las necesidades de su equipo con el diseño y las ventajas de un SCM en particular.
Ansible es más adecuado para aquellos que están interesados ​​en la configuración de estilo YAML y comparten la filosofía de Ansible de ser lo más simple posible mientras administran un gran conjunto de máquinas de forma rápida y simultánea. Además, esta filosofía se centra en usar las funciones SSH existentes en lugar de crear agentes de usuario.

Puppet es más adecuado para equipos que prefieren DSL, que modela los recursos del sistema de manera consistente y repetitiva. Esto es exactamente lo que hace Puppet DSL, junto con todo un ecosistema de herramientas para hacer que los equipos grandes sean predecibles y fáciles.

Si sabe exactamente qué principios de administración de configuración se adaptan mejor a sus necesidades, elegir entre Puppet y Ansible no será un problema para usted.

recomendaciones


Para facilitar su elección, le sugerimos que se familiarice con las principales ventajas y desventajas de ambos sistemas.



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?

All Articles