Forem: Aleksandar Polic

AWS ECS: Terms and Concepts

Aleksandar Polic — Thu, 15 Dec 2022 21:59:21 +0000

AWS ECS can be really daunting to grasp at first, mostly because it introduces a lot of new concepts. Without clear analogies, it is hard to understand tutorials explaining all the processes in ECS.

This blog post should serve you as entry point to ECS terms. It should help you understand them and give you examples so you can start learning one of the most valuable AWS services with ease.

Task Definition

To prepare your application to run on Amazon ECS, you create a task definition. The task definition is a text file, in JSON format, that describes one or more containers, up to a maximum of ten, that form your application.

It can be thought of as a blueprint for your application. Task definitions specify various parameters for your application. Examples of task definition parameters are which containers to use, which launch type to use, which ports should be opened for your application, and what data volumes should be used with the containers in the task. The specific parameters available for your task definition depend on the needs of your specific application.

Your entire application stack doesn't need to be on a single task definition. You can do this by combining related containers into their own task definitions, each representing a single component.

The following is an example of a task definition containing a single container that runs an NGINX web server using the Fargate launch type.

{
    "family": "webserver",
    "containerDefinitions": [
        {
            "name": "web",
            "image": "nginx",
            "memory": "100",
            "cpu": "99"
        }
    ],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "networkMode": "awsvpc",
    "memory": "512",
    "cpu": "256"
}

Task

Task is the instantiation of a task definition. After you create a task definition for your application within Amazon ECS, you can specify the number of tasks to run on your cluster. You can run a standalone task, or you can run a task as part of a service within a cluster. Task can be seen as running container instances.

Cluster and service are ECS terms used to name concepts used for logical grouping of tasks.

Service

You can use an Amazon ECS service to run and maintain your desired number of tasks simultaneously in an Amazon ECS cluster. In case a task fails or stops, service will replace the broken one with the new instance of the same.

Services can be really useful when your apps need maintained availability.

Containers, Images and AWS ECR

To deploy applications on Amazon ECS, your application components must be configured to run in containers. Containers are created from a read-only template that's called an image. ECS calls running containers tasks.

Images are typically built from a Dockerfile. A Dockerfile is a plaintext file that specifies all of the components that are included in the container.

After they're built, these images are stored in a registry where they can be downloaded from. Most popular one is Dockerhub, but AWS provides such a registry with AWS ECR (Elastic Container Registry). You can upload your images to ECR, then use them to create Task Definitions.

Cluster

An Amazon ECS cluster is a logical grouping of both tasks or services. You can use clusters to isolate your applications.

In environments using EC2, clusters are valuable to separate underlying infrastructures, so your apps don’t share them.

On the other hand, if you are using Fargate, your cluster resources are also managed by Fargate.

Elastic Beanstalk: Developer's AWS paradise

Aleksandar Polic — Sun, 20 Nov 2022 09:42:11 +0000

Beanstalk in a nutshell

Starting with the cloud, it can be pretty intimidating because of all the fancy words you hear while learning. Auto-scaling and resource provisioning are just a couple of phrases that may be confusing for new developers. Besides that, most developers just want their code to run, without digging deep into hosting technology. Especially when deadlines are approaching.

Enters the room, Elastic Beanstalk. It is a managed service that helps developers run their web applications fast and without worrying about best practices in the AWS environment. It is used by both new and more experienced developers since it is easy to set up but also rich with features so you can tailor your system to your custom needs.

But first, what does managed service even means? It means AWS itself is managing everything. You don't need to worry about updates, security patches, and every other detail that is essential for running the application securely and consistently.

What is your job then? Just provide an overview of what your system needs and upload a code. It is that simple. You simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, and automatic scaling to web application health monitoring.

How it works

