Asset-26

Simpler alternative to Kubernetes – Docker Swarm with Swarmpit

Introduction:

As more are more applications are moving to private or public cloud environments as part of modernization by adopting new microservices architecture, they are being containerized using Docker and are orchestrated using Kubernetes as popular platform choices. Kubernetes does offer many advanced features and great flexibility, making it suitable for complex and large-scale applications, however, it has a steeper learning curve requiring more time, effort and resources to set up, monitor and manage for simpler applications where these advanced features may not be needed.

Docker Swarm is another open-source orchestration platform with a much simpler architecture and can be used to do most of the activities that one does with Kubernetes including the deployment and management of containerized applications across a cluster of Docker hosts with built-in clustering capabilities and load balancing enabling you to manage multiple Docker hosts as a single virtual entity.

Swarmpit is a little-known open-source web-based interface which offers a simple and intuitive interface for easy monitoring and management of the Docker Swarm cluster.

In this article, we walk through the process of setting up a Docker Swarm cluster with one master node and two worker nodes and configure Swarmpit to easily manage and monitor this Swarm Cluster.

Problem Statement

Managing containerized applications at scale can be challenging due to the complexity of handling multiple nodes, ensuring high availability, and supporting scalability. Single-node deployments limit redundancy and scalability, while manually managing multiple nodes is time-consuming and error-prone.

Docker Swarm addresses these challenges with its clustering and orchestration capabilities, but monitoring and managing the cluster can still be complex. This is addressed using Swarmpit.

Use Cases

  1. High Availability: Ensure your application remains available even if individual nodes fail.
  2. Scalability: Easily scale services up or down to meet demand.
  3. Simplified Management: Use a single interface to manage multiple Docker hosts.
  4. Efficient Resource Utilization: Distribute container workloads across multiple nodes.

Why Choose Docker Swarm Over Kubernetes?

Docker Swarm is an excellent choice for smaller or less complex deployments because:

  1. Simplicity and Ease of Use: Docker Swarm is easier to set up and manage compared to Kubernetes. It integrates seamlessly with Docker’s command line tools, making it simpler for those already familiar with Docker.
  2. Faster Deployment: Swarm allows you to get your cluster up and running quickly without the intricate setup required by Kubernetes.
  3. High Availability and Scaling: Docker Swarm effectively manages high availability by redistributing tasks if nodes fail and supports multiple manager nodes. Scaling is straightforward with the docker service scale command and resource constraints. Kubernetes offers similar capabilities but with more advanced configurations, like horizontal pod autoscaling based on custom metrics for finer control.

Limitations of Docker Swarm

  1. Advanced Features and Extensibility: Docker Swarm lacks some of the advanced features and customization options found in Kubernetes, such as detailed resource management and extensive extensions.
  2. Ecosystem: Kubernetes has a larger community and more integrations, offering a broader range of tools and support.

While Kubernetes might be better for complex needs and extensive customization, Docker Swarm offers effective high availability and scaling in a more straightforward and manageable way for simpler use cases.

Comparison:

Prerequisites

Before you start, ensure you have the following:

  1. Three Ubuntu machines with Docker installed.
  2. Access to the machines via SSH.
  3. A basic understanding of Docker and Docker Compose.

Setting Up the Docker Swarm Cluster

To start, you need to prepare your machines. Begin by updating the system packages on all three Ubuntu machines. This ensures that you are working with the latest software and security updates. Use the following commands:

sudo apt update

sudo apt upgrade -y

Next, install Docker on each machine using:

sudo apt install -y docker.io

Enable and start Docker to ensure it runs on system boot:

sudo systemctl enable docker

sudo systemctl start docker 

It is essential that all nodes are running the same version of Docker to avoid compatibility issues. Check the Docker version on each node with:

docker –version

With the machines prepared, go to the instance where you want the manager node to be present and run the command below.

docker swarm init

This will initialize the swarm process and provide a token using which you can add the worker node.

