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.

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. 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.

1. Run gulp build to generate build artifacts, and update file references.
2. Run ./bin/image prod build to build the production deployment image.
3. Run ./bin/deploy release dev to tag the release.
4. Run ./bin/deploy publish dev to publish the release branch.
5. 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

1. Run gulp build to generate build artifacts, and update file references.
2. Run ./bin/image prod build to build the production deployment image.
3. Run ./bin/deploy release prod 1.10.0 to tag the release.
4. Run ./bin/deploy publish prod 1.10.0 to publish the release branch.
5. 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

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.

1. 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.
2. gulp build
3. ./bin/image prod build
4. ./bin/deploy release 1.10.1
5. ./bin/deploy publish 1.10.1
6. ./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.