Nos encontramos con un argumento interesante y estamos cayendo en dos campos. Estoy interesado en cualquier problema en particular con cualquiera de las ideas o problemas que podríamos estar perdiendo. Realmente, cualquier cosa que pueda ayudarnos a tomar una decisión o señalar cosas que no contamos. Sé que esto evita un poco la regla de "no opinión", pero espero que sea una pregunta aceptable. Lo siento por la longitud también, hay un poco de matiz.
1) Un lado (el mío, no estoy exento de sesgos) considera que el modelo de servidor inmutable es muy interesante para los sistemas en la nube. Con ese fin, creamos prototipos moviendo todos los componentes de nuestra infraestructura a Docker. Nuestras aplicaciones personalizadas se crean a través de Jenkins directamente en las imágenes de Docker que se implementan en un registro local de Docker. Luego creamos un gran conjunto de roles Ansible y un libro de jugadas 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á conectada y funcionando: registro, monitoreo, creación / población de bases de datos, etc. La máquina terminada es un entorno de control de calidad o desarrollo 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 base AMI confiable (probablemente una imagen muy simple), realizar implementaciones continuas de la aplicación de producción para manejar la gestión de configuración y las versiones y, en general, nunca volver a editar servidores. solo hazlos de nuevo. No me preocupa que lo que describí funcione en la práctica, solo si es un modelo razonable.
2) The other camp wants to use Puppet to handle configuration management, Ansible to deploy our custom applications that are tarballs generated from our build process, Foreman to handle the triggering and management of the process as a whole and Katello to do some amount of base image management. Releases would involve Puppet changing configuration as needed and Ansible deploying updated components with some amount of Foreman coordination. Servers would be built reasonably quickly if we needed new ones but the intent is not to make them disposable as part of the standard process. This is closer to the phoenix server model though with a long life.
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 puede literalmente construir un clon completo de las aplicaciones en vivo, dejar que QA lo golpee, luego simplemente voltear el almacenamiento de la base de datos y algunas configuraciones de DNS para hacerlo funcionar.
¿O el modelo de servidor inmutable falla en la práctica? Tenemos una buena experiencia con AWS y entornos en la nube, por lo que esa no es realmente la preocupación, más se trata de cómo implementar una aplicación razonablemente sofisticada de manera confiable en el futuro. Esto es de particular interés ya que lanzamos 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. Tengo problemas para entender por qué realmente 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 pueda ver. Ansible parece mucho más fácil de usar que Puppet cuando deja de preocuparse por tener que configurarlos in situ y simplemente construirlos nuevamente con la nueva configuración. Soy fanático del director de KISS, particularmente en la automatización donde la Ley de Murphy se desenfrena. Cuanta menos maquinaria, mejor IMO.
Cualquier idea / comentario o sugerencia sobre el enfoque sería muy apreciada.