Beanstalk works with the application/environment model. You create your application, and then you can have multiple environments for it. This basically means you can have completely different system architectures for different environments. For example, your server could run in only one instance for the development environment but have scaling functionalities implemented for production. And what do you need to do there? Just pick the options for scaling. Pick how many instances should be running minimally and maximally. Pick the thresholds for spinning new instances and terminating unused instances. Everything else is managed by Beanstalk itself.

You have the freedom to choose the deployment options for your applications. Some of them are All at once, Rolling, Blue/Green... This will not be covered in this blog post but it is mentioned to point out the vast range of features Beanstalk has.

Supported Platforms

Beanstalk supports a wide variety of platforms. The list is as follows:

GO
JAVA SE
JAVA Tomcat
.NET with IIS
NodeJS
PHP
Python
Ruby
Packer builder
Single Container Docker
Multi Container Docker
Preconfigured Docker

New platforms are added constantly. There is also one nice feature that makes Elastic Beanstalk perfectly capable of every need you can think of. It is called Custom platform. You can completely configure the platform you need for your applications. This is very important for companies that have a lot of custom system configurations. Custom platform has a major drawback though. It is seen as a very advanced feature which means that it is not easy at all to create your personalized platform.

Beanstalk CLI

We can install an additional CLI called the EB CLI which makes working with Beanstalk from the CLI easier. It’s helpful for your automated deployment pipelines!

After configuration of the environment, you can basically set up one command that will deploy your whole application.

Creating your first Beanstalk web app

Starting point

First login to your AWS account, and search for Elastic Beanstalk.
When you land on EB service home page, click on create a new application.

You will then be redirected to page shown below:

This is the place where you give your application the name, pick a platform and upload your code. This is basically all you need to do for your application to be deployed. Of course, you can manually configure in more detail by clicking Configure more options button. This is what we will do to check more in depth configurations.

As you can see, you can use Sample application code. AWS has sample source codes for every platform, so you can get a hang of most common Beanstalk features without the need for any code from your side.

Overview of most common environment configurations

After clicking on Configure more options button, you will land on Configure environment page:

This is where the magic happens. As you can see, configurations are categorized so it is easier to configure individual resources for your application.

We will go through the most important ones, but feel free to experiment with all. Just be aware that, even though Beanstalk is free, resources provisioned by it, that are out of free tier will be charged, so don't forget to check the pricing pages or erase all of the resources if you are just researching Beanstalk capabilities.

Presets:

Presets, also called deployment modes, tell Beanstalk the overall architecture you want for your environment. Single instance presets are great for development and testing. As the name suggests they use one instance (server) for running your web app.

High availability presets are most commonly used in production. They are leveraging the load balancer features and they use auto-scaling.

Platform:

This is the place where you can pick your platform and its version.

Software:

Software category is used for your software-related configs. You can set your environment variables (called environment properties here) in software configuration. Bye, bye env files.

Instances:

Here you can configure your instances memory resources and public availability. In high availability applications, it is best practice to keep your instances private while the load balancer should be public, which will route all the traffic to your application.

Load balancer:

Load balancer type, as well as listeners, protocols and ports, are configured here

Capacity:

In capacity section, you choose your EC2 instance type and system image. Basically, this is the same old school EC2 configuration

Security:

And last but not least, security. This is where the role is created that performs all the deployment actions on your behalf. It is also the place where you will need to create and assign private keys for SSH access to your instance(s).

After you are ready click on create an app and let Beanstalk create every resource for your application. After a few minutes, you should land on the page below, and if everything is OK, your application should be fully deployed.

Use link below environment name to visit your Beanstalk application.

Outro

This is just scratching the surface of one of the most powerful tools AWS is providing to developers. I hope I could show you how EB can save developers time every day while also being a platform where developers can learn about cloud best practices. Elastic Beanstalk is the service you should definitely have in your cloud tools arsenal.

Deployment of .NET 6 apps on ECS with Fargate

Aleksandar Polic — Mon, 14 Nov 2022 20:04:57 +0000

Introduction

