¿Es un buen enfoque confirmar .elasticbeanstalk/config.yml dentro del repositorio git de un proyecto que usa eb deploy ?
Queremos implementar usando nuestro CI, por lo que no podemos usar el eb init interactivo. Lo que estamos pensando ahora es definir nuestro dev, uat y prod dentro de ese config.yml (si es posible) y apuntar a ese entorno usando eb deployment.
Vimos que podíamos realizar eb init con todos los parámetros necesarios en la versión 2 de ebcli pero ya no en la versión 3. Entonces, ¿parece que el enfoque ha cambiado?
¿Alguien puede explicar cómo implementar EB para múltiples entornos, sin interacción?
- Queremos implementar usando nuestro CI y, por lo tanto, no podemos usar el
eb initinteractivo.
Puede suprimir el modo interactivo de la siguiente manera:
eb init --platform <platform-name> --region <region-name> <application-name>
- ¿Es un buen enfoque confirmar .elasticbeanstalk/config.yml dentro del repositorio git de un proyecto que usa eb deployment?
- ¿Alguien puede explicar cómo implementar EB para múltiples entornos, sin interacción?
Por diseño, EBCLI evita confirmar el directorio .elasticbeanstalk/ ya que puede contener información específica del desarrollador, que cuando se confirma en VC puede causar confusión. Por lo tanto, es mejor evitarlo de VC. Eres libre de enviarlo al control de versiones. Asegúrese de que no haya información confidencial aquí. Los registros y las configuraciones guardadas generalmente se almacenan en .elasticbeanstalk/ .
.elasticbeanstalk/config.yml en un archivo de nivel raíz desde el cual CI podría leer información, como el nombre del entorno que se usará..elasticbeanstalk/config.yml en el archivo de nivel raíz; llamémoslo .environment_config.sh . Podría ser una declaración tan simple como export BEANSTALK_ENVIRONMENT_NAME=<environment name from .elasticbeanstalk/config.yml>En el servidor CI:
3.1. Asegúrese de que PWD sea git init -ed. Los sistemas como Jenkins generalmente se inician con git init-ed con la rama necesaria, por lo que CI puede simplemente source .environment_config.sh en este punto y cargar el nombre del entorno para implementar.
3.2. eb init --platform <platform-name> --region <region-name> <application-name>
3.3. eb use $BEANSTALK_ENVIRONMENT_NAME
3.4. eb deploy
(Puede combinar 3.3. y 3.4. realizando eb deploy $BEANSTALK_ENVIRONMENT_NAME en su lugar; solo quería demostrar el uso de eb use )
La CLI de EB realmente está pensada para usarse desde una estación de trabajo. Creo que sería mejor que escribiera su CI con la CLI de AWS.
Una implementación con eb deploy deployment archivará su código en S3 (o CodeCommit), creará una nueva versión de la aplicación y luego actualizará el entorno con la nueva etiqueta de versión. Todas esas operaciones son compatibles con los comandos de la CLI de AWS.
O bien, podría escribir su propio script de implementación en Python con boto3. Esa es una opción fácil también. Eso es básicamente lo que es la CLI de EB.