Solo para un poco de historia, he trabajado con Puppet durante 3 años y entendí bastante bien su arquitectura. Nuestra empresa está refactorizando todo nuestro producto basando su arquitectura en microservicios y está comenzando a utilizar la Integración/Implementación Continua. Aproveché esta oportunidad para cambiar nuestra administración de configuración a Ansible para poder usar solo una herramienta tanto para la implementación como para la configuración/orquestación.
Nuestra arquitectura estará totalmente basada en AWS, con entornos Live, Staging y 3 Integration/QA. Cada microservicio tendrá su propio proceso de implementación independiente y los entornos de integración/control de calidad contendrán todas las aplicaciones en una sola instancia, mientras que Live/Staging tendrá múltiples instancias y, en algunos casos, diferentes grupos de instancias por microservicio.
Mi objetivo es tener un único "repositorio" de configuración/implementación de Ansible para todos los entornos, utilizando variables para parametrizar las plantillas a través de los entornos. De esta manera sabremos que tenemos un proceso de configuración e implementación consistente durante todo nuestro ciclo de desarrollo.
Lo que tengo dudas en este momento es cómo abordo la creación de roles para estas múltiples aplicaciones. También encuentro que este tema es bastante difícil de "googlear", ya que la mayoría de las publicaciones que encuentro son tutoriales simples o ejemplos de implementación de una sola aplicación.
Lo que estoy considerando ahora es:
Tengo roles separados para cada "servicio" que necesito, como nginx, java, logstash, etc., con cada archivo de configuración de aplicación dentro. De esta manera mantengo la reutilización de roles y evito repetirme cuando dos o más aplicaciones usan un archivo de configuración bastante similar que se puede diferenciar mediante variables. También tendré una función de implementación con todas las tareas de implementación. Este es el enfoque que suelo adoptar cuando trabajo con Puppet, pero a veces puede dispersar la configuración, lo que hace que sea "difícil" encontrar y agregar un par de casos en los que un cambio en la configuración de una aplicación puede afectar a otra (principalmente debido a que las plantillas individuales sirven a más de una aplicación).
Tenga un rol para el microservicio. Es más fácil trabajar con esto, ya que todas las configuraciones y variables tienen la misma función, pero tendré que repetir tareas y configuraciones para cada microservicio, y esto me da un poco de vergüenza.
El motivo de esta pregunta es medir cómo lo enfrentan las personas que enfrentan el mismo problema, ya que parece casi imposible encontrar respuestas razonables al respecto a través de una búsqueda en Google y no tengo amigos/conocidos que trabajen con Ansible/implementaciones de aplicaciones múltiples.
Lo siento si no fui lo suficientemente claro o confuso, y gracias por cada información que puedas brindarme.
Respuesta1
Lo que haría es tener roles para cada uno.servicio del sistemaque su aplicación necesita, unjugary unrolepara cada aplicación/microservicio, yvariables de grupo y/o hostyvariables de rol y valores predeterminadosque definen qué hacer.
Implemento muchas aplicaciones basadas en PHP, por lo que se parece mucho a esto:
Voy a jugar app_microservice.yml:
---
- hosts: app_microservice_servers
roles:
- nginx
- mariadb
- php-fpm
- app_microservice
Así que tendré unrole roles/app_microserviceque implementa el código. Cuando ejecute esta obra, los requisitos previos de nginx, mariadb y php-fpm se instalarán y configurarán primero, si aún no lo han hecho.
Además de igualar roles, una jugada también puede ser arbitraria tasks. Siéntete libre de mezclarlos y combinarlos si algo es lo suficientemente simple como para que no se requiera un papel completo.
Esta obra también va all.ymljunto con todas las demás, por lo que de vez en cuando puedo hacer ansible-playbook all.yml... Recuerde que ansible no garantiza la idempotencia como lo intenta Puppet, por lo que debe tener cuidado con esto.
- include: app_microservice.yml
yo suelogrupovariables para definir cosas que son comunes a un grupo (aunque hay muy pocas de ellas que no encajen en elrolevariables o valores predeterminados), allvariables de grupo para cosas globales, yanfitriónvariables para cualquier cosa que sea exclusiva de un host.
Por ejemplo, doy una contraseña raíz de MySQL única a cada host, pero tengo cifrados y protocolos SSL definidos para group_vars/all/main.ymlque, si es necesario cambiarlos, haya una fuente de verdad para ellos.