When we setup Elastic Beanstalk extensions in .ebextensions
I wonder what is the difference between commands
and container_commands
in Beanstalk configuration file keys.
My command is like this
container_commands: 04_insert_app: command: "cat .ebextensions/insertapp_job.txt > /etc/cron.d/insertapp_job && chmod 644 /etc/cron.d/insertapp_job" leader_only: true
container_commands works fine.
commands: has error .ebextensions/insertapp_job.txt
not found
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 .
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.
Python settings WSGI Path – The name of or path to your main application file. For example, application.py , or django/wsgi.py . NumProcesses – The number of processes to run on each application instance.
Open the Elastic Beanstalk console , and in the Regions list, select your AWS Region. In the navigation pane, choose Applications, and then choose Create a new application. Use the on-screen form to provide an application name. Optionally, provide a description, and add tag keys and values.
The major difference between these two pieces is when in the Elastic Beanstalk deployment process they are run.
These commands are run early in the deployment process, before the web server has been set up, and before your application code has been unpacked:
The commands are processed in alphabetical order by name, and they run before the application and web server are set up and the application version file is extracted.1
By default, the commands run in the root user's home folder. This and various other pieces of EB's behavior can be changed via options (working directory, whether to continue on error, environment variables to pass to commands, etc.) that can be passed along with the command.
These commands are run later in the deployment process, after the web server has been set up, and after your application code has been unpacked to the staging folder, but before your application has been "deployed" (by moving the staging folder to its final location):
Container commands run after the application and web server have been set up and the application version archive has been extracted, but before the application version is deployed. Non-container commands and other customization operations are performed prior to the application source code being extracted.2
By default, these commands run in the staging folder, so that any changes you make to the current folder will persist once your application is deployed (the path will change though, so be careful about relative links!).
Container commands support all the same options as (non-container) commands, but they also support a "leader_only" option:
You can use leader_only to only run the command on a single instance, or configure a test to only run the command when a test command evaluates to true. Leader-only container commands are only executed during environment creation and deployments, while other commands and server customization operations are performed every time an instance is provisioned or updated.2
As an addition to @Tiro and @t10508hn answer I just want to clarify that both commands
and container_commands
are executed on the host machine.
To execute commands within the docker container use the Dockerfile
.
This was a point of confusion when I was had to execute a couple of commands with leader_only
and assumed that container_commands
were actually executed within the container.
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