6

On Elastic Beanstalk, with an AWS Linux 2 based environment, updating the Environment Properties (i.e. environment variables) of an environment causes all generated files to be deleted. It also doesn't run container_commands as part of this update.

So, for example, I have a Django project with collectstatic in the container commands:

05_collectstatic:
  command: |
    source $PYTHONPATH/activate
    python manage.py collectstatic --noinput --ignore *.scss

This collects static files to a folder called staticfiles as part of deploy. But when I do an environment variable update, staticfiles is deleted. This causes all static files on the application to be broken until I re-deploy, which is extremely undesirable.

This behavior did not occur on AWS Linux 1 based environments. The difference appears to be that AWS Linux 2 based environments replace the /var/app/current folder during environment variable changes, where AWS Linux 1 based environments did not do this.

How do I fix this?

Research

I can verify that the container commands are not being run during an environment variable change by monitoring /var/log/cfn-init.log; no new entries are added to this log.

This happens with both rolling update type "disabled" and "immutable".

This happens even if I convert the environment command to be a platform hook, despite the fact that hooks are listed as running when environment properties are updated.

It seems to me like there are two potential solutions, but I don't know of an Elastic Beanstalk setting for either:

  1. Have environment variable changes leave /var/app/current rather than replacing it.
  2. Have environment variable changes run container commands.

The Elastic Beanstalk docs on container commands say "Leader-only container commands are only executed during environment creation and deployments, while other commands and server customization operations are performed every time an instance is provisioned or updated." Is this a bug in Elastic Beanstalk?

Related question: EB: Trigger container commands / deploy scripts on configuration change

Zags
  • 37,389
  • 14
  • 105
  • 140
  • I think you can't do nothing about that. Changing env veriables forces re-deployment of your app. – Marcin Dec 17 '21 at 00:07
  • @Marcin I am totally fine with it forcing redeployment of the app. But it isn't doing a true redeployment because it doesn't run any of the deployment commands, such as container commands. Is there a way to have it do an actual redeployment and not just replace the deployed directory? – Zags Dec 17 '21 at 14:59

1 Answers1

5

The solution is to use a Configuration deployment platform hook for any commands that change the files in the deployment directory. Note that this is different from an Application deployment platform hook.

Using the example of the collectstatic command, the best thing to do is to move it from a container command to a pair of hooks, one for standard deployments and one for configuration changes.

To do this, remove the collectstatic container command. Then, make two identical files:

  • .platform/confighooks/predeploy/predeploy.sh
  • .platform/hooks/predeploy/predeploy.sh

Each file should have the following code:

#!/bin/bash
source $PYTHONPATH/activate
python manage.py collectstatic --noinput --ignore *.scss

You need two seemingly redundant files because different hooks have different trigger conditions. Scripts in hooks run when you deploy the app whereas scripts in confighooks run when you change the configuration of the app.

Make sure to make both of these files executable according to git or else you will run into a "permission denied" error when you try to deploy. You can check if they are executable via git ls-files -s .platform; you should see 100755 before any shell files in the output of this command. If you see 100644 before any of your shell files, run git add --chmod=+x -- .platform/*/*/*.sh to make them executable.

Zags
  • 37,389
  • 14
  • 105
  • 140