Building the Python Flask app

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

Troubleshooting containers with busybox using an alias – Managing Advanced Kubernetes Resources

We use the following commands to open a busybox session:

$ kubectl run busybox-test –image=busybox -it –rm –restart=Never — <cmd>

Now, opening several busybox sessions during the day can be tiring. How about minimizing the overhead by using the following alias?

$ alias kbb=’kubectl run busybox-test –image=busybox -it –rm –restart=Never –‘

We can then open a shell session to a new busybox pod using the following command:

$ kbb sh

/ #

Now, that is much cleaner and easier. Likewise, you can also create aliases of other commands that you use frequently. Here’s an example:

$ alias kgp=’kubectl get pods’

$ alias kgn=’kubectl get nodes’

$ alias kgs=’kubectl get svc’

$ alias kdb=’kubectl describe’

$ alias kl=’kubectl logs’

$ alias ke=’kubectl exec -it’

And so on, according to your needs. You may also be used to autocompletion within bash, where your commands autocomplete when you press Tab after typing a few words. kubectl also provides autocompletion of commands, but not by default. Let’s now look at how to enable kubectl autocompletion within bash.

Using kubectl bash autocompletion

To enable kubectl bash autocompletion, use the following command:

$ echo “source <(kubectl completion bash)” >> ~/.bashrc

The command adds the kubectl completion bash command as a source to your .bashrc file. So, the next time you log in to your shell, you should be able to use kubectl autocomplete. That will save you a ton of time when typing commands.

Summary

We began this chapter by managing pods with Deployment and ReplicaSet resources and discussed some critical Kubernetes deployment strategies. We then looked into Kubernetes service discovery and models and understood why we required a separate entity to expose containers to the internal or external world. We then looked at different Service resources and where to use them. We talked about Ingress resources and how to use them to create reverse proxies for our container workloads. We then delved into Horizontal Pod autoscaling and used multiple metrics to scale our pods automatically.

We looked at state considerations and learned about static and dynamic storage provisioning using

PersistentVolume, PersistentVolumeClaim, and StorageClass resources, and talked about some best practices surrounding them. We looked at StatefulSet resources as essential resources that help you schedule and manage stateful containers. Finally, we looked at some best practices, tips, and tricks surrounding the kubectl command line and how to use them effectively.

The topics covered in this and the previous chapter are just the core of Kubernetes. Kubernetes is a vast tool with enough functionality to write an entire book, so these chapters only give you the gist of what it is all about. Please feel free to read about the resources in detail in the Kubernetes official documentation at https://kubernetes.io.

In the next chapter, we will delve into the world of the cloud and look at Container-as-a-Service (CaaS) and serverless offerings for containers.

2022-02-08 by Clara Pinder Building the Python Flask app Deleting an ECS service Exams of Cloud Knative architecture Providing variable values 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