Configuring Docker environments

There are several ways to configure the behavior of your Elastic Beanstalk Docker environment.

Configuring software in Docker environments

You can use the Elastic Beanstalk console to configure the software running on your environment's instances.

For information about configuring software settings in any environment, see Environment properties and other software settings. The following sections cover Docker specific information.

Container options

The Container options section has platform-specific options. For Docker environments, it lets you choose whether or not your environment includes the NGINX proxy server.

Environments with Docker Compose

If you manage your Docker environment with Docker Compose, Elastic Beanstalk assumes that you run a proxy server as a container. Therefore it defaults to None for the Proxy server setting, and Elastic Beanstalk does not provide an NGINX configuration.

Since the NGINX web server proxy is disabled for the Docker on Amazon Linux 2 platform with Docker Compose, you must follow the instructions for generating logs for enhanced health reporting. For more information, see Generating logs for enhanced health reporting (Docker Compose).

Environment properties and Environment Variables

The Environment properties section lets you specify environment configuration settings on the Amazon Elastic Compute Cloud (Amazon EC2) instances that are running your application. Environment properties are passed in as key-value pairs to the application. In a Docker environment, Elastic Beanstalk passes environment properties to containers as environment variables.

Your application code running in a container can refer to an environment variable by name and read its value. The source code that reads these environment variables will vary by progamming language. You can find instructions for reading environment variable values in the programming languages that Elastic Beanstalk managed platforms support in the respective platform topic. For a list of links to these topics, see Environment properties and other software settings.

Environments with Docker Compose

If you manage your Docker environment with Docker Compose, you must make some additional configuration to retrieve the environment variables in the containers. In order for the executables running in your container to access these environment variables, you must reference them in the docker-compose.yml. For more information see Referencing environment variables in containers.

Referencing environment variables in containers

If you are using the Docker Compose tool on the Amazon Linux 2 Docker platform, Elastic Beanstalk generates a Docker Compose environment file called .env in the root directory of your application project. This file stores the environment variables you configured for Elastic Beanstalk.

In order for a container to reference the environment variables you define in Elastic Beanstalk, you must follow one or both of these configuration approaches.

The following files provide an example. The sample docker-compose.yml file demonstrates both approaches.

To learn more about environment variables in Docker Compose, see Environment variables in Compose

Using interpolate feature for environment variables (Docker Compose)

Starting with the July 28, 2023 platform release, the Docker Amazon Linux 2 platform branch offers the Docker Compose interpolation feature. With this feature, values in a Compose file can be set by variables and interpolated at runtime. For more information about this feature, see Interpolation on the Docker documentation website.

The following is an example of a platform hook script that you can set up to allow use of the interpolation feature.

#!/bin/bash

: '
example data format in .env file
key1=value1
key2=value2
'
envfile="/var/app/staging/.env"
tempfile=$(mktemp)

