Script to set environment variables inside an ECS docker container during startup

[MikeTheCanuck]

This script is needed to pull in environment variable values from a dynamic store in AWS called Parameter Store (see #113), so that when a Docker container is launched on its own in the AWS ECS environment, it can fill in (mainly) the database connection parameters.

Script is intended to set the named environment variables early in the Docker container startup, so that the env vars will be available by the time their values get read during start of the API application.

Script has not been tested since it depends on certain roles and policies that are only assigned to AWS ECS containers.

ToDo:

• [x] Place a call to this script in the appropriate place in the Docker container startup
• [x] Confirm that it's possible to pip install awscli in our container without having to first install Python - or alternatively, to find another less burdensome way to install awscli
• [x] Test this by deploying one project's container and see whether the container stays up (or debug in production, since there's probably no way to test this outside an ECS environment)

[iant01]

Python must exist in the container both to install (pip) and to be able to run aws cli commands. Either python 2.x or 3.x can be used. There is a bundle installer that can be sucked into the container at build time from S3 and when the container starts up, have it run the installer, but python still needs to exist in the container. An advantage of the installer bundle is that it creates a symbolic link from the install directory to /usr/local/bin (maybe just /local/bin) so that the aws cli directory does not need to be added to the PATH variable.

[MikeTheCanuck]

Wait. I’m an idiot. Python must already be in the container - Django app, anyone?

[MikeTheCanuck]

@bhgrant8 @nam20485 Any opinions on whether this script (to initialize the runtime env vars) belongs in DOCKERFILE.api.production or something else?

If there, whether it makes sense as a RUN command or as a sub-command in the ENTRYPOINT (production-docker-entrypoint.sh)? I haven't mapped the first possible step when an env var becomes necessary - and how to ensure that the env var values don't get declared in a "sub-command" and they disappear before they become necessary?

[bhgrant8]

@MikeTheCanuck, If I am thinking that the env vars that are created from the Parameter store under a RUN command would only be available in the intermediate container that is built, not the final one, we might want this as part of the ENTRYPOINT script

See this reference: https://vsupalov.com/set-dynamic-environment-variable-during-docker-image-build/

[iant01]

Thought for the future, rather than creating a container OS or grabbing one from some other place. Consider using the AWS linux container image as a start to creating project containers. L I believe it has python and aws cli (as well as other items projects may be loading to use) pre-installed. There may be items installed that are not needed/wanted but that may be true with the base container that is currently being used.

[MikeTheCanuck]

Finalized. This is what worked for the Disaster Resilience API container.

I will merge this ASAP today (Sunday hackathon) unless anyone screams.