¿Las herramientas de administración de configuración son apropiadas para usar como herramientas de implementación?

10

Detrás de mi respuesta a la pregunta: ¿Cómo puede ayudar DevOps a mejorar los procedimientos de depósito de garantía de software? Tensibai tenía la pregunta:

¿Qué necesitaría Capistrano sobre una marioneta o un chef?

Mi respuesta fue publicar un enlace al artículo de Noah Gibbs "¿Necesitamos tanto a Capistrano como a Chef?" . Personalmente, todavía me suscribo a la opinión de Noah de que es más apropiado:

  • use una herramienta de implementación especializada como Capistrano para las implementaciones.
  • use una herramienta de administración de configuración especializada como Chef para la administración de la configuración.

El enfoque fundamental que utiliza cada tipo de herramienta para completar su tarea es muy diferente:

  • Las herramientas de administración de configuración : se trata de crear y mantener el estado deseado de un sistema, son inherentemente idempotentes por naturaleza. Ejemplos de herramientas de administración de configuración son Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

  • Herramientas de implementación : se trata de entregar versiones de software en un entorno de alojamiento, proporcionan funcionalidad para mantener múltiples versiones del software en varias máquinas y administrar qué versión es "actual", son de naturaleza inherentemente imperativa. Ejemplos de herramientas de implementación son Capistrano , Octopus Deploy , Deployer y Command.io .

Creo que las herramientas de administración de configuración pueden hacer el trabajo de las herramientas de implementación y, en el caso de la infraestructura inmutable , son la herramienta más adecuada para el trabajo, ya que no es necesario mantener las versiones de software en el destino.

Pregunta: ¿Han madurado las herramientas de gestión de configuración como Chef, Ansible y Puppet hasta el punto de que son capaces de cumplir tanto los modelos idempotentes como los imperativos?

Richard Slater
fuente
Ansible siempre pudo, Puppet since 4.0
Jiri Klouda
1
Richard, gracias por todas las preguntas de alta calidad que has estado enviando últimamente. Realmente aprecio el arduo trabajo que dedicaste a rellenar previamente el sitio durante la versión beta. Hacer buenas preguntas principales es difícil y eres muy bueno en lo que haces.
Jiri Klouda
@JiriKlouda eres más que bienvenido, literalmente tengo un "DevOps SE" post-it ™ en mi computadora para recordarme que publique las preguntas cuando se me ocurran.
Richard Slater

Respuestas:

10

En ese contexto, el consejo típico debería ser inmediatamente aplicable: use la herramienta adecuada para el trabajo.

Pero tampoco puede ignorar hoy en día la tendencia casi virulenta de las herramientas de software de extender la funcionalidad a campos más o menos relacionados y convertirse en conjuntos de herramientas por varias razones: características interesantes para tener, ampliar la base de clientes, acumular más ingresos, etc.

Por ejemplo, muchas herramientas de administración de archivos incluyen funciones de visualización de imágenes y muchas herramientas de procesamiento de imágenes incluyen funciones de administración de archivos. Puede mover archivos y puede ver imágenes con cualquiera de las herramientas, a menudo igualmente bien.

Debido a esto, es bastante posible tener porciones enteras del proceso de desarrollo de software cubiertas / superpuestas por múltiples herramientas (conjuntos) incluso si sus características / capacidades principales difieren.

Por lo tanto, realmente se reduce a la funcionalidad exacta que desea lograr en su proceso particular y qué tan bien una herramienta u otra hace el trabajo en su contexto . Subjetividad / preferencias / conveniencia incluidas.

Hacer esta pregunta principalmente basada en la opinión;)

Dan Cornilescu
fuente
¡Estoy completamente de acuerdo! Cada vez más organizaciones están desarrollando "DevOps toolchain" específicamente con estas herramientas adecuadas para la idea de trabajo. Para obtener más información, esta página wiki hace un trabajo decente al hablar sobre las diferentes herramientas / trabajos: en.wikipedia.org/wiki/DevOps_toolchain
Karl Harnagy
Solo agregaría que cuanto más extienda el uso de una herramienta más allá de su propósito principal, más esfuerzo tomará para hacerlo. Es posible que pueda usar cierta herramienta tanto para la implementación como para la configuración, pero hay una buena posibilidad de que sea más trabajo (o requiera mejores prácticas) que solo usar dos herramientas.
jschmitter
6

Las herramientas de gestión de configuración se utilizan para llevar un sistema a un estado conocido. Las herramientas de implementación implementan nuevos archivos de programa y datos de programa en un sistema. Al final del día, ambos tipos de herramientas combinan:

  • Determinar el estado actual del sistema.
  • Transfiere archivos al sistema.
  • Agregar o cambiar datos persistentes (por ejemplo, archivos de configuración, datos de bases de datos, configuraciones de registro)
  • Iniciar o reiniciar programas.

