Load testing your app on Knative

terraform init – Infrastructure as Code (IaC) with Terraform

To initialize a Terraform workspace, run the following command:

$ terraform init
Initializing the backend…
Initializing provider plugins…

  • Finding hashicorp/azurerm versions matching “3.63.0”…
  • Installing hashicorp/azurerm v3.63.0…
  • Installed hashicorp/azurerm v3.63.0 (signed by HashiCorp)

Terraform has created a lock file, .terraform.lock.hcl, to record the provider selections it made previously. Include this file in your version control repository so that Terraform can guarantee to make the same selections by default when you run terraform init in the future.

Terraform has been successfully initialized!

As the Terraform workspace has been initialized, we can create an Azure resource group to start working with the cloud.

Creating the first resource – Azure resource group

We must use the azurerm_resource_group resource within the main.tf file to create an

Azure resource group. Add the following to your main.tf file to do so:

resource “azurerm_resource_group” “rg” {
name         = var.rg_name
location = var.rg_location
}

As we’ve used two variables, we’ve got to declare those, so add the following to the vars.tf file:

variable “rg_name” {
type              = string
description = “The resource group name”
}
variable “rg_location” {
type              = string
description = “The resource group location”
}

Then, we need to add the resource group name and location to the terraform.tfvars file.

Therefore, add the following to the terraform.tfvars file:

rg_name=terraform-exercise
rg_location=”West Europe”

So, now we’re ready to run a plan, but before we do so, let’s use terraform fmt to format our files into the canonical standard.

terraform fmt

The terraform fmt command formats the .tf files into a canonical standard. Use the following command to format your files:

$ terraform fmt
terraform.tfvars
vars.tf

The command lists the files that it formatted. The next step is to validate your configuration.

terraform validate

The terraform validate command validates the current configuration and checks whether there are any syntax errors. To validate your configuration, run the following:

$ terraform validate
Success! The configuration is valid.

The success output denotes that our configuration is valid. If there were any errors, it would have highlighted them in the validated output.

Tip

Always run fmt and validate before every Terraform plan. It saves you a ton of planning time and helps you keep your configuration in good shape.

As the configuration is valid, we are ready to run a plan.

2024-07-02 by Cloud Certifications Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative 0

Providing variable values – Infrastructure as Code (IaC) with Terraform

There are a few ways to provide variable values within Terraform:

  • Via the console using -var flags: You can use multiple -var flags with the variable_ name=variable_value string to supply the values.
  • Via a variable definition file (the .tfvars file): You can use a file containing the list of variables and their values ending with an extension of .tfvars (if you prefer HCL) or .tfvars. json (if you prefer JSON) via the command line with the -var-file flag.
  • Via default variable definition files: If you don’t want to supply the variable definition file via the command line, you can create a file with the name terraform.tfvars or end it with an extension of .auto.tfvars within the Terraform workspace. Terraform will automatically scan these files and take the values from there.
  • Environment variables: If you don’t want to use a file or pass the information via the command line, you can use environment variables to supply it. You must create environment variables with the TF_VAR_<var-name> structure containing the variable value.
  • Default: When you run a Terraform plan without providing values to variables in any other way, the Terraform CLI will prompt for the values, and you must manually enter them.

If multiple methods are used to provide the same variable’s value, the first method in the preceding list has the highest precedence for a specific variable. It overrides anything that is defined in the methods listed later.

We will use the terraform.tfvars file for this activity and provide the values for the variables.

Add the following data to the terraform.tfvars file:

subscription_id = “<SUBSCRIPTION_ID>”

app_id= “<SERVICE_PRINCIPAL_APP_ID>”
password=“<SERVICE_PRINCIPAL_PASSWORD>”
tenant=“<TENANT_ID>”

If you are checking the Terraform configuration into source control, add the file to the ignore list to avoid accidentally checking it in.

If you use Git, adding the following to the .gitignore file will suffice:

*.tfvars

.terraform*

Now, let’s go ahead and look at the Terraform workflow to progress further.

Terraform workflow

