Skip to content

Instantly share code, notes, and snippets.

@airdrummingfool
Last active February 24, 2017 20:58
Show Gist options
  • Save airdrummingfool/29e73d6dfa68ec5da92e to your computer and use it in GitHub Desktop.
Save airdrummingfool/29e73d6dfa68ec5da92e to your computer and use it in GitHub Desktop.
A new version of the Elastic Beanstalk container removed the very useful $EB_CONFIG_* environment variables. This puts them back, as $EB_CONTAINER_*.
# The Ruby script at /opt/elasticbeanstalk/support/get_envvars.rb is responsible for compiling a list of
# environment variables for use throughout the system. This patches that file to add the EB container variables.
# Most of the added $EB_CONTAINER_* directly match the old $EB_CONFIG_* variables that Elastic Beanstalk did away with
# in a recent container version update; however, $EB_CONFIG_APP_CURRENT is now $EB_CONTAINER_APP_DEPLOY.
# Note: Since we're using `git apply` as a "better GNU patch" we need to pass `--unsafe-paths` in Git >=2.3.0
# See https://gist.github.com/airdrummingfool/29e73d6dfa68ec5da92e for updates and changelog
files:
"/tmp/add_container_envvars.patch" :
mode: "000755"
owner: root
group: users
content: |
--- ./get_envvars.rb 2015-01-28 01:52:31.000000000 +0000
+++ ./get_envvars.rb 2015-03-11 23:05:09.224547106 +0000
@@ -5,8 +5,10 @@
def get_env_vars
env_vars = JSON.parse(`/opt/elasticbeanstalk/bin/get-config environment`)
php_env_vars = JSON.parse(`/opt/elasticbeanstalk/bin/get-config optionsettings -n "aws:elasticbeanstalk:container:php:phpini"`)
+ container_vars = JSON.parse(`/opt/elasticbeanstalk/bin/get-config container`)
php_env_vars.each { |key, value| env_vars['PHP_' + key.upcase] = value }
+ container_vars.each { |key, value| next if !value.is_a?(String); env_vars['EB_CONTAINER_' + key.chomp("_dir").upcase] = value }
env_vars['PHP_DATE_TIMEZONE'] = 'UTC';
commands:
01-patch_get_envvars.rb:
command: grep --silent "container_vars" /opt/elasticbeanstalk/support/get_envvars.rb || git apply /tmp/add_container_envvars.patch --directory=/opt/elasticbeanstalk/support --ignore-whitespace --unsafe-paths
@airdrummingfool
Copy link
Author

The 2nd version of this config file patches the Ruby script responsible for generating a list of all environment variables. This should make the $EB_CONFIG_ variables available in all situations that they used to be available in.

Note that the whitespace on the empty lines in the file content is important.

@airdrummingfool
Copy link
Author

The 3rd version of this config file adds --unsafe-paths to the git patch call, which is needed when using git v2.3.0+.

@airdrummingfool
Copy link
Author

airdrummingfool commented Oct 24, 2016

The 4th version of this config file prevents deploys from dying a horrible death thanks to a missing / (cue embarrassment). It also renames EB_CONFIG_* to EB_CONTAINER_* to better reflect their purpose, and also to avoid namespacing issues in case EB decides to start using EB_CONFIG_* again.

@airdrummingfool
Copy link
Author

airdrummingfool commented Nov 15, 2016

The 5th revision of this config file limits container variables to strings only. Elastic Beanstalk's PHP image v2.2.0+ includes some arrays in the output of /opt/elasticbeanstalk/bin/get-config container, and there is code that relies on get_envvars.rb that assumes that all env_vars are strings. If they aren't all strings, an error like the following may occur:

/opt/elasticbeanstalk/support/php_apache_env:7:in `add_slashes': undefined method `gsub' for ["/var/log/httpd/error_log", "/var/log/httpd/access_log"]:Array (NoMethodError)

Because this file is implemented as a patch (mostly so that if get_envvars.rb changes, this breaks in a noticeable way), this revision will not fix already patched instances. This means that in order to upgrade an existing instance to v2.2.0+, you must manually apply this patch, or revert the previous patch job and then re-deploy. I recommend a simpler solution: set your Configuration Updates "Rolling update type" to Immutable, which spins up new instances to replace the old ones (this is safer in other ways too, it just takes longer). As long as you do this, you simply have to make sure this revision of the config file is in your currently running application version (i.e. the latest deployment in the environment you're updating) before you start the update to 2.2.0+.

@airdrummingfool
Copy link
Author

The 6th revision simply adds a link back to this gist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment