Amazon ECS Workshop > Deploying Microservices to ECS > Node.js Backend API

Node.js Backend API

copilot-cli
cdk

Deploy the Nodejs backend service

Navigate to the nodejs service repo and populate the git hash file which is required for our microservice.

cd ~/environment/ecsdemo-nodejs
git rev-parse --short=7 HEAD > code_hash.txt

In the previous section, we deployed our application, test environment, and the frontend service.

To start, we need to create our nodejs service in the ecsworkshop application.

The following command will open a prompt for us to add our service to the application.

copilot init

We will be prompted with a series of questions related to the application, environment, and the service we want to deploy. Answer the questions as follows:

Would you like to use one of your existing applications? “Y”
Which existing application do you want to add a new service to? Select “ecsworkshop”, hit enter
Which service type best represents your service’s architecture? Select “Backend Service”, hit enter
What do you want to name this Backend Service: ecsdemo-nodejs
Dockerfile: ./Dockerfile

After you answer the questions, it will begin the process of creating some baseline resources for your service. This also includes the manifest file which defines the desired state of this service. For more information on the manifest file, see the copilot-cli documentation.

Next, you will be prompted to deploy a test environment. An environment encompasses all of the resources that are required to support running your containers in ECS. This includes the networking stack (VPC, Subnets, Security Groups, etc), the ECS Cluster, Load Balancers (if required), and more.

Type “y”, and hit enter. Given that a test environment already exists, copilot will continue on and build the docker image, push it to ECR, and deploy the backend service.

Below is an example of what the cli interaction will look like:

deployment

That’s it! When the deployment is complete, navigate back to the frontend URL and you should now see the backend Nodejs service in the image.

Interacting with the application

Let’s check out the ecsworkshop application details.

copilot app show ecsworkshop

The result should look like this:

app_show

We can see that our recently deployed Nodejs service is shown as a Backend Service in the ecsworkshop application.

Interacting with the environment

Given that we deployed the test environment when creating our nodejs service, let’s show the details of the test environment:

copilot env show -n test

env_show

We now can see our newly deployed service in the test environment!

Interacting with the Nodejs service

Let’s now check the status of the nodejs service.

Run:

copilot svc status -n ecsdemo-nodejs

svc_status

We can see that we have one active running task, along with some additional details.

Scale our task count

Let’s scale our task count up! To do this, we are going to update the manifest file that was created when we initialized our service earlier. Open the manifest file (./copilot/ecsdemo-nodejs/manifest.yml), and replace the value of the count key from 1 to 3. This is declaring our state of the service to change from 1 task, to 3. Feel free to explore the manifest file to familiarize yourself.

# Number of tasks that should be running in your service.
count: 3

Once you are done and save the changes, run the following:

copilot svc deploy

Copilot does the following with this command:

Build your image locally
Push to your service’s ECR repository
Convert your manifest file to CloudFormation
Package any additional infrastructure into CloudFormation
Deploy your updated service and resources to CloudFormation

To confirm the deploy, let’s first check our service details via the copilot-cli:

copilot svc status -n ecsdemo-nodejs

You should now see three tasks running!

Now go back to the load balancer url, and you should see the diagram alternate between the three nodejs tasks.

Review the service logs

The services we deploy via copilot are automatically shipping logs to Cloudwatch logs by default. Rather than navigate and review logs via the console, we can use the copilot cli to see those logs locally. Let’s tail the logs for the nodejs service.

copilot svc logs -a ecsworkshop -n ecsdemo-nodejs --follow

Note that if you are in the same directory of the service you want to review logs for, simply type the below command. Of course, if you wanted to review logs for a service in a particular environment, you would pass the -e flag with the environment name.

copilot svc logs

Last thing to bring up is that you aren’t limited to live tailing logs, type copilot svc logs --help to see the different ways to review logs from the command line.

Next steps

We have officially completed deploying our nodejs backend service. In the next section, we will extend our application by adding the crystal backend service.

Validate deployment configuration

cd ~/environment/ecsdemo-nodejs/cdk

Confirm that the cdk can synthesize the assembly CloudFormation templates

cdk synth

Review what the cdk is proposing to build and/or change in the environment

cdk diff

Deploy the Nodejs backend service

cdk deploy --require-approval never

Code Review

As we mentioned in the platform build, we are defining our deployment configuration via code. Let’s look through the code to better understand how cdk is deploying.

Importing base configuration values from our base platform stack

Because we built the platform in its own stack, there are certain environmental values that we will need to reuse amongst all services being deployed. In this custom construct, we are importing the VPC, ECS Cluster, and Cloud Map namespace from the base platform stack. By wrapping these into a custom construct, we are isolating the platform imports from our service deployment logic.

class BasePlatform(core.Construct):

    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        # The base platform stack is where the VPC was created, so all we need is the name to do a lookup and import it into this stack for use
        self.vpc = aws_ec2.Vpc.from_lookup(
            self, "ECSWorkshopVPC",
            vpc_name='ecsworkshop-base/BaseVPC'
        )

        # Importing the service discovery namespace from the base platform stack
        self.sd_namespace = aws_servicediscovery.PrivateDnsNamespace.from_private_dns_namespace_attributes(
            self, "SDNamespace",
            namespace_name=core.Fn.import_value('NSNAME'),
            namespace_arn=core.Fn.import_value('NSARN'),
            namespace_id=core.Fn.import_value('NSID')
        )

        # Importing the ECS cluster from the base platform stack
        self.ecs_cluster = aws_ecs.Cluster.from_cluster_attributes(
            self, "ECSCluster",
            cluster_name=core.Fn.import_value('ECSClusterName'),
            security_groups=[],
            vpc=self.vpc,
            default_cloud_map_namespace=self.sd_namespace
        )

        # Importing the security group that allows frontend to communicate with backend services
        self.services_sec_grp = aws_ec2.SecurityGroup.from_security_group_id(
            self, "ServicesSecGrp",
            security_group_id=core.Fn.import_value('ServicesSecGrp')
        )

Nodejs backend service deployment code

For the backend service, we simply want to run a container from a docker image, but still need to figure out how to deploy it and get it behind a scheduler. To do this on our own, we would need to build a task definition, ECS service, and figure out how to get it behind CloudMap for service discovery. To build these components on our own would equate to hundreds of lines of CloudFormation, whereas with the higher level constructs that the cdk provides, we are able to build everything with 30 lines of code.

