Providing variable values

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

Let’s use ecs-cli to apply the configuration and schedule our task using the following command:

$ ecs-cli compose up –create-log-groups –cluster cluster-1 –launch-type EC2

Now that the task has been scheduled and the container is running, let’s list all the tasks to get the container’s details and find out where it is running. To do so, run the following command:

$ ecs-cli ps –cluster cluster-1

Name State Ports TaskDefinition

cluster-1/fee1cf28/web RUNNING 34.237.218.7:80->80 EC2:1

As we can see, the web container is running on cluster-1 on 34.237.218.7:80. Now, use the following command to curl this endpoint to see what we get:

$ curl 34.237.218.7:80

<html>

<head>

<title>Welcome to nginx!</title>

…

</html>

Here, we get the default nginx home page! We’ve successfully scheduled a container on ECS using the EC2 launch type. You might want to duplicate this task to handle more traffic. This is known as horizontal scaling. We’ll see how in the next section.

Scaling tasks

We can easily scale tasks using ecs-cli. Use the following command to scale the tasks to 2:

$ ecs-cli compose scale 2 –cluster cluster-1 –launch-type EC2

Now, use the following command to check whether two containers are running on the cluster:

$ ecs-cli ps –cluster cluster-1
Name	State	Ports	TaskDefinition
cluster-1/b43bdec7/web	RUNNING	54.90.208.183:80->80	EC2:1
cluster-1/fee1cf28/web	RUNNING	34.237.218.7:80->80	EC2:1

As we can see, two containers are running on the cluster. Now, let’s query CloudWatch to get the logs of the containers.

Querying container logs from CloudWatch

To query logs from CloudWatch, we must list the log streams using the following command:

$ aws logs describe-log-streams –log-group-name /aws/webserver \ –log-stream-name-prefix ecs | grep logStreamName

“logStreamName”: “ecs/web/b43bdec7”,

“logStreamName”: “ecs/web/fee1cf28”,

As we can see, there are two log streams for this—one for each task. logStreamName follows the convention <log_stream_prefix>/<task_name>/<task_id>. So, to get the logs for ecs/ b43bdec7/web, run the following command:

$ aws logs get-log-events –log-group-name/aws/webserver \ –log-stream ecs/web/b43bdec7

Here, you will see a stream of logs in JSON format in the response. Now, let’s look at how we can stop running tasks.

Stopping tasks

ecs-cli uses the friendly docker-compose syntax for everything. Use the following command to stop the tasks in the cluster:

$ ecs-cli compose down –cluster cluster-1

Let’s list the containers to see whether the tasks have stopped by using the following command:

$ ecs-cli ps –cluster cluster-1

INFO[0001] Stopping container… container=cluster-1/b43bdec7/web INFO[0001] Stopping container… container=cluster-1/fee1cf28/web INFO[0008] Stopped container… container=cluster-1/b43bdec7/web desiredStatus=STOPPED lastStatus=STOPPED taskDefinition=”EC2:1″ INFO[0008] Stopped container… container=cluster-1/fee1cf28/web desiredStatus=STOPPED lastStatus=STOPPED taskDefinition=”EC2:1″

As we can see, both containers have stopped.

Running tasks on EC2 is not a serverless way of doing things. You still have to provision and manage the EC2 instances, and although ECS manages workloads on the cluster, you still have to pay for the amount of resources you’ve provisioned in the form of EC2 instances. AWS offers Fargate as a serverless solution where you pay per resource consumption. Let’s look at how we can create the same task as a Fargate task.

Installing the AWS and ECS CLIs – Containers as a Service (CaaS) and Serverless Computing for Containers

The AWS CLI is available as a deb package within the public apt repositories. To install it, run the following commands:

$ sudo apt update && sudo apt install awscli -y

$ aws –version

aws-cli/1.22.34 Python/3.10.6 Linux/5.19.0-1028-aws botocore/1.23.34

Installing the ECS CLI in the Linux ecosystem is simple. We need to download the binary and move to the system path using the following command:

