Menu
I understand that AWS Elastic Beanstalk only needs a single configuration file in the .elasticbeanstalk directory, but (1) when I run eb config I get an additional file, myenv.env.yml; and (2) my IDE threats additional files as important to push, by placing
!.elasticbeanstalk/*.cfg.yml
!.elasticbeanstalk/*.global.yml
in my project's .gitignore.
What are these additional files and what role do they play? My understanding was that only config.yml mattered, and that only it had any effect.
934
ebextensions ) to your web application's source code to configure your environment and customize the AWS resources that it contains. Configuration files are YAML- or JSON-formatted documents with a . config file extension that you place in a folder named . ebextensions and deploy in your application source bundle.
Saved configurations are stored in the Elastic Beanstalk S3 bucket in a folder named after your application. For example, configurations for an application named my-app in the us-west-2 region for account number 123456789012 can be found at s3://elasticbeanstalk-us-west-2-123456789012/resources/templates/my-app .
yml . By default, the EB CLI saves the configuration settings with a configuration-name based on the environment name. You can specify a different configuration name by including the --cfg option with your desired configuration name when you run the command. You can tag your saved configuration using the --tags option.
Elastic Beanstalk supports two methods of saving configuration option settings. Configuration files in YAML or JSON format can be included in your application's source code in a directory named . ebextensions and deployed as part of your application source bundle. You create and manage configuration files locally.
The myenv.env.yml file is intended to be a temporary file. eb config creates it, then you edit it, save it, and exit the editor. Once the editor is closed, the CLI updates the environment and the file gets deleted.
As for the second part of your questions, the sections in .gitignore are intended for those who want to check in their configurations. For example, lets say you have a config.yml file. But you want other developers on your team to use a standard version of the file. You can create (or rename your current file) a file called config.global.yml and it will work exactly like config.yml except it can be checked in to version control.
If you have a config.global.yml and a config.yml the config.yml will always take precedence over any overlapping settings.
167
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
