Gravatar of Ian Blenke

Ian Blenke - DevOps

A 6502 hack living in a cloud orchestration world

AWS Docker Walkthrough With ElasticBeanstalk: Part 1

Jun 27, 2015 | Comments

While deploying docker containers for immutable infrastructure on AWS ElasticBeanstalk, I’ve learned a number of useful tricks that go beyond the official Amazon documentation.

This series of posts are an attempt to summarize some of the useful bits that may benefit others facing the same challenges.

Part 1 : Preparing a VPC for your ElasticBeanstalk environments

Step 1 : Prepare your AWS development environment.

On OS/X, I install homebrew, and then:

brew install awscli

On Windows, I install chocolatey and then:

choco install awscli

Because awscli is a python tool, on either of these, or on the various Linux distribution flavors, we can also avoid native package management and alternatively use python easyinstall or pip directly:

pip install awscli

You may (or may not) need to prefix that pip install with sudo, depending. ie:

sudo pip install awscli

These tools will detect if they are out of date when you run them. You may eventually get a message like:

Alert: An update to this CLI is available.

When this happens, you will likely want to either upgrade via homebrew:

brew update & brew upgrade awscli

or, more likely, upgrade using pip directly:

pip install --upgrade awscli

Again, you may (or may not) need to prefix that pip install with sudo, depending. ie:

sudo pip install --upgrade awscli

For the hardcore Docker fans out there, this is pretty trivial to run as a container as well. See CenturyLinkLabs/docker-aws-cli for a good example of that. Managing an aws config file requires volume mapping, or passing -e AWS_ACCESS_KEY_ID={redacted} -e AWS_SECRET_ACCESS_KEY={redacted}. There are various guides to doing this out there. This will not be one of them ;)

Step 2: Prepare your AWS environment variables

If you haven’t already, prepare for AWS cli access.

You can now configure your ~/.aws/config by running:

aws configure

This will create a default configuration.

I’ve yet to work with any company with only one AWS account though. You will likely find that you need to support managing multiple AWS configuration profiles.

Here’s an example ~/.aws/config file with multiple profiles:

output = json
region = us-east-1

[profile aws-dev]

[profile aws-prod]

You can create this by running:

$ aws configure --profile aws-dev
Default region name [None]: us-east-1
Default output format [None]: json

Getting in the habit of specifying --profile aws-dev is a bit of a reassurance that you’re provisioning resources into the correct AWS account, and not sullying AWS cloud resources between VPC environments.

Step 3: Preparing a VPC

Deploying anything to AWS EC2 Classic instances these days is to continue down the path of legacy maintenance.

For new ElasticBeanstalk deployments, a VPC should be used.

The easiest/best way to deploy a VPC is to use a CloudFormation template.

Below is a public gist of a VPC CloudFormation that I use for deployment:

Here is an example CloudFormation parameters file for this template:

To script the creation, updating, watching, and deleting of the CloudFormation VPC, I have this Makefile as well:

You can get these same files by cloning my github project, and ssuming you have a profile named aws-dev as mentioned above, you can even run make and have it create the myapp-dev VPC via CloudFormation:

git clone
cd aws-docker-walkthrough

You can run make watch to watch the CloudFormation events and wait for a CREATE_COMPLETE state.

When this is complete, you can see the CloudFormation outputs by running:

make output

The output will look something like this:

These CloudFormation Outputs list parameters that we will need to pass to the ElasticBeanstalk Environment creation during the next part of this walkthrough.

One final VPC note: IAM permissions for EC2 instance profiles

As a general rule of thumb, each AWS ElasticBanstalk Application Environment should be given its own IAM Instance Profile to use.

Each AWS EC2 instance should be allowed to assume an IAM role for an IAM instance profile that gives it access to the AWS cloud resources it must interface with.

This is accomplished by introspecting on AWS instance metadata. If you haven’t been exposed to this yet, I strongly recommend poking around at from your EC2 instances:


The JSON returned from that command allows an AWS library call with no credentials automatically obtain time-limited IAM STS credentials when run on AWS EC2 instances.

This avoids having to embed “permanent” IAM access/secret keys as environment variables that may “leak” over time to parties that shouldn’t have access.

Early on, we tried to do this as an ebextension in .ebextensions/00_iam.config, but this only works if the admin running the eb create has IAM permissions for the AWS account, and it appears impossible to change the launch InstanceProfile by defining option settings or overriding cloud resources in an ebextensions config file.

Instead, the VPC above generates an InstanceProfile that can be referenced later. More on that later in Part 2.

Stay tuned…