The Terraform workflow typically consists of the following:

  • init: Initializes the Terraform workspace and backend (more on them later) and downloads all required providers. You can run the init command multiple times during your build, as it does not change your workspace or state.
  • plan: It runs a speculative plan on the requested resources. This command typically connects with the cloud provider and then checks whether the objects managed by Terraform exist within the cloud provider and whether they have the same configuration as defined in the Terraform template. It then shows the delta in the plan output that an admin can review and change the

configuration if unsatisfied. If satisfied, they can apply the plan to commit the changes to the cloud platform. The plan command does not make any changes to the current infrastructure.

  • apply: This applies the delta configuration to the cloud platform. When you useapply by itself, it runs the plan command first and asks for confirmation. If you supply a plan to it, it applies the plan directly. You can also use apply without running the plan using the -auto-approve flag.
  • destroy: The destroy command destroys the entire infrastructure Terraform manages. It is, therefore, not a very popular command and is rarely used in a production environment. That does not mean that the destroy command is not helpful. Suppose you are spinning up a development infrastructure for temporary purposes and don’t need it later. In that case, destroying everything you created using this command takes a few minutes.

To access the resources for this section, cd into the following:

$ cd ~/modern-devops/ch8/terraform-exercise Now, let’s look at these in detail with hands-on exercises.

2024-06-03 by Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values 0

Terraform variables – Infrastructure as Code (IaC) with Terraform

To declare variables, we will need to create a vars.tf file with the following data:

variable “subscription_id” {
type              = string
description = “The azure subscription id”
}
variable “app_id” {
type              = string
description = “The azure service principal appId”
}
variable “password” {
type              = string
description = “The azure service principal password”
sensitive     = true
}
variable “tenant” {
type              = string
description = “The azure tenant id”
}

So, we’ve defined four variables here using variable blocks. Variable blocks typically have a type and a description. The type attribute defines the data type of the variable we declare and defaults to the string data type. It can be a primitive data type such as string , number, or bool, or a complex data structure such as list, set, map, object, or tuple. We will look at types in detail when we use them later in the exercises. The description attribute provides more information regarding the variable so users can refer to it for better understanding.

Tip

Always set the description attribute right from the beginning, as it is user-friendly and promotes the reuse of your template.

The client_secret variable also contains a third attribute called sensitive, a Boolean attribute set to true. When the sensitive attribute is true, the Terraform CLI does not display it in the screen’s output. This attribute is highly recommended for sensitive variables such as passwords and secrets.

Tip

Always declare a sensitive variable as sensitive. This is because if you use Terraform within your CI/CD pipelines, unprivileged users might access sensitive information by looking at the logs.

Apart from the other three, an attribute called default will help you specify default variable values. The default values help you provide the best possible value for a variable, which your users can override if necessary.

Tip

Always use default values where possible, as they allow you to provide users with soft guidance about your enterprise standard and save them time.

The next step would be to provide variable values. Let’s have a look at that.

2024-05-08 by Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0

Using the Azure Terraform provider – Infrastructure as Code (IaC) with Terraform

Before we define the Azure Terraform provider, let’s understand what makes a Terraform root module. The Terraform root module is just a working directory within your filesystem containing one or more .tf files that help you define your configuration and are where you would typically run your Terraform commands.

Terraform scans all your .tf files, combines them, and processes them internally as one. Therefore, you can have one or more .tf files that you can split according to your needs. While there are no defined standards for naming .tf files, most conventions use main.tf as the main Terraform file where they define resources, a vars.tf file for defining variables, and outputs.tf for defining outputs.

For this discussion, let’s create a main.tf file within our working directory and add a provider configuration like the following:

terraform {
required_providers {
azurerm = {
source  = “azurerm”
version = “=3.55.0”
}
}
}
provider “azurerm” {
subscription_id = var.subscription_id
client_id            = var.client_id
client_secret     = var.client_secret
tenant_id            = var.tenant_id
features {}
}

The preceding file contains two blocks. The terraform block contains the required_providers block, which declares the version constraint for the azurerm provider. The provider block

