Staying out of trouble on Elastic Beanstalk

Editor’s note: devops always makes me cranky and Domino is in the doggy hospital (he’s okay), so have a rant about Elastic Beanstalk.

This is my life:

If you’re unfamiliar with Elastic Beanstalk: healthy is green, unhealthy is red, and grey is unreachable. Grey is the worst, because it’s inescapable: you can’t change the configuration once it’s grey and if it’s your configuration at fault, none of these options will actually help you:

Theoretically, if you had a good configuration, you could load it from this list. But obviously I don’t. Amazon is just being prissy here: “Well, you really should have made a known-good configuration before mucking around with your only config, shouldn’t you have?”

Shut up, Amazon.

Here is some hard-won advice I have on configuring an Elastic Beanstalk environment:

If you’ve never used Elastic Beanstalk before, start your journey by filing an allocation request. By default, Amazon lets you start up 0 instances. This was insufficient for my needs of, you know, running something. You can check your limits at EC2 -> Limits section (for your region).

Set up SSH key and upload it to the Key Pairs section of EC2. Then, when you’re first creating your Elastic Beanstalk environment, go to “More options” and add it as an SSH key. That way you can actually log into the machine when things inevitably go wrong.

Add a user. Give it access to AWSElasticBeanstalkWhatever (honestly, I’d go with FullAccess for development, but obviously I have no idea what I’m doing). Create an access key for it. Copy the security key! It’s the last time Amazon will ever let you see it. Put it in your ~/.aws/credentials file.

The documentation on credentials files assumes that you were born knowing how a multi-profile credentials file should be formatted. In case you weren’t, here’s how it’s supposed to look:

aws_access_key_id = HEREISTHEKEYID
aws_secret_access_key = shhItsASecretToEveryone
aws_access_key_id = ANOTHERKEYID
aws_secret_access_key = moreSecrets

Not exactly mind-blowing, but I hate it when documentation does that.

personal is the profile I use for my personal projects. Every time I run eb whatever on a personal project, I have to remember to specify eb whatever --profile personal. This is not a thing I am good at remembering: I have uploaded personal projects to my work EB account ~40 times. But, it beats the alternative of uploading my work projects to my personal account.

For my fellow absent-minded readers, I recommend setting the environment variable AWS_PROFILE=personal to default to personal when needed. However, if I do that, I will inevitably forget to unset it when I’m done. So, I set my prompt to show the variable–prominently–whenever it’s set:

PS1='$(date +%X) w$(__git_ps1)${AWS_PROFILE+ e[41m${AWS_PROFILE}}e[0m$ '

This looks like:

Honestly, I could still miss that. But it’s less likely.

Once you get all that done, you’re probably ready to actually create your “zero configuration required” Elastic Beanstalk app.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: