Fargate

Programmatically Create AWS ECR Repository and Commit Docker Image to ECR

nigel — Sat, 07 Dec 2019 07:56:15 +0000

Programmatically Create AWS ECR Repository and Commit Docker Image to ECR nigel Sat, 07/12/2019 - 07:56

This is a tutorial for using AWS CLI to programmatically create an AWS ECR repository and then commit a Docker image to that repository. This is the first step in a series of tutorials for creating an automated testing framework in AWS Fargate which can be one step of a DevOps pipeline.

As an example I am going to use the Docker php:7.2-apache image and to make it a little more complex, add a few more PHP extensions using a new Dockerfile so that my new image will be Drupal 8 compliant.

Let's get started.

Pull Base Image and Define Dockerfile

The base php:7.2-apache image needs to be pulled from Docker Hub. Issue the following command.

$ docker pull php:7.2-apache
7.2-apache: Pulling from library/php
000eee12ec04: Pull complete 
8ae4f9fcfeea: Pull complete 
60f22fbbd07a: Pull complete 
ccc7a63ad75f: Pull complete 
a2427b8dd6e7: Pull complete 
91cac3b30184: Pull complete 
d6e40015fc10: Pull complete 
240e21c03bb4: Pull complete 
504858e1e4aa: Pull complete 
9a0523b2d73f: Pull complete 
e3acb84829f4: Pull complete 
28a372733f87: Pull complete 
62ee66cdb80a: Pull complete 
c3f368ddc7aa: Pull complete 
Digest: sha256:602bef9acc8d54527ae5b7ee0f16e5cdb6ab81364310f5123b93b95e357f608d
Status: Downloaded newer image for php:7.2-apache
docker.io/library/php:7.2-apache
$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
php                 7.2-apache          fec8a1aaffb8        31 hours ago        410MB
lambci/lambda       go1.x               8d962cde7e27        3 months ago        707MB
sls-docker          latest              8d962cde7e27        3 months ago        707MB

Yes the docker image is there. Now I need to create a directory for the Dockerfile and a sample index.php file which will prove our image is working.

$ mkdir automated && cd automated

By default the Docker php image uses /var/www/html as Apache's docroot. However, I'm going to alter this to something more standard for Drupal web apps - a directory called docroot will be created and will contain a simple index.php containing a call to phpinfo();

$ mkdir docroot && echo " > docroot/index.php

The Dockerfile should now be created and populated. There a number of activities that need to be performed on it.

Reference the base image with a FROM instruction
Install the libraries that support memcached and graphics manipulation
Enable memcached PHP extension
Configure the graphics PHP extension
Install the graphics PHP extension
Copy the files in the current directory and below into the Docker image at the /var/www/html ensuring the permissions are correct for the apache user and group
Set the environment variable AH_SITE_ENVIRONMENT to devops - this is an Acquia Cloud environment variable and only of any significance for those using Acquia as their host - or need a setting in my case to denote that devops is not running on Acquia
Change the default location for the docroot - that means setting an environment variable and using the sed editor to change the configuration in the sites files

Dockerfile

FROM php:7.2-apache
RUN apt-get update && apt-get install -y libmemcached-dev zlib1g-dev \
    libfreetype6-dev \
    libjpeg62-turbo-dev \
    libpng-dev \
    libwebp-dev \
    && pecl install memcached \
    && docker-php-ext-enable memcached \
    && docker-php-ext-configure gd --with-gd --with-webp-dir --with-jpeg-dir \
       --with-png-dir --with-zlib-dir --with-freetype-dir \
    && docker-php-ext-install gd
