deploy

The deploy section allows to set various settings around how the container should be deployed, and what compute resources are required to run the service.

For more details on the deploy, see docker documentation for deploy here

At the moment, all keys are not supported, mostly due to the way Fargate by nature is expecting settings to be.

resources

The resources is probably what interests most individuals, in setting up how much CPU and RAM should be setup for the service. I have tried to capture for various exceptions for the RAM settings, as you can find in ecs_composex.ecs.docker_tools.set_memory_to_mb

Once the container definitions are put together, the CPU and RAM requirements are put together. From there, it will automatically select the closest valid Fargate CPU/RAM combination and set the parameter for the Task definition.

Important

CPUs should be set between 0.25 and 4 to be valid for Fargate, otherwise you will have an error.

Warning

At the moment, I decided to hardcode these values in the CFN template. It is ugly, but pending bigger work to allow services merging, after which these will be put into a CFN parameter to allow you to change it on the fly.

replicas

This setting allows you to define how many tasks should be running for a given service. To make this work, I simply update the MicroserviceCount parameter default value, to keep things configurable.

Note

update_config will be use very soon to support replacement of services using a LB to possibly use CodeDeploy Blue/Green deployment.

labels

These labels aren’t used for much in native Docker compose as per the documentation. They are only used for the service, but not for the containers themselves. Which is great for us, as we can then leverage that structure to implement a merge of services.

In AWS ECS, a Task definition is a group of one or more containers which are going to be running as a one task. The most usual use-case for this, is with web applications, which need to have a reverse proxy (ie. nginx) in front of the actual application. But also, if you used the use_xray option, you realized that ECS ComposeX automatically adds the x-ray-daemon sidecar. Equally, when we implement AppMesh, we will also have another side-car container for this.

So, here is the tag that will allow you to merge your reverse proxy or waf (if you used a WAF in container) fronting your web application:

ecs.task.family

For example, you would have:

---
# base file for services with the x-keys for BDD
version: '3.8'
secrets:
  abcd: {}
  john:
    x-secrets:
      LinksTo:
        - EcsExecutionRole
        - EcsTaskRole
      Name: SFTP/asl-cscs-files-dev
  zyx:
    x-secrets:
      Name: secret/with/kmskey
      Lookup:
        Tags:
          - costcentre: lambda
      JsonKeys:
        - VarName: ZYX_TEST
          SecretKey: test
services:
  app01:
    env_file: ./use-cases/env-files/dummy.env
    deploy:
      labels:
        ecs.task.family: bignicefamily
      resources:
        reservations:
          cpus: '0.25'
          memory: 1GB
    environment:
      LOGLEVEL: DEBUG
      SHELLY: /bin/bash
      TERMY: screen
    image: nginx
    links:
      - app03:dateteller
    ports:
      - mode: awsvpc
        protocol: tcp
        published: 5000
        target: 5000
    secrets:
      - zyx
    x-logging:
      RetentionInDays: 42
      CreateLogGroup: False
    x-network:
      is_public: False
      use_cloudmap: True
      Ingress:
        Myself: False
        AwsSources:
          - Type: PrefixList
            Id: pl-6da54004
    x-iam:
      Policies:
        - PolicyName: AllowPublishToCw
          PolicyDocument:
            Statement:
              - Action:
                  - cloudwatch:PutMetricData
                Effect: Allow
                Resource:
                  - '*'
                Sid: AllowPublishMetricsToCw
    x-xray: false
    x-scaling:
      Range: "1-4"
  app02:
    env_file:
      - ./use-cases/env-files/dummy.env
    deploy:
      labels:
        ecs.task.family: youtoo
      replicas: 2
      resources:
        reservations:
          cpus: '0.1'
          memory: 64000kB
    environment:
      LOGLEVEL: DEBUG
    healthcheck:
      interval: 30
      retries: 3
      test:
        - CMD
        - curl
        - localhost:5000/ping
    image: nginx
    ports:
      - mode: awsvpc
        protocol: tcp
        published: 5000
        target: 5000
    secrets:
      - zyx
    volumes:
      - source: some-volume
        target: /app/data
        type: volume
    x-iam:
      PermissionsBoundary: arn:aws:iam::aws:policy/AdministratorAccess
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess
    x-scaling:
      Range: "1-5"
      TargetScaling:
        CpuTarget: 88
        DisableScaleIn: true
    x-xray: false
  app03:
    deploy:
      resources:
        reservations:
          cpus: '0.25'
          memory: 134217728b
    environment:
      LOGLEVEL: DEBUG
    image: nginx
    ports:
      - mode: awsvpc
        protocol: tcp
        published: 5000
        target: 5000
    secrets:
      - abcd
      - zyx
      - john
    volumes:
      - normal-vol
      - shared-images:/app/images
      - some-volume:/app/data:ro
    x-network:
      Ingress:
        Myself: False
        ExtSources:
          - Ipv4: 0.0.0.0/0
            Description: ANYWHERE

    x-logging:
        RetentionInDays: 30
    x-scaling:
      Range: 1-10
  rproxy:
    depends_on:
      - app01
      - app02
    deploy:
      labels:
        ecs.task.family: bignicefamily,youtoo
      replicas: 1
      resources:
        limits:
          cpus: '0.25'
          memory: 64M
        reservations:
          cpus: '0.1'
          memory: 32M
    image: nginx
    ports:
      - mode: awsvpc
        protocol: tcp
        published: 80
        target: 80
    x-iam:
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/ReadOnlyAccess
    x-xray: true
    x-network:
      is_public: False
      use_cloudmap: True
volumes:
  shared-images: {}
  some-volume: {}
  normal-vol: {}


x-dns:
  PrivateNamespace:
    Name: lambda.internal

x-tags:
  costcentre: lambda

Warning

The example above illustrates that you can either use, for deploy labels

  • a list of strings

  • a dictionary

ecs.depends.condition

This label allows to define what condition should this service be monitored under by ECS. Useful when container is set as a dependency to another.

Hint

Allowed values are : START, SUCCESS, COMPLETE, HEALTHY. By default, sets to START, and if you defined healthcheck, defaults to HEALTHY. See Dependency reference for more information