Cloud Certifications

Creating task definitions – Containers as a Service (CaaS) and Serverless Computing for Containers

ECS tasks are similar to Kubernetes pods. They are the basic building blocks of ECS and comprise one or more related containers. Task definitions are the blueprints for ECS tasks and define what the ECS task should look like. They are very similar to docker-compose files and are written in YAML format. ECS also uses all versions of docker-compose to allow us to define tasks. They help you define containers and their images, resource requirements, where they should run (EC2 or Fargate), volume and port mappings, and other networking requirements.

Tip

Using the docker-compose manifest to spin up tasks and services is a great idea, as it will help you align your configuration with an open standard.

A task is a finite process and only runs once. Even if it’s a long-running process, such as a web server, the task still runs once as it waits for the long-running process to end (which runs indefinitely in theory). The task’s life cycle follows the Pending -> Running -> Stopped states. So, when you schedule your task, the task enters the Pending state, attempting to pull the image from the container registry. Then, it tries to start the container. Once the container has started, it enters the Running state. When the container has completed executing or errored out, it ends up in the Stopped state. A container with startup errors directly transitions from the Pending state to the Stopped state.

Now, let’s go ahead and deploy an nginx web server task within the ECS cluster we just created.

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

$ cd ~/modern-devops/ch7/ECS/tasks/EC2/

We’ll use docker-compose task definitions here. So, let’s start by defining the following docker-compose.yml file:

version: ‘3’
services:
web:
image: nginx
ports:
“80:80”
logging: driver: awslogs options:
awslogs-group: /aws/webserver
awslogs-region: us-east-1
awslogs-stream-prefix: ecs

The YAML file defines a web container with an nginx image with host port 80 mapped to container port 80. It uses the awslogs logging driver, which streams logs into Amazon CloudWatch. It will stream the logs to the /aws/webserver log group in the us-east-1 region with the ecs stream prefix.

The task definition also includes the resource definition—that is, the amount of resources we want to reserve for our task. Therefore, we will have to define the following ecs-params.yaml file:

version: 1
task_definition:
services:
web:
cpu_shares: 100
mem_limit: 524288000

This YAML file defines cpu_shares in millicores and mem_limit in bytes for the container we plan to fire. Now, let’s look at scheduling this task as an EC2 task.

Amazon ECS with EC2 and Fargate – Containers as a Service (CaaS) and Serverless Computing for Containers-2

ECS is a cloud-based regional service. When you spin up an ECS cluster, the instances span multiple AZs, where you can schedule your tasks and services using simple manifests. ECS manifests are very similar to docker-compose YAML manifests, where we specify which tasks to run and which tasks comprise a service.

You can run ECS within an existing VPC. We can schedule tasks in either Amazon EC2 or AWS Fargate.

Your ECS cluster can have one or more EC2 instances attached to it. You also have the option to attach an existing EC2 instance to a cluster by installing the ECS node agent within your EC2 instance. The agent sends information about your containers’ state and tasks to the ECS scheduler. It then interacts with the container runtime to schedule containers within the node. They are similar to kubelet in the Kubernetes ecosystem. If you run your containers within EC2 instances, you pay for the number of EC2 instances you allocate to the cluster.

If you plan to use Fargate, the infrastructure is wholly abstracted from you, and you must specify the amount of CPU and memory your container is set to consume. You pay for the CPU and memory your container consumes rather than the resources you allocate to the machines.

Tip

Although you only pay for the resources you consume in Fargate, it is more expensive than running your tasks on EC2, especially when running long -running services such as a web server. A rule of thumb is to run long-running online tasks within EC2 and batch tasks with Fargate. That will give you the best cost optimization.

When we schedule a task, AWS spins up the container on a managed EC2 or Fargate server by pulling the required container image from a container registry. Every task has an elastic network interface (ENI) attached to it. Multiple tasks are grouped as a service, and the service ensures that all the required tasks run at once.

Amazon ECS uses a task scheduler to schedule containers on your cluster. It places your containers in an appropriate node of your cluster based on placement logic, availability, and cost requirements. The scheduler also ensures that the desired number of tasks run on the node at a given time.

The following diagram explains the ECS cluster architecture beautifully:

Figure 7.1 – ECS architecture

Amazon provides the ECS command-line interface (CLI) for interacting with the ECS cluster. It is a simple command-line tool that you can use to administer an ECS cluster and create and manage tasks and services on the ECS cluster.

Now, let’s go ahead and install the ECS CLI.

2022-08-15 by Clara Pinder Building the Python Flask app Cloud Certifications Exams of Cloud Knative architecture Load testing your app on Knative 0

The need for serverless offerings – Containers as a Service (CaaS) and Serverless Computing for Containers

Numerous organizations, so far, have been focusing a lot on infrastructure provisioning and management. They optimize the number of resources, machines, and infrastructure surrounding the applications they build. However, they should focus on what they do best—software development. Unless your organization wants to invest heavily in an expensive infrastructure team to do a lot of heavy lifting behind the scenes, you’d be better off concentrating on writing and building quality applications rather than focusing on where and how to run and optimize them.

Serverless offerings come as a reprieve for this problem. Instead of concentrating on how to host your infrastructure to run your applications, you can declare what you want to run, and the serverless offering manages it for you. This has become a boon for small enterprises that do not have the budget to invest heavily in infrastructure and want to get started quickly without wasting too much time standing up and maintaining infrastructure to run applications.