Copy the above-given command by the system and paste it into the instance or machine where you need the worker node to be present. Now both the manager and worker’s nodes are ready.

Once all nodes are joined, verify that the Swarm is properly configured. On the master node, list all nodes using: 

docker node ls

This command should display the master node and the two worker nodes, confirming that they are part of the Swarm. Additionally, you can inspect the Swarm’s status with:

docker info

Check the Swarm section to ensure it is active and reflects the correct number of nodes.

To ensure that your cluster is functioning as expected, deploy a sample service.

Create a Docker service named my_service with three replicas of the nginx image: 

docker service create –name my_service –replicas 3 nginx

Verify the deployment by listing the services and checking their status:

docker service ls

docker service ps my_service

Managing and scaling your Docker Swarm cluster is straightforward. To scale the number of replicas for your service, use:

docker service scale my_service=5 

If you need to update the service to a new image, you can do so with: 

docker service update –image nginx:latest my_service

Troubleshooting Common Issues

Node Not Joining the Swarm

  1. Check Docker Version: Ensure all nodes are running compatible Docker versions.
  2. Firewall Settings: Make sure port 2377 is open on the master node.
  3. Network Connectivity: Verify network connectivity between nodes.

Deploying Swarmpit for Monitoring and Management

Swarmpit is a user-friendly web interface for monitoring and managing Docker Swarm clusters. It simplifies cluster administration, providing an intuitive dashboard to monitor and control your Swarm services and nodes. Here’s how you can set up Swarmpit and use it to manage your Docker Swarm cluster.

Deploy Swarmpit Container

On the manager node, deploy Swarmpit using the following Docker command:

docker run -d -p 8888:8888 –name swarmpit -v /var/run/docker.sock:/var/run/docker.sock swarmpit/swarmpit:latest

Access the Swarmpit Interface

Open your web browser and navigate to http://<manager-node-ip>:8888. You will see the Swarmpit login page. Use the default credentials (admin/admin) to log in. It is recommended to change the default password after the first login.

Using Swarmpit for Monitoring and Management

Once you have logged in, you can perform a variety of tasks through Swarmpit’s web interface:


Dashboard Overview

○ Cluster Health: Monitor the overall health and status of your Docker Swarm cluster.
○ Node Information: View detailed information about each node, including its status, resources, and running services.


Service Management

  1. Deploy Services: Easily deploy new services by filling out a form with the necessary parameters (image, replicas, ports, etc.).
  2. Scale Services: Adjust the number of replicas for your services directly from the interface.
  3. Update Services: Change service configurations, such as updating the Docker image or environment variables.
  4. Service Logs: Access logs for each service to troubleshoot and watch their behavior.

Container Management

  1. View Containers: List all running containers across the cluster, including their status and resource usage.
  2. Start/Stop Containers: Manually start or stop containers as needed.
  3. Container Logs: Access logs for individual containers for troubleshooting purposes.

Network and Volume Management

  • Create Networks: Define and manage custom networks for your services.
  • Create Volumes: Create and manage Docker volumes for persistent storage.

User Management

  1. Add Users: Create additional user accounts with varying levels of access and permissions.
  2. Manage Roles: Assign roles to users to control what actions they can perform within the Swarmpit interface.

Benefits of Using Swarmpit

  1. User-Friendly Interface: Simplifies the complex task of managing a Docker Swarm cluster with a graphical user interface.
  2. Centralized Management: Provides a single point of control over all aspects of your Swarm cluster, from node management to service deployment.
  3. Real-Time Monitoring: Offers real-time insights into the health and performance of your cluster and its services.
  4. Enhanced Troubleshooting: Facilitates easy access to logs and service status for quick issue resolution.

Conclusion

By integrating Swarmpit into the Docker Swarm setup, we get a powerful tool that streamlines cluster management and monitoring. Its comprehensive features and intuitive interface make it easier to maintain a healthy and efficient Docker Swarm environment, enhancing the ability to deploy and manage containerized applications effectively.

