Skip to main content

Deploy containerized applications to Amazon ECS

11 min

Amazon Elastic Container Service (Amazon ECS) is a scalable, high-performance container orchestration service that supports Docker containers and allows you to easily run and scale containerized applications on AWS. ECS eliminates the need for you to install and operate your own container orchestration software, manage and scale a cluster of virtual machines, or schedule containers on those virtual machines.

Overview#

Pulumi’s AWSx library simplifies deploying containerized applications into ECS and managing all of the associated resources. This includes simple support for load-balanced container services and one-off tasks, in addition to managing the clusters and associated scaling, network, and security policies. This includes ECS Fargate — the simplest option, alleviating the need to manage the cluster’s servers themselves — in addition to the EC2 launch type — providing full control over the underlying EC2 machine resources that power your cluster.

Creating a load balanced ECS service#

To run a Docker container in ECS using default network and cluster settings, use the awsx.ecs.FargateService class. Since we need to access this container over port 80 using a stable address, we will use a load balancer.

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";


const lb = new awsx.lb.ApplicationLoadBalancer("lb");
const cluster = new aws.ecs.Cluster("cluster");


const service = new awsx.ecs.FargateService("service", {
    cluster: cluster.arn,
    assignPublicIp: true,
    desiredCount: 2,
    taskDefinitionArgs: {
        container: {
            name: "my-service",
            image: "nginx:latest",
            cpu: 128,
            memory: 512,
            essential: true,
            portMappings: [
                {
                    containerPort: 80,
                    targetGroup: lb.defaultTargetGroup,
                },
            ],
        },
    },
});


export const url = pulumi.interpolate`http://${lb.loadBalancer.dnsName}`;

After deploying this program, pulumi stack output url can be used to access the Url output property. We can then access our NGINX web server behind our load balancer via curl:

Terminal window
curl http://$(pulumi stack output url)

Giving the following output:

<!DOCTYPE html>
<html>
<body>
<h1>Welcome to nginx!</h1>
</body>
</html>

We have chosen to create an Elastic Load Balancer so that we can access our services over the Internet at a stable address, spread evenly across two instances. Any of the ELB options described in the AWS ELB tutorial can be used with our ECS service.

Behind the scenes, our program creates the ECS cluster in the default VPC to run the compute. This is something we can configure if we want to use a different VPC.

Because we’ve used Fargate, we don’t need to specify anything about our machine instances. Instead, Fargate will manage that for us automatically based on the optional memory and cpu values we request for our containers.

For many scenarios, this is exactly what we want: a simple way of just running containerized applications. While this approach is simple and hides a lot of complexity, it’s often desirable to control more of what is going on.

Creating an ECS cluster in a VPC#

To create an ECS service inside of a VPC, we will first create or use an existing VPC using any of the techniques described in the AWS VPC tutorial. Then we pass the subnets from that VPC into the network configuration argument for our cluster:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";


const vpc = new awsx.ec2.Vpc("vpc");


const securityGroup = new aws.ec2.SecurityGroup("securityGroup", {
    vpcId: vpc.vpcId,
    egress: [
        {
            fromPort: 0,
            toPort: 0,
            protocol: "-1",
            cidrBlocks: ["0.0.0.0/0"],
            ipv6CidrBlocks: ["::/0"],
        },
    ],
});


const cluster = new aws.ecs.Cluster("cluster", {});


const service = new awsx.ecs.FargateService("service", {
    cluster: cluster.arn,
    networkConfiguration: {
        subnets: vpc.privateSubnetIds,
        securityGroups: [securityGroup.id],
    },
    desiredCount: 2,
    taskDefinitionArgs: {
        container: {
            name: "my-service",
            image: "nginx:latest",
            cpu: 128,
            memory: 512,
            essential: true,
        },
    },
});

When using a custom VPC, you will also need to specify your own security groups if you need to allow ingress or egress.

ECS tasks, containers, and services#

We saw example uses above but didn’t describe the details of how ECS core concepts work, or are authored in your application.

To deploy your application to ECS, it must be containerized. This means authoring a Dockerfile that specifies how all of your application’s runtime dependencies are built and packaged up. This is then used to create an image that is used by the ECS runtime to mount and run your code, as services scale out. For more information about container technology, see Docker Basics for Amazon ECS.

Given an image, ECS requires that you author a Task Definition, which specifies what requirements your Docker application has of the underlying cluster. This includes information about the container(s) to run. After that, ECS containers may be run as one-off Tasks, or long-lived Services.

For full details of the available component arguments, please refer to the registry API documentation.

Building and publishing Docker images automatically#

Containers with the AWSx library are far more flexible than just accepting a preexisting image URL, and can even refer to a Dockerfile on disk so you do not need to build and publish it separately ahead of time. This makes it very easy to use private registrations for your ECS workloads.

For example, specifying a path will run a docker build in that path, push the result up to the ECR repository that specified in the first argument, and then pass the private ECR repository path to the container:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";
import * as awsx from "@pulumi/awsx";


const repo = new awsx.ecr.Repository("repo", {
    forceDelete: true,
});


const image = new awsx.ecr.Image("image", {
    repositoryUrl: repo.url,
    context: "./app",
    platform: "linux/amd64",
});


const cluster = new aws.ecs.Cluster("cluster");


const lb = new awsx.lb.ApplicationLoadBalancer("lb");


const service = new awsx.ecs.FargateService("service", {
    cluster: cluster.arn,
    assignPublicIp: true,
    taskDefinitionArgs: {
        container: {
            name: "my-service",
            image: image.imageUri,
            cpu: 128,
            memory: 512,
            essential: true,
            portMappings: [
                {
                    containerPort: 80,
                    targetGroup: lb.defaultTargetGroup,
                },
            ],
        },
    },
});


export const url = pulumi.interpolate`http://${lb.loadBalancer.dnsName}`;

For more information about using ECR, refer to the Amazon ECR tutorial.

Additional ECS resources#

AWSTypeScriptPythonGo.NETJavaYAMLAWSxAmazon ECSContainersDocker

Related

Tutorial

Build and push container images to Amazon ECR

Provision ECR repositories, build and publish images, and manage lifecycle policies with AWSx.
16 min
Tutorial

Run Kubernetes on Amazon EKS

Provision EKS clusters, node groups, and Kubernetes workloads — including Helm charts — with Pulumi.
43 min

The infrastructure as code platform for any cloud.

Contact usGet started