amazon web services - Ansible-¿Automatización remota o local?

amazon-web-services automation

Question

Si ejecuta una herramienta de automatización como Ansible para construir su pila de infraestructura en la nube (por ejemplo, AWS), ¿es suficiente tener su herramienta de automatización y pila de construcción en regiones / VPC separadas en la nube, o tiene más sentido tener su automatización? herramienta y scripts localmente (propio centro de datos / máquina)?

Ambos parecen ser utilizados, pero me preguntaba si existía un estándar de mejores prácticas.

Answer 1

Ejecutamos todo localmente

Más

• Probamos todos los libros de jugadas (y nuestro software) en un recuadro Vagrant local, por lo que lo necesitamos localmente de todos modos.
• No necesitamos máquinas adicionales. Y también debe configurarlos con Ansible, por lo que al menos alguien debe tener instalado Ansible. De lo contrario, tienes un problema de pollo contra huevo.
• Probablemente sea un poco más rápido, porque tienes una red hop menos.

Menos

• Todo el mundo necesita una instalación local de Ansible, que solo funcionará en Linux y Mac, pero no en Windows (solo puede ser el objetivo).

Otras Consideraciones

• Para nuestros usuarios de Windows, un usuario de Linux / Mac crea una máquina virtual con Ansible (todo configurado) y lo exporta como un cuadro base. Entonces los usuarios de Windows pueden importar ese cuadro base en Vagrant y solo necesitan iniciarlo; todo está ya instalado. Esto incluye Ansible para que pueda ejecutar todo desde la VM.
• Al principio planeamos poner Ansible en nuestras instancias de NAT (para las subredes privadas de VPC). Pero luego necesitaríamos una configuración para configurar la VPC, los grupos de seguridad y las instancias NAT, y otra para ejecutar en las instancias NAT y configurar el resto de la infraestructura. Sin embargo, no pudimos ver ningún beneficio real en eso, así que ahora estamos teniendo todo localmente.

PD: No estoy seguro de si hay una respuesta definitiva, pero estos son nuestros argumentos.

Answer 2

Como contraste a la buena respuesta de xeraa , corremos tanto como sea posible desde AWS.

Los beneficios reales que obtenemos de esto es que nos permite usar servidores Jenkins centralizados que ejecutan Ansible (y Terraform en nuestro caso para el aprovisionamiento real de AWS con Ansible utilizado para configurar instancias EC2 y ejecutar libros de jugadas ad-hoc para tareas administrativas).

A continuación, podemos controlar el acceso a estos servidores Jenkins a través de credenciales y / o grupos de seguridad / NACL.

Hacerlo de esta manera significa que podemos controlar la cantidad de personas que tienen algún tipo de credencial que les permita construir lo que quieran y / o destruir lo que quieran.

Lo ideal sería que solo proporcionáramos credenciales a los servidores de Jenkins a través de los roles de instancia de IAM EC2, pero aún no lo hemos logrado.

Un aspecto positivo de esto es que nuestra línea de frente / segunda línea admiten chicos que usan Windows casi exclusivamente pueden acceder a una buena GUI web para administrar cosas en el medio de la noche y ejecutar trabajos de Jenkins a los que tienen acceso específicamente para ejecutarlos. hacer cosas como reiniciar un servidor / servicio o incluso reconstruir parte de una VPC.

Tenemos una cuenta de "desarrollo" separada a la que los desarrolladores tienen acceso desde sus propias máquinas y es aquí donde construimos cosas a medida que desarrollamos nuestra base de códigos Ansible (y Terraform) antes de que esa base de código se use en nuestros entornos de prueba y producción.