ECS invalid container image

ECS invalid container image allows you to update the Docker image used by a container in an Amazon ECS (Elastic Container Service) task.

Use cases

ECS invalid container image:

• Tests the behavior of your ECS tasks when the container images are updated, and validates the resilience and performance of your ECS tasks during image updates.
• Updates the Docker image of a container by modifying the task definition associated with the ECS service or task.
• Simulates scenarios where container images are updated, that may impact the behavior of your application or infrastructure. For example, you can update the Docker image of a container to a newer version or a different image to test how your application handles image updates.
• Validates the behavior of your application and infrastructure during simulated container image updates, such as:
  • Testing the resilience of your system during image updates, including verifying if the updated image is pulled successfully and if the container starts with the new image.
  • Validating the performance and availability of your application after the container image updates, that includes checking if the updated image performs as expected and if there are issues with the new image.

Prerequisites

• Kubernetes >= 1.17
• ECS cluster running with the desired tasks and containers and familiarity with ECS service update and deployment concepts.
• Create a Kubernetes secret that has the AWS access configuration(key) in the CHAOS_NAMESPACE. Below is a sample secret file:

apiVersion: v1
kind: Secret
metadata:
  name: cloud-secret
type: Opaque
stringData:
  cloud_config.yml: |-
    # Add the cloud AWS credentials respectively
    [default]
    aws_access_key_id = XXXXXXXXXXXXXXXXXXX
    aws_secret_access_key = XXXXXXXXXXXXXXX

tip

It is recommended to use the same secret name, that is, cloud-secret. Otherwise, you will need to update the AWS_SHARED_CREDENTIALS_FILE environment variable in the fault template and you may be unable to use the default health check probes.

Permissions required

Here is an example AWS policy to execute the fault.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:DescribeTasks",
                "ecs:DescribeServices",
                "ecs:DescribeTaskDefinition",
                "ecs:RegisterTaskDefinition",
                "ecs:UpdateService",
                "ecs:ListTasks",
                "ecs:DeregisterTaskDefinition"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": "*"
        }
    ]
}

note

• Refer to AWS named profile for chaos to know how to use a different profile for AWS faults.
• The ECS containers should be in a healthy state before and after introducing chaos. Refer to the common attributes and AWS-specific tunables to tune the common tunables for all faults and AWS-specific tunables.
• Refer to the superset permission/policy to execute all AWS faults.

Mandatory tunables

Tunable	Description	Notes
CLUSTER_NAME	Name of the target ECS cluster.	For example, cluster-1.
SERVICE_NAME	Name of the ECS service under chaos.	For example, nginx-svc.
REGION	Region name of the target ECS cluster	For example, us-east-1.

Optional tunables

Tunable	Description	Notes
TOTAL_CHAOS_DURATION	Duration that you specify, through which chaos is injected into the target resource (in seconds).	Defaults to 30s.
CHAOS_INTERVAL	Interval between successive instance terminations (in seconds).	Defaults to 30s.
AWS_SHARED_CREDENTIALS_FILE	Path to the AWS secret credentials.	Defaults to /tmp/cloud_config.yml.
IMAGE	Provide the invalid image to be updated in the ECS container.	Default to 'nginx'
RAMP_TIME	Period to wait before and after injecting chaos (in seconds).	For example, 30s.

Invalid ECS container image

Invalid image used for the ECS task containers. Tune it by using the IMAGE environment variable.

The following YAML snippet illustrates the use of this environment variable:

# Set container image for the target ECS task
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: aws-nginx
spec:
  engineState: "active"
  annotationCheck: "false"
  chaosServiceAccount: litmus-admin
  experiments:
  - name: ecs-invalid-container-image
    spec:
      components:
        env:
        - name: IMAGE
          value: 'nginx'
        - name: REGION
          value: 'us-east-2'
        - name: TOTAL_CHAOS_DURATION
          VALUE: '60'