declares an azurerm provider, which requires four parameters.

Tip

Always constrain the provider version, as providers are released without notice, and if you don’t include the version number, something that works on your machine might not work on someone else’s machine or the CI/CD pipeline. Using a version constraint avoids breaking changes and keeps you in control.

You might have noticed that we have declared several variables within the preceding file instead of

directly inputting the values. There are two main reasons for that – we want to make our template as generic as possible to promote reuse. So, suppose we want to apply a similar configuration in another subscription or use another service principal; we should be able to change it by changing the variable values. Secondly, we don’t want to check client_id and client_secret in source control. It

is a bad practice as we expose our service principal to users beyond those who need to know about it.

Tip

Never store sensitive data in source control. Instead, use a tfvars file to manage sensitive information and keep it in a secret management system such as HashiCorp’s Vault.

Okay, so as we’ve defined the provider resource and the attribute values are sourced from variables, the next step would be to declare variables. Let’s have a look at that now.

2024-04-03 by Building the Python Flask app Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0

Authentication and authorization with Azure – Infrastructure as Code (IaC) with Terraform

The simplest way to authenticate and authorize with Azure is to log in to your account using the Azure CLI. When you use the Azure provider within your Terraform file, it will automatically act as your account and do whatever it needs to. Now, this sounds dangerous. Admins generally have a lot of access, and having a tool that acts as an admin might not be a great idea. What if you want to plug Terraform into your CI/CD pipelines? Well, there is another way to do it – by using Azure service principals. Azure service principals allow you to access the required features without using a nameduser account. You can then apply the principle of least privilege to the service principal and provide only the necessary access.

Before configuring the service principal, let’s install the Azure CLI on our machine. To do so, run the following command:

$ curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

The preceding command will download a shell script and execute it using bash. The script will then automatically download and configure the Azure CLI. To confirm whether the Azure CLI is installed successfully, run the following command:

$ az –version 
azure-cli2.49.0

We see that the Azure CLI is correctly installed on the system. Now, let’s go ahead and configure the service principal.

To configure the Azure service principal, follow these steps.

Log in to Azure using the following command and follow all the steps the command prompts. You must browse to a specified URL and enter the given code. Once you’ve logged in, you will get a JSON response that will include some details, something like the following:

$ az login

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter

the code XXXXXXXXX to authenticate:

[

{

“id”: “00000000-0000-0000-0000-0000000000000”,

…

}

]

Make a note of the id attribute, which is the subscription ID, and if you have more than one subscription, you can use the following to set it to the correct one:

$ export SUBSCRIPTION_ID=”<SUBSCRIPTION_ID>”

$ az account set –subscription=”$SUBSCRIPTION_ID”

Use the following command to create a service principal with the contributor role to allow Terraform to manage the subscription’s infrastructure.

Tip

Follow the principle of least privilege while granting access to the service principal. Do not give privileges thinking you might need them in the future. If any future access is required, you can grant it later.

We use contributor access for simplicity, but finer-grained access is possible and should be used:

$ az ad sp create-for-rbac –role=”Contributor” \

–scopes=”/subscriptions/$SUBSCRIPTION_ID”

Creating ‘Contributor’ role assignment under scope ‘/subscriptions/<SUBSCRIPTION_ID>’ The output includes credentials that you must protect. Ensure you do not include these credentials in your code or check the credentials into your source control (for more information, see https://aka.ms/azadsp-cli): {

“appId”: “00000000-0000-0000-0000-0000000000000”,

“displayName”: “azure-cli-2023-07-02-09-13-40”,

“password”: “00000000000.xx-00000000000000000”,

“tenant”: “00000000-0000-0000-0000-0000000000000”

}

We’ve successfully created the service principal. The response JSON consists of appId, password, and tenant. We will need these to configure Terraform to use the service principal. In the next section, let’s define the Azure Terraform provider with the details.

2024-03-16 by Building the Python Flask app Cloud Certifications Exams of Cloud Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0

Load testing your app on Knative – Containers as a Service (CaaS) and Serverless Computing for Containers

