Ja/jr/auto instrumentation sidecar provisioning

[aug24]

What does this change?

This PR is half of Jorge's excellent #16453

It provisions the sidecar for tag-page-rendering in ECS using Open Telemetry (OTEL), which has been the official AWS recommendation since February 2026.

At a high level this PR

• Adds a new side container to the ECS task whose purpose is to receive traces from the application and forward them to AWS x-ray.

Integration with x-ray

In the new ECS world, tag-page rendering runs in an ECS "service", for which we have a "Task" (the ec2 equivalent of an instance) where we can run multiple containers. This PR adds an ADOT (AWS Distro for OpenTelemetry) Collector container to the service.

AWS Distro for OpenTelemetry (ADOT) is a secure, production-ready, AWS-supported distribution of the Cloud Native Computing Foundation (CNCF) OpenTelemetry project. OpenTelemetry (OTel) provides open source APIs, libraries, and agents to collect logs, metrics, and traces.

Luckily ,AWS provides an example cloudformation template that shows how to set up this container for forwarding traces to x-ray. The end result then looks like this

flowchart LR
    user["User"]

    subgraph task["ECS task (shared network namespace)"]
        app["Application container (node)"]
        adot["aws-otel-collector sidecar<br/>:4318 OTLP"]
        app -->|"POST Trace / HTTP :4318"| adot
    end

    adot -->|"POST X-Ray API"| xray["AWS X-Ray"]
    user -->|"AWS console - Cloudwatch"| xray

Loading

Why?

One of the benefits of switching to containers is adding tracing becomes easier because we rely on the AWS-provided side car. Because we believe it will prove useful to understand performance issues in this and future migrations to ECS, we've decided to add it up front.

How has this change been tested?

Deployed to CODE and POSTed a JSON to both the ec2 and ecs target groups from the SOCKS proxy instance. Only ECS traces show up in x-ray.

[github-actions]

Hello 👋! When you're ready to run Chromatic, please apply the run_chromatic label to this PR.

You will need to reapply the label each time you want to run Chromatic.

Click here to see the Chromatic project.

[github-actions]

Deploy build 2755 of dotcom:ab-testing to CODE

All deployment options

• Deploy build 2755 of dotcom:ab-testing to CODE
• Deploy parts of build 2755 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[github-actions]

🚀 Image pushed to AWS ECR

Image digest: sha256:faa95dae4920c4b64b2c6ba1b89fae6af6f7e00e7f23b3d5ce8c0659ac00ce6e

🐛 Run the image locally

The following can be used to run the image locally:

# Refer to image using the immutable digest. Find alternatives below.
IMAGE_IDENTIFIER="@sha256:faa95dae4920c4b64b2c6ba1b89fae6af6f7e00e7f23b3d5ce8c0659ac00ce6e"

# Refer to image using branch tag
# IMAGE_IDENTIFIER=":branch-ja-jr-auto-instrumentation-sidecar-provisioning"

# Refer to image using build tag
# IMAGE_IDENTIFIER=":build-30328"

# Refer to image via the GitHub commit SHA tag
# IMAGE_IDENTIFIER=":sha-8433c8321727d20693658e1c139b72a4bdbc0f85"

# Set environment variables for the AWS CLI
AWS_PROFILE="<A_PROFILE_FROM_JANUS>"
AWS_DEFAULT_REGION="eu-west-1"

IMAGE_ACCOUNT_ID=$(aws ssm get-parameter --name /organisation/accounts/deployTools --query "Parameter.Value" --output text)
REGISTRY="${IMAGE_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com"
IMAGE="${REGISTRY}/guardian/dotcom-rendering${IMAGE_IDENTIFIER}"

# Login to AWS ECR https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html
aws ecr get-login-password | docker login --username AWS --password-stdin $REGISTRY

# Pull the image
docker pull $IMAGE

# Run the image. You'll likely need to set additional flags. See https://docs.docker.com/reference/cli/docker/container/run.
docker run $IMAGE

---

From guardian/actions-publish-image.

[github-actions]

Deploy build 30328 of dotcom:rendering-all to CODE

All deployment options

• Deploy build 30328 of dotcom:rendering-all to CODE
• Deploy parts of build 30328 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[akash1810]

Since #16557, this is no longer needed.

[akash1810]

Could we use the digest, rather than a tag?

[akash1810]

Do these versions need to be kept in sync? If so, lets add a grouping in dependabot.yml.

[akash1810]

IIUC this will write logs to CloudWatch Logs and won't make their way to Central ELK by default? Is it worth pushing them to Central ELK to co-locate with application logs? Do to this, we'd use a firelens driver (example).