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:
1
|
|
On Windows, I install chocolatey and then:
1
|
|
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:
1
|
|
You may (or may not) need to prefix that pip install with sudo
, depending. ie:
1
|
|
These tools will detect if they are out of date when you run them. You may eventually get a message like:
1
|
|
When this happens, you will likely want to either upgrade via homebrew:
1
|
|
or, more likely, upgrade using pip directly:
1
|
|
Again, you may (or may not) need to prefix that pip install with sudo
, depending. ie:
1
|
|
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:
1 2 3 4 5 6 7 8 9 10 11 |
|
You can create this by running:
1 2 3 4 5 |
|
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 https://github.com/ianblenke/aws-docker-walkthrough
cd aws-docker-walkthrough
make
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 http://169.254.169.254
from your EC2 instances:
1
|
|
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…