Knative architecture

terraform plan – Infrastructure as Code (IaC) with Terraform

To run a Terraform plan, use the following command:

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions:

  • azurerm_resource_group.rg will be created + resource “azurerm_resource_group” “rg” {
 +id= (known after apply)
 +location= “westeurope”
 + name= “terraform-exercise”
}   
Plan:1to add, 0 to change, 0 to destroy.

Note: You didn’t use the -out option to save this plan, so Terraform can’t guarantee to take exactly these actions if you run terraform apply now.

The plan output tells us that if we run terraform apply immediately, it will create a single terraform_exercise resource group. It also outputs a note that since we did not save this plan, the subsequent application is not guaranteed to result in the same action. Meanwhile, things might have changed; therefore, Terraform will rerun plan and prompt us for yes when applying. Thus, you should save the plan to a file if you don’t want surprises.

Tip

Always save terraform plan output to a file and use the file to apply the changes. This is to avoid any last-minute surprises with things that might have changed in the background and apply not doing what it is intended to do, especially when your plan is reviewed as a part of your process.

So, let’s go ahead and save the plan to a file first using the following command:

$ terraform plan -out rg_terraform_exercise.tfplan

This time, the plan is saved to a file calledrg_terraform_exercise.tfplan. We can use this file to apply the changes subsequently.

terraform apply

To apply the changes using the plan file, run the following command:

$ terraform apply “rg_terraform_exercise.tfplan”

azurerm_resource_group.rg: Creating…

azurerm_resource_group.rg: Creation complete after 2s [id=/subscriptions/id/ resourceGroups/terraform-exercise]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

And that’s it! Terraform has applied the configuration. Let’s use the Azure CLI to verify whether the resource group is created.

Run the following command to list all resource groups within your subscription:

$ az group list

…

“id”: “/subscriptions/id/resourceGroups/terraform-exercise”,

“location”: “westeurope”,

“name”: “terraform-exercise”,

…

We see that our resource group is created and within the list.

There might be instances when apply is partially successful. In that case, Terraform will automatically taint resources it believes weren’t created successfully. Such resources will be recreated automatically in the next run. If you want to taint a resource for recreation manually, you can use the terraform taint command:

$ terraform taint <resource>

Suppose we want to destroy the resource group as we no longer need it. We can use terraform destroy for that.

2024-08-31 by Building the Python Flask app Cloud Certifications Deleting an ECS service Exams of Cloud Knative architecture 0

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

Technical requirements – Infrastructure as Code (IaC) with Terraform

Cloud computing is one of the primary factors of DevOps enablement today. The initial apprehensions about the cloud are a thing of the past. With an army of security and compliance experts manning cloud platforms 24×7, organizations are now trusting the public cloud like never before. Along with cloud computing, another buzzword has taken the industry by storm – Infrastructure as Code (IaC). This chapter will focus on IaC withTerraform, and by the end of this chapter, you will understand the concept and have enough hands-on experience with Terraform to get you started on your journey.

In this chapter, we’re going to cover the following main topics:

  • Introduction to IaC
  • Setting up Terraform and Azure providers
  • Understanding Terraform workflows and creating your first resource using Terraform
  • Terraform modules
  • Terraform state and backends
  • Terraform workspaces
  • Terraform outputs, state, console, and graphs

Technical requirements

For this chapter, you can use any machine to run Terraform. Terraform supports many platforms, including Windows, Linux, and macOS.

You will need an active Azure subscription to follow the exercises. Currently, Azure is offering a free trial for 30 days with $200 worth of free credits; you can sign up at https://azure.microsoft. com/en-in/free.

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, and cd into the ch8 directory to access the required resources:

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

$ cd modern-devops/ch8

So, let’s get started!

2023-12-21 by Building the Python Flask app Cloud Certifications Exams of Cloud Knative architecture 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

Open source CaaS with Knative – Containers as a Service (CaaS) and Serverless Computing for Containers

As we’ve seen, several vendor-specific CaaS services are available on the market. Still, the problem with most of them is that they are tied up to a single cloud provider. Our container deployment specification then becomes vendor-specific and results in vendor lock-in. As modern DevOps engineers, we must ensure that the proposed solution best fits the architecture’s needs, and avoiding vendor lock-in is one of the most important requirements.

However, Kubernetes in itself is not serverless. You must have infrastructure defined, and long-running services should have at least a single instance running at a particular time. This makes managing microservices applications a pain and resource-intensive.

But wait! We said that microservices help optimize infrastructure consumption. Yes—that’s correct, but they do so within the container space. Imagine that you have a shared cluster of VMs where parts of the application scale with traffic, and each part of the application has its peaks and troughs. Doing this will save a lot of infrastructure by performing this simple multi-tenancy.

However, it also means that you must have at least one instance of each microservice running every time—even if there is zero traffic! Well, that’s not the best utilization we have. How about creating instances when you get the first hit and not having any when you don’t have traffic? This would save a lot of resources, especially when things are silent. You can have hundreds of microservices making up the application that would not have any instances during an idle period. If you combine it with a managed service that runs Kubernetes and then autoscale your VM instances with traffic, you can have minimal instances during the silent period.

There have been attempts within the open source and cloud-native space to develop an open source, vendor-agnostic, serverless framework for containers. We have Knative for this, which the Cloud Native Computing Foundation (CNCF) has adopted.

Tip

The Cloud Run service uses Knative behind the scenes. So, if you use Google Cloud, you can use Cloud Run to use a fully managed serverless offering.

To understand how Knative works, let’s look at the Knative architecture.

2023-06-17 by Cloud Certifications Deleting an ECS service Exams of Cloud Knative architecture 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