1.1 Describing the application

The application showcases a building block of a pet store. In the current version, the application shows a few pictures of cats.

The root directory of the application contains a file named docker-compose.yml that contains the declarative configuration of the application. The content of the file is as follows. It is a sequence of key-value pairs.

version: "3.6"
services:
  web:
    build: web
    image: pet-store-web
    networks:
      - backend
    ports:
      - 5000:3000
  db:
    build: database
    image: pet-store-db
    networks:
      - backend
    volumes:
      - pets-data:/var/lib/postgresql/data

networks:
  backend:

volumes:
  pets-data:

There are three main sections:

• services. Defines the services of the application. Here two services are defined: web and db.

• networks. Defines the networks used by the application. Here one network is defined: backend.

• volumes. Defines the volumes used by the application. Here one volume is defined: pets-data. The volume is attached to the directory /var/lib/postgresql/data (that is in the container).

When we’ll build the application from the file docker-compose.yml, two images will be created, one for each service.

1.2 Building the application

We now build the application.

• Open the command-line terminal and by using the command cd position yourself in the root directory pet-store of the application.

• Execute the following command:

docker-compose build

• During the build you might get a npm warning. Just ignore it.

• When the build is complete, verify that the two images corresponding to the two services have been created (which docker command do you need here?).

1.3 Executing the application

We now execute the application with the following command:

docker-compose up

The execution of the command will print a series of messages on screen. The terminal should hang when the messages stop (the last message should be database system is ready to accept connections).

Take no action on the screen and open a new terminal or a new tab in the current terminal window.

You can verify the answer to the previous question by typing the following command:

docker-compose ps

This command is exactly equivalent to docker container ls, except that it only shows the containers associated with the application that we’ve just executed.

1.4 Shutting down the application

You can shut down the application by typing the following command:

docker-compose down

1.5 Scaling a service

When we launch the application, we can specify the number of instances of each service. This is useful when we expect our application to be solicited by many users; the workload will be automatically balanced across all the instances of the service.

Let’s launch our application with 3 instances of the service web:

docker-compose up --scale web=3 -d

• Modify the file docker-compose.yml and relaunch the application.

• Run the following command and verify that you actually have three running instances of the service web.

docker-compose ps

• Try to connect to the application by using the three port numbers indicated in the output of the previous command.

2.1 Creating an account on DockerHub

You need to create an account on the DockerHub website in order to perform this activity.

2.2 Renaming the images

In order to push your images to the registry, you need to rename them, so as the new name has the following structure:

yourusername/image-name:image-tag

For instance, since my username is quercinigia, I’ll rename the two images pet-store-web and pet-store-db with the docker tag command as follows:

docker tag pet-store-web quercinigia/pet-store-web:1.0

docker tag pet-store-db quercinigia/pet-store-db:1.0

I chosen 1.0 as a tag, but feel free to pick another one.

2.3 Logging in

You need to log in to your DockerHub account.

2.4 Pushing the images

Once you’re successfully logged in, you can type the following commands in the terminal to push the two images of your application:

docker push YOUR-USERNAME/pet-store-web:1.0

docker push YOUR-USERNAME/pet-store-db:1.0

Remember to replace YOUR-USERNAME with your actual username in the commands above.

After the task is completed, verify that the images appear in your Docker registry.

services:
  web:
    build: web
    image: quercinigia/pet-store-web:1.0
  ...
  db:
    build: database
    image: quercinigia/pet-store-db:1.0
  ...

3.1 Activate Kubernetes

3.2 Deploying a pod

In order to deploy a pod, we first have to give its specification, basically its name and the containers that compose it with their settings. Similarly to Docker Compose, a pod is specified in a declarative way with a YAML configuration file.

Consider the following specification.

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web-pod
spec:
  containers:
  - name: web
    image: nginx:alpine
    ports:
    - containerPort: 80

Here is an explanation of the properties in the specification.

• apiVersion. Defines the versioned schema of this representation.

• kind. The type of the resource that we intend to create.

• metadata. The resource metadata. The list of all metadata is specified here.

• spec. The specification of the desired behaviour of the pod. The list of the possible specifications can be found here.

Essentially, the previous specification defines a pod with a container that is launched from the image nginx:alpine (a Web server) and listens to port 80.