We will use the hey utility to perform load testing. Since your application has already been deployed, run the following command to do the load test:

$ hey -z 30s -c 500 http://py-time.default.35.226.198.46.sslip.io

Once the command has executed, run the following command to get the currently running instances of the py-time pods:

$ kubectl get pod    
NAMEREADY STATUS RESTARTSAGE
py-time-00001-deployment-52vjv 2/2Running044s
py-time-00001-deployment-bhhvm 2/2Running044s
py-time-00001-deployment-h6qr5 2/2Running042s
py-time-00001-deployment-h92jp 2/2Running040s
py-time-00001-deployment-p27gl 2/2Running088s
py-time-00001-deployment-tdwrh 2/2Running038s
py-time-00001-deployment-zsgcg 2/2Running042s

As we can see, Knative has created seven instances of the py-time pod. This is horizontal autoscaling in action.

Now, let’s look at the cluster nodes by running the following command:

$ kubectl get nodes

NAME STATUS AGE gke-cluster-1-default-pool-353b3ed4-js71 Ready 3m17s gke-cluster-1-default-pool-353b3ed4-mx83 Ready 106m gke-cluster-1-default-pool-353b3ed4-vf7q Ready 106m

As we can see, GKE has created another node in the node pool because of the extra burst of traffic it received. This is phenomenal, as we have the Kubernetes API to do what we want. We have automatically horizontally autoscaled our pods. We have also automatically horizontally autoscaled our cluster worker nodes. This means we have a fully automated solution for runningcontainers without worrying about the management nuances! That is open source serverless in action for you!

Summary

This chapter covered CaaS and serverless CaaS services. These help us manage container applications with ease without worrying about the underlying infrastructure and managing them. We used Amazon’s ECS as an example and deep-dived into it. Then, we briefly discussed other solutions that are available on the market.

Finally, we looked at Knative, an open source serverless solution for containers that run on top of Kubernetes and use many other open source CNCF projects.

In the next chapter, we will delve into IaC with Terraform.

2023-11-05 by Deleting an ECS service Exams of Cloud Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0

Spinning up GKE – Containers as a Service (CaaS) and Serverless Computing for Containers

Once you’ve signed up and are on your console, you can open the Google Cloud Shell CLI to run the following commands.

You need to enable the GKE API first using the following command:

$ gcloud services enable container.googleapis.com

To create a two-node autoscaling GKE cluster that scales from 1 node to 5 nodes, run the following command:

$ gcloud container clusters create cluster-1 –num-nodes 2 \

–enable-autoscaling –min-nodes 1 –max-nodes 5 –zone us-central1-a

And that’s it! The cluster is up and running.

You will also need to clone the following GitHub repository for some of the exercises:

https://github.com/PacktPublishing/Modern-DevOps-Practices-2e

Run the following command to clone the repository into your home directory. Then, cd into the ch7 directory to access the required resources:

$ git clone https://github.com/PacktPublishing/Modern-DevOps-Practices-2e.git \ modern-devops

Now that the cluster is up and running, let’s go ahead and install Knative.

Installing Knative

We will install the CRDs that define Knative resources as Kubernetes API resources.

To access the resources for this section, cd into the following directory:

$ cd ~/modern-devops/ch7/knative/

Run the following command to install the CRDs:

$ kubectl apply -f \

https://github.com/knative/serving/releases/download/knative-v1.10.2/serving-crds.yaml

As we can see, Kubernetes has installed some CRDs. Next, we must install the core components of the Knative serving module. Use the following command to do so:

$ kubectl apply -f \

https://github.com/knative/serving/releases/download/knative-v1.10.2/serving-core.yaml

Now that the core serving components have been installed, the next step is installing Istio within the

Kubernetes cluster. To do so, run the following commands:

$ curl -L https://istio.io/downloadIstio | sh –

$ sudo mv istio-*/bin/istioctl /usr/local/bin

$ istioctl install –set profile=demo -y

Now that Istio has been installed, we will wait for the Istio Ingress Gateway component to be assigned an external IP address. Run the following command to check this until you get an external IP in the response:

