Repository navigation
feat(tag-page-rendering)!: Remove EC2 infrastructure - #16965
Conversation
4129069 to
5b955ff
Compare
Supporting the scenario of an application moving entirely to ECS.
5b955ff to
83019c4
Compare
🚀 Image pushed to AWS ECRImage digest: 🐛 Run the image locallyThe following can be used to run the image locally: # Refer to image using the immutable digest. Find alternatives below.
IMAGE_IDENTIFIER="@sha256:c9a76863d47cf60d0b511fd21bf6c0e8848d0a1b7c54bc58ed3578b8bc562078"
# Refer to image using branch tag
# IMAGE_IDENTIFIER=":branch-rm-tag-page-rendering-ec2"
# Refer to image using build tag
# IMAGE_IDENTIFIER=":build-32800"
# 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/artifacts --query "Parameter.Value" --output text)
REGISTRY="${IMAGE_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com"
IMAGE="${REGISTRY}/guardian/dotcom-rendering/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 $IMAGEFrom guardian/actions-ecr. |
arelra
left a comment
arelra
left a comment
There was a problem hiding this comment.
🎉
I can see there is a refactor of EC2 props as part of this PR. Is that strictly required to remove tag-pages EC2 infrastructure?
It is required for this feature (see also fe8fe27). We currently always provision EC2 infrastructure and optionally provision ECS infrastructure. Changes to the EC2 props allow for ECS infra only; the lack of changes to the snapshot demonstrate its no-op characteristic. Happy to break this out into its own PR if desired? |
Thanks that's okay. Approved |
The "cloudformation" template defined in `riff-raff.yaml` assumes the CFN template has AMI parameters. The template for tag-page-rendering no longer does.
| # tag-page-rendering cloudformation | ||
| tag-page-rendering-cfn: | ||
| template: cloudformation | ||
| type: cloud-formation |
There was a problem hiding this comment.
Break away from the templated deployment configuration which assumes an AMI parameter will be in the CFN template. This causes a deployment error:
User specified parameters that are not in template: AMI. Ensure that you are not specifying a parameter directly or as an AMI parameter.
| amiParameter: AMITagpagerendering | ||
| # tag-page-rendering autoscaling | ||
| tag-page-rendering: | ||
| type: autoscaling |
There was a problem hiding this comment.
Removal of the autoscaling deployment type means tag-page-rendering is now deployed entirely with CloudFormation. As a result, its deployment is atomic 🎉.
|
Seen on PROD (merged by @akash1810 12 minutes and 30 seconds ago) Please check your changes! |
Note
What does this change?
Deletes the EC2 infrastructure for
tag-page-renderingin CODE and PROD. This has to be done in the same PR due to the way Riff-Raff is implemented.Important
AWS::ElasticLoadBalancingV2::TargetGroupandAWS::SNS::Topicresources. I've done this on CODE.mainto avoid recreating the infrastructure.What you'll see upon deploying when not rebased
Why?
Since #16922, the EC2 infrastructure is sitting idle and we've been running on ECS only in PROD since #16908.
How has this change been tested?
Since #16922, the EC2 infrastructure is sitting idle. That is, the updated CDK snapshots should provide confidence in this change.
Additionally, we can use
cdk diffto create visualise the changes. The output of this is below.CODE cdk diff
PROD cdk diff