$ sudo curl -Lo /usr/local/bin/ecs-cli \ https://amazon-ecs-cli.s3.amazonaws.com/ecs-cli-linux-amd64-latest $ sudo chmod +x /usr/local/bin/ecs-cli

Run the following command to check whether ecs-cli has been installed correctly:

$ ecs-cli –version

ecs-cli version 1.21.0 (bb0b8f0)

As we can see, ecs-cli has been successfully installed on our system.

The next step is to allow ecs-cli to connect with your AWS API. You need to export your AWS CLI environment variables for this. Run the following commands to do so:

$ export AWS_SECRET_ACCESS_KEY=…

$ export AWS_ACCESS_KEY_ID=…

$ export AWS_DEFAULT_REGION=…

Once we’ve set the environment variables, ecs-cli will use them to authenticate with the AWS API.

In the next section, we’ll spin up an ECS cluster using the ECS CLI.

Spinning up an ECS cluster

We can use the ECS CLI commands to spin up an ECS cluster. You can run your containers in EC2 and Fargate, so first, we will create a cluster that runs EC2 instances. Then, we will add Fargate tasks within the cluster.

To connect with your EC2 instances, you need to generate a key pair within AWS. To do so, run the following command:

$ aws ec2 create-key-pair –key-name ecs-keypair

The output of this command will provide the key pair in a JSON file. Extract the JSON file’s key material and save that in a separate file called ecs-keypair.pem. Remember to replace the \n characters with a new line when you save the file.

Once we’ve generated the key pair, we can use the following command to create an ECS cluster using the ECS CLI:

$ ecs-cli up –keypair ecs-keypair –instance-type t2.micro \ –size 2 –cluster cluster-1 –capability-iam

INFO[0002] Using recommended Amazon Linux 2 AMI with ECS Agent 1.72.0 and Docker version 20.10.23

INFO[0003] Created cluster cluster=cluster-1 region=us-east-1 INFO[0004] Waiting for your cluster resources to be created…

INFO[0130] Cloudformation stack status stackStatus=CREATE_IN_PROGRESS VPC created: vpc-0448321d209bf75e2

Security Group created: sg-0e30839477f1c9881

Subnet created: subnet-02200afa6716866fa

Subnet created: subnet-099582f6b0d04e419

Cluster creation succeeded.

When we issue this command, in the background, AWS spins up a stack of resources using CloudFormation. CloudFormation is AWS’s Infrastructure-as-Code (IaC) solution that helps you deploy infrastructure on AWS through reusable templates. The CloudFormation template consists of several resources such as a VPC, a security group, a subnet within the VPC, a route table, a route, a subnet route table association, an internet gateway, an IAM role, an instance profile, a launch configuration, an ASG, a VPC gateway attachment, and the cluster itself. The ASG contains two EC2 instances running and serving the cluster. Keep a copy of the output; we will need the details later during the exercises.

Now that our cluster is up, we will spin up our first task.

2022-09-05 by Clara Pinder Deleting an ECS service Exams of Cloud Providing variable values Using the Azure Terraform provider 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

Dynamic provisioning – Managing Advanced Kubernetes Resources

Dynamic provisioning is when Kubernetes provides storage resources for you by interacting with the cloud provider. When we provisioned the disk manually, we interacted with the cloud APIs using the gcloud command line. What if your organization decides to move to some other cloud provider later? That would break many existing scripts, and you would have to rewrite the storage provisioning steps. Kubernetes is inherently portable and platform-independent. You can provision resources in the same way on any cloud platform.

But then, different cloud providers have different storage offerings. How would Kubernetes know what kind of storage it needs to provision? Well, Kubernetes uses StorageClass resources for that. StorageClass resources are Kubernetes resources that define the type of storage they need to provide when someone uses it.

The following diagram illustrates dynamic provisioning:

Figure 6.10 – Dynamic provisioning

Let’s see an example storage class manifest, fast-storage-class.yaml, that provisions an SSD within GCP:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-ssd