Frequently Asked Questions (FAQs)

Docker Swarm is a clustering tool that manages multiple Docker hosts as a single entity, providing high availability, load balancing, and easy scaling of containerized applications.

Install Docker on all machines, initialize the Swarm on the master with docker swarm init, and join worker nodes using the provided token. Verify the setup with docker node ls.

Docker Swarm offers high availability, scalability, simplified management, load balancing, and automated failover for services across a cluster.

Swarmpit is a web-based interface for managing and monitoring Docker Swarm clusters, providing a visual dashboard for overseeing services, nodes, and logs.

Access Swarmpit at http://<manager-node-ip>:8888, log in, and use the dashboard to monitor the health of nodes, view service status, and manage configurations.

824a67c0-e747-4b68-affa-55cc2025551c

Locust Load Testing in Kubernetes [with Concourse]

Load testing is the critical part of any web application quality test to know how it behaves when the load / volume of users accessing it are high. The first step of any load testing is to select the right tools. Locust is one of those tools which is popular in testing python-based
applications. For testers who prefer a command-line interface, Locust is faster, easier to configure, and  enables testing code to be easily reused between projects and different environments. Locust makes the effort to work around the limitation of resources while running the load
test by allowing you to spin up a distributed load test. Through this, we can simulate a large number of users by scaling the number of workers. To install the locust into your local system for development you can run the following
command:

$ pip install locust [you can use Anaconda command line also]For reference, you can look ahead: Locust.
Prerequisites:
1) Kubernetes
2) Concourse
3) Helm Kubernetes is a container management technology developed in Google lab to manage containerized applications in different kinds of environments such as physical, virtual, and cloud infrastructure. It is an open-source system that helps in creating and managing the containerization of applications. Helm chart is the package manager tool for Kubernetes which has the collection of files. Concourse CI is a system built with a loosely coupled microservice architecture. To manage the concourse pipeline by command-line interface we have to use fly.

Setup Locust in Kubernetes:
Add the Helm repository by the command below:
1) $ helm repo add stable https://charts.helm.sh/stable
2) $ helm repo list
Then we will get the output as one helm repo added as:

3) Create a ConfigMap with any name, here I’m calling it locust-worker-configs which holds our locust file. Since in our example we are running Odoo locusts it has multiple files and all the files in a particular folder are added to this ConfigMap which is later referenced in the locust pods (master and worker).

$ kubectl create configmap locust-worker-configs –from-file &lt;local dir&gt;/odoolocust -o
yaml –dry-run=client | kubectl apply -f –

4) Install locust:
$ helm install locust stable/locust -f values.YAML
Here is the list of all configurable values. Be sure to add the ConfigMap name created earlier in the values. YAML file.

After running this command, we will have the following output:

5) Check if all the pods are up and running.

$ kubectl get pods

6) Let’s check the service created:
$ kubectl get service

7) We have one service named “locust-master-svc” created and we can expose it by port forwarding to access from local.

$ kubectl port-forward service/locust-master-svc 8089:8089

We have the locust dashboard up and running from where we can provide the number of users, spawn rate, and host.

Below is the image of the load test which has three workers at a ready state and the CPU percentage metrics is mentioned:

Now we can connect to the remote locust instance and run our tests. The next steps will automate the tests and store the results in a google bucket using Concourse.

Concourse pipeline:

To create the ConfigMap and to run the pods, we have to provide the directory of our folder where all test scripts and concourse pipeline files are located. For that, check the folder structure below:

Here, we’re using pipelines as “locust-tests.pipeline.YAML”. It has two different jobs, one to update the locust scripts and the other to run the tests for a different number of users.


platform: Linux

groups:
– name: locust-test
jobs:
– update-locust-script
– users-50
– users-100
– users-150
– users-200

jobs:

