amazon ec2 - pricing - Implementación continua y escalamiento automático de AWS utilizando Ansible(+ Docker?)
ecs aws (3)
El sitio web de mi organización es una aplicación Django que se ejecuta en servidores web front-end + algunos servidores de procesamiento en segundo plano en AWS.
Actualmente estamos usando Ansible para ambos:
- configuración del sistema (desde una imagen del sistema operativo)
- frecuentes implementaciones de código activadas manualmente.
El mismo Ansible Playbook es capaz de aprovisionar una máquina virtual de desarrollo local de Vagrant o una instancia de EC2 de producción desde cero.
Ahora queremos implementar el escalado automático en EC2, y eso requiere algunos cambios hacia una filosofía de "tratar a los servidores como ganado, no como mascotas" .
El primer requisito previo fue pasar de un inventario de Ansible administrado estáticamente a uno dinámico, basado en la API de EC2, listo.
La siguiente gran pregunta es cómo implementarse en este nuevo mundo en el que las instancias desechables surgen en medio de la noche. Las opciones que se me ocurren son:
- Prepare una nueva AMI completamente implementada para cada implementación , cree una nueva configuración de inicio AS y actualice el grupo de AS con eso. Suena muy, muy engorroso, pero también muy confiable debido al enfoque de pizarra limpia, y asegurará que cualquier cambio en el sistema que requiera el código estará aquí. Además, no es necesario realizar ningún paso adicional en el arranque de la instancia, por lo que se puede ejecutar y ejecutar más rápidamente.
- Use una AMI base que no cambie muy a menudo, obtenga automáticamente el último código de aplicación de git al iniciar, inicie el servidor web. Una vez que esté listo, simplemente realice implementaciones manuales según sea necesario, como antes. Pero, ¿qué sucede si el nuevo código depende de un cambio en la configuración del sistema (nuevo paquete, permisos, etc.)? Parece que tiene que empezar a ocuparse de las dependencias entre las versiones de código y las versiones de sistema / AMI, mientras que el enfoque de "solo hacer una ejecución completa" es más integrado y más confiable. ¿Es algo más que un dolor de cabeza potencial en la práctica?
- ¿Usar Docker? Tengo la corazonada de que puede ser útil, pero aún no estoy seguro de cómo se ajusta a nuestra imagen. Somos una aplicación front-end de Django relativamente autónoma con solo RabbitMQ + memcache como servicios, que de todos modos nunca vamos a ejecutar en el mismo host. Entonces, ¿qué ventajas hay en la creación de una imagen de Docker utilizando Ansible que contiene paquetes de sistema + el código más reciente, en lugar de que Ansible lo haga directamente en una instancia de EC2?
Cómo lo haces ? ¿Alguna información / mejores prácticas? Gracias !
También puede usar AWS CodeDeploy con AutoScaling y su servidor de compilación. Usamos el complemento CodeDeploy para Jenkins.
Esta configuración le permite:
- Realiza tu construcción en Jenkins
- subir a la cubeta S3
- implemente en todos los EC2 uno por uno, que forman parte del grupo AWS Auto-Scaling asignado.
¡Todo eso con solo presionar un botón!
Aquí está el tutorial de AWS: Implementar una aplicación en un grupo de autoescala mediante el uso de AWS CodeDeploy
Una solución híbrida puede darte el resultado deseado. Almacene la imagen de la ventana acoplable principal en S3, prepare previamente la AMI con un simple arranque y ejecute el script en el inicio (o pásela a una AMI estándar con datos de usuario). Control de versión moviendo la imagen principal a su última versión estable, probablemente también podría implementar pilas de prueba de nuevas versiones haciendo que el script de búsqueda sea lo suficientemente inteligente como para identificar qué versión de docker se debe obtener en función de las etiquetas de instancia que se pueden configurar en el lanzamiento de la instancia.
Esta pregunta está muy basada en la opinión. Pero solo para darles mi opinión, simplemente prefiero preparar las AMI con Ansible y luego usar CloudFormation para implementar sus pilas con Autoscaling, Monitoring y sus AMI precocidas. La ventaja de esto es que si tiene la mayor parte de la pila de aplicaciones precocida en el AMI de autoescalado, la operación UP será más rápida.
Docker es otro enfoque, pero en mi opinión, agrega una capa adicional en su aplicación que quizás no necesite si ya está utilizando EC2. Docker puede ser realmente útil si dice que desea contener en un solo servidor. Tal vez tenga alguna capacidad adicional en un servidor y Docker le permitirá ejecutar esa aplicación adicional en el mismo servidor sin interferir con las existentes.
Una vez dicho esto, a algunas personas les resulta útil a Docker, no para optimizar los recursos en un solo servidor, sino más bien para que pueda preparar sus aplicaciones en contenedores. Entonces, cuando implemente una nueva versión o un nuevo código, todo lo que tiene que hacer es copiar / replicar estos contenedores de la ventana acoplable en sus servidores, luego detener las versiones antiguas del contenedor e iniciar las nuevas versiones del contenedor.
Mis dos centavos.