The StorageClass resource contains a provisioner and any parameters the provisioner requires. You may have noticed that I have kept the name fast instead of gce-ssd or similar. That is because we want to keep the names as generic as possible.

Tip

Keep generic storage class names such as fast, standard, block, and shared, and avoid names specific to the cloud platform. Because storage class names are used in Persistent Volume claims, if you migrate to another cloud provider, you may end up changing a lot of manifests just to avoid confusion.

Let’s go ahead and apply the manifest using the following command:

$ kubectl apply -f fast-storage-class.yaml

As the StorageClass resource is created, let’s use it to provision an nginx StatefulSet resource dynamically.

We need to create a Service resource manifest, nginx-dynamic-service.yaml, first:

apiVersion: v1
kind: Service
metadata:
name: nginx-dynamic
labels:
app: nginx-dynamic
spec:
ports:
port: 80
name: web
clusterIP: None
selector:
app: nginx-dynamic

The manifest is very similar to the manual Service resource. Let’s go ahead and apply it using the following command:
$ kubectl apply -f nginx-dynamic-service.yaml
Now, let’s look at the StatefulSet resource manifest, nginx-dynamic-statefulset.yaml:
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-dynamic
spec:
…
serviceName: “nginx-dynamic”
template:
spec:
containers:
name: nginx
image: nginx volumeMounts:
name: html
mountPath: /usr/share/nginx/html
…
volumeClaimTemplates:
metadata:
name: html
spec:
storageClassName: “fast”
accessModes: [ “ReadWriteOnce” ]
resources:
requests:
storage: 40Gi

The manifest is similar to the manual one, but this one contains the storageClassName attribute in the volumeClaimTemplates section and lacks the selector section, as we are dynamically provisioning the storage. Use the following command to apply the manifest:

$ kubectl apply -f nginx-dynamic-statefulset.yaml

As the StatefulSet resource is created, let’s go ahead and check the PersistentVolumeClaim and PersistentVolume resources using the following commands:

$ kubectl get pvc
NAME		STATUS	VOLUME	CAPACITY	ACCESS MODES STORAGECLASS
html-nginx-dynamic-0		Bound	pvc-6b78	40Gi	RWO	fast
$ kubectl get pv
NAME	CAPACITY	ACCESS MODES RECLAIM POLICY			STATUS	CLAIM
pvc-6b78	40Gi	RWO	Delete		Bound	default/html-nginx-dynamic-0

And we can see that the claim is bound to a Persistent Volume that is dynamically provisioned. Now, let’s proceed and run the following command to do similar tests with this StatefulSet resource.

Let’s create a file in the nginx-dynamic-0 pod using the following command:

$ kubectl exec -it nginx-dynamic-0 — bash

root@nginx-dynamic-0:/# cd /usr/share/nginx/html/ root@nginx-dynamic-0:/usr/share/nginx/html# echo ‘Hello, dynamic world’ > index.html root@nginx-dynamic-0:/usr/share/nginx/html# exit

Now, delete the pod and open a shell session again to check whether the file exists by using the following commands:

$	kubectl delete pod nginx-dynamic-0
$	kubectl get pod	nginx-dynamic-0
NAME		READY	STATUS	RESTARTS	AGE
nginx-dynamic-0		1/1	Running	0	13s

$ kubectl exec -it nginx-dynamic-0 — bash
root@nginx-dynamic-0:/# cd /usr/share/nginx/html/
root@nginx-dynamic-0:/usr/share/nginx/html# cat index.html
Hello, dynamic world
root@nginx-dynamic-0:/usr/share/nginx/html# exit

And as we can see, the file exists in the volume, even if the pod was deleted. That is dynamic provisioning in action for you!

You will have observed that we have used the kubectl command multiple times throughout this chapter. When you perform activities throughout the day, using shortcuts and best practices wherever you can makes sense. Let’s look at some best practices while using kubectl.

2021-12-06 by Clara Pinder Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0