containers Archives - Laura Liparulo's blog

Docker – hello world example

February 10, 2022February 10, 2022

To run your first docker container, you can simply use a busybox image. With a single command, docker will download and execute the application inside a n isolated container:

> docker run busybox echo "Hello world"

As the image was not present on the machine, Docker pulled it from the Docker Hub Registry.

Another way is to create a simple two lines Dockerfile, like:

FROM alpine
CMD ["/bin/sh", "-c", "echo 'hello world'"]

As you can see, the starting point (with “FROM”) is an alpine base image. Then it´s just a matter of running an echo command in it.
From the folder where the Dockerfile is stored, invoke:

docker build -t helloworld .

And you get in the console:

Run:  
docker run hello-world
And you will see again:
hello world
As you can see, docker pulls the base alpine image  (6dbb9cc54074)
You can check the history of the container:
docker history hello-world

Or inspect it:

docker inspect f5d273aa2dcb

And finally remove it:

docker rmi -f f5d237aa2dcb

Kubernetes – Imperative Job creation

February 2, 2022February 12, 2022

Let´s create a job the imperative way, by using the docker whalesay image:

kubectl create job whalesay --image=docker/whalesay --dry-run=client -o yaml > job.yaml -- cowsay I am going to ace CKAD!

We are using the “dry-run” option to create a yaml manifest without creating the job.

In the last part of the command with add a command for the container, that will be put directly in the manifest.

Once the file is created, we can add parameters like completions, parallelism and backoffLimit under the spec.template section, like this:

Then we need to create the job, by running:

kubectl create -f job.yaml -n <your-namespace>

After a while we can see the pods have been run and completed:

If you inspect the log of one of the pod, you can see the funny whale comics:

kubectl logs whalesay-7h27f

MORE ABOUT JOBS

Specifying the restartPolicy is mandatory for a Job.

Notice that:

a job is persisted and survives cluster restarts
a completed job is kept for tracking purposes

Kubernetes – Multi-Containers Design Pattern

February 12, 2022February 12, 2022

cloud , CONTAINERS , Kubernetes

A multi-container pod can be defined by the following structural design patterns:

init container
sidecar
ambassador
adapter

The are basically best practices and distributed system design patterns.

They contribute to achieving separation of concerns.

INIT CONTAINERS
Init containers are additional containers used to complete tasks before the regular containers are started in a pod.

For example:

spec:
  template:
    metadata:
      labels:
         app: flask
    spec:
      containers:
      - name: flask
        image: quay.io/kubernetes-for-developers/flask:0.2.0
        ports:
        - containerPort: 5000
        envFrom:
        - configMapRef:
           name: flask-config
        volumeMounts:
          - name: config
            mountPath: /etc/flask-config
            readOnly: true
      volumes:
        - name: config
          configMap:
            name: flask-config
      initContainers:
      - name: init-myservice
        image: busybox
        command: ['sh', '-c', 'until nslookup redis-master; do echo waiting for redis; sleep 2; done;']

SIDECAR

A sidecar container is meant to assist the main container with additional functionalities, like intercepting the inbound traffic, or aggregating logs.

The main application container is unaware of the sidecar container.

Let´s consider, for example, a central logging agent.

      containers:

      - name: cleaner-con

        image: bash:5.0.11

        args: ['bash', '-c', 'while true; do echo `date`: "remove random file" >> /var/log/cleaner/cleaner.log; sleep 1; done']

        volumeMounts:

        - name: logs

          mountPath: /var/log/cleaner

      - name: logger-con

        image: busybox:1.31.0

        command: ["sh", "-c", "tail -f /var/log/cleaner/cleaner.log"]

        volumeMounts:

        - name: logs

          mountPath: /var/log/cleaner

In the code about the sidecar container is called “logger-con”

The sidecar container will send the logs to a central logging service, for aggregation purporse.

This would have a huge benefit, as your changes to your central logging policy (for example, a new provider) will only affected the dedicates side container.

This would prevent you from breaking the application containers while performing logging updates.

ADAPTER