Serverless offerings also offer automatic placement and scaling for container and application workloads. You can spin from 0 to 100 instances in minutes, if not seconds. The best part is that you pay for what you use in some services rather than what you allocate.

This chapter will concentrateon a very popular AWS container management offering called ECS and AWS’s container serverless offering, AWS Fargate. We will then briefly examine offerings from other cloud platforms and, finally, the open source container-based serverless solution known as Knative.

Now, let’s go ahead and look at Amazon ECS.

2022-05-22 by Clara Pinder Building the Python Flask app Cloud Certifications Exams of Cloud Providing variable values Using the Azure Terraform provider 0

Technical requirements – Containers as a Service (CaaS) and Serverless Computing for Containers

In the last two chapters, we covered Kubernetes and how it helps manage your containers seamlessly. Now, let’s look at other ways of automating and managing container deployments—Containers as a Service (CaaS) and serverless computing for containers. CaaS provides container-based virtualizationthat abstracts away all management behind the scenes and helps you manage your containers without worrying about the underlying infrastructure and orchestration.

For simple deployments and less complex applications, CaaS can be a savior. Serverless computing is a broad term that encompasses applications that can be run without us having to worry about the infrastructure behind the scenes. It has an additional benefit that you can focus purely on the application. We will discuss CaaS technologies such as Amazon Elastic Container Service (Amazon ECS) with Amazon Web Services Fargate (AWS Fargate) in detail and briefly discuss other cloud-based CaaS offerings such as Azure Kubernetes Services (AKS), Google Kubernetes Engine (GKE), and Google Cloud Run. We will then delve into the popular open source serverless CaaS solution known as Knative.

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

The need for serverless offerings

Amazon ECS with Elastic Compute Cloud (EC2) and Fargate

Other CaaS services

Open source CaaS with Knative

Technical requirements

You will need an active AWS subscription for this chapter’s exercises. AWS is the market’s most popular, feature-rich cloud platform. Currently, AWS is offering a free tier for some products. You can sign up for this at https://aws.amazon.com/free. This chapter uses some paid services, but we will try to minimize how many we use as much as possible during the exercises.

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

$ cd modern-devops/ch7

As the repository contains files with placeholder strings, you must replace the <your_dockerhub_ user> string with your actual Docker Hub user. Use the following commands to substitute the placeholders:

$ find ./ -type f -exec sed -i -e \

‘s/<your_dockerhub_user>/<your actual docker hub user>/g’ {} \;

So, let’s get started!

2022-04-06 by Clara Pinder Cloud Certifications Exams of Cloud Load testing your app on Knative Using the Azure Terraform provider 0

Kubernetes command-line best practices, tips, and tricks – Managing Advanced Kubernetes Resources

For seasoned Kubernetes developers and administrators, kubectl is a command they run most of the time. The following steps will simplify your life, save you a ton of time, let you focus on more essential activities, and set you apart from the rest.

Using aliases

Most system administrators use aliases for an excellent reason—they save valuable time. Aliases in Linux are different names for commands, and they are mostly used to shorten the most frequently used commands; for example, ls -l becomes ll.

You can use the following aliases with kubectl to make your life easier.

k for kubectl

Yes—that’s right. By using the following alias, you can use k instead of typing kubectl:

$	alias k=’kubectl’
$	k get node
NAME		STATUS	ROLES	AGE	VERSION
kind-control-plane		Ready	master	5m7s	v1.26.1
kind-worker		Ready	<none>	4m33s	v1.26.1

That will save a lot of time and hassle.

Using kubectl –dry-run

kubectl –dry-run helps you to generate YAML manifests from imperative commands and saves you a lot of typing time. You can write an imperative command to generate a resource and append that with a –dry-run=client -o yaml string to generate a YAML manifest from the imperative command. The command does not create the resource within the cluster, but instead just outputs the manifest. The following command will generate a Pod manifest using –dry-run:

$ kubectl run nginx –image=nginx –dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: nginx
name: nginx
spec:
containers:
image: nginx
name: nginx
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

And you now have the skeleton YAML file that you can edit according to your liking.

Now, imagine typing this command multiple times during the day! At some point, it becomes tiring. Why not shorten it by using the following alias?

$ alias kdr=’kubectl –dry-run=client -o yaml’

You can then use the alias to generate other manifests.

To generate a Deployment resource manifest, use the following command:

$ kdr create deployment nginx –image=nginx

You can use the dry run to generate almost all resources from imperative commands. However, some resources do not have an imperative command, such as a DaemonSet resource. You can generate a manifest for the closest resource and modify it for such resources. A DaemonSet manifest is very similar to a Deployment manifest, so you can generate a Deployment manifest and change it to match the DameonSet manifest.

Now, let’s look at some of the most frequently used kubectl commands and their possible aliases.

kubectl apply and delete aliases

If you use manifests, you will use the kubectl apply and kubectl delete commands most of the time within your cluster, so it makes sense to use the following aliases:

$ alias kap=’kubectl apply -f’

$ alias kad=’kubectl delete -f’

You can then use them to apply or delete resources using the following commands:

$ kap nginx-deployment.yaml

$ kad nginx-deployment.yaml

While troubleshooting containers, most of us use busybox. Let’s see how to optimize it.

2022-01-17 by Clara Pinder Building the Python Flask app Cloud Certifications Deleting an ECS service Exams of Cloud 0