$ kubectl -n istio-system get service istio-ingressgateway

NAME TYPE EXTERNAL-IP PORT(S) istio-ingressgteway LoadBalancer 35.226.198.46 15021,80,443

As we can see, we’ve been assigned an external IP—35.226.198.46. We will use this IP for the rest of this exercise.

Now, we will install the Knative Istio controller by using the following command:

$ kubectl apply -f \

https://github.com/knative/net-istio/releases/download/knative-v1.10.1/net-istio.yaml

Now that the controller has been installed, we must configure the DNS so that Knative can provide custom endpoints. To do so, we can use the MagicDNS solution known as sslip.io, which you can use for experimentation. The MagicDNS solution resolves any endpoint to the IP address present in the subdomain. For example, 35.226.198.46.sslip.io resolves to 35.226.198.46.

Note

Do not use MagicDNS in production. It is an experimental DNS service and should only be used for evaluating Knative.

Run the following command to configure the DNS:

$ kubectl apply -f \

https://github.com/knative/serving/releases/download/knative-v1.10.2\

/serving-default-domain.yaml

As you can see, it provides a batch job that gets fired whenever there is a DNS request.

Now, let’s install the HorizontalPodAutoscaler (HPA) add-on to automatically help us autoscale pods on the cluster with traffic. To do so, run the following command:

$ kubectl apply -f \

https://github.com/knative/serving/releases/download/knative-v1.10.2/serving-hpa.yaml

That completes our Knative installation.

Now, we need to install and configure the kn command-line utility. Use the following commands to do so:

$ sudo curl -Lo /usr/local/bin/kn \

https://github.com/knative/client/releases/download/knative-v1.10.0/kn-linux-amd64

$ sudo chmod +x /usr/local/bin/kn

In the next section, we’ll deploy our first application on Knative.

2023-09-28 by Building the Python Flask app Cloud Certifications Exams of Cloud Knative architecture Load testing your app on Knative 0

Other CaaS services – Containers as a Service (CaaS) and Serverless Computing for Containers

Amazon ECS provides a versatile way of managing your container workloads. It works great when you have a smaller, simpler architecture and don’t want to add the additional overhead of using a complex container orchestration engine such as Kubernetes.

Tip

ECS is an excellent tool choice if you run exclusively on AWS and don’t have a future multi-cloud or hybrid-cloud strategy. Fargate makes deploying and running your containers easier without worrying about the infrastructure behind the scenes.

ECS is tightly coupled with AWS and its architecture. To solve this problem, we can use managed services within AWS, such as Elastic Kubernetes Service (EKS). It offers the Kubernetes API to schedule your workloads. This makes managing containers even more versatile as you can easily spin up a Kubernetes cluster and use a standard, open source solution that you can install and run anywhere you like. This does not tie you to a particular vendor. However, EKS is slightly more expensive than ECS and adds a $0.10 per hour cluster management charge. That is nothing in comparison to the benefits you get out of it.

If you aren’t running on AWS, there are options from other providers too. The next of the big three cloud providers is Azure, which offers Azure Kubernetes Service (AKS), a managed Kubernetes solution that can help you get started in minutes. AKS provides a fully managed solution with event-driven elastic provisioning for worker nodes as and when required. It also integrates nicely with Azure DevOps, giving you a faster end- to-end (E2E) development experience. As with AWS, Azure also charges $0.10 per hour for cluster management.

Google Kubernetes Engine (GKE) is one of the most robust Kubernetes platforms. Since the Kubernetes project came from Google and is the largest contributor to this project in the open source community, GKE is generally quicker to roll out newer versions and is the first to release security patches into the solution. Also, it is one of the most feature-rich with customizable solutions and offers several plugins as a cluster configuration. Therefore, you can choose what to install on Bootstrap and further harden your cluster. However, all these come at a cost, as GKE charges a $0.10 cluster management charge per hour, just like AWS and Azure.