AWS offers great support for running apps inside docker containers. The whole management cycle is made easy and the real difference is that it offers running containers in serverless environment. Using Fargate, we can spin up and down number of containers without having a host infrastructure.

ECS with Fargate will give you all the tools you need to build, deploy and maintain docker containers using serverless technology.

This article will guide you through all the steps you need to take to run fully functional ASP.NET 6 application in ECS environment. I know that running the app is not good enough for modern needs, so at the end of the article, there are also explanations of how to set up HTTPS with SSL certificate on load balancer and CI/CD pipeline. With that, you will have full development cycle covered in ECS. The only thing you will then need is to write code!

Create a Dockerfile

Dockerfile example:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /app

# Copy everything
COPY . ./
# Restore as distinct layers
RUN dotnet restore
# Build and publish a release
RUN dotnet publish -c Release -o out

# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "SampleProject.Presentation.dll"]

This example is valid if Dockerfile is added to the same directory where the solution file resides.

Build an image using Dockerfile*

This step can be skipped if you are directly building an image for ECR

To build a docker image is a necessary step, since we will be using docker image to start a container in any environment. The command that we want to use is docker build

Example for building the image would be:

 docker build -f SampleProject/Dockerfile -t sample-project-image ./SampleProject

-f flag stands for path to Dockerfile

-t will tell the Docker how we want to name our image

The only parameter in docker build command is PATH or URL. It gives the context about image, or to be precise, set of files necessary to build an image. For more information check out docker build docs page.

docker build

Push the image to Repository (ECR)

Docker images must be stored in repository from which we can access it to run a container. In our case, we will use AWS ECR (Elastic Container Registry).

To start, create a repository.
Go to AWS Console and search for Elastic Container Registry service.
Locate Create a repository button and click on it.
Choose if you want it to be Public facing or Private, give it a name, leave all other settings as they are and click Create repository button

Now go to Repositories tab on the left and select your new repository via radio button on the left side

Now, above the list of repos, there should be a button called View push commands. It will give you the instructions for pushing the Docker image to ECR based on OS you are using

After all steps are completed successfully, you should be able to see your image in the ECR repository you created earlier.

Create Task definition

Task definition defines containers and their settings as well as it specifies which containers are included in your task and how they interact with each other. You can also specify data volumes for your containers to use.

To start go to AWS Console and search for ECS:

On the left side, choose Task definitions
Click on Create new Task definiton
For launch type compatibility choose Fargate and click Next step button
Give your task a name
Task should have Task role
- This is just IAM role, which can be created directly from this page by clicking on the link below the input field

This role will be created with AmazonECSTaskExecutionRolePolicy policy.
This is fine for the most part, but we want to have Logging to CloudWatch from our CI/CD pipeline later on. To be able to log to a different AWS service, we will need to add access policy for that particular service.
Add CloudWatchLogsFullAccess policy to newly created IAM Role
You are all set now!
Operating system family should be Linux
For Task execution IAM role choose the same Role you created in a step above
For Task size you can pick a value that is best for you, but for now, let’s choose 0.5GB for memory and 0.5 vCPU for Task CPU
Now it is time to add Container definitions
- Click on Add container button. This will toggle a new modal
- Give your container a name
- For Image, copy the value of your image link from ECR repository
- Add soft limit to be the same as Task memory (500mb)
- For port mappings, you can add HTTP and HTTPS ports for example (80 and 443)
- In advanced container configuration section you can fine tune your container. Add environment files and variables, open volumes if necessary etc.
- Regarding our app, this is not necessary, so we will go straight to creation, so click Add button
You can leave other settings after container definitions unchanged. Of course, for other cases, these other settings can be tuned.

Create Service based on Task

Service represents the place for long running tasks to live. It is part of the Cluster in ECS.

First create a cluster in ECS.

For cluster template use Networking only, since we want out cluster to be using Fargate.

Give cluster a name on the next screen, leave everything else as default and click Create.

