Here is the gist of what I did to upgrade our stale EB AMI's (staging, dev and prod envs) to a newer Ruby. Note, there are a few changes to how the new AMI's handle environment variables. See below.
1. Find a base AMI that will work for you. AWS Image id's at the bottom of this page: https://aws.amazon.com/amazon-linux-ami/ This was the only one that worked with our instance type: ami-c7e7f2d0.
2. I used the latest version of the Configuration and Solutions Stack Name from here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.platforms.html#concepts.platforms.ruby
3. In our CloudFormation template, the SolutionStackName will be 64bit Amazon Linux 2016.09 v2.3.0 running Ruby 2.3 (Puma). I know in the doc they label it Ruby 2.3 with Puma version 2.3.0 but that is NOT the name used for SolutionStackName. It's the italicized name below the title.
Example CloudFormation myapp.json:
...
"ElasticBeanstalkTemplate": {
"Type": "AWS::ElasticBeanstalk::ConfigurationTemplate",
"Properties": {
"ApplicationName": "MyFrontendApp",
"Description": "Ruby 2.3.1, Puma",
"SolutionStackName": "64bit Amazon Linux 2016.09 v2.3.0 running Ruby 2.3 (Puma)",
...
4. We use environment variables in our app that are pulled from S3. The environment file is copied from S3 using Puppet (not shown here). When Elastic Beanstalk starts the Puma server, we need to have those environment variables sourced, or exported to the environment. .ebextensions runs as the app is deployed. To ensure the the env vars are sourced, make sure the .ebextensions has proper .config.
VERY IMPORTANT: The key take away here is the container_commands directive. These commands will be executed in the same environment that the application will run in. All of the other directives execute prior to this, in a differing userspace.
(Documentation on .ebextensions http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html)
Example .ebextensions/myapp.config:
container_commands:
10-source-my-env-vars:
command: ". /etc/profile.d/my-env-vars.sh"
5. Other things I learned while upgrading
LOGS LOGS LOGS
Pay attention to anything in /var/log/eb-*, /var/log/cfn-* and of course /var/log/puma/puma.log
I've noticed that if a deploy fails early on, the instance may not be bootstrapped far enough to get any feedback on the Elastic Beanstalk deploy page. You may only get a generic error like: Update environment operation is complete, but with errors. For more information, see troubleshooting documentation. So dig deep into the logs mentioned above. I found that most of my failure had to do with our .ebextensions/ failing because AWS changed the directory structure around /opt/elasticbeanstalk.
Initially, I tried to update in place the old AMI with the new Solutions Stack Name. Big fat fail there. I could not get this to work. Spent way too much time shaving that cat.
❤️