Nos topamos con una discusión interesante y nos dividimos en dos bandos. Estoy interesado en cualquier problema particular con alguna idea o trampa que podamos estar pasando por alto. Realmente, cualquier cosa que pueda ayudarnos a tomar una decisión o señalar cosas que no estamos teniendo en cuenta. Sé que esto elude un poco la regla de "no opinión", pero espero que siga siendo una pregunta aceptable. Perdón por la extensión también, hay bastantes matices.
1) Un lado (el mío, no soy imparcial) considera que el modelo de servidor inmutable es muy interesante para los sistemas en la nube. Con ese fin, creamos un prototipo para trasladar todos los componentes de nuestra infraestructura a Docker. Nuestras aplicaciones personalizadas se crean a través de Jenkins directamente en imágenes de Docker que se implementan en un Registro de Docker local. Luego creamos un gran conjunto de roles de Ansible y un manual que es capaz de llegar a un servidor vacío, instalar Docker y luego decirle a Docker que instale todos los contenedores según sea necesario. Después de un par de minutos, toda la aplicación y toda su infraestructura de soporte están conectadas y funcionando: registro, monitoreo, creación/relleno de bases de datos, etc. La máquina terminada es un entorno de desarrollo o control de calidad autónomo con una copia exacta del solicitud. Nuestro plan para escalar esto sería crear nuevos Playbooks para construir nuevos servidores AWS a partir de una AMI básica confiable (probablemente una imagen muy simple), realizar implementaciones continuas de la aplicación de producción para manejar la administración de la configuración y los lanzamientos y, en general, nunca volver a editar servidores. simplemente hazlos de nuevo. No me preocupa que lo que describí funcione en la práctica, solo si es un modelo razonable.
2) El otro campo quiere usar Puppet para manejar la gestión de la configuración, Ansible para implementar nuestras aplicaciones personalizadas que son archivos comprimidos generados a partir de nuestro proceso de compilación, Foreman para manejar la activación y gestión del proceso en su conjunto y Katello para hacer una cierta cantidad de base. gestión de imágenes. Los lanzamientos implicarían que Puppet cambie la configuración según sea necesario y que Ansible implemente componentes actualizados con cierta coordinación de Foreman. Los servidores se construirían razonablemente rápido si necesitáramos otros nuevos, pero la intención no es hacerlos desechables como parte del proceso estándar. Esto se acerca más al modelo de servidor Phoenix, aunque tiene una larga vida útil.
Entonces, mi pregunta realmente se reduce a esto: ¿el modelo de servidor inmutable con las herramientas como las describí anteriormente es realmente tan realista como parece? Me encanta la idea de que nuestro proceso de preparación pueda consistir literalmente en crear un clon completo de las aplicaciones en vivo, dejar que el control de calidad lo marque y luego simplemente cambiar el almacenamiento de la base de datos y algunas configuraciones de DNS para ponerlo en marcha.
¿O el modelo de servidor inmutable falla en la práctica? Tenemos mucha experiencia tanto con AWS como con entornos de nube, por lo que esa no es realmente la preocupación, sino más bien una cuestión de cómo implementar una aplicación razonablemente sofisticada de manera confiable en el futuro. Esto es de particular interés ya que publicamos con bastante frecuencia.
Tenemos a Ansible haciendo la mayoría de las cosas necesarias excepto crear servidores EC2 para nosotros y eso no es difícil. Me cuesta entender por qué NECESITAS Puppet/Foreman/Katello en este modelo. Docker es mucho más limpio y simple que los scripts de implementación personalizados en cualquier herramienta que yo sepa. Ansible parece mucho más sencillo de usar que Puppet cuando dejas de preocuparte por tener que configurarlos in situ y simplemente vuelves a construirlos con la nueva configuración. Soy fanático del principio de KISS, particularmente en la automatización, donde la Ley de Murphy está muy extendida. Cuanta menos maquinaria, mejor en mi opinión.
¡Cualquier idea/comentario o sugerencia sobre el enfoque será muy apreciado!
Respuesta1
En nuestra empresa hemos implementado con éxito Puppet en la infraestructura heredada del cliente. También utilizamos contenedores Docker para ejecutar un servicio dedicado (que en realidad es una aplicación antigua recortada y adaptada para caber en contenedores).
No estaba contento con los contenedores la primera vez que comencé a trabajar con ellos (sí... la aplicación de 30 kb se convierte en una imagen pesada de 200 MB), pero cuando tuve que recrear todo el entorno después de un pequeño desastre, cambié de opinión. Creo que Docker se inventó exactamente para esto: implementaciones rápidas y frecuentes sin preocuparse por la configuración del servidor. Si diseña los contenedores correctamente, puede cambiar fácilmente entre proveedores de nube, computadoras portátiles para desarrolladores y centros de datos de colocación. Porque todo lo que necesitas es una caja Linux básica con el demonio Docker.
- En el escenario 1) tienes todo en un solo lugar (me refiero a uno porque con Docker tendrás el código Y la configuración en el mismo repositorio) fácil de administrar, leer e implementar.
- En el escenario 2), debe almacenar partes de configuración para 3 herramientas diferentes (!) en un repositorio y el código de la aplicación en el otro, lo que complica las cosas.
También estaba usando Puppet en mi proyecto anterior y mi experiencia hasta ahora es que el servidor inmutable se puede lograr con Docker en lugar de Puppet o Chef. Creo que las herramientas de gestión de configuración son más útiles para los proveedores de la nube que para el equipo de desarrollo.
Respuesta2
Aquí están mis 2 céntimos de euro.
Las 2 opciones que propones son opciones válidas para lograr (algún tipo de) inmutabilidad.
Creo que deberías elegir el que te resulte más cómodo.
Sin embargo, por lo que escribes parece que todavía no hay consenso.
¿Quizás entonces sea necesaria una tercera opción? ;)
Sin embargo, como tal, la inmutabilidad no es un objetivo sino un medio para garantizar otras propiedades (sin deriva de configuración, mejor estabilidad, ...).
Establecería claramente mis objetivos, pondría algunas métricas para validarlos y haría algunas pruebas usando las 2 opciones. Luego tendrás algunas cifras para seleccionar la que esté más alineada con tu negocio.
¡Buena suerte!