-
Notifications
You must be signed in to change notification settings - Fork 10
Deployments
To deploy to Amazon AWS Elastic Beanstalk, there are a few things to check
before running the deployment process. First, make sure the environment
variables are configured properly in .ebextensions/01_envvars.config
.
The default will work, but ENV_SECRET_KEY
should certainly be changed.
Your REPL must be authenticated to Amazon AWS with the eb-cli. A file
should exist in ~/.aws/config
with the aws key and secret. This can be
configured by running aws configure --profile <name>
where is
the name to give to this AWS account and the CLI will then prompt you to
enter your
AWS access keys.
These settings are stored in ~/.aws/config
and ~/.aws/credentials
.
The Elastic Beanstalk CLI is sync'ed with AWS through the settings in the .elasticbeanstalk/config.yml
file. This file is managed (created/modified) using the eb init --profile <name>
command. This command sets the default the AWS region, application name, Beanstalk platform and AWS CLI credentials to use for communicating with the AWS APIs.
To switch between multiple AWS profiles (aka accounts), run eb init --profile <name>
providing the name of the alternate AWS profile as configured in ~/.aws/config
.
Review the EB environment in .elasticbeanstalk/config.global.yml
for the right region-name and settings. This file will be overridden for your environment by writing a .elasticbeanstalk/config.yml
file which takes precedence.
Where is the name of the alternate AWS profile as configured in
~/.aws/config
.
If deploying to a new environment, it must be configured by running eb create
to use all the checked-in default configuration details. Alternatively use the the Amazon AWS Elastic Beanstalk
console.
Use this command to create a new environment, optionally from a saved config.
eb create -i <INSTANCE TYPE|t1.micro,m1.medium> \
-r <REGION|us-east1-1,us-west-2> \
--cfg <PATH|.elasticbeanstalk/saved_configs/blah.cfg.yml>
For example, you can create a new environment with:
eb create dockdj-test-1
- create an environment named "dockdj-test-1"
Make sure to commit any git changes so the deployment contains those changes.
After running this command, a dockdj environment will be created and the code deployed to AWS
To open the container in your browser, run eb open
and add the /health
path to the URL to view the health check page.
To check the status of the running instances, run eb status
. To stop the EB instances, run eb terminate
.
Useful commands for managing configurations
-
eb config delete <filename>
– Deletes the named saved configuration -
eb config get <filename
– Downloads the named saved configuration -
eb config list
– Lists the saved configurations that you have in Amazon S3 -
eb config put <filename>
– Uploads the named saved configuration to an Amazon S3 bucket
The docker image is stored in a public Docker repo hosted by Docker Hub.
If your needs require a private Docker repo, you must configure dockerrun.aws.json
with authentication credentials in order for Amazon ECS to access this repo. You must upload the credentials to an AWS S3 bucket that ECS can access, and ECS uses these credentials to authenticate against Docker hub.
This file is created by running docker login
with the correct credentials.
Note:
- The S3 bucket must be in the same region as the environment
- The S3 bucket and key are listed in
Dockerrun.aws.json
under "authentication" block (uncomment) - ECS and Elastic Beanstalk must have
GetObject
permissions to read from S3
Our versions are named using Semver naming conventions.
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Given those conventions, 9-times out of 10, you want to increment the MINOR version number, and not the MAJOR number. Numbers do NOT roll over after 9. So numbers like 1.2.0, 1.10.10 and 1.100.0 shall be anticipated.
When a new set of features are ready to be QAed run the following commands. These assume you're deploying a production-ready docker image to an AWS development environment.
- Run
gulp build
to generate build artifacts, and update file references. - Run
./bin/image prod build
to build the production deployment image. - Run
./bin/deploy release dev
to tag the release. - Run
./bin/deploy publish dev
to publish the release branch. - Run
./bin/deploy deploy dev
to deploy the release to development.
When a new set of features are ready to be released, and all tests are passing, increment the MINOR version number, and run the following commands. These assume you're deploying a production-ready docker image to an AWS production environment.
e.g. If previous release was 1.9.0, this release will be 1.10.0
- Run
gulp build
to generate build artifacts, and update file references. - Run
./bin/image prod build
to build the production deployment image. - Run
./bin/deploy release prod 1.10.0
to tag the release. - Run
./bin/deploy publish prod 1.10.0
to publish the release branch. - Run
./bin/deploy deploy prod 1.10.0
to deploy the release to production.
To deploy a patch or hotfix to an existing release branch: e.g. 1.10.0
Increment the PATCH version number rather than the MINOR version number:
e.g. 1.10.1
- Make fixes, changes in the code directly in the release branch, increment the PATCH version number rather than the Major version number in the above process.
- [optionally]: Cherry-pick the fixes into
master
.
- Run all deployment commands using the PATCH version number. This will run the deployment process associated to a release branch rather than the master branch.
gulp build
./bin/image prod build
./bin/deploy release 1.10.1
./bin/deploy publish 1.10.1
./bin/deploy deploy 1.10.1
You can also run the app using the Elastic Beanstalk command line utility:
eb local run
- start local Docker container
eb local open
- open site in browser
Run eb local status
to view the Docker containers' status and eb local logs
to see where the server logs are being written.