Aquí está mi escenario actual.
Deseo trabajar en cada entorno en su propia twig de git.
Mi dificultad
si tengo que implementar en el entorno de desarrollo, se vuelve realmente simple
// make config changes in master branch // git add, commit // eb deploy // thus development environment is updated Pero si tengo que implementar para la producción es donde comienza el problema
git checkout production git merge master // pulls config that is meant for development environment only eb deploy
Quiero que cuando fusiono los cambios desde la twig principal, todas las actualizaciones de mi código con los últimos cambios. Pero los directorys .ebextensions y .elasticbeanstalk permanecen intactos
¿Cómo le digo a git que ignore toda la carpeta .ebextensions mientras se fusiona con la twig de producción?
Para esta versión es relativamente simple. Por ejemplo:
mkdir HelloWorld # create new directory for project cd HelloWorld # enter the new directory git init # create git repository eb init -p PHP # create new application echo "<?php echo getenv("ENV_NAME"); ?>" > index.php git add .gitignore index.php git commit -m 'Initial commit.' eb create dev-env # create environment named dev-env eb create prod-env # create environment named prod-env eb use dev-env # associate dev-env to current branch (master) eb setenv ENV_NAME=DEV # set env variable specific to dev-env git checkout -b production # create production branch and switch to it eb use prod-env # associate prod-env to the current branch (production) eb setenv ENV_NAME=PROD # set env variable specific to prod-env
Esto no salva ENV_NAME en ninguna parte del sistema de files local. EB CLI cambia la instancia de EB activa directamente. Puede usar eb config save (como lo sugirió Nick Humrich) para save las configuraciones de entorno para el entorno en ejecución actual en .elasticbeanstalk/saved_configs/<env-name>.cfg.yml . Dado que cada entorno tiene su propio file, no debe tener ningún conflicto, a less que cambie uno de ellos en ambas twigs. Otra opción (consulte Protección de información confidencial ) sería agregarlos a .gitignore .
Una forma es tener distintos files de configuration de opciones para cada entorno (twig). El EB CLI puede ayudarte con eso 🙂
Ejecute eb init desde cada twig (ver más abajo) y elija un nombre de entorno diferente para cada uno, de modo que termine con 2 .elasticbeanstalk/optionsettings.<env-name> distintos .elasticbeanstalk/optionsettings.<env-name> . De esta forma .elasticbeanstalk/ los conflictos en .elasticbeanstalk/ .
mkdir MyApp cd MyApp
git init .
eb init
NOTA : Cuando le pida que proporcione un nombre de entorno, elija un nombre que identifique si se trata de un entorno de desarrollo o producción.
Enter your AWS Access Key ID (current value is "<networkingacted>"): Enter your AWS Secret Access Key (current value is "<networkingacted>"): Select an AWS Elastic Beanstalk service region. Available service regions are: <networkingacted> Select (1 to 8): 1 Enter an AWS Elastic Beanstalk application name (auto-generated value is "MyApp"): MyApp Enter an AWS Elastic Beanstalk environment name (auto-generated value is "MyApp-env"): MyApp-dev Select an environment tier. Available environment tiers are: 1) WebServer::Standard::1.0 2) Worker::SQS/HTTP::1.0 Select (1 to 2): 1 Select a solution stack. Available solution stacks are: <networkingacted> Select (1 to 59): 32 Select an environment type. Available environment types are: 1) LoadBalanced 2) SingleInstance Select (1 to 2): 2 Create an RDS DB Instance? [y/n]: n Attach an instance profile (current value is "[Create a default instance profile]"): <networkingacted> Select (1 to 5): 4
git checkout -b production
eb init
Repita el paso 3 pero elija un nombre de entorno diferente. Esto creará distintos .elasticbeanstalk/optionsettings.<env-name> .
Deberías usar el mismo app.config para ambos entornos. Lo único que puede divergir entre entornos es la sección option_settings . Pero hasta donde sé, no puede tener diferentes option_settings por entorno, entonces, ¿cómo podemos hacerlo?
Bueno, eso es algo que todavía no tengo una solución óptima, pero te diré cómo lo hago. Agrego todos los option_name de option_name que necesito y uso los valores de marcador de position, por ejemplo:
option_settings: - option_name: MY_CONFIG value: CHANGEME
Luego, más adelante, cambio sus valores manualmente a través del panel de administración de AWS Elastic Beanstalk. Vaya a Application > Configuration > Software Configuration > Environment Properties .
Otra posibilidad sería tener un script personalizado que sea ejecutado por tus container_commands . Esta secuencia de commands podría identificar la instancia de EC2 por su nombre de host (u otro valor único) y cargar automáticamente las variables de entorno (por ejemplo, source <hostname>.env ).
La única regla que debe obedecer es esta: su repository NO DEBE contener información confidencial como cnetworkingenciales, a less que no le importe.
Por ejemplo, una aplicación espera leer cnetworkingenciales RDS a través de variables de entorno, por lo que las pone en option_settings . Pero no quieres que otros contribuyentes los vean, ¿verdad? La solución que propongo usar placeholder es conveniente en este aspecto.
Puede fusionar maestro a producción y producción a maestro. Sin embargo, después de cada fusión, debe reiniciar el tree de trabajo de las carpetas en cuestión. Aquí es cómo puedes hacer esto.
git checkout production git merge --no-commit --no-ff master git reset /path/to/[.ebextensions and .elasticbeanstalk]/folders git commit git push
Además, puede olvidarse de reiniciar después de cada fusión, así que le sugiero que configure un post-merge para hacer esto automáticamente para las twigs respectivas después de cada fusión.