– name: update-locust-script
plan:
– get: pipeline
trigger: true
– put: task
params:
wait_until_ready: 0
kubectl: create configmap locust-worker-configs –from-file pipeline/tasks/odoolocust/ -o yaml –dry-run=client -n | kubectl apply -f –

– name: users-50
plan:
– get: pipeline
– task: users-50
file: pipeline/tasks/locust-test.yaml
params:
user_count: 50

– name: users-100
plan:
– get: pipeline
– task: users-100
file: pipeline/tasks/locust-test.yaml
params:
user_count: 100

resource_types:
– name: kubernetes
type: docker-image
source:
repository: zlabjp/kubernetes-resource
tag: “1.17”

resources:
– name: pipeline
type: git
source:
uri:
branch:
private_key: {{git_private_key}}

– name: task
type: kubernetes
source:
server: {{cluster_url}}
namespace:
token: {{token}}
certificate_authority: ((kubernetes_ca_crt))

The pipeline

Under the task folder, we have 2 files and the Odoo locust folder has the locus file. The cred.py stated below is used in the locust-test. YAML to convert Google Cloud credentials retrieved from a secret manager into JSON file to authenticate Google Cloud to push the test results to a google bucket.

import json
f=open(‘credentials.json’)
d = f.read()

data = json.loads(d, strict=False)

with open(“cred.json”, “w”) as outfile:
json.dump(data, outfile)

                                                                      cred.py

The locust-test. YAML runs the actual tests for different numbers of users as mentioned in the pipeline.


platform: Linux

image_resource:
type: docker-image
source:
repository: google/cloud-sdk
tag: “alpine”

params:
KUBE_CONFIG: ((kubernetes-config))

inputs:
– name: pipeline

run:
path: sh
args:
– -exc
– |
set +x
mkdir -p /root/.kube/
printf %s “${KUBE_CONFIG}” > /root/.kube/config
curl -L -s https://storage.googleapis.com/kubernetes-release/release/v1.18.6/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl
chmod +x /usr/local/bin/kubectl
cd pipeline/tasks/
cat << EOF >> credentials.json
((kubernetes-bucket-storage))
EOF
python3 cred.py
export GOOGLE_APPLICATION_CREDENTIALS=cred.json
POD_NAME=$(kubectl get pods -n <namespace> | grep locust-master | awk ‘{print $1}’)
kubectl exec –stdin –tty ${POD_NAME} bash -n <namespace> << EOF
mkdir tmp
cd tmp
locust -f /mnt/locust/test.py Seller –csv=${user_count}_users –headless –run-time 30m -u ${user_count} -r ${user_count} -H <host> –only-summary
cd ..
tar -zcf users_${user_count}.tgz tmp
rm -rf tmp
EOF
kubectl cp <namespace>/${POD_NAME}:/home/locust/users_${user_count}.tgz users_${user_count}.tgz
kubectl exec –stdin –tty ${POD_NAME} bash -n <namespace> << EOF
rm users_${user_count}.tgz
EOF
gcloud auth activate-service-account –project=<google_project_id> –key-file=cred.json
gsutil mv users_${user_count}.tgz gs://locust-tests/${user_count}_users/users_${user_count}_$(date ‘+%d-%m-%YT%H:%M:%S’).tgz

                                                                       Locust-test.yaml

When we trigger the jobs for 50 users it’ll run the test for the time mentioned in this line of the code where the run-time is 30 minutes.

locust -f /mnt/locust/test.py Seller –csv=${user_count}_users –headless –run-time 30m -u ${user_count} -r ${user_count} -H <host> –only-summary

Once the test is completed, it’ll push the .tgz file with the results to a google bucket named locust-tests and it has subfolders for a different number of users so that we can track the tests for different periods.

This flow can also be integrated with the deployment pipeline of the application so that it runs the test right after the deployment. Here we are using the Odoo locust script to test an Odoo application and the same procedure can be followed for any other application.

This is how we can completely automate the execution of Locust tests using Concourse.

Please get in touch for assistance with setup and use of Locust for your Performance testing needs.