Las herramientas de administración de configuración tienen lenguajes declarativos que especifican el estado del sistema. Las herramientas de implementación tienen lenguajes imperativos que le indican al sistema que haga cosas. Una persona DevOps necesita hacer ambas cosas.

Usando la herramienta de implementación Capistrano, es torpe usar su lenguaje para decirle al sistema que se asegure de que el servidor web esté activo. Debe emitir un comando para reiniciar el servidor web y otro para verificar si el servidor web está activo. Es un error llevar el servidor web a un estado conocido.

Usando la herramienta de administración de configuración Ansible, es torpe reiniciar un servidor web. El idioma le permite decirle al servidor web que esté "activo", pero si desea específicamente que se reinicie, debe establecer su estado en "reiniciado". Pero no hay una manera fácil de verificar si el servidor web se ha reiniciado. Esto es un error en Ansible para habilitar operaciones únicas.

Algunas personas prefieren hacer ambos tipos de trabajos con una herramienta y trabajar en los bordes ásperos. Otras personas prefieren tener dos herramientas para hacer casi lo mismo, pero sin bordes ásperos. Para responder a la pregunta, "lo apropiado" es una cuestión de gustos. Esta respuesta explica por qué.

Jay Godse
fuente
Estoy de acuerdo en que Capistrano sea un poco incómodo para este caso. Por lo general, se utiliza como espacio de nombres para scripts / fragmentos / lambda de ruby ​​ejecutados remotamente sobre ssh. Su sección sobre Ansible no es correcta. Es posible que desee investigar un poco y solucionarlo. Buena primera publicación, pero por favor trabaje un poco más.
Jiri Klouda
@JiriKlouda, ¿qué tiene de malo la sección Ansible? ¿Te refieres a la sección no easy way to check if the web server has been restarteden la que podría verificarse registrando una variable?
David Vasandani
Hay varias formas de hacerlo, el autor de la respuesta simplemente no las conoce. Siéntase libre de convertirlo en una pregunta separada ya que los comentarios no son un buen lugar para respuestas técnicas.
Jiri Klouda
4

TL; DR : solo use Ansbile, es tanto una herramienta de configuración como de implementación :)

Existen varios tipos de implementación:

  • Basado en aplicaciones (archivos, paquetes de archivos)

  • Basado en contenedor (incluye máquinas virtuales, Hábitat, LXC, Docker)

  • Basada en funciones (Micro servicios / Lambdas / Funciones)

Supongo que en este caso solo hablamos de actualizaciones de aplicaciones en servidores.


Para la implementación, debe hacer que sucedan dos cosas:

  1. Los archivos o paquetes correctos deben moverse al servidor.
  2. La configuración y los estados de servicio deben cambiar.

Ahora para (1) puede usar múltiples estrategias:

  • Repositorios de artefactos / Sincronización
  • Repositorios de paquetes / Gerentes de paquetes
  • Sistema de control de versiones / Actualización + Compilación (opcionalmente)
  • Protocolos de transferencia de archivos (scp, rsync, ftp)
  • Herramientas de implementación

Para el (2) puede usar:

  • Herramientas de gestión de la configuración
  • Herramientas de implementación

Entonces, si bien las Herramientas de implementación son una forma de implementar todo en uno, no siempre son la mejor estrategia. A veces desea utilizar la combinación de estas formas para la implementación. Lo más probable es que ya use administradores de paquetes al menos en sus servidores. Lo más probable es que ejecute herramientas de configuración de todos modos. El problema con algunas de las herramientas de configuración era una orquestación adecuada entre varios servidores, pero ahora incluso Chef y Puppet pueden hacerlo bastante bien. Ansible siempre ha sido bueno en esto.

Por experiencia personal , he usado todas las combinaciones, pero actualmente usamos Capistrano para la implementación y sincronización Ansible para la administración de la configuración, y VCS y repositorios de paquetes para transferencias de archivos, pero hay problemas con Capistrano y estamos planeando alejarnos de él para Unify en Ansible para la implementación, el mantenimiento y la gestión de la configuración.

Jiri Klouda
fuente
2
Mi experiencia con Ansible y Capistrano me llevaría a la misma conclusión. Solo iría con Ansible. Y lo bueno de Ansible es que sus declaraciones de "estado deseado" se asignan muy bien a los comandos imperativos subyacentes.
Jay Godse
1
Las personas a veces ignoran las contribuciones de la comunidad en torno a las herramientas de gestión de configuración. Los componentes de la comunidad de Ansible, con algunas excepciones notables (como DebOps), aún no están tan pulidos y completos como los de Chef y Puppet. Como medida de esto, si bien descubrí que Puppet y Chef pueden "aplicar" y no aplicar directivas de configuración (hacer o deshacer un conjunto de cambios), Ansible es excelente en la parte "aplicar", pero no es tan bueno en " no aplicar "parte.
Jesse Adelman
3