class NodejsService(core.Stack):

    def __init__(self, scope: core.Stack, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        # Importing our shared values from the base stack construct
        self.base_platform = BasePlatform(self, self.stack_name)

        # The task definition is where we store details about the task that will be scheduled by the service
        self.fargate_task_def = aws_ecs.TaskDefinition(
            self, "TaskDef",
            compatibility=aws_ecs.Compatibility.EC2_AND_FARGATE,
            cpu='256',
            memory_mib='512',
        )

        # The container definition defines the container(s) to be run when the task is instantiated
        self.container = self.fargate_task_def.add_container(
            "NodeServiceContainerDef",
            image=aws_ecs.ContainerImage.from_registry("brentley/ecsdemo-nodejs"),
            memory_reservation_mib=512,
            logging=aws_ecs.LogDriver.aws_logs(
                stream_prefix='ecsworkshop-nodejs'
            )
        )

        # Serve this container on port 3000
        self.container.add_port_mappings(
            aws_ecs.PortMapping(
                container_port=3000
            )
        )

        # Build the service definition to schedule the container in the shared cluster
        self.fargate_service = aws_ecs.FargateService(
            self, "NodejsFargateService",
            task_definition=self.fargate_task_def,
            cluster=self.base_platform.ecs_cluster,
            security_group=self.base_platform.services_sec_grp,
            desired_count=1,
            cloud_map_options=aws_ecs.CloudMapOptions(
                cloud_map_namespace=self.base_platform.sd_namespace,
                name='ecsdemo-nodejs'
            )
        )

Review service logs

Review the service logs from the command line:

Expand here to see the solution

Review the service logs from the console:

Expand here to see the solution

Scale the service

Manually scaling

Expand here to see the solution

Autoscaling

Expand here to see the solution

Why autoscale?

Well, to put it simply - it’s either a human scales the service, or the orchestrator.
- If we choose to do it manually, this means that as load increases, we need to stop what we are doing to scale the service to meet the load (and not to mention that we have to eventually scale back down once the load clears). This can be tedious and painful, hence why autoscaling exists.
- If we let the orchestrator handle the scaling in and out for the service, we can focus on continuous improvement, and less on operational heavy lifting. In order to get autoscaling setup, one first needs to know what metric to use as the decision to autoscale. Some example metrics for scaling are CPU utilization, memory utilization, and queue depth.

Setup Autoscaling in the code

Using the editor of your choice, open ‘~/environment/ecsdemo-nodejs/cdk/app.py’ in the cdk directory.
Search for Enable Service Autoscaling to find the code that will enable autoscaling for the service.
Remove the comments (#) from the code for self.autoscale and below, once you remove them, it should look like the following:

# Enable Service Autoscaling
self.autoscale = self.fargate_service.auto_scale_task_count(
    min_capacity=1,
    max_capacity=10
)

self.autoscale.scale_on_cpu_utilization(
    "CPUAutoscaling",
    target_utilization_percent=50,
    scale_in_cooldown=core.Duration.seconds(30),
    scale_out_cooldown=core.Duration.seconds(30)
)

Code Review

To start modeling our autoscaling logic, we first set what our upper and lower bounds are. This ensures that we will always be at a minimum of 1 task, and a maximum of 10 tasks.

# Enable Service Autoscaling
self.autoscale = self.fargate_service.auto_scale_task_count(
    min_capacity=1,
    max_capacity=10
)

When the ECS service is deployed, Cloudwatch metrics such as CPU utilization are enabled by default. We are going to take advantage of that metric and use it as our scaling target. In this method, we are setting what our target cpu utilization percent is, and how long in between scale activities we want to wait before it adds/removes another task.

self.autoscale.scale_on_cpu_utilization(
    "CPUAutoscaling",
    target_utilization_percent=50,
    scale_in_cooldown=core.Duration.seconds(30),
    scale_out_cooldown=core.Duration.seconds(30)
)

Deploy Autoscaling

Now that you have the autoscaling code in place, let’s deploy it!
Let’s see a diff of our present state, vs the proposed changes to our environment. Run the following:

cdk diff

You should see the additon of two resources (image below). ECS is utilizing the Application Autoscaling service to manage the scaling of ECS tasks. In short, this will create a target tracking policy, which will set the desired target for scaling in and out (in this case, CPU utilization), and attach it to the ECS service.

Deploy time!

cdk deploy --require-approval never

Load test

In order to introduce load to the Nodejs Fargate service, we need to have the ability to reach its service endpoint. Since the service is in a private subnet, we will use the EC2 instance that was deployed within the same VPC. The instance was created in the Platform/Build Environment steps.
Once you have deployed the autoscaling, copy the instance id created during the platform deployment and get into temporary ec2 using the SSM agent or use the following code:

ec2InstanceId=$(aws cloudformation describe-stacks --stack-name ecsworkshop-base --query "Stacks" --output json | jq -r '.[].Outputs[] | select(.OutputKey |contains("StressToolEc2Id")) | .OutputValue')
aws ssm start-session --target "$ec2InstanceId"

Once you are in the ec2 instance, generate the load test for the nodejs service.

siege -c 100 -i http://ecsdemo-nodejs.service:3000&

While siege is running in the background, either navigate to the console or monitor the autoscaling from the command line in a new cloud9 terminal.

Command Line

Compare the tasks running vs tasks desired. As the load increases on the nodejs service, we should see these counts eventually increase up to 10. This is autoscaling happening in real time. Please note that this step will take a few minutes. Feel free to run this in one terminal, and move on to the next steps in another terminal.

watch -d -n 3 echo `aws ecs describe-services --cluster container-demo --services ecsdemo-nodejs | jq '.services[] | "Tasks Desired: \(.desiredCount) vs Tasks Running: \(.runningCount)"'`

Now that we’ve seen the service autoscale out, let’s stop the running while loop. Simply press control + c to cancel.
Time to cancel the load test. By prepending our command with &, we instructed it to run in the background. Bring it back to the foreground, and stop it. To stop it, type the following:
- fg
- control + c
NOTE: To ensure application availability, the service scales out proportionally to the metric as fast as it can, but scales in more gradually. For more information, see the documentation

Node.js Backend API

Deploy the Nodejs backend service

Interacting with the application

Interacting with the environment

Interacting with the Nodejs service

Scale our task count

Review the service logs

Next steps

Validate deployment configuration

Confirm that the cdk can synthesize the assembly CloudFormation templates

Review what the cdk is proposing to build and/or change in the environment

Deploy the Nodejs backend service

Code Review

Importing base configuration values from our base platform stack

Nodejs backend service deployment code

Review service logs

Review the service logs from the command line:

Review the service logs from the console:

Scale the service

Manually scaling

Autoscaling

Why autoscale?

Setup Autoscaling in the code

Code Review

Deploy Autoscaling

Load test

Command Line

Console