Go into your new cluster if you are not redirected automatically.
Locate Services tab.
On Services tab, click on Create button.

For launch type, choose Fargate
Operating system family should be Linux
For Task definition, use the definition we created earlier
Give your service a meaningful name
Service type should be REPLICA
Add number of tasks you want to run by default (number of containers to be running all the time). For testing purposes, leave insert 1
Minimum health capacity should be 0. This means we are OK to have 0 tasks running while doing a deployment
Minimum health capacity should be 100. This means we are OK to have 1 task running max when we are deploying new version
Use default settings for rest and click Next step

In the next step, we are setting up VPC (virtual private cloud) settings and Load Balancer. You will need to create a Load balancer first (explained below). After you create the load balancer, do the following:

Now select VPC and for subnets, include all 3
Next we should setup is load balancing
For Load balancer type choose Application Load Balancer
In Load balancer name dropdown, choose the balancer we created earlier
You should now see the container from task definition in Container to load balance section
Click on Add to load balancer button to set up the container
For production listener port use 80:HTTP from dropdown (we created this port listener when we created load balancer)
For target group name choose the group we created when creating load balancer
Now, click on Next step
On Set Auto Scaling page, just click Next step
Now you can rewiew your service, once you are happy with everyhing, click Create service
If the service is created successfully, click on View service button, and check out how the service is booted up and how tasks are starting to run.

Congratulations, you should now have the running service in place!

Create Load balancer

Load balancer will be used as an entry point to our application. It is also responsible to send the request to one of the ECS service tasks.

To create a load balancer:

Go to EC2 instance
Locate Load Balancers section on the left and enter it
Click Create Load Balancer button
Choose Application Load Balancer as a type
Give your ALB a name
In Network mappings section check all 3 mappings
Create new Secutity group for ALB and open ports 80 and 443, then choose it from the dropdown
In Listeners and Routing section Add HTTP listener for port 80
You will need to create a target group to forward to
- Use Create target group link below the dropdown field. It will redirect you to page to create a new target group
- Choose IP addresses for target type
- Give group a name and leave everything else as default
- Click on Next button
- On the next page leave everything as it is and click Create target group
Now the target group can be selected from the dropdown
After that, click Create load balancer button and that is it!

HTTPS Specifics

To be able to use HTTPS with our new load balancer, we will need to have SSL certificate present in ACM (Amazon certificate manager).
You can either get the certificate from Amazon (free), or import your own certificate.
More info here:

Importing a certificate

Requesting a public certificate

Once you have your verified certificate in ACM, go to load balancers in EC2 service:

Select your load balancer
Locate and go to Listeners tab
Click on Add Listener button
For protocol, choose HTTPS
For action choose Forward and find your target group in dropdown
In secure listener settings for Default SSL/TLS certificate choose your certificate from a dropdown
Now click Add

Now, you have to add CNAME DNS record in your DNS settings. Use domain you used for setting up ACM certificate and value of the record should be DNS address of your load balancer.

Evrything is set up now, but HTTP to HTTPS redirection is not yet in place.

To do this, again, go to load balancers, select your load balancer and go to Listeners tab.

In the Listeners table locate Rules column
For HTTP:80 listener click on View/Edit rules in Rules column
Click on Edit rules tab on the next page
Click on Edit rule (pencil icon) button next to Listener name
In Then section, edit the rule from Forward to Redirect to
Select HTTPS and 443 for redirect values
Click on circled checkmark icon to save the changes

Now, all the HTTP requests will be automatically redirected to our secure listener

CI/CD pipeline

We will be using Gitlab CI to set up the pipeline. The process will automate everything we did above.
For pipeline to be successful, there should be initial setup. This means, there must be cluster, service and task definition created beforehand.

CI/CD pipeline for this particular case is very easy to set up since we are only going to use 2 template files.

Variable fields will be presented in format, and for each variable there will be example at the end.