while IFS= read -r line; do
  # split each env var string at '='
  split_str=(${line//=/ })
  if [ ${#split_str[@]} -eq 2 ]; then
    # replace '$$' with '$'
    replaced_str=${split_str[1]//\$\$/\$}
    # update the value of env var using ${replaced_str}
    line="${split_str[0]}=${replaced_str}"
  fi
  # append the updated env var to the tempfile
  echo "${line}" ≫"${tempfile}"
done < "${envfile}"
# replace the original .env file with the tempfile
mv "${tempfile}" "${envfile}"

Place the platform hooks under both of these directories:

For more information, see Platform hooks in the Extending Linux platforms topic of this guide.

Generating logs for enhanced health reporting (Docker Compose)

The Elastic Beanstalk health agent provides operating system and application health metrics for Elastic Beanstalk environments. It relies on web server log formats that relay information in a specific format.

Elastic Beanstalk assumes that you run a web server proxy as a container. As a result the NGINX web server proxy is disabled for Docker environments running Docker Compose. You must configure your server to write logs in the location and format that the Elastic Beanstalk health agent uses. Doing so allows you to make full use of enhanced health reporting, even if the web server proxy is disabled.

For instructions on how to do this, see Web server log configuration

Docker container customized logging (Docker Compose)

In order to efficiently troubleshoot issues and monitor your containerized services, you can request instance logs from Elastic Beanstalk through the environment management console or the EB CLI. Instance logs are comprised of bundle logs and tail logs, combined and packaged to allow you to view logs and recent events in an efficient and straightforward manner.

Elastic Beanstalk creates log directories on the container instance, one for each service defined in the docker-compose.yml file, at /var/log/eb-docker/containers/<service name>. If you are using the Docker Compose feature on the Amazon Linux 2 Docker platform, you can mount these directories to the location within the container file structure where logs are written. When you mount log directories for writing log data, Elastic Beanstalk can gather log data from these directories.

If your applications are on a Docker platform that is not using Docker Compose, you can follow the standard procedure desribed in Docker container customized logging (Docker Compose).

Docker images

The Docker and ECS managed Docker platform branches for Elastic Beanstalk support the use of Docker images stored in a public or private online image repository.

Specify images by name in Dockerrun.aws.json. Note these conventions:

For environments using the Docker platform only, you can also build your own image during environment creation with a Dockerfile. See Building custom images with a Dockerfile for details. The Multi-container Docker platform doesn't support this functionality.

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowEbAuth",
        "Effect": "Allow",
        "Action": [
          "ecr:GetAuthorizationToken"
        ],
        "Resource": [
          "*"
        ]
      },
      {
        "Sid": "AllowPull",
        "Effect": "Allow",
        "Resource": [
          "arn:aws-cn:ecr:us-west-2:account-id:repository/repository-name"
        ],
        "Action": [
          "ecr:GetAuthorizationToken",
          "ecr:BatchCheckLayerAvailability",
          "ecr:GetDownloadUrlForLayer",
          "ecr:GetRepositoryPolicy",
          "ecr:DescribeRepositories",
          "ecr:ListImages",
          "ecr:BatchGetImage"
        ]
      }
    ]
  }

  "Image": {
      "Name": "account-id.dkr.ecr.us-west-2.amazonaws.com.cn/repository-name:latest",
      "Update": "true"
    },

"containerDefinitions": [
        {
        "name": "my-image",
        "image": "account-id.dkr.ecr.us-west-2.amazonaws.com.cn/repository-name:latest",

$ docker login

$ docker login registry-server-url

Configuring managed updates for Docker environments

With managed platform updates, you can configure your environment to automatically update to the latest version of a platform on a schedule.

In the case of Docker environments, you might want to decide if an automatic platform update should happen across Docker versions—when the new platform version includes a new Docker version. Elastic Beanstalk supports managed platform updates across Docker versions when updating from an environment running a Docker platform version newer than 2.9.0. When a new platform version includes a new version of Docker, Elastic Beanstalk increments the minor update version number. Therefore, to allow managed platform updates across Docker versions, enable managed platform updates for both minor and patch version updates. To prevent managed platform updates across Docker versions, enable managed platform updates to apply patch version updates only.

For example, the following configuration file enables managed platform updates at 9:00 AM UTC each Tuesday for both minor and patch version updates, thereby allowing for managed updates across Docker versions:

option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Tue:09:00"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: minor

For environments running Docker platform versions 2.9.0 or earlier, Elastic Beanstalk never performs managed platform updates if the new platform version includes a new Docker version.

Docker configuration namespaces

You can use a configuration file to set configuration options and perform other instance configuration tasks during deployments. Configuration options can be defined by the Elastic Beanstalk service or the platform that you use and are organized into namespaces.

The Docker platform supports options in the following namespaces, in addition to the options supported for all Elastic Beanstalk environments:

The following example configuration file configures a Docker environment to run no proxy server.

option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none

Docker configuration on Amazon Linux AMI (preceding Amazon Linux 2)

If your Elastic Beanstalk Docker environment uses an Amazon Linux AMI platform version (preceding Amazon Linux 2), read the additional information in this section.

{
    "auths":{
      "server":{
        "auth":"key"
      }
    }
  }

{
    "server" :
    {
      "auth" : "auth_token",
      "email" : "email"
    }
  }

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:100::io1:500

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24