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?
fuente
Respuestas:
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;)
fuente
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:
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é.
fuente
no easy way to check if the web server has been restarteden la que podría verificarse registrando una variable?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:
Ahora para (1) puede usar múltiples estrategias:
Para el (2) puede usar:
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.
fuente
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.
fuente
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.
fuente