Tag Archives: Dockerfile options in ECS

ECS container advanced configuration

The Container configurations in Amazon ECS

A quick post on advanced container configurations in Amazon ECS.

ECS container advanced configurations.

Container definitions are part of Task Definitions in Amazon ECS. It’s the configuration where you can customize the container’s infrastructure aspects. In this article, we will walk you through advanced configurations of containers.

In our last article about Task Definitions, we walked you through standard container configurations. Now, we will check all the parameters available in Advanced container definitions.

Read more about Amazon ECS –

The first advanced configuration is health check:

Container healthcheck
  • Healthcheck
    • Command: It will be run within containers to determine if the container is healthy. Since I am spinning up a webserver I used the curl command. It depends on what kind of container is and how you can determine its health.
    • Interval: Duration of two consecutive health checks. (Range: 5-300, default: 30)
    • Timeout: Duration to wait to check health check once it’s executed. (Range: 2-60, default: 5)
    • Start period: Grace period for the container to recover before it can be marked unhealthy after max health check retries. (Range: 0-300)
    • Retries: Max number of failed health checks to mark containers as unhealthy and terminate. (Range: 1-10, default: 3)
Container environment
  • Environment
    • CPU Units: 1 CPU core of ECS instances = 1024 CPU units. These are units of CPUs allocated for the container.
    • GPUs: Number of GPU units reserved for containers. 1 GPU = 1 unit. ECS instances must be GPU supported.
    • Essential: If this is checked, the task will be marked as failed on the failing of this container. If unchecked, the task will continue to run even if this container is failed.
    • Entry Point: Its Dockerfile ENTRYPOINT command.
    • Command: It’s the same as CMD option in Dockerfile.
    • Working directory: WORKDIR from Dockerfile.
    • Environment Files: Source container environments saved in S3.
    • Environment variables: Key-value pairs of variables to be used by the container.
Container timeout and network settings
  • Container timeouts
    • Start timeout: Duration to wait for the container to resolve all dependencies to become fully operational
    • Stop timeout: Duration to wait for the container to exit normally or kill it after this timeout.
  • Network settings
    • Disable networking: No communication outside of the container. The container will be assigned with a loopback address.
    • Links: To communicate with other containers.
    • Hostname: Hostname for the container.
    • DNS servers: To be used by the container
    • DNS search domains: To be used by containers.
    • Extra hosts: Any entry not resolvable by the above two options can be added here.
Container storage and logging
  • Storage and logging
    • Read only root file system: RO for root FS in the container. If mounted it will be able to write on data volumes.
    • Mount points: Data volumes to be mounted inside the container
    • Volumes from: Data volumes from other containers
    • Log configuration: Loggings container logs in AWS CloudWatch
Rest of the configs
  • Security
    • Privileged: Container gets elevated privileges on container instances
    • User: To be used inside the container
    • Docker security options: SELinux and AppArmor security settings to be passed to the container
  • Resource Limits
    • Ulimits: Those are Linux kernel ulimit values.
      • CORE: Limites the core file size (KB)
      • CPU: Max CPU time (MIN)
      • FSIZE: Maximum filesize (KB)
      • LOCKS: Max file locks user can hold
      • MEMLOCK: Max locked-in-memory space (KB)
      • MSGQUEUE: Max memory used by POSIX messages queue (bytes)
  • Docker labels
    • Key value pairs: Tags

Once I run the Task containing the above container definition, it ran successfully. All the custom configurations can be seen in the AWS console. under Task details.

Container details under running task in Amazon ECS

Alternatively, we can log into the ECS instance and then a container to verify stuff.

Checking container on ECS instance

First verify if the container is running.

[ec2-user@ip-10-0-0-122 ~]$ docker container ls
CONTAINER ID        IMAGE                            COMMAND                  CREATED              STATUS                                 PORTS                   NAMES
2c2267e6ce85        nginx:latest                     "/docker-entrypoint.…"   About a minute ago   Up About a minute (health: starting)   0.0.0.0:32768->80/tcp   ecs-webserver-nginx-8-nginx-d28beae194c4eada5b00
9bb8f8b0b6ea        amazon/amazon-ecs-agent:latest   "/agent"                 2 minutes ago        Up 2 minutes (healthy)

Log in to container and verify if custom configurations are applied.

[ec2-user@ip-10-0-0-122 ~]$ docker exec -it 2c2267e6ce85 /bin/bash
root@kt-web-container:/usr/share/nginx/html# cat /etc/resolv.conf
search kerneltalks.com
nameserver 1.1.1.1
nameserver 8.8.8.8
options timeout:2 attempts:5
root@kt-web-container:/usr/share/nginx/html# cat /etc/hosts
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.2.3.4        xyz.com
172.17.0.2      kt-web-container
root@kt-web-container:/usr/share/nginx/html#

You can see container hostname is set, DNS nameservers are set, extra IP-hostname pair has been added to /etc/hosts, logged in user is the root and working directory is set to /usr/share/nginx/html! Everything is accommodated.

Last thing to verify if the container is sending logs to the CloudWatch service. Click on the link View Logs in CloudWatch under container details on the Tasks page. (can be seen in the above screenshot)

ECS container logs in CloudWatch

And logs are being populated in CloudWatch!

That’s all! All advanced container configuration which one can configure under Amazon ECS Task Definition.