La implementación de aplicaciones es difícil de precisar porque tiene muchos subproblemas. Los sistemas de gestión de configuración son excelentes para modelar tareas que son convergentes y funcionan con "cuál es el estado deseado del sistema". En el contexto de la implementación de aplicaciones, esto es ideal para cosas como implementar bits en una máquina, administrar archivos de configuración y configurar servicios del sistema. Lo que es extremadamente malo son las cosas que son inherentemente procesales, en particular las migraciones de bases de datos y los reinicios del servicio. Por lo general, trato de poner la lógica convergente en Chef y dejo que una herramienta de procedimiento externa (generalmente Fabric en mi caso) maneje los pocos bits restantes, así como la secuencia de los convergentes reales.

Entonces, básicamente, debes usar ambos para las piezas en las que son mejores.

coderanger
fuente
3

Para el software y el código de implementación en un servidor existente o dentro de un contenedor Docker, la respuesta es relativamente simple: no, no necesita ambos, pero puede querer ambos si otra herramienta o utilidad agrega valor y es la herramienta adecuada para el trabajo , sin embargo, las cosas se vuelven más complicadas cuando implementa servidores y sistemas operativos.

Un valor agregado de una mentalidad de DevOps es tratar la infraestructura como código y, con frecuencia, implementar o destruir máquinas virtuales o incluso metal desnudo en un entorno altamente elástico. Su sistema de administración de la configuración no puede arrancar y arrancar fácilmente su servidor por usted y no puede administrar repositorios, paquetes y actualizaciones / parches por usted durante y después de las implementaciones o, en algunos casos, licencias y derechos.

Para los servicios web de Amazon, esto es convenientemente manejable por las API en su mayor parte, pero para aquellos de nosotros que tenemos que administrar nuestros propios centros de datos, esta no es una opción. Por esta razón, el proyecto Foreman (y Red Hat, que lo renombra ) ha encontrado necesario agrupar a Katello , Candlepin y un administrador de configuración como Ansible, Foreman o Puppet al implementar el Escenario de Katello .

Entonces, si bien puede salirse con la suya utilizando herramientas de administración de configuración para implementaciones de código de software en el lado Dev de la casa, en el lado Ops, hay varios casos en los que la respuesta es un rotundo "no, las herramientas de administración de configuración no son apropiado para usar como herramientas de despliegue "Hacerlo requeriría una reinvención seria de la rueda y no es práctico. En su lugar, debe usar sus herramientas de administración de configuración para iniciar implementaciones en otra herramienta.

James Shewey
fuente
O no, el chef maneja con gracia Capistrano como despliegues, los paquetes de chocolate se implementan bajo Windows y todas las instalaciones de paquetes bien conocidos (deb, rpm, msi, nullsoft, etc.). Trae algo de carga en el lado del empaque, que el hábitat tiene como objetivo resolver, pero ese es un sistema de gestión de configuración bastante capaz de manejar implementaciones, puedo decirlo al ver que realiza aproximadamente 40 implementaciones por semana en entornos múltiples, incluida la producción, eso no está exento una gran carga de antemano para codificarlo, pero eso no está muy por encima de lo mismo con cualquier otra herramienta ateotd.
Tensibai
1
En realidad, The Foreman no es un sistema de gestión de aprovisionamiento, implementación o configuración. Es solo una máscara que proporciona una interfaz de usuario y un marco basados ​​en la web que unen un sistema de gestión de configuración (títere), un sistema de gestión de licencias (Candlepin), un sistema de gestión de repositorios y parches (Katello) y un sistema de aprovisionamiento / implementación (kickstart). Pone en primer plano todos estos proyectos diferentes y los une. Si bien casi cualquier sistema de administración de configuración puede instalar un paquete, lo que no pueden hacer es proporcionar administración de parches de manera similar a un servidor WSUS
James Shewey
o anclar o implementar versiones específicas de paquetes, incluir paquetes que no están en repositorios ascendentes o repositorios mashup. Mi punto es que si Red Hat / The Foreman / Katello sintiera que no se podría hacer solo con un sistema de administración de configuración, especialmente porque carecía de la pieza de aprovisionamiento / implementación que vale la pena señalar.
James Shewey
Leí mal la frase sobre katello, mi mal. El primer comentario fue en aras de la integridad :)
Tensibai