First template file is aws-ecs.json, which is used to configure AWS ECS service from code

{
    "executionRoleArn": "<execution-role-arn>",
    "containerDefinitions": [{

        "memoryReservation": 1024,
        "environment": [{
            "name": "ASPNETCORE_ENVIRONMENT",
            "value": "Test"
        }],
        "name": "<cluster->",
        "mountPoints": [],
        "image": "<image-link>",
        "essential": true,
    "logConfiguration": {
          "logDriver": "awslogs",
          "options": {
                "awslogs-create-group": "true",
                "awslogs-region": "<region>",
                "awslogs-stream-prefix": "ecs",
                "awslogs-group": "<log-group>"
             }
         },
        "portMappings": [{
            "hostPort": 80,
            "protocol": "tcp",
            "containerPort": 80
        }]
    }],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "networkMode": "awsvpc",
    "cpu": "512",
    "taskRoleArn": "<execution-role-arn>",
    "memory": "1024",
    "family": "aws-ecs"
}

Variables, examples and definitions:

- unique identifier for Task execution role (found in IAM role)

arn:aws:iam::123482667567:role/ecsTaskExecutionRole

- name of the cluster you created for this pipeline

sample-project-image

- unique image link found in ECR repository

123482667567.dkr.ecr.eu-west-2.amazonaws.com/sample-project-image

- region where you want your logs to reside

eu-west-2

- name of the log group in CloudWatch where the logs about this cluster will reside

/ecs/sample-project-logs

Settings like portMappings, cpu, memory and family can be changed based on your applications needs, but I won’t be putting those as variables.

Second template file is .gitbal-ci.yml. It is the file that tells the Gitlab CI how to run the pipeline.

stages:
  - publish

variables:
  EXAMPLE_REPOSITORY_URL: <repo-url>
  REGION: <region>
  EXAMPLE_TASK_DEFINTION_NAME: <task-definition-name>
  EXAMPLE_CLUSTER_NAME: <cluster-name>
  EXAMPLE_SERVICE_NAME: <service-name>
  EXAMPLE_DESIRED_COUNT: <task-count>

publish:
  stage: publish
  image: docker:latest
  services:
    - docker:18-dind
  before_script:
    - apk add --no-cache curl jq python3 py3-pip
    - pip install awscli
    - date
    - docker version
  script:
    - $(aws ecr get-login --no-include-email --region "${REGION}")
    - echo "Building image"
    - docker build -f <path-to-Dockerfile> -t <image-name> <path-to-root-of-project>
    - echo "Tagging image"
    - docker tag <image-name>:latest "${EXAMPLE_REPOSITORY_URL}"
    - echo "Pushing image to ECR"
    - echo "${EXAMPLE_REPOSITORY_URL}"
    - docker push "${EXAMPLE_REPOSITORY_URL}"
    - aws ecs register-task-definition --region "${REGION}" --family "${EXAMPLE_TASK_DEFINTION_NAME}" --cli-input-json file://aws-ecs.json
    - aws ecs update-service --region "${REGION}" --cluster "${EXAMPLE_CLUSTER_NAME}" --service "${EXAMPLE_SERVICE_NAME}" --task-definition "${EXAMPLE_TASK_DEFINTION_NAME}" --desired-count "${EXAMPLE_DESIRED_COUNT}"
  only:
    - release/testing

Variables, examples and definitions:

- url to the image found in ECR repository

123482667567.dkr.ecr.eu-west-2.amazonaws.com/sample-project-image:latest

- Region where ECS should be set up

eu-west-2

- Name of the Task Definition you created earlier

sample-task-definition

- Name of the Cluster you created earlier

sample-project-cluster

- Name of the Service in Cluster you created earlier

sample-project-cluster

- Number of Tasks you want to run after deployment

SampleProject/Dockerfile

- Number of Tasks you want to run after deployment

sample-project-image

- Number of Tasks you want to run after deployment

./SampleProject