You can use Google Cloud Run if you don’t want to use Kubernetes if your architecture is not complicated, and there are only a few containers to manage. Google Cloud Run is a serverless CaaS solution built on the open source Knative project. It helps you run your containers without any vendor lock-in. Since it is serverless, you only pay for the number of containers you use and their resource utilization. It is a fully scalable and well-integrated solution with Google Cloud’s DevOps and monitoring solutions such as Cloud Code, Cloud Build, Cloud Monitoring, and Cloud Logging. The best part is that it is comparable to AWS Fargate and abstracts all infrastructure behind the scenes. So, it’s a minimal Ops or NoOps solution.

Now that we’ve mentioned Knative as an open source CaaS solution, let’s discuss it in more detail.

2023-05-12 by Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative 0

Deleting an ECS service – Containers as a Service (CaaS) and Serverless Computing for Containers

To delete the service, run the following command:

$ ecs-cli compose service down –cluster cluster-1

INFO[0001] Deleted ECS service service=FARGATE

INFO[0001] Service status desiredCount=0 runningCount=1 serviceName=FARGATE INFO[0006] Service status desiredCount=0 runningCount=0 serviceName=FARGATE INFO[0006] (service FARGATE) has stopped 1 running tasks: (task 9b48084d11cf49be85141fd9bfe9e1c3). timestamp=”2023-07-03 11:34:10 +0000 UTC” INFO[0006] ECS Service has reached a stable state desiredCount=0 runningCount=0 serviceName=FARGATE

As we can see, the service has been deleted.

Note that even if we create multiple instances of tasks, they run on different IP addresses and can be

accessed separately. However, tasks need to be load-balanced, and we need to provide a single endpoint.

Let’s look at a solution we can use to manage this.

Load balancing containers running on ECS

Load balancing is an essential functionality of multi-instance applications. They help us serve the application on a single endpoint. Therefore, you can have multiple instances of your applications

running simultaneously, and the end user doesn’t need to worry about which instance they’re calling. AWS provides two main load-balancing solutions—Layer 4 with the Network Load Balancer (NLB) and Layer 7 with the Application Load Balancer (ALB).

Tip

While both load balancers have their use cases, a Layer 7 load balancer provides a significant advantage for HTTP-based applications. It offers advanced traffic management, such as path-based and host-based routing.

So, let’s go ahead and create an ALB to frontend our tasks using the following command:

$ aws elbv2 create-load-balancer –name ecs-alb –subnets <SUBNET-1> <SUBNET-2> \ –security-groups <SECURITY_GROUP_ID> –region us-east-1

The output of the preceding command contains values for LoadBalancerARN and DNSName. We will need to use them in the subsequent steps, so keep a copy of the output safe.

The next step will be to create a target group. The target group defines the group of tasks and the port they will be listening to, and the load balancer will forward traffic to it. Use the following command to define a target group:

$ aws elbv2 create-target-group –name target-group –protocol HTTP \

–port 80 –target-type ip –vpc-id <VPC_ID> –region us-east-1

You will get the targetGroupARN value in the response. Keep it safe, as we will need it in the next step.

Next, we will need a listener running on the load balancer. This shouldforward traffic from the load balancer to the target group. Use the following command to do so:

$ aws elbv2 create-listener –load-balancer-arn <LOAD_BALANCER_ARN> \ –protocol HTTP –port 80 \

–default-actions Type=forward,TargetGroupArn=<TARGET_GROUP_ARN> \ –region us-east-1

You will get the listenerARN value in response to this command. Please keep that handy; we will need it in the next step.

Now that we’ve defined the load balancer, we need to run ecs-cli compose service up to deploy our service. We will also provide the target group as a parameter to associate our service with the load balancer.

To access the resources for this section, cd into the following directory:

$ cd ~/modern-devops/ch7/ECS/loadbalancing/

Run the following command to do so:

$ ecs-cli compose service up –create-log-groups –cluster cluster-1 \ –launch-type FARGATE –target-group-arn <TARGET_GROUP_ARN> \ –container-name web –container-port 80

Now that the service and our task are running on Fargate, we can scale our service to three desired tasks. To do so, run the following command:

