DEV Community: Waji

Kubernetes Introduction for Starters

Waji — Thu, 27 Apr 2023 05:45:13 +0000

Introduction

Kubernetes is a container orchestration tool that has revolutionized the way we deploy and manage containerized applications. It is an open-source platform that automates container deployment, scaling, and management. Kubernetes architecture is designed to make container orchestration easier, faster, and more efficient

Container Orchestration

Container orchestration refers to the process of managing complex configurations of various containers using server administration and management code. It supports automation of tasks such as clustering server resources, container deployment and management, service discovery and access, load handling, and fault recovery

Docker Swarm is also one of the popular container orchestration tools, with Kubernetes being the de facto standard

Why use Container Orchestration?

In typical container virtualization, deployment and operation management consume a lot of resources, making efficient container management impossible.

By using container orchestration tools, clustered servers can be managed in a centralized manner, greatly reducing management resources.

With container orchestration tools, automated deployment and scaling, rollouts/rollbacks, and container recovery operations can be implemented.

▣ Example: Building container images using only container virtualization and deploying them to multiple servers

Kubernetes Architecture

Kubernetes is a de facto standard container orchestration tool that was open-sourced by Google in 2014
Kubernetes supports most of the functions required for container-based service operation, such as container deployment in MSA structure and service fault recovery.
Kubernetes has high scalability as it supports most of the functions and components required for operation in a cloud environment and can be easily integrated with other cloud operating tools.
It has high reliability and stability as it is developed and maintained by an open-source project involving companies such as Google and Red Hat.
Most of the various components that make up the container orchestration are developed and updated based on Kubernetes.
Currently, Kubernetes is an open-source project managed by the Cloud Native Computing Foundation (CNCF) (URL: https://landscape.cncf.io/)

So what are the components included in the Kubernetes Cluster?

💡 A cluster refers to a logical binding of several servers configured to be used as if they were one server

Kubernetes composes of the Master and its Worker nodes.

Master Node

Master node has different core components that make up a “Kubernetes control Plane”
The core components include an API Server, Controller Manager, Scheduler and etcd
Master node is used for administrative tasks only
It manages the entire Kubernetes cluster, assigning scheduled tasks to the worker nodes, managing the health of the system, scaling applications to go up and down
Essentially its the brain of the Kubernetes Cluster

Let’s look into the Components included in the Master Node

→ kube-API Server: The API Server refers to a server that provides APIs to control internal resources within the Kubernetes cluster (The API Server must be accessible from outside the Kubernetes cluster)

→ kube-scheduler: The scheduler is responsible for scheduling resource requests for Kubernetes resources. It selects the optimal node to handle resource requests that require node allocation by examining the status of the worker nodes that make up the Kubernetes cluster.

→ kube-controller-mananger: It watches the state of the Kubernetes cluster and makes changes to bring the state of the Kubernetes cluster back to the desired state.

→ etcd: etcd is a distributed key-value store used to store configuration data for the Kubernetes cluster. It is used to store the state of the Kubernetes cluster, such as node status and service status.

💡 Also, it keeps the cluster’s current and its desired states so if the Kubernetes find any distinguishes between the two states - it will apply the desired state

There are several Add-ons inside the Control Plane that can further activate some extra features. These add on components are:

Metrics-server — It collects resource usage status of the nodes inside the K8s cluster by collecting the metrics such as CPU and memory usage

Core-DNS — A DNS server used within the cluster

Dashboard — Provides a GUI web-based dashboard for managing the cluster

Worker Node

It was previously known as the minion node
Worker nodes run the applications and workloads of the Kubernetes cluster.
It is responsible for running containers and handling the container runtime environment.
The core components include Kubelet, Container runtime and Kube-proxy

Looking into the main components of the worker node:

→ kubelet: It is the main Kubernetes component that communicates with the API server of the Master node to register nodes in a Kubernetes cluster. It manages the lifecycle of pods and also monitors the status of nodes and pods.

💡 The kubelet communicates to Docker(or another container runtime) daemon via its API to create and manage containers. After any changes in a Pod on a Node – it will send them to the API server, which in its turn will save them to the etcd database

→ kube-proxy: It is a network proxy that runs on every worker node and generates and manages network rules for each node. It is just like a reverse-proxy that forwards requests to appropriate service or application inside a K8s private network

→ Container Runtime: It runs on all worker nodes and is responsible for running and managing containers (Docker in almost all cases)

The K8s Workflow

So basically the workflow looks like the following:

The engineer/developer creates a manifest file that describes the desired state of the application or workload that has to be deployed in the cluster. It contains details about the containers, volumes, networking and other resources that are required for the application
💡 The manifest file uses the YAML format as it is human-readable and easy to understand
The manifest file is applied using the kubectl command-line tool that communicates with the K8s API-server
The API server receives the manifest file and validates it for correctness and compliance with the Kubernetes API schema. If the manifest file is valid, it stores the desired state of the application in etcd database
The scheduler component of the Master node continuously monitors the state of the Kubernetes cluster and the available resources on each worker node. When a new pod needs to be scheduled, the scheduler queries the API server to obtain the current state of the cluster along with the current state of the worker nodes and the desired state.
The scheduler selects a suitable worker node according to the scheduling policy and then instructs the API server to create the pod on that node. The API server then updates the desired state of the cluster in etcd to include the new pod and its current status.
The kubelet component of the worker node receives the instructions to run the new pod from the API server. It communicates with the container runtime to create the container for the pod, based on the specifications provided in the manifest file
After the container is created, the kubelet communicates with the kube-proxy to set up a network routing rules and load balancing for the pod, so it can communicate with other pods and services inside the cluster

Kubernetes Features

Let’s look into some of the core features that Kubernetes offer:

Self-healing: Kubernetes can automatically restart or replace containers that fail to run properly
Automated Rollouts & Rollbacks: The current deployment status can be changed at a speed that suits the desired deployment state
Service Discovery & Load Balancing: Kubernetes can expose containers within the cluster to the outside world using DNS names or their own IP addresses. For services with high network traffic loads, network traffic can be load balanced by deploying them to ensure stable service operation
Storage Orchestration: Kubernetes can link local storage servers and storage services provided by public cloud providers for use. External storage server resources can be easily used, and data persistence can be ensured
Secret and Configuration Management: Kubernetes can safely store and manage important information such as passwords, SSH keys, and OAuth tokens. When the container configuration information is changed, Kubernetes can deploy and update it by reflecting the changes in the configuration information without reconstructing the container image
Automatic Bin Packing: Kubernetes receives resource utilization required for container operation and provides the most appropriate cluster node for container operation.

Conclusion

Today we looked at Kubernetes, the most popular container orchestration tool today. We also looked at what components are present inside the Kubernetes cluster and how they work. Finally, we discussed important features that Kubernetes bring to the table. To check out how to set up a working Kubernetes cluster, without using any managed cloud services(often referred to "Vanilla" Kubernetes), follow this link

References

K8s Architecture and main components overview
K8s in 5 minutes

Docker Registry Management

Waji — Wed, 08 Mar 2023 03:11:03 +0000

Introduction

A Docker registry is a place to store Docker images. There are two types of Docker registries

Private registry
Public registry

Docker Hub is a popular public registry, but organizations often prefer to use their own private registry to store and manage their images as it provides more control over image access and security.

Docker registry management involves pushing and pulling images from a registry, as well as managing access control, security, and versioning. To facilitate these tasks, various Docker registry management tools are available, such as Docker Trusted Registry, Harbor, and JFrog Artifactory

👉 In this post, I will be testing Docker-Hub repository, Nexus Repository and then apply GitHub actions to build an image automatically (CI)

Hands on Docker-Hub

💡 If you don't have a dockerhub ID, you can refer to the steps mentioned over here

After logging in to our account in Docker hub, we need to head to 'repositories' and select 'create repository'

Creating a private repository

Once the repository is created, we can confirm the repository name

Now back to our Linux terminal. I will be working on a new directory



mkdir /DockerFile_Root
cd /DockerFile_Root

Creating a simple test index.html file



cat "Test" > index.html

Creating a Dockerfile



vi Dockerfile

FROM nginx:latest
LABEL maintainer "Author <Author@localhost.com>"
ADD index.html /usr/share/nginx/html

Building this dockerfile



docker build -t mynginx:v1 ./

Successfully built a367f58de111
Successfully tagged mynginx:v1

Logging in to my docker hub



docker login
Username:
Password:
Login Succeeded

Pushing the image to our docker hub repository



docker tag mynginx:v1 waji97/myrepo:v1
docker push waji97/myrepo:v1

Deleting the local images and tags



docker rmi mynginx:v1
docker rmi waji97/myrepo:v1

Checking the repository from dockerhub

Now we can start a docker container on our local machine using this image from our dockerhub



docker run -d --name Mynginx_1 -p 80:80 waji97/myrepo:v1
Unable to find image 'waji97/myrepo:v1' locally
v1: Pulling from waji97/myrepo
.
.
Status: Downloaded newer image for waji97/myrepo:v1
c3eeab8e250c18e472f105356790368253eb60991532d0b9b786829f94bf6bbe

👉 We can see that it pulled from my repository

Checking the docker process and images



docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                NAMES
c3eeab8e250c        waji97/myrepo:v1    "/docker-entrypoint.…"   About a minute ago   Up About a minute   0.0.0.0:80->80/tcp   Mynginx_1

docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
waji97/myrepo       v1                  a367f58de111        10 minutes ago      142MB

We can also visit our nginx server

Hands on Nexus Repository

Nexus repository is a popular open-source repository manager developed by Sonatype. Nexus provides storing & managing software components, access control and integration with tools like Jenkins and Docker.

It was mainly used with Java projects and the repositories were accessible by an WEB UI. We will be using Nexus repository to build a private image repository using docker format.

There are three types of nexus repository:

Hosted: a private repository within a company (uploads are only possible locally)
Proxy: mirrors remote repositories (cache)
Group: groups various types of repositories together

👉 Before starting the hands on, I recommend turning off swap memory using swapoff -a

We will start by creating a volume



docker volume create nexus_volume
nexus_volume

Next we will change the ownership for the data directory for this volume



chown 200:200 /var/lib/docker/volumes/nexus_volume/_data/

👉 We need to change this as not changing this could possibly incur push/pull errors later

Pulling the nexus image



docker pull sonatype/nexus3:latest

Now, we will create a new container for our nexus repo



docker run -d --name Nexus -p 8081:8081 -p 5000-5001:5000-5001 -v nexus_volume:/nexus-data sonatype/nexus3

👉 I would recommend to have atleast 3GBs of RAM in your host system for the above to actually run



docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                      NAMES
9c68a0f95437        sonatype/nexus3     "/opt/sonatype/nexus…"   3 seconds ago       Up 1 second         0.0.0.0:5000-5001->5000-5001/tcp, 0.0.0.0:8081->8081/tcp   Nexus

Now we need to copy the password from



cat /var/lib/docker/volumes/nexus_volume/_data/admin.password

👉 Copy the password that is displayed

Navigating to the Nexus Repo Manager via our browser and logging in as 'admin' user

This will trigger a new 'change password' wizard. We can change our admin account password using this wizard

From settings, we will navigate to 'Blob Stores'

Creating a new blob to use as docker-registry

Now heading to "Repositories" and clicking on "Create repository"

We need to select 'docker(hosted)' from here and set up as following

After creating the above repository, we need to create another one named 'docker(proxy)'

Finally we will create our 'docker(group)' repository as well

Adding all the members to our group

Now from the "Security" section, we will navigate to Realms

Adding the "Docker Bearer Token Realm"

👉 Going back to our Linux terminal

We will add the following to our daemon JSON file



vi /etc/docker/daemon.json

"insecure-registries" : ["192.168.1.10:5000", "192.168.1.10:5001"]

💡 We had to add this as Nexus supports HTTPS but we are using HTTP

Reloading the daemon and restarting docker



systemctl daemon-reload
systemctl restart docker

docker start Nexus
Nexus

Now we can pull a test image for our nexus repository



docker pull 192.168.1.10:5000/hello-world
Using default tag: latest
latest: Pulling from hello-world
.
Status: Downloaded newer image for 192.168.1.10:5000/hello-world:latest

To confirm if this image was downloaded,

We will perform another test by tagging our existing 'alpine' image to our nexus repository



docker tag alpine 192.168.1.10:5001/myalpine:v1

Logging in to our repository



docker login 192.168.1.10:5001
Username:
Password:
Login Succeeded

Pushing the tagged image to our repository



docker push 192.168.1.10:5001/myalpine:v1
The push refers to repository [192.168.1.10:5001/myalpine]
7cd52847ad77: Pushed 

# Logging out
docker logout 192.168.1.10:5001/myalpine:v1

Confirming this push from the WEB UI

Hands on GitHub actions (CI)

GitHub Actions is a powerful CI/CD tool for automating software development workflows. It allows developers to automate tasks, build, test, and deploy code directly from GitHub.

Workflows are defined in YAML format and consist of Events and Jobs.
Events are triggers that execute a workflow.
Events can be configured to trigger on actions such as a push to a repository.
Workflows can contain multiple Jobs.
When multiple Jobs are present, parallel execution is the default behavior.
A Runner is required to execute Jobs and is typically a container.

✨ WorkFlow:-

Workflow: The entire workspace for building, deploying, and testing.
Event: The trigger for a Workflow to run (when it executes).
Job: The unit of work in a Workflow.
Step: Defines the sequence of tasks that a Job should perform.
Action: A pre-defined function (library) that performs a specific task. Runner: A containerized instance used to execute a Workflow.

👉 I will be doing a short hands on in which we will use Github actions to automatically create a docker image and push it to the dockerhub repository

From GitHub, we need to create a new repository for testing Github actions

Now from DockerHub

Now we will navigate to "My profile" => "Edit Profile" => "Security"

From this section, we will create a new access token with Read, Write and Delete permissions

👉 Going back to Github

From our repository, we will head to settings and select

We will make 2 new secrets, one contains your DockerHub username and the other should contain the Access Token that we created from Dockerhub

Now from our Github repository, we will create a new Dockerfile and also add a test html file

We will head to "Actions" and setup our custom workflow

My workflow YAML file looks like this

👉 This file will build an image and push it automatically to Dockerhub using Dockerfile present in the Github repository's main branch

Upon committing this file, we will have a new workflows folder in our repository

We can also check our actions section

To test if this actually worked, we will go to our Dockerhub repository

👉 Dockerhub test repository

We will test this image from our Linux Terminal now

Creating a container using our image from Dockerhub



docker login

docker run -d --name Mynginx_1 -p 80:80 waji97/testrepo:latest
latest: Pulling from waji97/testrepo
.
.
Status: Downloaded newer image for waji97/testrepo:latest
6bd35189a8261f80ed6763bd75f78cb0172bd21a0abcdb871ffb047c0d9e9729

Testing from the browser

👉 We will now try changing our index.html file from Github and commit so that Github actions can actually integrate this automatically

Upon committing the changes, we will be able to see a new workflow

Now from the Linux System, we will delete the container and the image.

After deleting the current image, we will pull the latest image from our Dockerhub repository and create a new container using the image to check our results

✨ This is Continuous Integration

Conclusion

In conclusion, managing a Docker registry is an essential aspect of containerization. Dockerhub, Nexus Repository, and Github Actions CI are three popular options for Docker registry management, each with their own advantages and limitations ✔

Docker-Compose Management

Waji — Tue, 07 Mar 2023 04:52:43 +0000

Introduction

Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to define the services that make up your application and how they interact with each other. Docker Compose uses a YAML file to configure the application services, networks, and volumes.

Here are some of the key elements we can find in a Docker Compose YAML file:

version: Specifies the version of the Docker Compose file format being used.
services: Defines the various services that make up the application. Each service is given a name and specifies its image, ports, environment variables, and any other necessary configuration options.
networks: Specifies the networks that the application's services will use to communicate with each other.
volumes: Defines the volumes that will be mounted to the containers in the application. configs: Specifies configuration files that will be injected into the containers as Docker Configs.
secrets: Specifies secrets that will be injected into the containers as Docker Secrets.
deploy: Specifies options for deploying the application as a stack, including replicas, update policies, and placement constraints.

💡 To read more regarding docker compose, you can look at the official documentation over here

Some of the important terminologies

✨ Infrastructure as Code (IaC)

Technology for deploying and managing IT system infrastructure in the form of software, rather than by people.
As the software is written in source code, management quality can be improved.
Decreased work time for infrastructure managers due to parallel processing of multiple systems.
Cost savings due to efficient processing possible by reducing work time.
Lower error rate because only defined operations are performed by the software.

✨ Container Scaling Out (Scale Out)

Scale out refers to increasing the number of servers operating the service in response to increasing loads to distribute the load.
Horizontal scaling of containers: one of the core technologies of microservices, it prevents unnecessary system expansion by horizontally scaling only the containers responsible for a specific service.
Vertical scaling (Scale Up): Concept of expanding the server vertically by increasing insufficient resources such as CPU and RAM.
Traditional monolithic scaling method / Hardware is added because the entire system server cannot be added (there are limitations).

✨ Service Dependency and Discovery

Services running on each container in a specific project have interdependent relationships (e.g., WEB-DB-Kafka, etc.).
In a cloud environment, each service runs on an instance, and these instance information (IP, Port, etc.) has a characteristic that can easily change depending on the situation.
Services with interdependencies are highly sensitive to such changes, and to quickly reflect the changed information, service discovery must be configured.

Docker Compose Wordpress

For starters, I will be creating an emtpy directory



mkdir /Compose
cd /Compose

Creating a new .yml file



vi docker-compose.yml

# Compose File Format Version

version: '3.7'    
services:
  wordpress_db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: wordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    networks:
      - wordpress_net
    volumes:
      - wordpress_data:/var/lib/mysql

  wordpress:
    depends_on:
      - wordpress_db
    image: wordpress:latest
    restart: always
    ports:
      - "80:80"
    environment:
      WORDPRESS_DB_HOST: wordpress_db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    networks:
      - wordpress_net
    volumes:
      - wordpress_web:/var/www/html

volumes:
  wordpress_data: {}
  wordpress_web: {}

networks:
  wordpress_net: {}

Checking the docker-compose version



docker-compose -v
Docker Compose version v2.2.3

If we use the following,



docker-compose config

It will show us the current configuration for the docker compose file in the current directory

Now composing the YAML file



docker-compose up -d

 ⠿ Network compose_wordpress_net     Created                                        0.4s
 ⠿ Volume "compose_wordpress_data"   Created                                        0.0s
 ⠿ Volume "compose_wordpress_web"    Created                                        0.0s
 ⠿ Container compose-wordpress_db-1  Created                                        0.7s
 ⠿ Container compose-wordpress-1     Created                                        0.0s

👉 The -d option declares the container to run in the background

After the compose build is done, we can check the docker volume and network are created as per the compose file



docker volume ls
local               compose_wordpress_data
local               compose_wordpress_web

docker network ls
755a8af21193        compose_wordpress_net   bridge              local

We can also check compose status as well



docker-compose ls
docker-compose ps

Now if we open the website using the IP address of our host system

💡 When deleting composed containers, we can use docker-compose down however this won't delete the docker volume. We will need to include the -v option to delete the docker volume as well

Docker Compose building Nginx

I will now demonstrate using docker compose to build a Dockerfile

Creating a new directory



mkdir /Compose/build
cd /Compose/build

Creating an index.html



echo "Hello My Nginx" > index.html

Creating the Dockerfile



vi Dockerfile

FROM nginx:latest
LABEL maintainer "Author <Author@localhost.com>“
ADD index.html /usr/share/nginx/html

Creating the docker-compose YAML file



vi docker-compose.yml

version: '3.7'
services:
  web:
    image: myweb/nginx:v1
    build: .
    restart: always

Now using docker compose to build our Dockerfile



docker-compose -p myweb up -d --build

[+] Running 2/2
 ⠿ Network myweb_default  Created                                                   0.1s
 ⠿ Container myweb-web-1  Started                                                   0.2s

👉 Here the "-p" option specifies a project name, and the "--build" option skips the image search and pull, performing only the build operation. If the "--build" option is omitted, the pull operation is automatically performed, but using it is recommended during build operations to avoid errors.

We can confirm the process



docker-compose -p myweb ps -a
NAME                COMMAND                  SERVICE             STATUS              PORTS
myweb-web-1         "/docker-entrypoint.…"   web                 running             80/tcp

Another thing we can try is,



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

[+] Running 3/3
 ⠿ Container myweb-web-3  Started                                                   0.9s
 ⠿ Container myweb-web-2  Started                                                   0.9s
 ⠿ Container myweb-web-1  Started                                                   0.9s

Checking the compose process again



docker-compose -p myweb ps

NAME                COMMAND                  SERVICE             STATUS              PORTS
myweb-web-1         "/docker-entrypoint.…"   web                 running             80/tcp
myweb-web-2         "/docker-entrypoint.…"   web                 running             80/tcp
myweb-web-3         "/docker-entrypoint.…"   web                 running             80/tcp

👉 With the "--scale" option, it's possible to horizontally scale specific service containers, explicitly declaring a scale of 1 reduces the containers to 1. However, this option cannot be used when ports are specified, as it's not possible to expose multiple containers to the outside with the same port number. To serve multiple instances of the same web container, a proxy server must be used

Docker Compose HAproxy with Nginx LB

Starting with an empty directory



mkdir /Compose/prod
cd /Compose/prod

Creating an index.html



echo "Hello My Nginx" > index.html

Creating a Dockerfile for Nginx and HAproxy



vi Dockerfile_nginx

FROM nginx:latest
LABEL maintainer "Author <Author@localhost.com>"
ADD index.html /usr/share/nginx/html
WORKDIR /usr/share/nginx/html

vi Dockerfile_haproxy

FROM haproxy:2.3
LABEL maintainer "Author <Author@localhost.com>"
ADD haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

Configuring the haproxy.cfg file



vi haproxy.cfg
global
        log /dev/log  local0
        log /dev/log  local1 notice
        chroot /var/lib/haproxy
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

defaults
        log global
        mode http
        option httplog
        option dontlognull
        option dontlog-normal
        option http-server-close
        maxconn 3000
        timeout connect 10s
        timeout http-request 10s
        timeout http-keep-alive 10s
        timeout client 1m
        timeout server 1m
        timeout queue 1m

listen stats
        bind *:9000
        stats enable
        stats realm Haproxy Stats Page
        stats uri /
        stats auth admin:haproxy1

frontend proxy
        bind *:80
        default_backend WEB_SRV_list

backend WEB_SRV_list
        balance roundrobin
        option httpchk HEAD /
        server prod-web-1 prod-web-1:80 check inter 3000 fall 5 rise 3
        server prod-web-2 prod-web-2:80 check inter 3000 fall 5 rise 3
        server prod-web-3 prod-web-3:80 check inter 3000 fall 5 rise 3

👉 At the backend section of the configuration file, the web server's status is checked using the HEAD method every 3 seconds. If the status check fails 5 times in a row, the web server is removed from the load balancer group. If the server becomes available again and passes 3 consecutive status checks, it is added back to the load balancer group.

Finally creating the docker compose YAML file



vi docker-compose.yml

version: '3.7'
services:
  proxy:
    depends_on:
      - web
    image: prod/haproxy:v1
    build:
      context: ./
      dockerfile: ./Dockerfile_haproxy

    restart: always
    ports:
      - "80:80"
      - "9000:9000"
    networks:
      - myweb_net

  web:
    image: prod/nginx:v1
    build:
      context: ./
      dockerfile: ./Dockerfile_nginx
    restart: always
    deploy:
      mode: replicated
      replicas: 3
    networks:
      - myweb_net

networks:
  myweb_net: {}

Using docker compose to build our Dockerfiles



docker-compose up -d --build

Successfully built 5deb0e3b5821
Successfully tagged prod/haproxy:v1
[+] Running 5/5
 :: Network prod_myweb_net  Created                                                                  0.2s
 :: Container prod-web-3    Started                                                                  0.7s
 :: Container prod-web-1    Started                                                                  0.7s
 :: Container prod-web-2    Started                                                                  0.6s
 :: Container prod-proxy-1  Started                                                                  1.5s

Once the job is done, we can check the processes



docker-compose ps
NAME                COMMAND                  SERVICE             STATUS              PORTS
prod-proxy-1        "docker-entrypoint.s…"   proxy               running             0.0.0.0:80->80/tcp, 0.0.0.0:9000->9000/tcp
prod-web-1          "/docker-entrypoint.…"   web                 running             80/tcp
prod-web-2          "/docker-entrypoint.…"   web                 running             80/tcp
prod-web-3          "/docker-entrypoint.…"   web                 running             80/tcp

To test if the load balancing if it is working between these 3 web pages, we can include a different entry in each of the web server



docker exec -it prod-web-1 /bin/bash
root@c6f1c535ce6c:/usr/share/nginx/html# echo "prod-web-1 Server Main Page" >> index.html
root@c6f1c535ce6c:/usr/share/nginx/html# cat index.html
Hello My Nginx
prod-web-1 Server Main Page

docker exec -it prod-web-2 /bin/bash
root@e86233007a76:/usr/share/nginx/html# echo "prod-web-2 Server Main Page" >> index.html
root@e86233007a76:/usr/share/nginx/html# cat index.html
Hello My Nginx
prod-web-2 Server Main Page

docker exec -it prod-web-3 /bin/bash
root@11aa89e08619:/usr/share/nginx/html# echo "prod-web-3 Server Main Page" >> index.html
root@11aa89e08619:/usr/share/nginx/html# cat index.html
Hello My Nginx
prod-web-3 Server Main Page

Testing our setup

👉 We can confirm that round robin load balancing is working

Conclusion

In conclusion, Docker Compose is a powerful tool that simplifies the process of managing and deploying complex multi-container applications. Through hands-on experience building an Nginx server with HAProxy and a WordPress application, we have seen how Docker Compose streamlines the management of container orchestration, network configuration, and service scaling.

Docker Logs & Monitoring

Waji — Mon, 06 Mar 2023 05:46:55 +0000

Introduction

Effective log and monitoring management is essential for ensuring the health and performance of Docker containers. By leveraging Docker's built-in log and monitoring tools, as well as third-party tools, we can gain insights into our containers' behavior and troubleshoot any issues that arise

I will be utilizing docker logs and docker events commands to manage logs. Furthermore, I will also use cAdvisor to monitor logs

Utilizing Docker Logs

Starting a mysql container



docker run -d --name log_con1 mysql:5.7

Checking the status



docker ps -a
8f2640092ab8        mysql:5.7           "docker-entrypoint.s…"   17 minutes ago      Exited (1) 10 seconds ago                       log_con1

To check logs for this container



docker logs log_con1
.
.
2023-03-06 05:04:29+00:00 [ERROR] [Entrypoint]: Database is uninitialized and password option is not specified
    You need to specify one of the following as an environment variable:
    - MYSQL_ROOT_PASSWORD
    - MYSQL_ALLOW_EMPTY_PASSWORD
    - MYSQL_RANDOM_ROOT_PASSWORD

Now, to test live logs, we will start another container



docker run -it --name log_con2 ubuntu:bionic

Opening another terminal and entering the following



docker logs -f log_con2

👉 It will be in a standby to wait for any action in the ubuntu container

From the container



echo "Log Test"

We will be able to see the logs from the host system on the other terminal



root@6246287978ac:/# echo "Log Test"
Log Test

We can inspect the container to confirm how logs are saved



docker container inspect log_con2

"LogConfig": {
 "Type": "json-file",
 "Config": {}
},

👉 We can see that log files are saved in JSON format in the host system

💡 The log files are present under /var/lib/docker/containers/

We can also edit the docker daemon file to rotate logs if they reach a certain size or value



vi /etc/docker/daemon.json

{
 "log-driver": "json-file",
 "log-opts": {
 "max-size": "10k",
 "max-file": "5"
 }
}

💡 If there is no daemon.json file, we can create one

Restarting the daemon and docker service



systemctl daemon-reload
systemctl restart docker

Starting another container



docker run -d --name log_con3 ubuntu:bionic
docker container inspect log_con3

"LogConfig": {
 "Type": "json-file",
 "Config": {
 "max-file": "5",
 "max-size": "10k"
 }
},

👉 We can confirm that the container started with the log rotate configurations

Utilizing Docker Events

With another terminal connected, we will enter



docker events

👉 On standby mode to fetch live logs

From the other terminal,



docker run -d --name events_con nginx:latest
docker rm -f events_con

Now going back to the first terminal to check logs,



docker events

2023-03-06T14:35:09.394975329+09:00 container create 6ec4910cc606a135ca6fe1d10b8f9fdaf88c5dc008e53c00f28c7d1e8325f51b (image=nginx:latest, maintainer=NGINX Docker Maintainers <docker-maint@nginx.com>, name=events_con)
.
.
.
2023-03-06T14:35:15.131094800+09:00 container destroy 6ec4910cc606a135ca6fe1d10b8f9fdaf88c5dc008e53c00f28c7d1e8325f51b (image=nginx:latest, maintainer=NGINX Docker Maintainers <docker-maint@nginx.com>, name=events_con)

Utilizing Container Advisor

cAdvisor (Container Advisor) is an open-source container monitoring tool that is integrated with Docker. It is designed to provide detailed information about the resource usage and performance of running containers, including CPU, memory, disk, and network utilization.

👉 The best part about this tool is that we can examine container logs via a WEB interface

Starting a cAdvisor container



docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:rw \
--volume=/sys/fs/cgroup:/sys/fs/cgroup:ro \
--volume=/dev/disk/:/dev/disk:ro \
--privileged=true \
--publish=8080:8080 \
--detach=true \
--name=cAdvisor google/cadvisor:latest

Now if we open our browser and go to the address of our host linux system

I wil use a Stress container to check CPU usage via cAdvisor



docker run --rm -d progrium/stress --cpu 2 --vm 2 --vm-bytes 128M --timeout 30s

Conclusion

In conclusion, managing Docker logs is essential for monitoring the health and performance of Docker containers. I utilized several docker commands and an open-source tool to keep tabs with our container logs ✔

Docker Image Management

Waji — Mon, 06 Mar 2023 04:57:41 +0000

Introduction

Docker image management involves creating, managing, and distributing Docker images. Docker images are the building blocks of Docker containers, which are lightweight and portable virtualized environments that can run anywhere. It uses a layered architecture to build and manage Docker images. Each layer in the Docker image represents a specific set of changes or additions to the previous layer.

Docker Image Archive

Docker provides two different methods to save and load Docker images:

docker save/docker load

docker export/docker import

👉 docker save and docker load are used to save and load entire Docker images along with all of their layers and metadata.

👉 docker export and docker import are used to export and import a container as a tar file. Docker export and docker import do not include metadata or information about the image's layers.

Short hands on

Save/Load

Creating an empty directory



mkdir /image_backup

Checking current images detail



docker images;
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              904b8cb13b93        4 days ago          142MB
ubuntu              bionic              b89fba62bc15        4 days ago          63.1MB
mysql               latest              4f06b49211c0        10 days ago         530MB
mysql               5.7                 be16cf2d832a        4 weeks ago         455MB

To save a backup for a specific image



docker save -o /image_backup/ubuntu.tar ubuntu:bionic

So now if we delete the image



docker rmi ubuntu:bionic

# Checking for the image
docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              904b8cb13b93        4 days ago          142MB
mysql               latest              4f06b49211c0        10 days ago         530MB
mysql               5.7                 be16cf2d832a        4 weeks ago         455MB

We can load the ubuntu:bionic image from the backup directory



docker load -i /image_backup/ubuntu.tar

Checking the results



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              904b8cb13b93        4 days ago          142MB
ubuntu              bionic              b89fba62bc15        4 days ago          63.1MB
mysql               latest              4f06b49211c0        10 days ago         530MB
mysql               5.7                 be16cf2d832a        4 weeks ago         455MB

Export/Import

Creating a new container using the ubuntu image



docker run -d --name image_con ubuntu:bionic

Exporting this container



docker export image_con -o /image_backup/image_con.tar

ls -l /image_backup/
total 127984
-rw------- 1 root root 65521664 Mar  6 09:34 image_con.tar
-rw------- 1 root root 65529856 Mar  6 09:30 ubuntu.tar

Now we can import this image with a different tag



docker import /image_backup/image_con.tar myubuntu:v1

Checking the results



docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
myubuntu            v1                  3e3a5217f941        3 seconds ago       63.1MB
nginx               latest              904b8cb13b93        4 days ago          142MB
ubuntu              bionic              b89fba62bc15        4 days ago          63.1MB

Docker Image Commit & Build

docker commit and docker build are both Docker commands used to create Docker images

docker commit command is used to create a new Docker image from an existing container. This command is useful when you have made changes to a running container, and you want to save those changes as a new image.

docker build command is used to create a new Docker image from a Dockerfile. A Dockerfile is a script that contains instructions on how to build a Docker image

Some of the commonly used Dockerfile instructions:

FROM: This instruction is used to specify the base image that the new image will be built on top of
LABEL: This instruction is used to add metadata to the image
RUN: This instruction is used to execute commands within the container
ADD: This instruction is used to copy files from the host system into the container
WORKDIR: This instruction is used to set the working directory for any subsequent commands in the Dockerfile
EXPOSE: This instruction is used to specify which port(s) the container will listen on at runtime
CMD: This instruction is used to specify the default command to be executed when the container starts
ENTRYPOINT: This instruction is used to specify the command that will be executed when the container starts, and it cannot be overridden when the container is run

Short hands on

Docker Commit

To check how many layers are there in the ubuntu image



docker inspect ubuntu:bionic

"Layers": [
                "sha256:52c5ca3e9f3bf4c13613fb3269982734b189e1e09563b65b670fc8be0e223e03"
            ]

Creating the container using the -it option



docker run -it --name commit_con ubuntu:bionic

From inside the container,



cat > TestFile
TestFile

ls
TestFile  boot  etc   lib    media  opt   root  sbin  sys  usr
bin       dev   home  lib64  mnt    proc  run   srv   tmp  var

Now from the host machine



docker commit -a "MyName" -m "Image Comment" commit_con myubuntu:v1.0.0

We can confirm this commit using



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
myubuntu            v1.0.0              2e214faf96f7        32 seconds ago      63.1MB

Inspecting our v1.0.0 ubuntu image



            "Layers": [
                "sha256:52c5ca3e9f3bf4c13613fb3269982734b189e1e09563b65b670fc8be0e223e03",
                "sha256:cea6ad35f448cdba9f2bb5c32b245c497e90cafa36c8f856706c8257bb666e34"
            ]

👉 We can see that a new image was created with an extra layer when we committed the changes for our ubuntu container

Docker Build

Creating an empty directory for our dockerfile



mkdir /DockerFile_root
cd /DockerFile_root

Creating an empty dockerfile



vi Dockerfile # Using this default name is more efficient

Adding the following inside this file



FROM ubuntu:bionic  
LABEL maintainer "Author <Author@localhost.com>" # (Key : Value) Format
RUN apt-get update && apt-get install apache2 -y 
ADD index.html /var/www/html
WORKDIR /var/www/html # works just like 'cd' 
RUN ["/bin/bash", "-c", "echo RunTest > Test.html"]
EXPOSE 80
CMD ["apachectl", "-DFOREGROUND"] # Either have to use 'CMD' or 'ENTRYPOINT' to run the service

Creating an index.html



echo Test > index.html

Our working directory is currently /DockerFile_root which is also known as Build Context Directory

This is where the docker build should happen



docker build -t my:v1.0.0 ./
Successfully built e5581d044d20
Successfully tagged my:v1.0.0

Checking our new image



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
my                  v1.0.0              e5581d044d20        28 seconds ago      204MB

Creating and starting the container



docker run -d --name apache2_con -p 80:80 my:v1.0.0
891473bcd83ed3f94830e5595aa698f3e40652183183a205bc3aa60fe8eef843

If we check inside the container



docker exec -it apache2_con /bin/bash
root@891473bcd83e:/var/www/html# cat ./Test.html 
RunTest

Returning to the host system and checking port 80



curl localhost:80
Test

curl localhost:80/Test.html
RunTest

Docker Build Cache & Image Sizes

Finally, I want to discuss regarding Docker build sizes and how to manage them

Creating a new Dockerfile



vi Dockerfile_L

FROM ubuntu:bionic
LABEL maintainer "Author <Author@localhost.com>"
RUN mkdir /dummy
RUN fallocate -l 100m /dummy/A
RUN rm -rf /dummy/A

To build this image



docker build -t dummy:v1.0.0 ./ -f Dockerfile_L

👉 The -f option in the docker build command specifies the Dockerfile name to use during the build process, when the Dockerfile is not named "Dockerfile"

This will build the image as follows



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
dummy               v1.0.0              4ef94c4001fe        2 minutes ago       168MB

👉 As we can see that it is 168MBs big. We know that ubuntu:bionic is only about 63MBs. In the Dockerfile we just created dummy directory and deleted a file inside the directory that cost us over 100MBs

To decrease the size we can try to edit our Dockerfile



FROM ubuntu:bionic
LABEL maintainer "Author <Author@localhost.com>"
RUN mkdir /dummy && \
fallocate -l 100m /dummy/A && \
rm -rf /dummy/A

Now if we check the image size after building this new image



docker build -t dummy:v1.0.1 ./ -f Dockerfile_L

docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
dummy               v1.0.1              6ced40e23a77        11 seconds ago      63.1MB
dummy               v1.0.0              4ef94c4001fe        8 minutes ago       168MB

✨ Another important thing is Docker Cache

💡 Docker caches build layers to speed up subsequent builds of a Dockerfile. However, when using GitHub for building, changes to source code may not be properly reflected due to cached layers. To force a rebuild of all layers and ensure changes are properly incorporated, use the --no-cache option with the docker build command

We can try to compile a C code as well



vi ./app.c
#include <stdio.h>
void main()
{
 printf("Hello World\n");
}

To compile our C code, we need the gcc compiler



vi Dockerfile_M

FROM gcc:latest
LABEL maintainer "Author <Author@localhost.com>"
ADD app.c /root
WORKDIR /root
RUN gcc -o ./app ./app.c
CMD ["./app"]

Now building this Dockerfile



docker build -t multi:v1.0.0 ./ -f Dockerfile_M

👉 This will first pull the gcc:latest image from the docker hub website

If we check the image size



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
multi               v1.0.0              8b00f89eb22c        23 seconds ago      1.27GB
gcc                 latest              c6aa7ca27d67        4 days ago          1.27GB

Testing the image by running it in a container



docker run -it --rm --name pritn_c multi:v1.0.0
Hello World

Well this works but the size of images are obnoxiously large for such a simple task 😥

To solve this, we can edit the Dockerfile as follows



# GCC Compile Block
FROM gcc:latest as compile_base
LABEL maintainer "Author <Author@localhost.com>"
ADD app.c /root
WORKDIR /root
RUN gcc –o ./app ./app.c

# APP Running Block
FROM alpine:latest
RUN apk add --no-cache gcompat
WORKDIR /root
COPY --from=compile_base /root/app ./ # we set an alias in the compile block as "compile_base" which is being used here
CMD ["./app"]

This is called multi-stage build. Multi-stage builds in Docker allow you to use multiple FROM statements in a single Dockerfile to create multiple intermediate images, each with its own set of instructions and layers.

✨ The advantage of using multi-stage builds is that it allows you to create smaller and more efficient Docker images.

Now we will build this image



docker build -t multi:v1.0.1 ./ -f Dockerfile_M

Checking this image size



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
multi               v1.0.1              1cc2b8149d7d        6 seconds ago       7.23MB

Testing the image by running it in a container



docker run -it --rm --name print_c multi:v1.0.1
Hello World

We can even reduce this image size further by dividing the Package install block as well



vi Dockerfile_M2

# GCC Compile Block
FROM gcc:latest as compile_base
LABEL maintainer "Author <Author@localhost.com>"
ADD app.c /root
WORKDIR /root
RUN gcc –o ./app ./app.c

# Package Install Block
FROM alpine:latest as package_install
RUN apk add --no-cache gcompat
WORKDIR /root
COPY --from=compile_base /root/app ./

# App running Block
FROM package_install as run
WORKDIR /root
CMD ["./app"]

Building the image



docker build -t multi:v1.0.2 ./ -f Dockerfile_M2

Checking the size



docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
multi               v1.0.2              60500955b71d        4 seconds ago       7.23MB

Testing the image by running it in a container



docker run -it --rm --name print_c multi:v1.0.2
Hello World

💡 The size different can't be seen in the above case as the actual compile file is really small as compared to an actual program

Conclusion

In conclusion, managing Docker images is an important part of working with Docker containers. By understanding the various Docker image management commands and best practices I discussed above, users can effectively manage their Docker images to optimize their container environment and workflow ✔

Docker Volume Management

Waji — Sun, 05 Mar 2023 12:24:34 +0000

Introduction

We are aware of the fact that Docker images are Read-only. When you run a container in Docker, it creates a writable layer on top of the image file system. This layer is used to store any changes made to the container during its lifetime, such as installed software or modified files. When a container is terminated, the writable layer is removed, and any data or settings that were stored in the layer are lost.

To solve this, we can use Docker volumes. They allow us to mount directories from the host machine or other containers into the container. By storing data and settings in a volume, they can be easily accessed and reused between container runs. There are three types of volume management:

Host Volume
Container Volume
Docker Volume

👉 I will be going through each of them along with a short hands on examples

Host Volumes

Host volumes are directories on the host machine that are mounted into containers, allowing the container to read and write files directly to the host file system

✨ Useful for scenarios where we need to persist data outside of the container, or share data between the host and container

Simple Test

Creating a mysql_DB container

docker run -d \
> --name mysql_db \
> -e MYSQL_ROOT_PASSWORD=root \
> -e MYSQL_DATABASE=testDB \
> -v /docker_dir/con_volume_1:/var/lib/mysql \
> mysql:5.7

👉 The -e option lets us create root user's password and a test DB as well

👉 The line containing -v option means that any data written to the /var/lib/mysql directory within the container will be stored in the /docker_dir/con_volume_1 directory on the host, allowing the data to persist even if the container is deleted

💡 In Kubernetes, credentials are handled through a secret file

Checking docker process

docker ps

👉 We will be able to see the mysql5.7 container that we just created and started

In our host system,

ls -l /docker_dir/con_volume_1/
drwxr-x--- 2 polkitd input     4096 Mar  5 19:34 mysql
drwxr-x--- 2 polkitd input       20 Mar  5 19:34 testDB

The data is saved in our local host

We can also find the same data inside our container

docker exec -it mysql_db /bin/bash
bash-4.2# ls -l /var/lib/mysql
drwxr-x--- 2 mysql mysql     4096 Mar  5 10:34 mysql
drwxr-x--- 2 mysql mysql       20 Mar  5 10:34 testDB

Returning to the host and after deleting the container, we can still see the database data still remains

docker stop mysql_db
docker rm mysql_db
ls -l /docker_dir/con_volume_1
drwxr-x--- 2 polkitd input     4096 Mar  5 19:34 mysql
drwxr-x--- 2 polkitd input       20 Mar  5 19:34 testDB

😥 But using the -v option has a slight issue

Creating a new container with a different DB name

docker run -d \
> --name mysql_db \
> -e MYSQL_ROOT_PASSWORD=root \
> -e MYSQL_DATABASE=MYSQLDB \
> -v /docker_dir/con_volume_1:/var/lib/mysql \
> mysql:5.7

👉 The above should create a MYSQLDB but instead it shows the previous database data

From the host

ls -l /docker_dir/con_volume_1
drwxr-x--- 2 polkitd input     4096 Mar  5 19:34 mysql
drwxr-x--- 2 polkitd input       20 Mar  5 19:34 testDB

Inside the container

ls -l /var/lib/mysql
drwxr-x--- 2 mysql mysql     4096 Mar  5 10:34 mysql
drwxr-x--- 2 mysql mysql       20 Mar  5 10:34 testDB

👉 We can confirm that the container directory replicates the same data from the host directory. This means that the -v option is actually mounting the container's directory into the host directory.

Container Volume

Container volumes are volumes created and managed by Docker, and are associated with a specific container

✨ Useful when we need to isolate and share data between containers

Simple Test

Creating an index.html file inside the directory

cat > /docker_dir/con_volume_1/index.html
Nginx Main Page !!

Starting a container on port 8001

docker run -d --name Nginx_1 -p 8001:80 \
> -v /docker_dir/con_volume_1:/usr/share/nginx/html \
> nginx:latest

On port 8002

docker run -d --name Nginx_2 -p 8002:80 \ 
> --volumes-from Nginx_1 \
> nginx:latest

On port 8003

docker run -d --name Nginx_3 -p 8003:80 \
> --volumes-from Nginx_1 \
> nginx:latest

👉 Here --volumes-from shares the host directory that is connected to the specified container with another container

Now from the host system

curl localhost:8001
Nginx Main Page !!

curl localhost:8002
Nginx Main Page !!

curl localhost:8003
Nginx Main Page !!

If we add something to the existing file,

cat >> /docker_dir/con_volume_1/index.html
Volumes From Test !!

curl localhost:8001
Nginx Main Page !!
Volumes From Test !!

curl localhost:8002
Nginx Main Page !!
Volumes From Test !!

curl localhost:8003
Nginx Main Page !!
Volumes From Test !!

👉 We can see that one volume directory is shared across several containers

Docker Volume

Docker volumes are volumes created and managed by Docker, and can be used by multiple containers, not just a single container.

✨ Useful for scenarios where we need to share data between multiple containers, or when we need to back up or restore volumes

Simple Test

Creating a docker volume

docker volume create myVolume_1
myVolume_1

To check current volumes

docker volume ls

DRIVER              VOLUME NAME
local               97e467c79d320138ef408f661ea6ce37d8294ce7e58524ae018d4225ad5ba914
local               db9eb4a8b3eb12c36056d398b65c6385315a28e3d3a43b7a7913afc94efc86aa
local               myVolume_1

👉 We can also use docker volume inspect myVolume_1 to inspect further details such as mountpoint of the volume

Now we can start a new container connected to the docker volume

docker run -d \
> --name mysql_DB \
> -e MYSQL_ROOT_PASSWORD=root \
> -e MYSQL_DATABASE=testDB \
> -v myVolume_1:/var/lib/mysql \
> mysql:5.7

Accessing the CLI inside the container

docker exec -it mysql_DB /bin/bash

Inside the container

mysql -u root -p testDB

mysql> create database testDB2;
Query OK, 1 row affected (0.00 sec)

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| testDB             |
| testDB2            |
+--------------------+
6 rows in set (0.00 sec)

mysql> exit

👉 I created a testDB2 database to check results

From the host system

ls -l /var/lib/docker/volumes/myVolume_1/_data/
drwxr-x--- 2 polkitd input     4096  6월 23 11:53 mysql
drwxr-x--- 2 polkitd input       20  6월 23 11:53 testDB
drwxr-x--- 2 polkitd input       20  6월 23 11:55 testDB2

👉 We can confirm the database that we created inside the container can be seen from the host system

Read-only Docker Volume

Creating another docker volume

docker volume create myVolume_2
myVolume_2

Creating a new index.html inside this volume

cat > /var/lib/docker/volumes/myVolume_2/_data/index.html
My Nginx Web Site !!

ls -l /var/lib/docker/volumes/myVolume_2/_data/
-rw-r--r-- 1 root root 41  6월 23 12:06 index.html

Creating a new nginx container and checking

docker run -d --name Nginx_1 -p 80:80 \
> -v myVolume_2:/usr/share/nginx/html:ro \
> nginx:latest

curl localhost:80
My Nginx Web Site !!

👉 The ro is used to connect it as read-only

Now from inside this container if we try to edit the file

cat >> /usr/share/nginx/html/index.html
bash: /usr/share/nginx/html/index.html: Read-only file system

👉 As we mounted as read-only, we cannot write from inside the container

However, we can add contents from the host system

cat >> /var/lib/docker/volumes/myVolume_2/_data/index.html
Change Content !!

curl localhost:80
My Nginx Web Site !!
Change Content !!

Conclusion

In conclusion, Docker volumes provide a way to manage and persist data within containers. The three types of Docker volumes - host volumes, container volumes, and Docker volumes - offer different approaches to managing data, each with its own strengths and limitations ✔

Docker Network Management

Waji — Sun, 05 Mar 2023 10:24:22 +0000

Introduction

Docker provides various options for managing networking between containers and between containers and the host system

Docker's network management features allow developers to easily create and manage network connections between containers and between containers and the host system

Bridge network driver: Creates a virtual bridge network that allows containers to communicate with each other and with the host system
Host network driver: Removes the network isolation between the container and the host system, and allows the container to use the host system's networking stack
None network driver: Disables networking for the container, which means that the container cannot connect to the network or access the Internet
Overlay network driver: Creates a multi-host network that spans multiple Docker hosts, allowing containers to communicate with each other across hosts

Short hands on

Creating 2 containers



docker run -d --name myWEB nginx

# The second container
docker run -d --name myWEB2 nginx

Now we if check our network interfaces



ifconfig
veth14ce8a6
veth5e588d5

👉 We will be able to see 2 new interfaces that are created automatically when the containers are created

Using following command we can check bridge interface details



brctl show docker0
bridge name bridge id       STP enabled interfaces
docker0     8000.0242cc3ec3d9   no      veth14ce8a6
                            veth5e588d5

👉 So as we didn't use the -it command when running the container, we can use



docker exec -it myWEB /bin/bash

✨ This will let us connect to the bash shell of our nginx server image

Now we need to check the interface and IP address of this container



apt-get update && apt-get install net-tools

ifconfig
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255

If we check on our second container



eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.3  netmask 255.255.0.0  broadcast 172.17.255.255

We are able to confirm that

myWEB1 => eth0: 172.17.0.2
myWEB2 => eth0: 172.17.0.3

Another thing we can try is creating a custom bridge



docker network create --driver=bridge \
--subnet=10.1.1.0/24 \
--ip-range=10.1.1.0/24 \
--gateway=10.1.1.1 myNet

To confirm



docker network ls

dd6eaf504ee5        myNet               bridge              local

If we check the local host network interfaces



ifconfig

br-dd6eaf504ee5: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.1.1.1  netmask 255.255.255.0  broadcast 10.1.1.255

We can also inspect using



docker network inspect myNet

So what if we want to run a new container using our Network interface?



docker run -d --net myNet -p 80:80 --name myNet_nginx1 nginx

docker run -d --net myNet -p 8080:80 --name myNet_nginx2 nginx

We are actually performing port forwarding here

If we use the Host Linux's base Interface IP address,

This will mean that we need to tell each client that they need to connect to either port 80 or port 8080 to access the website. This is not a very efficient way. This is where we could potentially use a Proxy server (HAproxy Docker Image) along with the Net-alias

In this post, I shared some of the basic network management tools used in Docker. In the future posts, I will be sharing how we can actually utilize Proxy with the net-aliases ✔

Process Scheduling in Linux

Waji — Sun, 05 Mar 2023 04:12:03 +0000

cron is a process scheduler for Linux. The crontab is a list of commands that you want to run on a regular schedule, and also the name of the command used to manage that list.

👉 cron is a time-based job scheduler in Unix-like operating systems. Users can schedule jobs (commands or scripts) to run automatically at a specified time and date.

crontab is the program used to install, deinstall or list the tables used to drive the cron daemon. Each user can have their own crontab, and though these are files in /var, they are not intended to be edited directly.

💡 Format
MIN HOUR DOM MON DOW CMD

Field    Description    Allowed Value

MIN      Minute field    0 to 59
HOUR     Hour field      0 to 23
DOM      Day of Month    1-31
MON      Month field     1-12
DOW      Day Of Week     0-6
CMD      Command         Any command to be executed

“ * “ 모든 값을 의미 “ * ” : 모든 일 마다 ( 3번 필드 ) “ - " 범위 지정 “ 1-12 ” : 1월 부터 12월 ( 4번 필드 ) “ , “ 여러 개의 값 지정 “ 10,15 ” : 10시 그리고 15시 ( 2번 필드 ) “ / “ 특정 주기로 나눌 때 사용 “ */10 ” : 매 10분 마다 ( 1번 필드 )

Linux System에서 주기적인 작업처리를 진행할 때 주로사용 된다. ( 예약 작업을 의미 )
Cron은 프로세스 예약 데몬이며, 특정시각에 지정 된 작업을 수행한다.
Crontab은 Cron에 의해 실행 될 예약 작업의 목록을 정의하는 파일을 말한다. ( CronTable )
Cron은 사용자별 예약작업을 따로 가질 수 있다
Cron작업에 대한 로그기록은 /var/log/cron에 저장 된다.

rpm -qa | grep cronie

ps -ef | grep cron

ls -l /var/log/cron

ls -l /var/spool/cron

ls -d /etc/cron

Setting up cron

crontab -l : 예약 작업 리스트 확인
crontab -e : 예약 작업 편집
crontab -r : 예약 작업 삭제
crontab -u [UserName] : 특정 사용자의 예약작업 확인 및 편집

💡 We can schedule a task or a process using the crontab -e command within the vi editor. Also, only the ‘root’ user can use the crontab -u [UserName] command.ca

We can also see how the crontab file looks like:

➜  ~ cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

Examples

Example1:

Making an empty directory with a script file in it. Providing ‘execute’ permission to the file as well.

➜  ~ mkdir ./script
➜  ~ cd ./script

➜  script vi ./cron_test1.sh

#!/bin/bash

echo "Cron Test" > /root/cron.txt

➜  script chmod +x ./cron_test1.sh

Setting up the schedule for the script to run and confirming it.

➜  script crontab -e
0 19 * * * /root/script/cron_test1.sh

➜  script crontab -l
0 19 * * * /root/script/cron_test1.sh

After the script runs at 19:00

➜  script ls -l /root
total 12
-rw-r--r--   1 root root    0 Jan 12 15:12 풀이
-rw-------.  1 root root 1483 Jan 10 11:41 anaconda-ks.cfg
**-rw-r--r--   1 root root   10 Jan 26 23:24 cron.txt

# Checking the logs for cron**
➜  script tail /var/log/cron

Example2:

Creating a new script that saves logs as tar backup file and deletes it after 10 days.

➜  script vi ./cron_test2.sh

#!/bin/bash

DATE=$(date +%Y-%m-%d)
BACKUP_DIR="/backup“
tar -cvzpf $BACKUP_DIR/test-$DATE.tar.gz /var/log 
find $BACKUP_DIR/* -mtime +10 -exec rm {} \;

Giving the file executable permissions and also adding new crontab settings.

➜  script chmod +x ./cron_test2.sh
➜  script crontab -e
crontab: installing new crontab

0 20 * * * /root/script/cron_test2.sh

After the script runs at 20:00

➜  script ls -l /backup
test-26-01-2023.tar.gz

**# Checking the logs for cron**
➜  script tail /var/log/cron

Deletion, Backup and Control

Before deleting our crontab settings,

➜  ~ crontab -l > /root/cron_back.txt
➜  ~ cat /root/cron_back.txt 
0 19 * * * /root/script/cron_test1.sh
0 20 * * * /root/script/cron_test2.sh

Deleting the crontab settings

➜  ~ crontab -r
➜  ~ crontab -l
no crontab for root

We can easily backup our crontab settings using the bakcup .txt file that we created.
```
➜  ~ crontab /root/cron_back.txt
➜  ~ crontab -l
0 19 * * * /root/script/cron_test1.sh
0 20 * * * /root/script/cron_test2.sh
```
👉 Just a note that we cannot delete a specific `crontab`

We can ‘control’ what users can set up crontab configs

➜  ~ vi /etc/cron.deny
itbank

# If we try to use the following command as 'itbank'
➜ itbank ~ crontab -e
You (itbank) are not allowed to use this program (crontab)
See crontab(1) for more information

LVM & VG in Linux

Waji — Sun, 05 Mar 2023 04:08:45 +0000

We can think LVM as a device mapper that provides logical volume management for Linux. It is used for creating single logical volumes of multiple physical volumes or entire hard disks.

👉 For example, we can consider sda1 partition for the sda disk for the / directory. If there is no space left inside this partition, normally we would consider deleting some files to make space for new files or application. However, if we use LVM, we will be connecting the ‘Volume Group’ and divide ‘Logical Volumes’ which will be connected with the ‘/’. This will allow different hard disks (sdb, sdc, etc.) to be added to this ‘Volume Group’ ultimately leading to more space in ‘/’.

💡 Just a note that we can add hard disks to the Volume Group however we cannot remove them!

LVM Hands on

Preparation for the hands on>

Creating 2 new disks in our Linux - 1 system.
- 2GB Hard disk+1GB Hard disk

The file should contain only two entries:

# /etc/fstab
# Created by anaconda on Tue Jan 10 10:45:44 2023
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos_linux--1-root /                       xfs     defaults        0 0
UUID=2d2f3276-dc8a-403c-bb04-53e472b9184c /boot                   xfs     defaults        0 0
/dev/mapper/centos_linux--1-swap swap                    swap    defaults        0 0

We can check the mount status as well using the df -h command:

[root@Linux-1 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          475M     0  475M   0% /dev
tmpfs                             487M     0  487M   0% /dev/shm
tmpfs                             487M  7.6M  479M   2% /run
tmpfs                             487M     0  487M   0% /sys/fs/cgroup
/dev/mapper/centos_linux--1-root   17G  1.6G   16G  10% /
/dev/sda1                        1014M  168M  847M  17% /boot
tmpfs                              98M     0   98M   0% /run/user/0

We can also use the lsblk command to see the current hard disks:

[root@Linux-1 ~]# lsblk
NAME                     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                        8:0    0   20G  0 disk 
├─sda1                     8:1    0    1G  0 part /boot
└─sda2                     8:2    0   19G  0 part 
  ├─centos_linux--1-root 253:0    0   17G  0 lvm  /
  └─centos_linux--1-swap 253:1    0    2G  0 lvm  [SWAP]
sdb                        8:16   0    1G  0 disk 
sdc                        8:32   0    1G  0 disk 
sdd                        8:48   0    2G  0 disk 
sde                        8:64   0    1G  0 disk 
sr0                       11:0    1 1024M  0 rom

Hands on>

We will create 1 partition for each disks with the default configuration.

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     2097151     1047552   83  Linux

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048     2097151     1047552   83  Linux

Device Boot      Start         End      Blocks   Id  System
/dev/sdd1            2048     4194303     2096128   83  Linux

Device Boot      Start         End      Blocks   Id  System
/dev/sde1            2048     2097151     1047552   83  Linux

#Checking the results using lsblk command.

[root@Linux-1 ~]# lsblk
NAME                     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                        8:0    0   20G  0 disk 
├─sda1                     8:1    0    1G  0 part /boot
└─sda2                     8:2    0   19G  0 part 
  ├─centos_linux--1-root 253:0    0   17G  0 lvm  /
  └─centos_linux--1-swap 253:1    0    2G  0 lvm  [SWAP]
sdb                        8:16   0    1G  0 disk 
└─sdb1                     8:17   0 1023M  0 part /sdb1
sdc                        8:32   0    1G  0 disk 
└─sdc1                     8:33   0 1023M  0 part 
sdd                        8:48   0    2G  0 disk 
└─sdd1                     8:49   0    2G  0 part 
sde                        8:64   0    1G  0 disk 
└─sde1                     8:65   0 1023M  0 part 
sr0                       11:0    1 1024M  0 rom

In /dev/sdb,

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     2097151     1047552   83  Linux

We can use ‘t’ and ‘L’ . Upon pressing those buttons, we will be able to see,

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): L

 0  Empty           24  NEC DOS         81  Minix / old Lin bf  Solaris        
 1  FAT12           27  Hidden NTFS Win 82  Linux swap / So c1  DRDOS/sec (FAT-
 2  XENIX root      39  Plan 9          83  Linux           c4  DRDOS/sec (FAT-
 3  XENIX usr       3c  PartitionMagic  84  OS/2 hidden C:  c6  DRDOS/sec (FAT-
 4  FAT16 <32M      40  Venix 80286     85  Linux extended  c7  Syrinx         
 5  Extended        41  PPC PReP Boot   86  NTFS volume set da  Non-FS data    
 6  FAT16           42  SFS             87  NTFS volume set db  CP/M / CTOS / .
 7  HPFS/NTFS/exFAT 4d  QNX4.x          88  Linux plaintext de  Dell Utility   
 8  AIX             4e  QNX4.x 2nd part 8e  Linux LVM       df  BootIt

Here, we need to find the “Linux LVM”. The code is 8e for this so we will type it and see our results

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048     2097151     1047552   8e  Linux LVM

VG Hands on

To create a physical volume,

👉 pvcreate /dev/sdb

👉 pvcreate /dev/sdc

👉 pvcreate /dev/sdd

👉 pvcreate /dev/sde

To create the Volume Group,

vgcreate VG /dev/sdb /dev/sdc /dev/sdd

[root@Linux-1 ~]# vgcreate VG /dev/sdb /dev/sdc /dev/sdd
Volume group "VG" successfully created

We can use vgdisplay command to see our VGs,

[root@Linux-1 ~]# vgdisplay
  --- Volume group ---
  VG Name               centos_linux-1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <19.00 GiB
  PE Size               4.00 MiB
  Total PE              4863
  Alloc PE / Size       4863 / <19.00 GiB
  Free  PE / Size       0 / 0   
  VG UUID               7hBnc9-6dXE-9f1q-rpmW-SuBd-TZv0-TVBa6X

  --- Volume group ---
  VG Name               VG
  System ID             
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               <3.99 GiB
  PE Size               4.00 MiB
  Total PE              1021
  Alloc PE / Size       0 / 0   
  Free  PE / Size       1021 / <3.99 GiB
  VG UUID               DdSDJQ-EpWo-uy8S-Pb3m-9AWP-tzBw-vaLSov

Now we will create the logical volumes for this VG,

This will create a logical volume ‘LV-1’ using 1GB of the VG’s space.

[root@Linux-1 ~]# lvcreate -L 1GB -n LV-1 VG
  Logical volume "LV-1" created.

This will create a logical volume ‘LV-2’ using 50% of the Volume Group’s total space.

[root@Linux-1 ~]# lvcreate -l +50%VG -n LV-2 VG
WARNING: xfs signature detected on /dev/VG/LV-2 at offset 0. Wipe it? [y/n]: y
  Wiping xfs signature on /dev/VG/LV-2.
  Logical volume "LV-2" created.

This will create a logical volume ‘LV-3’ using 100% of the remaining of the Volume Group.

[root@Linux-1 ~]# lvcreate -l +100%FREE -n LV-3 VG
  Logical volume "LV-3" created.

We can use ‘lvscan’ here,

[root@Linux-1 ~]# lvscan
  ACTIVE            '/dev/centos_linux-1/swap' [2.00 GiB] inherit
  ACTIVE            '/dev/centos_linux-1/root' [<17.00 GiB] inherit
  ACTIVE            '/dev/VG/LV-1' [1.00 GiB] inherit
  ACTIVE            '/dev/VG/LV-2' [1.99 GiB] inherit
  ACTIVE            '/dev/VG/LV-3' [1020.00 MiB] inherit

We have logical volumes created inside the VG. Now we can just give them the filesystem,

[root@Linux-1 ~]# mkfs.xfs /dev/VG/LV-1
meta-data=/dev/VG/LV-1           isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[root@Linux-1 ~]# mkfs.xfs /dev/VG/LV-2
meta-data=/dev/VG/LV-2           isize=512    agcount=4, agsize=130560 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=522240, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[root@Linux-1 ~]# mkfs.xfs /dev/VG/LV-3
meta-data=/dev/VG/LV-3           isize=512    agcount=4, agsize=65280 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=261120, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=855, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

We can use blkid to see the filesystem type and short summary for our partitions

[root@Linux-1 ~]# blkid
/dev/sda1: UUID="2d2f3276-dc8a-403c-bb04-53e472b9184c" TYPE="xfs" 
/dev/sda2: UUID="UJrgq8-Rei9-528e-Hg0W-2QHD-n7Jp-OL4L13" TYPE="LVM2_member" 
/dev/sdb: UUID="gsms5M-xl9S-DxUo-BO4O-Qf3V-35ch-LXUOaB" TYPE="LVM2_member" 
/dev/sdc: UUID="l59wcF-iURW-suWZ-dfC6-Gf2z-5T0A-qb8xaK" TYPE="LVM2_member" 
/dev/sdd: UUID="BV4Gjx-jMBs-4K3V-sinB-lc7R-7DEM-bYYGXS" TYPE="LVM2_member" 
/dev/sde: UUID="UdVQLK-TlsI-cDsh-isfT-tuAT-yURe-np6RZW" TYPE="LVM2_member" 
/dev/mapper/centos_linux--1-root: UUID="8f826410-dc1d-4aba-bc6d-36d25621e5cf" TYPE="xfs" 
/dev/mapper/centos_linux--1-swap: UUID="ad01e948-9fdd-43ad-84e5-ce4ab14a995c" TYPE="swap" 
/dev/mapper/VG-LV--1: UUID="048f9bc6-f8f0-46b3-95f1-c7b1900adda6" TYPE="xfs" 
/dev/mapper/VG-LV--2: UUID="3074670a-13de-47ed-abc0-08b3319fb20e" TYPE="xfs" 
/dev/mapper/VG-LV--3: UUID="96062612-1a8a-4a21-bfc6-c16ccd3e96a6" TYPE="xfs"

Now we can make 3 directories for these logical volumes to be mounted,

[root@Linux-1 ~]# mkdir /data1
[root@Linux-1 ~]# mkdir /data2
[root@Linux-1 ~]# mkdir /data3

[root@Linux-1 ~]# mount /dev/VG/LV-1 /data1
[root@Linux-1 ~]# mount /dev/VG/LV-2 /data2
[root@Linux-1 ~]# mount /dev/VG/LV-3 /data3

Confirming the mount,

[root@Linux-1 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          475M     0  475M   0% /dev
tmpfs                             487M     0  487M   0% /dev/shm
tmpfs                             487M  7.6M  479M   2% /run
tmpfs                             487M     0  487M   0% /sys/fs/cgroup
/dev/mapper/centos_linux--1-root   17G  1.6G   16G  10% /
/dev/sda1                        1014M  168M  847M  17% /boot
tmpfs                              98M     0   98M   0% /run/user/0
/dev/mapper/VG-LV--1             1014M   33M  982M   4% /data1
/dev/mapper/VG-LV--2              2.0G   33M  2.0G   2% /data2
/dev/mapper/VG-LV--3             1017M   33M  985M   4% /data3

If we want this mount to happen automatically, we can just mention them in the /etc/fstab file

For now, we will just umount these volumes.

[root@Linux-1 ~]# umount /data1
[root@Linux-1 ~]# umount /data2
[root@Linux-1 ~]# umount /data3

We now want to add /dev/sde to this VG.

First,

[root@Linux-1 ~]# pvcreate /dev/sde
  Physical volume "/dev/sde" successfully created.

Then we will use the ‘vgextend’ command,

[root@Linux-1 ~]# vgextend VG /dev/sde
  Volume group "VG" successfully extended

We can see the VG

[root@Linux-1 ~]# vgdisplay VG
  --- Volume group ---
  VG Name               VG
  System ID             
  Format                lvm2
  Metadata Areas        4
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               0
  Max PV                0
  Cur PV                4
  Act PV                4
  VG Size               4.98 GiB
  PE Size               4.00 MiB
  Total PE              1276
  Alloc PE / Size       1021 / <3.99 GiB
  Free  PE / Size       255 / 1020.00 MiB
  VG UUID               DdSDJQ-EpWo-uy8S-Pb3m-9AWP-tzBw-vaLSov

Now if we see using lvscan,

[root@Linux-1 ~]# lvscan
  ACTIVE            '/dev/centos_linux-1/swap' [2.00 GiB] inherit
  ACTIVE            '/dev/centos_linux-1/root' [<17.00 GiB] inherit
  ACTIVE            '/dev/VG/LV-1' [1.00 GiB] inherit
  ACTIVE            '/dev/VG/LV-2' [1.99 GiB] inherit
  ACTIVE            '/dev/VG/LV-3' [1020.00 MiB] inherit

We want to add the extended logical volume to the LV-3,

[root@Linux-1 ~]# lvextend -l +100%FREE /dev/VG/LV-3
  Size of logical volume VG/LV-3 changed from 1020.00 MiB (255 extents) to 1.99 GiB (510 extents).
  Logical volume VG/LV-3 successfully resized.

Now, if we mount the LV-3 into the data3 directory, we can find,

[root@Linux-1 ~]# mount /dev/VG/LV-3 /data3

[root@Linux-1 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          475M     0  475M   0% /dev
tmpfs                             487M     0  487M   0% /dev/shm
tmpfs                             487M  7.6M  479M   2% /run
tmpfs                             487M     0  487M   0% /sys/fs/cgroup
/dev/mapper/centos_linux--1-root   17G  1.6G   16G  10% /
/dev/sda1                        1014M  168M  847M  17% /boot
tmpfs                              98M     0   98M   0% /run/user/0
/dev/mapper/VG-LV--3             1017M   33M  985M   4% /data3

In this current mounted state,

[root@Linux-1 ~]# xfs_growfs /dev/VG/LV-3
meta-data=/dev/mapper/VG-LV--3   isize=512    agcount=4, agsize=65280 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=261120, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=855, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 261120 to 522240

Now if we check,

[root@Linux-1 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          475M     0  475M   0% /dev
tmpfs                             487M     0  487M   0% /dev/shm
tmpfs                             487M  7.6M  479M   2% /run
tmpfs                             487M     0  487M   0% /sys/fs/cgroup
/dev/mapper/centos_linux--1-root   17G  1.6G   16G  10% /
/dev/sda1                        1014M  168M  847M  17% /boot
tmpfs                              98M     0   98M   0% /run/user/0
/dev/mapper/VG-LV--3              2.0G   33M  2.0G   2% /data3

Let’s add this to the auto-mount.


[root@Linux-1 ~]# vi /etc/fstab

# /etc/fstab
# Created by anaconda on Tue Jan 10 10:45:44 2023
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos_linux--1-root /                       xfs     defaults        0 0
UUID=2d2f3276-dc8a-403c-bb04-53e472b9184c /boot                   xfs     defaults        0 0
/dev/mapper/centos_linux--1-swap swap                    swap    defaults        0 0

/dev/VG/LV-1    /data1          xfs     defaults        0 0
/dev/VG/LV-2    /data2          xfs     defaults        0 0
/dev/VG/LV-3    /data3          xfs     defaults        0 0

After the reboot,

[root@Linux-1 ~]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          475M     0  475M   0% /dev
tmpfs                             487M     0  487M   0% /dev/shm
tmpfs                             487M  7.6M  479M   2% /run
tmpfs                             487M     0  487M   0% /sys/fs/cgroup
/dev/mapper/centos_linux--1-root   17G  1.6G   16G  10% /
/dev/mapper/VG-LV--3              2.0G   33M  2.0G   2% /data3
/dev/mapper/VG-LV--1             1014M   33M  982M   4% /data1
/dev/mapper/VG-LV--2              2.0G   33M  2.0G   2% /data2
/dev/sda1                        1014M  168M  847M  17% /boot
tmpfs                              98M     0   98M   0% /run/user/0

Deleting the VG and its volumes.

Let’s umount and remove the auto-mount for these 3 volumes.

Removing the local volumes from the VG,

[root@Linux-1 ~]# lvremove /dev/VG/LV-1
Do you really want to remove active logical volume VG/LV-1? [y/n]: y
  Logical volume "LV-1" successfully removed

[root@Linux-1 ~]# lvremove /dev/VG/LV-2
Do you really want to remove active logical volume VG/LV-2? [y/n]: y
  Logical volume "LV-2" successfully removed

[root@Linux-1 ~]# lvremove /dev/VG/LV-3
Do you really want to remove active logical volume VG/LV-3? [y/n]: y
  Logical volume "LV-3" successfully removed

Let’s check now,

[root@Linux-1 ~]# lvscan
  ACTIVE            '/dev/centos_linux-1/swap' [2.00 GiB] inherit
  ACTIVE            '/dev/centos_linux-1/root' [<17.00 GiB] inherit

Removing the VG,

[root@Linux-1 ~]# vgremove VG
  Volume group "VG" successfully removed

[root@Linux-1 ~]# vgdisplay VG
  Volume group "VG" not found
  Cannot process volume group VG

Removing the physical volumes,

[root@Linux-1 ~]# pvremove /dev/sdb
  Labels on physical volume "/dev/sdb" successfully wiped.

[root@Linux-1 ~]# pvremove /dev/sdc
  Labels on physical volume "/dev/sdc" successfully wiped.

[root@Linux-1 ~]# pvremove /dev/sdd
  Labels on physical volume "/dev/sdd" successfully wiped.

[root@Linux-1 ~]# pvremove /dev/sde
  Labels on physical volume "/dev/sde" successfully wiped.

Docker Container Management

Waji — Fri, 03 Mar 2023 01:41:59 +0000

Introduction

Docker container management involves tasks such as creating, starting, stopping, and removing containers, as well as monitoring and troubleshooting container performance and health

Some Basic Commands Hands-on

docker

👉 This will show us some options that we can use and also some of the management commands

docker search hello-world

👉 This will search for the 'hello-world' images from dockerhub

docker pull hello-world

👉 This will pull the latest hello-world image from the dockerhub

docker images

👉 This will show us pulled images

docker run --name hello1 -it hello-world

👉 This command creates and starts a new Docker container using the hello-world image

💡 'hello1' is the container name and '-it' enables interactive mode but '-it' shouldn't be used as it is for developing or debugging only as it enables us to interact with the container's shell

In the above case, as the 'hello-world' image doesn't have any shell to be interacted with, it automatically pushes us back to our Linux terminal. To check any running container process

docker ps

👉 This will show us nothing as the 'hello1' container was stopped immediately

But we can see previous container using

docker ps -a

👉 This will show us 'hello1' container and at what time it exited

Now let's use the -d option to run a docker container

docker run --name hello2 -d hello-world

👉 This will show us the container ID and quit itself

💡 The 'hello-world' image is designed to automatically quit itself after its processing. -d option indicates the container to run in the background

If we want to delete these exited containers,

docker rm <first-four-digits-of-container-ID>

# OR

docker rm <container-name>

To remove the hello-world image

docker rmi hello-world

We can confirm this using docker images commmand

Next, we can try creating a container

docker create --name myWEB nginx:latest

👉 create command simply 'creates' the container and doesn't run it while the run command creates and run the container

💡 run is a shortcut for the docker create and docker start commands combined

We can also check the status using the ps -a that will show us the container status as 'Created'

docker start myWEB

👉 This will start the container and we can see the process using docker ps

What if we want to delete this container?

docker rm myWEB
Error response from daemon: You cannot remove a running container

We can either stop the container first and delete it or force delete it using

docker rm -f myWEB

Finally removing the nginx image

docker rmi nginx:latest

Another test we can do using an ubuntu image

docker run -it --name ubuntu_1 ubuntu:bionic

👉 This will allow us to connect to ubuntu shell automatically

So what if we want to exit from the ubuntu image terminal while keeping the container running?

✨ We will use CTRL + P + Q

We can confirm that our container is running even after returning to our own terminal using docker ps

To return to the container shell

docker attach <container-name>

We can also pause and unpause the container

docker pause ubuntu_1

docker unpause ubuntu_1

Stopping a container

docker stop ubuntu_1

Killing a container

docker kill ubuntu_1

👉 This is force stop

To remove all Docker containers that are currently stopped

docker rm $(docker ps -a -q)

Now what if we don't apply a custom name for our container

docker run --rm -it ubuntu:bionic

👉 The --rm option automatically removes the container when we 'exit' from the container

We can also change the container name

docker rename <current-container-name> <new-custom-container-name>

To inspect a container or an image

docker inspect <container-name> 

# OR

docker inspect <image-name>

✍ In this post I walked through some of the basic docker container commands that are beginner friendly

Docker & Kubernetes Setup

Waji — Thu, 02 Mar 2023 02:06:39 +0000

Introduction

Docker is a platform that allows developers to create, deploy, and run applications in containers. Docker Compose simplifies managing multi-container applications by defining and running multiple containers as a single application with dependencies and configurations. Compose plugins extend the functionality of Docker Compose, allowing developers to add new commands, modify behavior, or integrate with external services

Kubernetes is an open-source platform for container orchestration and management that automates deployment, scaling, and management of containerized applications. It is often used in conjunction with Docker to manage containerized applications.

✨ Kubernetes provides a framework for automating deployment, scaling, and operations of application containers across clusters of hosts, while Docker provides a standardized way to package and distribute those containers

👉 I will be installing Docker in 3 CentOS7 Virtual Machines in my VMWare workstation

192.168.1.10 👉 Master
192.168.1.20 👉 Node-1
192.168.1.30 👉 Node-2

Before I begin, I will share official documentations available on installing the docker engine and compose

Installing Docker

In all systems,

yum -y install yum-utils

# Saving the docker repository to install docker from it
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

Checking docker files

yum list docker-ce --showduplicates | sort -r

👉 This should show us different versions of docker available. I will be proceeding with version 18.x

Installing the Docker Engine

yum -y install docker-ce-18.09.8 docker-ce-cli-18.09.8 containerd.io docker-compose-plugin

Checking the docker version

rpm -qa | grep docker
docker-ce-cli-18.09.8-3.el7.x86_64
docker-compose-plugin-2.6.0-3.el7.x86_64
docker-ce-18.09.8-3.el7.x86_64

Enabling and starting the docker service

systemctl start docker
systemctl enable docker

We can check the Docker version

docker version

👉 Working only from the 'Master' Linux

Installing Docker Compose

curl -SL https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
docker-compose version
Docker Compose version v2.2.3

Installing Kubernetes

👉 I have VSCode and Kubernetes installed in my Host PC to write manifest files for Kubernetes with ease

✨ From the 'Master' VM

Configuring SWAP memory to be deactivated

sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
swapoff -a

Creating the daemon.json file

vi /etc/docker/daemon.json

{
    "exec-opts": ["native.cgroupdriver=systemd"]
}

Reloading the daemon and restarting docker

systemctl daemon-reload
systemctl restart docker

👉 This will change the Docker cgroup drive

Adding the Kubernetes Local Repository

vi /etc/yum.repos.d/kubernetes.repo

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

# Installing Kuber
yum install -y kubelet-1.19.16-0.x86_64 kubectl-1.19.16-0.x86_64 kubeadm-1.19.16-0.x86_64

Confirming kubernetes installation

rpm -qa | grep kube
kubelet-1.19.16-0.x86_64
kubectl-1.19.16-0.x86_64
kubernetes-cni-0.8.7-0.x86_64
kubeadm-1.19.16-0.x86_64

Enabling ports used

firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2376/tcp
firewall-cmd --permanent --add-port=2379/tcp
firewall-cmd --permanent --add-port=2380/tcp
firewall-cmd --permanent --add-port=6443/tcp
firewall-cmd --permanent --add-port=8472/udp
firewall-cmd --permanent --add-port=9099/tcp
firewall-cmd --permanent --add-port=10250/tcp
firewall-cmd --permanent --add-port=10251/tcp
firewall-cmd --permanent --add-port=10252/tcp
firewall-cmd --permanent --add-port=10254/tcp
firewall-cmd --permanent --add-port=10255/tcp
firewall-cmd --permanent --add-port=30000-32767/tcp
firewall-cmd --permanent --add-port=30000-32767/udp
firewall-cmd --permanent --add-masquerade
firewall-cmd --reload

Configuring the Kuber cluster on our Master

kubeadm init --apiserver-advertise-address=192.168.1.10 --pod-network-cidr=10.244.0.0/16

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.1.10:6443 --token y20gfe.s5kx71a4nh0gzhsw \
    --discovery-token-ca-cert-hash sha256:7c46fa0f4ce64ea4642183250afb3305ca17a89867ed877e2eacdf2a835095b3

👉 The final line says to use the "join" command when adding nodes to the cluster.

👉 I specified the Master Node's IP address with the "apiserver-advertise-address" command and the network area for Pod usage with the "pod-network-cidr" command

Moving the authentication data to use kubectl under root user's Home directory .kube

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

Installing the Network Plugin to be used in Kuber cluster (Flannel)

curl -O -L https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

👉 As I am using a VM with NAT connection, I needed to add the NIC device name to the flannel.yml file

vi kube-flannel.yml

args:
        - --ip-masq
        - --kube-subnet-mgr
        - --iface=ens32

Now, we just need to apply the flannel plugin

kubectl apply -f kube-flannel.yml
systemctl restart kubelet

✨ From Both Node-1 and Node-2 VMs

👉 Same steps as Master node till firewall settings in both nodes

After firewall settings are done, we will use the join command that we got from the Master node

kubeadm join 192.168.1.10:6443 --token 172vji.r0u77jcmcnccm6no \
    --discovery-token-ca-cert-hash sha256:72b9648c647f724ab52471847cb06c47b23097375f2e67633b745fc69db16e8d

👉 This will add both nodes to the Kuber cluster created by the Master

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

Upon successful joining,

kubectl get nodes
NAME     STATUS   ROLES    AGE    VERSION
master   Ready    master   107m   v1.19.16
node-1   Ready    <none>   91s    v1.19.16
node-2   Ready    <none>   48s    v1.19.16

We can also check pods

kubectl get pods --all-namespaces

👉 A pod represents a single instance of a running process in the cluster

✍ Today I walked through installing Docker and Kubernetes in Linux systems and joined 2 working nodes to the Master Kuber cluster

Proxy Server Setup (HAproxy)

Waji — Tue, 28 Feb 2023 06:14:51 +0000

Introduction

Proxy servers are computer servers that act as intermediaries between clients (such as web browsers) and servers. When a client requests a resource from a server, the request is first sent to the proxy server, which then forwards the request to the server on behalf of the client. The server then sends the response back to the proxy server, which in turn sends it back to the client

👉 Why do we use it?

Mainly we would use a proxy server for load balancing. They can improve performance, provide anonymity, filter content, enable access to blocked resources, enhance security, control content, bypass geographic restrictions, protect privacy, aid in debugging and troubleshooting, and save bandwidth

There are 2 modes in Load balancing. L4 load balancing is based on transport layer while L7 load balancing is based on application layer. L4 load balancing uses IP addresses and port numbers while L7 load balancing uses content of the traffic like HTTP headers or cookies

✨ I will be using HAProxy that uses both modes of Load Balancing

Furthermore, I will be setting up 2 Proxy servers (one as the backup server). I already have 2 web servers prepared for testing purpose

Installing HAProxy

I will install some initial required packages

yum -y install gcc openssl openssl-devel systemd-devel wget

👉 gcc is a compiler, openssl for ssl/tls setting, systemd-devel for including the source into systemd, wget for downloading the haproxy package from the website

Creating an empty directory

mkdir /HAproxy
cd /HAproxy

Downloading the HAproxy package,

wget http://www.haproxy.org/download/2.3/src/haproxy-2.3.10.tar.gz

# Unzipping
tar xvfz haproxy-2.3.10.tar.gz
cd haproxy-2.3.10

# Compiling & installing required files
make TARGET=linux-glibc USE_OPENSSL=1 USE_SYSTEMD=1
make install

Downloading and saving HAproxy service file into /etc/systemd/system/haproxy-service

curl "https://git.haproxy.org/?p=haproxy-2.3.git;a=blob_plain;f=contrib/systemd/haproxy.service.in;" -o /etc/systemd/system/haproxy.service

We can confirm the file after this

ls -l /etc/systemd/system/haproxy.service
-rw-r--r--. 1 root root 1409 Feb 28 10:38 /etc/systemd/system/haproxy.service

Editing service lines inside this file

vi /etc/systemd/system/haproxy.service

ExecStartPre=/usr/local/sbin/haproxy -Ws -f $CONFIG -c -q $EXTRAOPTS
ExecStart=/usr/local/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE $EXTRAOPTS
ExecReload=/usr/local/sbin/haproxy -Ws -f $CONFIG -c -q $EXTRAOPTS

After this, we can try starting the haproxy service

systemctl start haproxy
Job for haproxy.service failed because the control process exited with error code. See "systemctl status haproxy.service" and "journalctl -xe" for details.

👉 This means that the primary setup has been done as the control process actually tried to start the service

Now, we need to make some directories for HAproxy

mkdir /etc/haproxy
mkdir /etc/haproxy/certs
mkdir /etc/haproxy/errors
mkdir /var/log/haproxy

Copying errorfiles under haproxy errors

cd ./examples/errorfiles
cp ./* .http /etc/haproxy/errors

Adding a HAproxy service user

useradd -c "HAproxy Daemon User" -s /sbin/nologin haproxy

tail -1 /etc/passwd
haproxy:x:1001:1001:HAproxy Daemon User:/home/haproxy:/sbin/nologin

Setting up the log file configuration

vi /etc/rsyslog.d/haproxy.conf

$ModLoad imudp
$UDPServerAddress 127.0.0.1
$UDPServerRun 514
local0.* /var/log/haproxy/haproxy-traffic.log

Setting up logrotate

vi /etc/logrotate.d/haproxy

  /var/log/haproxy/*.log {
        daily
        rotate 30
        create 0600 root root
        compress
        notifempty
        missingok
        sharedscripts
        postrotate
                /bin/systemctl restart rsyslog.service > /dev/null 2>/dev/null || true
        endscript
   }

Main Configuration file

We need the following lines inside the main config file for HAproxy

vi /etc/haproxy/haproxy.cfg

global
    daemon
    maxconn 4000 
    user haproxy
    group haproxy
    log 127.0.0.1:514 local0

defaults
    mode http
    option redispatch 
    retries 3
        # Redispatching to the another web server if retries are over 3
    log global
    option httplog
    option dontlognull
    option dontlog-normal
    option http-server-close
    option forwardfor
        # These are the log formats

    maxconn 3000
    timeout connect 10s
    timeout http-request 10s
    timeout http-keep-alive 10s
    timeout client 1m
    timeout server 1m
    timeout queue 1m

    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

listen stats
    bind *:9000
    stats enable
    stats realm Haproxy Stats Page
    stats uri /
    stats auth admin:haproxy1
        # Authentication for the Admin page

frontend proxy
    bind *:80
    default_backend WEB_SRV_list


backend WEB_SRV_list
    balance roundrobin
    option httpchk HEAD /
    http-request set-header X-Forwarded-Port %[dst_port]
    cookie SRVID insert indirect nocache maxlife 10m
    server WEB_01 192.168.1.128:80 cookie WEB_01 check inter 3000 fall 5 rise 3
    server WEB_02 192.168.1.129:80 cookie WEB_02 check inter 3000 fall 5 rise 3

👉 HAproxy configuration file setup reference:
※ https://www.haproxy.com/blog/the-four-essential-sections-of-an-haproxy-configuration/
※ https://cbonte.github.io/haproxy-dconv/2.3/configuration.html#3.1

The above sets rules for load-balancing incoming traffic across two backend web servers using round-robin, health checks, and cookies, and includes settings for connection limits, timeouts, error files, logging, and authentication. The "listen stats" section enables access to HAProxy statistics with authentication

Verifying the config file

haproxy -f /etc/haproxy/haproxy.cfg -c
Configuration file is valid

Starting and enabling haproxy

systemctl start haproxy
systemctl enable haproxy

Editing firewall settings

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-port=9000/tcp
firewall-cmd --reload

👉 From both Web Servers

We will open the configuration file

vi /etc/httpd/conf/httpd.conf

# Line 196
SetEnvIf Request_Method HEAD Health-Check        
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{x-forwarded-for}i %l %u %t \"%r\" %>s %b" common

# Line 219
CustomLog "logs/access_log" common env=!Health-Check

Now, we need to restart the web server service and set firewall

systemctl restart httpd
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

👉 If we don't have any page running on web servers

cd /var/www/html
cat > index.html
WEB 1

# From Server 2
cd /var/www/html
cat > index.html
WEB 2

To test if our proxy server is working, we can navigate to our proxy server's IP address,

After deleting the cookies data, we can reload the page to see that the proxy server forwards the client to the other server as well

We can also check report for HAproxy by connecting to the port 9000

Applying SSL/TLS

👉 From the proxy server

rpm -qa | grep openssl

We needed to confirm that we have openssl package available

Creating the private key

openssl genrsa -out /etc/haproxy/certs/ha01.key 2048

Creating the authentication .csr file

openssl req -new -key /etc/haproxy/certs/ha01.key -out /etc/haproxy/certs/ha01.csr

Creating the public key cert

openssl x509 -req -days 365 -in /etc/haproxy/certs/ha01.csr -signkey /etc/haproxy/certs/ha01.key -out /etc/haproxy/certs/ha01.crt

We need a backup of the Public and the private key in one file

cd /etc/haproxy/certs
cat ha01.crt ha01.key > ha01_ssl.crt
mv ha01.* /backup # Create /backup if it isn't available

Finally need to edit the main haproxy config file

vi /etc/haproxy/haproxy.cfg

# Adding these lines below the 'global' block
ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 # the hash cipher set for SSL/TLS
 ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets # Allowing only TLSv1.2 above versions

# Adding these lines below the 'frontend' block
bind *:443 ssl crt /etc/haproxy/certs/ha01_ssl.crt
 http-request redirect scheme https code 308 unless { ssl_fc }
# the `unless {ssl_fc}` prevents looping when redirecting to `https`

Now we need to verify the configuration and add firewall

haproxy -f /etc/haproxy/haproxy.cfg -c

firewall-cmd --permanent --add-service=https
firewall-cmd --reload

systemctl restart haproxy

We can use https to see the result

Setting up a Backup Server

👉 What if the proxy server goes down? We would need a backup proxy server to serve when the main server goes down. To make a backup server and to make it run when the main goes down we first need a duplicate of the Proxy server that we created.

I have already created a duplicate proxy server (only the SSL key names are HA02 instead of HA01)

So on both Proxy servers,

echo net.ipv4.ip_nonlocal_bind=1 >> /etc/sysctl.conf
sysctl -p
net.ipv4.ip_nonlocal_bind = 1

👉 We are making the nonlocal_bind parameter to be active.

From both of the Proxy Servers

yum -y install keepalived-*

Now we have to set up the config files for the keepalived service

# Main Proxy Server
vi /etc/keepalived/keepalived.conf

global_defs {
   router_id HA_01
}

vrrp_script HA_Check {
        script "killall -0 haproxy"
        interval 1
    rise 3
    fall 3
        weight 2
}

vrrp_instance HAGroup_1 {
    state MASTER
    interface ens32
    garp_master_delay 5
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass test123
    }
    virtual_ipaddress {
        192.168.1.150
    }
    track_script {
        HA_Check
    }
}

# Backup Proxy Server
vi /etc/keepalived/keepalived.conf

global_defs {
   router_id HA_02
}

vrrp_script HA_Check {
        script "killall -0 haproxy"
        interval 1
    rise 3
    fall 3
        weight 2
}

vrrp_instance HAGroup_1 {
    state BACKUP
    interface ens32
    garp_master_delay 5
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass test123
    }
    virtual_ipaddress {
        192.168.1.150
    }
    track_script {
        HA_Check
    }
}

✔ How does Keepalived works

The master device sends VRRP messages according to a set schedule

The backup device receives the VRRP messages sent by the master device

If the backup device does not receive VRRP messages from the master device, it changes its state to become the master device

When the backup device becomes the master device, it sends a Gratuitous ARP (GARP) message, which includes its MAC address, to inform other devices on the network of the change

The GARP message is used by the switch devices connected to the server equipment where VRRP is running

The switch devices update their MacAddress Table by mapping the VIP (Virtual IP) address to the MAC address of the device that has become the master

👉 As VRRP is L3 protocol, we need to use iptable rules to set up the firewall

From both Proxy Servers

firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -i ens32 -d 224.0.0.18 -p vrrp -j ACCEPT
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -o ens32 -d 224.0.0.18 -p vrrp -j ACCEPT
firewall-cmd --runtime-to-permanent
firewall-cmd --direct --get-all-rules
ipv4 filter OUTPUT 1 -o ens32 -d 224.0.0.18 -p vrrp -j ACCEPT
ipv4 filter INPUT 1 -i ens32 -d 224.0.0.18 -p vrrp -j ACCEPT

systemctl start keepalived
systemctl enable keepalived

Now to test if this works,

From the Main Proxy Server

ip address list | grep 192.168.1.150
inet 192.168.1.150/32 scope global ens32

From the Backup Proxy Server

ip address list | grep 192.168.1.150

Now we will try stopping the keepalived service from our main Proxy Server to test if the Backup Proxy server runs automatically

So now from Main Proxy Server

systemctl stop keepalived
ip address list | grep 192.168.1.150

From the Backup Proxy Server

ip address list | grep 192.168.1.150
inet 192.168.1.150/32 scope global ens32

👉 If the Keepalived daemon is stopped on the master device, the backup device will confirm that it has taken over the VIP (Virtual IP) associated with the stopped master device

When the Keepalived daemon is started again, it is necessary to confirm that the original master device has regained control of the VIP

Conclusion

✍ Today I discussed regarding how to set up a proxy server in Linux CentOS7, apply SSL/TLS certificate to redirect traffic to HTTPS and finally configured a backup proxy server for the main server.