The following configuration defines a Service object of type LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  ports:
  - port: 8080
    targetPort: 80
    protocol: TCP
    name: http
  selector:
      app: web-pod

4.1 The web service: deployment

For stateless application services, we can use a Deployment for the deployment of a set of identical pods that are launched across several nodes in the Kubernetes cluster.

We here define the specification of a Deployment corresponding to the service web.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pets
      service: web
  template:
    metadata:
      labels:
        app: pets
        service: web
    spec:
      containers:
      - image: quercinigia/pet-store-web:1.0
        name: web
        ports:
        - containerPort: 3000
          protocol: TCP

Here is the explanation of the specification:

• A Deployment named web is created, as indicated by the field metadata.name.

• The Deployment creates three replicated pods, as indicated by the field spec.replicas.

• The Deployment considers that the pods with both labels app: pets and service: web are part of the deployment. This is indicated by the field spec.selector.matchLabels. This field is used to let the Deployment know how to find its pods.

• The configuration of the pods that are part of the Deployment is given in the field spec.template and its subfields.

• Each pod of the Deployment is given labels app: pets and service: web. This is indicated by the field spec.template.metadata.labels. Note that here we specify exactly the same values as in spec.selector.matchLabels. This field is used to give pods labels so that they can be identified and located in Kubernetes.

• Each pod has exactly one container, named web, run from the image quercinigia/pet-store-web:1.0 stored in the DockerHub. The container listens on port 3000 and uses the TCP protocol. This is specified in the field spec.template.spec.containers.

4.2 The web service: service

Now we need to define a Service in order to expose the web service to the public. Here is the definition:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  ports:
  - port: 8080
    targetPort: 3000
    protocol: TCP
  selector:
    app: pets
    service: web

4.3 The db service: StatefulSet

Kubernetes has defined a special type of ReplicaSet for stateful services that is called StatefulSet.

Let’s define a StatefulSet to give the specification of the db service.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  selector:
    matchLabels:
      app: pets
      service: db
  serviceName: db
  template:
    metadata:
      labels:
        app: pets
        service: db
    spec:
      containers:
      - image: quercinigia/pet-store-db:1.0
        name: db
        ports:
        - containerPort: 5432
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: pets-data
  volumeClaimTemplates:
  - metadata:
      name: pets-data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi

By now you shouldn’t have any problem understanding the meaning of the fields in this specification. The fields are also documented in the official Kubernetes documentation. Two points are worth a comment. First, the specification of a StatefulSet needs an attribute serviceName that indicates the name of the service that is responsible for the network identify of the pods in the set. That attribute is mandatory.

Another novelty is the field volumeClaimTemplates. It describes additional constraints on the volumes defined in the specification, in this case the volume named pets-data (where PostgreSQL keeps the data). In particular, two claims are given:

• The access mode ReadWriteOnce means that the volume can be mounted as read-write by a single node in the Kubernetes cluster. Access modes are documented here.

• We request at least 100MB of storage for the database.

In the output of the command get kubectl all, look at the names of the pods that are instances of the web service. Take the name of any these pods, and put it in place of NAME-OF-POD in the following command:

kubectl logs NAME-OF-POD --previous

5.1 Shutting down the application

After you’re done with the application, you can shut it down with the following commands:

kubectl delete svc/web

kubectl delete svc/db

kubectl delete deploy/web

kubectl delete statefulset/db

The order in which you type these commands doesn’t matter.

If you type multiple times the command:

kubectl get all

you should see that the resources progressively disappear.

5.2 Conclusion

In the previous exercises, we deployed an application with two services, for which we had to create four files and type as many commands. For larger applications this gets a bit annoying. We can write all the definitions in a single file (e.g., pets.yaml) where each specification is terminated by - - -.

Here is an example, where we write the specification of the Service and Deployment associated with the service web.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  ports:
  - port: 8080
    targetPort: 3000
    protocol: TCP
  selector:
    app: pets
    service: web
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: pets
      service: web
  template:
    metadata:
      labels:
        app: pets
        service: web
    spec:
      containers:
      - image: quercinigia/pet-store-web:1.0
        name: web
        ports:
        - containerPort: 3000
          protocol: TCP