COPY --chown=www-data:www-data ./ /var/www/html/.
ENV AH_SITE_ENVIRONMENT devops
ENV APACHE_DOCUMENT_ROOT /var/www/html/docroot
RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/sites-available/*.conf
RUN sed -ri -e 's!/var/www/!${APACHE_DOCUMENT_ROOT}!g' /etc/apache2/apache2.conf /etc/apache2/conf-available/*.conf

Build the Image, Run the Container

Once the Dockerfile is complete, it is built with

$ docker build -t d8codebase .

and to confirm it's built correctly:

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
d8codebase          latest              c2193f9778a6        33 minutes ago      439MB
<none>              <none>              2a71964685e0        2 hours ago         432MB
php                 7.2-apache          fec8a1aaffb8        35 hours ago        410MB
lambci/lambda       go1.x               8d962cde7e27        3 months ago        707MB
sls-docker          latest              8d962cde7e27        3 months ago        707MB

Great it's there. Now to spin up the container.

$ docker run -d -p 8080:80 d8codebase

Note I am mapping port 8080 to the container's port 80 which probably won't be pertinent to you. Long story I will try to make short. I write my blogs on my Macbook on a local network in the 192.168 range assigned by my ISP's hub. But I develop and test all the practical work in my blogs in a VM in the IP 10. range. Routing between 192.168 and 10. is difficult without port forwarding - so I port forward 127.0.0.1 8080 to my VM's 10.0.2.15 8080, so when I run my Docker Apache container I must remember incoming is on port 8080 and map that against the container's port 80. Hope that makes sense!

Now check it's running:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
9a6dc2fb88ff        d8codebase          "docker-php-entrypoi…"   44 minutes ago      Up 44 minutes       0.0.0.0:8080->80/tcp   agitated_feistel

Yes, and we can see from the screenshot above that it's picking up the memcached and the gd graphics extensions. Success.

Programmatically Create the AWS ECR Repository

This is quite easy and I've put it into a shell script that requires one parameter - the repo name to be created. The work is done by the aws ecr create-repository call. The rest of the code is simply checking for error conditions. The screenshot above was taken on the AWS console after the shell script below was successfully run with a parameter of d8codebase.

#!/bin/bash
 
#Programmatically create an ECR repo
 
# Check whether we have the args
if [[ -z $@ ]]; then
	echo "usage: [repo_name]"
	exit 1
fi
 
# Create the repo
REPO_NAME=`aws ecr create-repository --repository-name "$1" | jq .repository.repositoryName -r`
 
# Check it was created ok. We already get a quality stderr msg from aws cli so just quit on error.
# Similarly, if already exists it will tell us
if [[ "${REPO_NAME}" != $1 ]]; then
	exit 2
fi
 
echo "Successfully created ${REPO_NAME}"

Now the script to automatically login to Docker and push the image to ECR. Note that AWS ECR does require you to use the docker login command, and therefore provides a AWS CLI ECR command get-login which returns a token than can be piped into the docker login command. The token retrieved from ECR has a large payload, and it is top and tailed with other metadata beyond just the password. Therefore that needs to be removed, and if you look closely at the script below, you can see that I pipe the entire returned payload through sed with a regex, and then the result is piped onwards to docker login. Hopefully the rest is quite self explanatory - and you can see the screenshot above that the push has worked and the image can now be included in ECS / Fargate task definitions.

#!/bin/bash
 
#Programmatically push to an ECR repo
 
# Check whether we have the args
if [[ -z $@ ]]; then
	echo "usage: [repo_name]"
	exit 1
fi
 
REPO_NAME=$1
ECR_ACCOUNT="XXXXXXXXXX.dkr.ecr.eu-west-2.amazonaws.com"
ECR_REPO="${ECR_ACCOUNT}/$1"
 
# AWS Authentication - since we need to use docker push
# The sed regex will top and tail the additional meta data sent by the aws login request.
aws ecr get-login --region eu-west-2  | sed -e 's/^.*-p \(.*\)\s\-\e.*$/\1/' |  docker login --password-stdin -u AWS ${ECR_ACCOUNT}
 
# Get the image id of the Docker build. If there is a "latest" use that else get the first without latest
TAG=`docker images | grep -w "${REPO_NAME}" | grep latest | awk '{ print $3; }'`
if [[ -z ${TAG} ]]; then
        TAG=`docker images | grep -w "${REPO_NAME}" | awk '{ print $3; }'`
fi
 
docker tag "$TAG" "${ECR_REPO}"
docker push "${ECR_REPO}"

blog terms

AWS AWS CLI Docker devops Fargate ECS Development bash

Create Arbitrary Subdomains for AWS Fargate Tasks using AWS CLI

nigel — Fri, 01 Nov 2019 15:03:02 +0000

Create Arbitrary Subdomains for AWS Fargate Tasks using AWS CLI nigel Fri, 01/11/2019 - 15:03

AWS Fargate is a relatively new product offering the capability of running Docker bundles as an ECS compute service on EC2 without the necessity for the user to have to orchestrate the underlying EC2 infrastructure. It is perfect for DevOps, and was the technology I chose as DevOps Architect at my current client. The client wanted standard CI/CD capabilities such as spinning up containerised copies of their website environment per feature branch to perform static analysis, automated testing, and also significantly, a persisting playground that QA or development personnel could use for manual testing and troubleshooting a feature (or hotfix) branch they are currently working on.

This is similar to the offering of both Platform.sh and Amazee Labs hosting solutions - developers can spin up their feature branches. Alas my client is locked into another host yet needed on-the-fly feature branch Docker bundles.

AWS Fargate tasks can achieve this, but out of the box it isn't possible to create public domain registration via ECS Service Discovery. The Fargate task is issued a bare IPv4 address which will obviously work but our requirement is to have a subdomain created per branch that would be of the format {hotfix|feature}--{jira ticket}-{suitable branch name}.{top level domain}. So an example would be:

feature--doi-746-my-whizzy-new-feature.clientdomain.dev

So whilst we can't create a subdomain like that natively, we can do it by retrieving the IP address from the ECS Fargate task, then add that IP to a public Route 53 Hosted Zone. Furthermore, since the Fargate task is run via a Jenkins pipeline job that uses shell scripts populated with AWS CLI, the good news is we can indeed complete the registration of subdomain also using the AWS CLI *and* have the DNS propagate within 60 seconds! Amazing! Let's dive into how we achieve this.

Requirements + Assumptions

The solution will be built using the standard httpd Apache2 server sample Fargate task described on the AWS blog Tutorial: Creating a Cluster with a Fargate Task Using the AWS CLI. I added the task definition into the console, although it is also possible create a shell script and use AWS CLI. I have used the default cluster for brevity's sake, and the AWS account default VPC. I have also transferred a spare domain I had, saasidate.com, into Route 53 before I started the blog. This will be my tld and all the subdomains will be added off it. It's important that the ownership of the domain is transferred into Route 53 since otherwise subdomains will have authority issues if the parent domain is still registered to other domain providers such as GoDaddy or 123-Reg.

The solution I am putting together will use AWS CLI which by default returns JSON structured data. It is absolutely essential to use the Linux command line utility jq for parsing the JSON. Documentation on jq is readily available on the net.

Steps

The solution will need the following steps:

Get the user's default VPC (or create a custom VPC if preferred. We'll need this at a few points in the code.
Get a subnet from the VPC. Three subnets are created for use with the default VPC. I pick the first which is arbitrary.
Get a security group. A new security group is created per task when using the console but that is unnecessary for the shell scripts we will be building. So in our script, check whether our 'standard' security group has been created. If so use it, if not then create a security group with an ingress port of 80 and a CIDR of 0.0.0.0/0 which allows access worldwide on TCP port 80.
Run the Fargate task and loop / sleep until the task has a status of RUNNING.
Get the network interface id of the task and interrogate it for the IP address.
Get the hosted zone for the parent domain.
Add a record set containing the feature branch subdomain to the parent domain's hosted zone.
Create a new hosted zone using the feature branch.

Ok - let's crack on and put this into AWS CLI shell scripts.

Get the VPC

I'm using the default VPC so I can filter the list I get back from AWS using the IsDefault attribute.

VPC=`aws ec2 describe-vpcs | jq '.Vpcs[] | select(.IsDefault == true) | .VpcId' -r`

Note the use of the jq select statement. This is a familiar construct and will be used throughout this blog. Also note the -r flag - this removes the double quotes from the response.

Get the First Subnet in the Default VPC

Here I am using jq again but piping the results through head to get the first subnet. There wasn't an obvious jq query to do this natively within jq.

# Get the first subnet of the VPC
SUBNET=`aws ec2 describe-subnets | jq --arg VPC "$VPC" '.Subnets[] | select(.VpcId == $VPC) | .SubnetId' -r | head -n 1`

Get the Security Group

Here I check whether we already have a dedicated security group which gives us worldwide access to port 80. I search first for a unique security group description and if it doesn't exist, then create it.

# Check if our security group for port 80 webserver already exists. Search for our funky unique description
SECURITY=`aws ec2 describe-security-groups | jq ' .SecurityGroups[] | select (.Description == "Ingress Port 80 Anywhere") | .GroupId' -r`
 
# Let's inspect what we got back.
if [[ $? -ne 0 ]]; then
	echo "describe-security-groups failed with code $?"
	exit $?
fi
 
# If we didn't get a security group then create
if [[ -z "$SECURITY" ]]; then
	SECURITY=`aws ec2 create-security-group \
		--description "Ingress Port 80 Anywhere" \
		--group-name "Fargate Webserver Port 80" \
		--vpc-id "$VPC" | jq .GroupId -r `
 
 
	aws ec2 authorize-security-group-ingress \
		--group-id "$SECURITY" \
		--ip-permissions "FromPort=80,ToPort=80,IpProtocol=TCP,IpRanges=[{CidrIp=0.0.0.0/0}]"
fi

Run the Fargate Task

Next I run the Fargate task. This is the sample Fargate task covered in the AWS documentation and uses the httpd docker image. When I created it in the console I called it "first-run-task-definition" - for the life of me I can't remember why I chose such a crazy name! Note I am piping the result through jq as per normal and then onwards through sed to get the task id without all the arn information that precedes it. The sed command looks for the final forward slash in the task arn and crops anything before it.

# Run the task and parse the task ARN for polling later to determine its status
TASK=`aws ecs run-task \
	--cluster "default" \
	--task-definition "first-run-task-definition" \
	--network-configuration "awsvpcConfiguration={subnets=[${SUBNET}],securityGroups=[${SECURITY}],assignPublicIp=ENABLED}" \
	--launch-type FARGATE  | jq .tasks[0].taskArn -r | sed "s/.*\///" `
 
# Let's inspect what we got back. There should be a task identifier.
if [[ $? -ne 0 ]]; then
	echo "task-run failed with code $?"
	exit $?
fi
 
if [[ -z "$TASK" ]]; then
	echo "task-run could not create task"
	exit 1
fi

Loop and Wait for Fargate Task to get to RUNNING Status

Next I have to wait for the task to acquire RUNNING status, However I can't wait for ever, and thus I have wrapped a shell script rule into a timeout mechanism. I have allowed for 5 minutes for the task to get to RUNNING status and that should be more than enough.

# Loop around until we see a RUNNING status or timeout after 10 x 30 second sleeps
for i in 1 2 3 4 5 6 7 8 9 10 11
do
	if [[ $i -eq 11 ]]; then
		echo "Timed out before could establish task is running"
		exit 1
	fi
 
	STATUS=`aws ecs describe-tasks --cluster="default" --tasks $TASK  | jq .tasks[0].lastStatus -r`
 
	# Did it exit unexpectedly?
	if [[ $? -ne 0 ]]; then
		echo "describe-tasks failed with code $?"
		exit $?
	fi
 
	if [[ "$STATUS" = "RUNNING"  ]]; then
		break
	fi
 
	sleep 30
done

Obtain the Network Interface Id

The ENI is available in the Fargate task's description so I needed to parse this on my quest to get the public IP.

# Get the network Interface id
ENI=`aws ecs describe-tasks --cluster="default" --tasks $TASK  | jq '.tasks[0].attachments[0].details[] | select(.name == "networkInterfaceId") | .value' -r `
 
# Let's inspect what we got back. There should be a network interface id.
if [[ $? -ne 0 ]]; then
	echo "describe-tasks failed with code $?"
	exit $?
fi
 
if [[ -z "$ENI" ]]; then
	echo "describe-tasks could not establish eni"
	exit 1
fi

Get the Public IP Address

With the ENI it is possible to parse the the descriptions of all the network interfaces for the public IP address.

PUBLIC_IP=`aws ec2 describe-network-interfaces | jq --arg ENI "$ENI" '.NetworkInterfaces[] | select(.NetworkInterfaceId == $ENI) | .PrivateIpAddresses[0].Association.PublicIp' -r`
 
# Did we get an IP address?
if [[ $? -ne 0 ]]; then
	echo "describe-network-interfaces failed with code $?"
	exit $?
fi
 
if [[ -z "$PUBLIC_IP" ]]; then
	echo "describe-network-interfaces could not retrieve public IP address"
	exit 1
fi

Get the Parent Domain's Hosted Zone Id

The shell script needs to know about the parent domain and the subdomain name (which in my case is a feature branch name) - so those need to be retrieved from runtime arguments. This will go at the top of the shell script.

if [[ -z $1 ]] || [[ -z $2 ]]; then
	echo "usage: parent_domain_name feature_branch_name"
	exit 1
fi
 
BRANCH=$2.$1
PARENT=$1.

Then continuing at the end of the codebase, the following gets the parent domain

PARENT_ZONE=`aws route53 list-hosted-zones-by-name | jq --arg PARENT "$PARENT" '.HostedZones[] | select(.Name == $PARENT) | .Id' -r | sed "s/.*\///"`

Add the Feature Branch Name and Public IP Address to the Parent Hosted Zone

Now I created a new record set for the parent domain's hosted zone. This uses the AWS CLI command change-resource-record-sets which allows for insert, upsert and delete. I needed a DNS A record adding. The easiest way of providing the runtime parameters is via a JSON structure and that is created in shell script heredoc format to simplify shell script escaping.

BATCH=$(cat <
)
 
 
# Use the hosted zone of the tld
aws route53 change-resource-record-sets \
	--hosted-zone-id $PARENT_ZONE \
	--change-batch "$BATCH"

Create the Feature Branch Hosted Zone

The final AWS CLI call is to use create-hosted-zone, and here I needed to provide the feature branch name and an arbitrary unique caller reference for which I used a timestamp.

timestamp=$(date +%s)
 
# Now create a new hosted zone of the feature branch
aws route53 create-hosted-zone \
	--name "$BRANCH" \
	--caller-reference "$timestamp"

The Complete Script

The complete script is listed below. Note that for brevity and easy reading I have cut a few coding standards. There is repetition in the error condition checking. This should be rewritten with calls to shell script functions in a separate file.

#!/bin/bash
 
# Script to assign a public IP address issued by a Fargate task to a subdomain
 
if [[ -z $1 ]] || [[ -z $2 ]]; then
	echo "usage: parent_domain_name feature_branch_name"
	exit 1
fi
 
BRANCH=$2.$1
PARENT=$1.
 
 
# Get the default VPC.
VPC=`aws ec2 describe-vpcs | jq '.Vpcs[] | select(.IsDefault == true) | .VpcId' -r`
 
# Get the first subnet of the VPC
SUBNET=`aws ec2 describe-subnets | jq --arg VPC "$VPC" '.Subnets[] | select(.VpcId == $VPC) | .SubnetId' -r | head -n 1`
 
# Check if our security group for port 80 webserver already exists. Search for our funky unique description
SECURITY=`aws ec2 describe-security-groups | jq ' .SecurityGroups[] | select (.Description == "Ingress Port 80 Anywhere") | .GroupId' -r`
 
# Let's inspect what we got back.
if [[ $? -ne 0 ]]; then
	echo "describe-security-groups failed with code $?"
	exit $?
fi
 
# If we didn't get a security group then create
if [[ "$SECURITY" = "" ]]; then
	SECURITY=`aws ec2 create-security-group \
		--description "Ingress Port 80 Anywhere" \
		--group-name "Fargate Webserver Port 80" \
		--vpc-id "$VPC" | jq .GroupId -r `
 
 
	aws ec2 authorize-security-group-ingress \
		--group-id "$SECURITY" \
		--ip-permissions "FromPort=80,ToPort=80,IpProtocol=TCP,IpRanges=[{CidrIp=0.0.0.0/0}]"
fi
 
# Run the task and parse the task ARN for polling later to determine its status
TASK=`aws ecs run-task \
	--cluster "default" \
	--task-definition "first-run-task-definition" \
	--network-configuration "awsvpcConfiguration={subnets=[${SUBNET}],securityGroups=[${SECURITY}],assignPublicIp=ENABLED}" \
	--launch-type FARGATE  | jq .tasks[0].taskArn -r | sed "s/.*\///" `
 
# Let's inspect what we got back. There should be a task identifier.
if [[ $? -ne 0 ]]; then
	echo "task-run failed with code $?"
	exit $?
fi
 
if [[ -z "$TASK" ]]; then
	echo "task-run could not create task"
	exit 1
fi
 
# Loop around until we see a RUNNING status or timeout after 10 x 30 second sleeps
for i in 1 2 3 4 5 6 7 8 9 10 11
do
	if [[ $i -eq 11 ]]; then
		echo "Timed out before could establish task is running"
		exit 1
	fi
 
	STATUS=`aws ecs describe-tasks --cluster="default" --tasks $TASK  | jq .tasks[0].lastStatus -r`
 
	# Did it exit unexpectedly?
	if [[ $? -ne 0 ]]; then
		echo "describe-tasks failed with code $?"
		exit $?
	fi
 
	if [[ "$STATUS" = "RUNNING"  ]]; then
		break
	fi
 
	sleep 30
done
 
 
# Get the network Interface id
ENI=`aws ecs describe-tasks --cluster="default" --tasks $TASK  | jq '.tasks[0].attachments[0].details[] | select(.name == "networkInterfaceId") | .value' -r `
 
# Let's inspect what we got back. There should be a network interface id.
if [[ $? -ne 0 ]]; then
	echo "describe-tasks failed with code $?"
	exit $?
fi
 
if [[ -z "$ENI" ]]; then
	echo "describe-tasks could not establish eni"
	exit 1
fi
 
 
# Get the Public IP Address
PUBLIC_IP=`aws ec2 describe-network-interfaces | jq --arg ENI "$ENI" '.NetworkInterfaces[] | select(.NetworkInterfaceId == $ENI) | .PrivateIpAddresses[0].Association.PublicIp' -r`
 
# Did we get an IP address?
if [[ $? -ne 0 ]]; then
	echo "describe-network-interfaces failed with code $?"
	exit $?
fi
 
if [[ -z "$PUBLIC_IP" ]]; then
	echo "describe-network-interfaces could not retrieve public IP address"
	exit 1
fi
 
BATCH=$(cat <
)
 
PARENT_ZONE=`aws route53 list-hosted-zones-by-name | jq --arg PARENT "$PARENT" '.HostedZones[] | select(.Name == $PARENT) | .Id' -r | sed "s/.*\///"`
 
aws route53 change-resource-record-sets \
	--hosted-zone-id $PARENT_ZONE \
	--change-batch "$BATCH"
 
 
timestamp=$(date +%s)
 
# Now create a new hosted zone of the feature branch
aws route53 create-hosted-zone \
	--name "$BRANCH" \
	--caller-reference "$timestamp"

Invoking the Script

The script requires two parameters as previous discussed. Here's my example for the blog:

$ ./feature-branch.sh saasidate.com feature--doi-746-my-whizzy-new-feature

Currently the output of the script is the response from the AWS CLI route53 create-hosted-zone call, and here you can detect the full domain name.

Checking the Outcome

Obviously the first check is to copy and paste the url of the feature branch into a browser and see if it loads. An example of this is the blog heading image at the top of the page.

Also the AWS console is the place to check everything is as required. Navigate to ECS -> default -> Tasks and you should see a screenshot similar to the first one immediately above. This is the task we invoked from inside our shell script. Now navigate to Route 53 -> Hosted Zones -> {domain name} and you can see the feature branch and its IP address.

Steps left to do

New hosted zones will normally propagate in 60 seconds in Route 53 - but it would be good if the script above polls Route 53 every 10 seconds or so and reports back the subdomain url and the IP address once the propagation has completed. This should be surfaced on the command line as a minimum, but perhaps a notification on Slack would be even better. Both options are trivial.

Whilst the idea is that the Fargate tasks should persist, they shouldn't be around forever. Therefore there needs to be clear up activities to remove the feature subdomain from the parent domain's hosted zone, and the subdomain hosted zone. Also there obviously needs a step to stop the Fargate task.

Caveats

There are caveats to this solution - but for my use case, it's one of those rare occurrences in life that the caveats don't apply to me.

Firstly, this solution will only work with a Fargate task and not an ECS service running a Fargate task. Tasks should be run as services for production environments since services give you great things like replication, and health percentages against number of running tasks. There is therefore no scaling, no load balancing, no DDOS protection in what I'm offering here.

Fargate tasks run in isolation are perfect for spun up short living environments such as playgrounds for devs and QAs to run manual tests against or troubleshoot development issues - which is exactly my use case.

blog terms

AWS AWS CLI Docker devops Fargate ECS Development Route 53 bash