$ ecs-cli compose service scale 3 –cluster cluster-1

Since our service has scaled to three tasks, let’s go ahead and hit the load balancer DNS endpoint we captured in the first step. This should provide us with the defaultnginx response. Run the following command to do so:

$ curl ecs-alb-1660189891.us-east-1.elb.amazonaws.com

<html>

<head>

<title>Welcome to nginx!</title>

…

</html>

As we can see, we get a default nginx response from the load balancer. This shows that load balancing is working well!

ECS provides a host of other features, such as horizontal autoscaling, customizable task placement algorithms, and others, but they are beyond the scope of this book. Please read the ECS documentation to learn more about other aspects of the tool. Now, let’s look at other popular CaaS products available on the market.

2023-03-16 by Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values 0

Scheduling services on ECS – Containers as a Service (CaaS) and Serverless Computing for Containers

ECS services are similar to Kubernetes ReplicaSets. They ensure that a certain number of tasks are always running at a particular time. To schedule a service, we can use the ecs-cli command line.

Tip

Always use services for applications that are long-running, such as web servers. For batch jobs, always use tasks, as we don’t want to recreate the job after it ends.

To run the nginx web server as a service, we can use the following command:

$ ecs-cli compose service up –create-log-groups \

–cluster cluster-1 –launch-type FARGATE

INFO[0001] Using ECS task definition TaskDefinition=”FARGATE:1″

INFO[0002] Auto-enabling ECS Managed Tags

INFO[0013] (service FARGATE) has started 1 tasks: (task 9b48084d).   timestamp=”2023-07-03

11:24:42 +0000 UTC”

INFO[0029] Service status desiredCount=1 runningCount=1 serviceName=FARGATE

INFO[0029] (service FARGATE) has reached a steady state. timestamp=”2023-07-03 11:25:00 +0000 UTC”

INFO[0029] (service FARGATE) (deployment ecs-svc/94284856) deployment completed. timestamp=”2023-07-03 11:25:00 UTC”

INFO[0029] ECS Service has reached a stable state desiredCount=1 runningCount=1 serviceName=FARGATE

INFO[0029] Created an ECS service service=FARGATE taskDefinition=”FARGATE:1″

Looking at the logs, we can see that the service is trying to ensure that the task’s desired count matches the task’s running count. If your task is deleted, ECS will replace it with a new one.

Let’s list the tasks and see what we get by using the following command:

$ ecs-cli ps –cluster cluster-1 Name State Ports cluster-1/9b48084d/web RUNNING 18.234.123.71:80

TaskDefinition

FARGATE:1

As we can see, the service has created a new task that is running on 18.234.123.71:80. Let’s try to access this URL using the following command:

$ curl 18.234.123.71

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

…

</html>

We get the default nginx home page in the response. Now, let’s try to browse the logs of the task.

Browsing container logs using the ECS CLI

Apart from using Amazon CloudWatch, you can also use the friendly ECS CLI to do this, irrespective of where your logs are stored. This helps us see everything from a single pane of glass.

Run the following command to do so:

$ ecs-cli logs –task-id 9b48084d –cluster cluster-1 /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration

/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/ default.conf

/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh

/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh

/docker-entrypoint.sh: Configuration complete; ready for start up

2023/07/03 11:24:57 [notice] 1#1: nginx/1.25.1

2023/07/03 11:24:57 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14)

2023/07/03 11:24:57 [notice] 1#1: OS: Linux 5.10.184-175.731.amzn2.x86_64

2023/07/03 11:24:57 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 65535:65535

2023/07/03 11:24:57 [notice] 1#1: start worker processes

2023/07/03 11:24:57 [notice] 1#1: start worker process 29

2023/07/03 11:24:57 [notice] 1#1: start worker process 30

13.232.8.130 – – [03/Jul/2023:11:30:38 +0000] “GET / HTTP/1.1” 200 615 “-” “curl/7.81.0”

“-“

As we can see, we can browse the logs for the particular task this service is running. Now, let’s go ahead and delete the service.

2023-02-04 by Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0