If the sidecar container is meant to adapt data for the container, it´s called an adapter.

The adapter pattern is about standardizing output from the main application container.

Consider the case of a service that is being rolled out incrementally: it may generate reports in a format that doesn’t conform to the previous version.

Other services and applications that consume that output haven’t been upgraded yet. An adapter container can be deployed in the same pod with the new application container and massage the output to match the old version until all consumers have been upgraded.

The adapter container shares the filesystem with the main application container, so it can watch the local filesystem, and whenever the new application writes something, it immediately adapts it.

AMBASSADOR

It´s a container calling other containers on behalf of the main container.

This allows to have several ambassadors according to protocols or different database types.

For example you might have a Database ambassador for MySql and another one for oracle-db.

It´s a specialization of a sidecar, responsible for hiding complexity and providing interfaces.

Kubernetes – updating strategies

February 11, 2022February 12, 2022

cloud , CONTAINERS , Kubernetes

The applications you deploy on Kubernetes will often need updates. Rather than deploying them from scratch again, you can take advantage of different update strategies.

A live update is not trivial, especially if you have interactions between different parts of the system, inter-dependecies among pods, etc.

in many cases you need to keep your applications running also while performing maintenance and upgrading tasks. After all, it´s what Kubernetes is designed for: providing high availability and reliability.

There ae several updating strategies like:

rolling update
blue-green deployments
canary deployments

ROLLING UPDATE

With a rolling update strategy, Kubernetes creates a new ReplicaSet, replacing the Replicas one by one. the cluster will be running current and new components at the same time. If the components are backward-compatible, it´s a lot easier of course.

Two strategies possible:

– Recreate , which means killing all the pods before creating the new ones

– RollingUpdate – which guarantees the availability of the service during the update

RollingUpdate is the default strategy and can be tuned to guarantee a minimal and maximal amount of pods available during the update by using the options “maxSurge” and “maxUnavailable”.

The way an update is handled can be defined as a strategy in the spec.strategy section of the deployment manifest, like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: random-generator
spec:
  replicas: 3                            
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1                        
      maxUnavailable: 1                  
    selector:
      matchLabels:
        app: random-generator
    template:
      metadata:
        labels:
          app: random-generator
      spec:
        containers:
        - image: k8spatterns/random-generator:1.0
            name: random-generator
          readinessProbe:                
            exec:
              command: [ "stat", "/random-generator-ready" ]

Notice that we can use both integer and percentages as value in the options. It means that the following is also valid:

strategy:

rollingUpdate:

maxSurge: 25%

maxUnavailable: 50%

type: RollingUpdate

You might have to create a temporary compatibility layer, while doing your updates. So Rolling updates is not the answer to more complex architectures.

BLUE-GREEN

It consists of preparing a full new version deployment for the whole production environment. So you have a blue old productive environment and a brand new green one ready to be put in place. If you have storage data to carry with you in the new version, you might need additional efforts.

The green deployment doesn´t serve any request, until the staff is confident that it will be working properly. That´s when the blue deployment will be killed and replaced.

Such strategy can be aided by extensions like a Service Mesh or Knative.

A drawback is that it takes double capacity.

CANARY DEPLOYMENT

A canary deployment is a new version deployment that is only submitted to a subset of users for testing purposes. Only when the subset of new instances will be satisfying, the whole deployment will be replaced.

This technique can be implemented by creating a new ReplicaSet for the new container version, by using a new deployment, with few replicas.

Tag: containers

Docker – hello world example

Kubernetes – Imperative Job creation

Kubernetes – Multi-Containers Design Pattern

Kubernetes – updating strategies

Linux Day 2011 Call for Papers (IT)

Discovering Sqlite by Banshee media player

First steps in Sqlite and Perl

Sqlite database backup: the .dump command

Privacy Policy

What information do we collect?

What do we use your information for?

How do we protect your information?

Do we use cookies?

Do we disclose any information to outside parties?

Registration

Children’s Online Privacy Protection Act Compliance

Updating your personal information

Online Privacy Policy Only

Your Consent

Changes to our Privacy Policy