Forem: Ankit Kumar

Deploying Scalable Applications with Docker Swarm and Docker Compose

Ankit Kumar — Mon, 08 Sep 2025 07:45:24 +0000

Part 1: Building the cluster (The Foundation)

1. Go to the Play-With-Docker and Create Instances
You will create 5 instances. These will be your 5 servers.

2. Initialize the Swarm (Nominate the First Leader)

docker swarm init --advertise-addr [ManagerNodeIP]

You pick one of your 5 instances to be the first Manager Node. This command "starts" the swarm and declares this node as the leader. The --advertise-addr tells other nodes which IP address they should use to find and connect to this manager.

3. Add Worker Nodes (Recruit the Workers)

docker swarm join --token SWMTKN-1-17xx0ratormliuuff545oiotqjjgdrlfvbmji5xny007bhdqdx-98ny7h91d36bcy4dgfd8zujm9 192.168.0.29:2377

You copy the join command from the manager and paste it into 3 of your other instances. The long token is like a secret password that proves they are allowed to join your swarm. These nodes become Worker Nodes. Their only job is to run containers as instructed by the manager.

4. Add a Second Manager (Get a Backup Leader)

Commands:

1.On the first manager:

docker swarm join-token manager

2.On the last remaining instance: Paste command which appears after join-token manager command into the remained instance:

docker swarm join --token SWMTKN-1-17xx0ratormliuuff545oiotqjjgdrlfvbmji5xny007bhdqdx-1hahfhs9mrrgsb0nsyzk8vpyp 192.168.0.29:2377

5. Verify the Cluster

docker node ls

Part 2: Defining and Deploying Your Application

This is the docker-compose.yml file

version: "3.8"

services:
  mydatabase:
    image: mysql:5.7
    restart: always
    volumes: 
      - mydata:/var/lib/mysql
    environment: 
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    networks:
      - mynet
  mywordpress:
    image: wordpress:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 2
        delay: 5s
        order: stop-first
    depends_on: 
      - mydatabase
    restart: always
    ports:
      - "80:80"
      - "443:443"
    environment: 
      WORDPRESS_DB_HOST: mydatabase:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    networks:
      - mynet

volumes:
  mydata:

networks:
  mynet:
    driver: overlay

7. Deploy the Stack

docker stack deploy --compose-file docker-compose.yml firststack

docker stack: The command for managing multi-service applications in Swarm.
deploy: The action to create or update the application.
firststack: The name you are giving your application stack.

The manager will now read your file and start creating containers on the worker nodes according to your specifications (1 MySQL container and 3 WordPress containers).

Part 3: Verifying and Testing the Application

** 8. Inspect the Stack

docker stack ls
docker stack services firststack
docker stack ps firststack

docker stack ls: Lists all the stacks running on your swarm.

docker stack services firststack: Shows the services in your stack (firststack_mydatabase and firststack_mywordpress) and how many replicas are running.

docker stack ps firststack: This is the most detailed view. It shows every individual container (called a "task" in Swarm), which node it's running on, and its current state.

9. Test the Self-Healing Feature

Action: You'll go to one of the worker nodes and manually stop a WordPress container using docker container stop [containerID].
What's Happening Here? You are simulating a crash.
The Result: The Swarm manager is constantly monitoring the cluster. It will see that one of the mywordpress replicas is gone (the desired state is 3, but the current state is 2). It will immediately command a worker node to start a new WordPress container to bring the count back up to 3.
Verification: If you run docker stack ps firststack on the manager again, you will see the stopped container and a new one that was recently started to replace it. This proves the "self-healing" power of Swarm.

docker stack ps firststack

From a Single Container to a Secure Application Stack: A Practical Guide to Docker and Server Hardening

Ankit Kumar — Sun, 07 Sep 2025 12:25:13 +0000

Hello, fellow tech enthusiasts and DevOps practitioners!

The world of DevOps is vast, but its foundation is built on a few core principles: containerization, orchestration, and security. Today, I want to walk you through a practical journey I took to solidify my understanding of these pillars. We'll start with a single container and the challenge of data persistence, then scale up to a multi-service application, and finally, zoom out to secure the very server our containers run on.

This isn't just a list of commands; it's a step-by-step guide with explanations of why we do what we do. Let's dive in!

LAB 1: Solving the Problem — Why Docker Volumes are Essential

By their nature, Docker containers are ephemeral. Think of them as temporary workspaces. If you remove a container, all the files and data created inside it vanish forever. This is fine for stateless applications, but what about a database or a web server that hosts user content? We need that data to stick around.

This is the problem that Docker Volumes solve. A volume is like an external hard drive that you plug into your container. It's managed by Docker but exists outside of any single container's lifecycle.

My Hands-On Scenario: Proving Data Persistence

My goal was to see this in action: could I make data survive even after its original container was deleted?

Step 1: Creating the "Digital Safe" (Our Volume)
First, I told Docker to create a managed, persistent storage space called test.

docker volume create test

You can see all your volumes with docker volume ls. At this point, test is just an empty but safe place for data.

Step 2: Launching a Web Server and connecting the Volume

Next, I launched as Nginx web server. The key part of this command is the -v flag, which connects our test volume to the /usr/share/nginx/html directory inside the container. This is the directory where Nginx looks for its website files.

 sudo docker container run --name mywebserver -d -p 80:80 -v test:/usr/share/nginx/html nginx

What happened here is subtle but important: since our test volume was empty, the Nginx container automatically copied it's own default index.html file into the volume. The volume is now the source of truth for the website's contnet.

Step 3: Changing the Data from Inside
To prove we were now working with the volume, I entered the running container and changed the index.html file.

# for go inside the 'mywebserver' container
docker exec -it mywebserver sh

# Once inside, overwrite the content of the main web page
echo '<h1>Data Persists Beyond the Container!</h1>' > /usr/share/nginx/html/index.html

# Exit the container shell
exit

When I refreshed my browser at http://localhost:80, I saw my new message. This confirmed I had successfully modified the data inside the persistent volume.

Step 4: The Ultimate Test — Destroying the Container
Now for the moment of truth. I completely stopped and removed the mywebserver container.

docker rm -f mywebserver

The container is gone. A traditional workspace would have been wiped clean.

Step 5: Resurrecting the Data with a New Container
I launched a brand new, completely separate Nginx container called mywebserver3. However, I connected it to the exact same test volume.

sudo docker run --name mywebserver3 -d -p 80:80 -v test:/usr/share/nginx/html nginx

When I visited http://localhost:80 again... Success! The message "Data Persists Beyond the Container!" was there. We proved that the volume keeps our data safe, completely independent of the container's lifecycle. This concept is critical for running databases, CMSs, or any stateful application in Docker.

LAB 2: Building a Real Application with Docker Compose

Running one container is useful, but modern applications are rarely that simple. They are usually composed of multiple services working together—a web server, a database, a caching service, etc. Managing the lifecycle and networking of all these containers with individual docker commands would be a nightmare.

Enter Docker Compose. It's a tool for defining and running multi-container applications using a single, simple configuration file: docker-compose.yml.

My Hands-On Scenario: Deploying a WordPress Site
I set up a classic web application stack: a WordPress frontend that depends on a MySQL database backend.

The Blueprint: docker-compose.yml
This file is the single source of truth for my entire application.

version: "3.8"

services:
  # The first service: our MySQL Database
  mydatabase:
    image: mysql:5.7
    restart: always
    volumes: 
      - mydata:/var/lib/mysql # Attach a volume to the DB's data directory!
    environment: 
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    networks:
      - mynet

  # The second service: our WordPress frontend
  mywordpress:
    image: wordpress:latest
    depends_on: 
      - mydatabase # Instruction: Don't start WordPress until the database is ready!
    restart: always
    ports:
      - "80:80" # Expose the web server on port 80 of my computer
    environment: 
      WORDPRESS_DB_HOST: mydatabase:3306 # The magic of Docker networking!
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    networks:
      - mynet

# Global definitions for resources used by the services
volumes:
  mydata: {} # Formally create the volume for our database

networks:
  mynet: # Formally create a private network for our containers
    driver: bridge

With this file in place, launching the entire stack was as simple as running docker-compose up -d.

My Key Learnings:

Declarative Infrastructure: I didn't have to tell Docker how to do things. I just declared the desired state in the YAML file, and Compose figured it out.
Service Discovery: The most powerful feature here is networking. The WordPress container found the database using its service name, mydatabase, as its hostname (WORDPRESS_DB_HOST: mydatabase:3306). Docker Compose created a private virtual network (mynet) where containers can find each other by name. No more hard-coding IP addresses!
Dependency Management: The depends_on key is a lifesaver. It ensures the mydatabase container is started and healthy before the mywordpress container even begins to start, preventing connection errors.

LAB 3: Securing the Foundation — A Core SysAdmin Skill

Containers are great, but they still run on a host operating system—usually Linux. Securing this host is just as important as securing the application. One of the most fundamental security-hardening steps is disabling direct root login via SSH.

Why? Because it enforces accountability. It forces every administrator to log in with their own personal user account first, and then use sudo to perform administrative tasks. This creates a clear audit trail (user 'bob' ran command 'xyz') instead of a mysterious log of actions performed by the all-powerful root.

My Hands-On Scenario: KodeKloud Security Challenge

The task was to apply this security measure on three different app servers.

The Universal 5-Step Process:

1.SSH as a Standard User: First, I connected to the server using a non-root account.

ssh tony@stapp01

2.Elevate Privileges Correctly: I became the root user using the sudo command, which required my personal password and logged the action.

sudo su -

3.Edit the SSH Configuration File: Using a text editor like vi, I opened the SSH daemon's configuration file.

vi /etc/ssh/sshd_config

4.Change the Security Directive: Inside the file, I found the line PermitRootLogin and changed its value to no. (It's often commented out with a #, which must be removed).

PermitRootLogin no

5.Apply the Changes: A configuration change is meaningless until the service is restarted.

systemctl restart sshd

I repeated this simple but critical process on all required servers, ensuring a consistent and secure baseline across the infrastructure.

Thanks for following along! I hope this detailed walkthrough was helpful.

Ultimate Guide to Containerizing Node.js + MongoDB

Ankit Kumar — Wed, 13 Aug 2025 17:34:15 +0000

Ankit | Jr DevOps Engineer | akv280501@gmail.com

📁 File Breakdown & Architecture

1. docker-compose.yml

Purpose: Defines multi-container architecture

version: '3.8'

services:
  app:
    build: .
    container_name: node_app
    ports:
      - "3000:3000"
    environment:
      - DB_URI=mongodb://mongo:27017/testdb
    depends_on:
      - mongo


  mongo:
    image: mongo:latest
    container_name: mongo_db
    ports:
      - "27017:27017"
    volumes:
      - mongodata:/data/db

volumes:
   mongodata:

Key Concepts:

Service Discovery: Containers communicate via service names (mongo)
Port Mapping: 3000:3000 exposes Node.js to host machine
Declarative Setup: Infrastructure-as-Code

2. Dockerfile

Layer-by-Layer Optimization:

FROM node:18-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["npm", "start"]

Best Practices:

Layer Caching: Separate COPY package.json + RUN npm install speeds up rebuilds
Minimal Images: Alpine reduces attack surface
Explicit Ports: Documentation for other developers

3. package.json

Dependency Management:

{
  "name": "node-mongo-app",
  "version": "1.0.0",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2",
    "mongoose": "^7.4.3"
  }
}

Why It Matters:

npm start becomes the container's PID 1 process

Version pinning (^4.18.2) prevents breaking changes

4. server.js

const express = require('express');
const mongoose = require('mongoose');

const app = express();
const PORT = 3000;

// Connect to MongoDB -> 'mongodb://mongo:27017/testdb'
// 'mongo' is the service name we will use in docker-compose
const dbUri = process.env.DB_URI || 'mongodb://localhost:27017/testdb';
mongoose.connect(dbUri)
    .then(() => console.log('MongoDB connected successfully!'))
    .catch(err => console.error('MongoDB connection error:', err));

app.get('/', (req, res) => {
    res.send('Hello from your Node.js app! Connected to MongoDB.');
});

app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

🚀 My DevOps Learning Path

20 Projects Challenge:

✅ Node+MongoDB Containers
Flask+Redis+PostgreSQL (Coming Soon)

💬 Let's Build Together!

I need your input on:

*Which project should I tackle next?

*How would you improve this setup?

*DevOps interview tips for 2-3 yr experience roles

Hire Me:

📞 +91-8384860549 | 📧 akv280501@gmail.com
Open to relocation | Immediate joiner

DevOps #Docker #Mentorship #Hiring

Understanding Docker: Containers, Volumes, and Dockerfile by Example

Ankit Kumar — Thu, 17 Jul 2025 19:58:15 +0000

In this blog, we'll walk through some core Docker concepts — including containers, volume mounts, persistent data, and building custom Docker images using Dockerfile. If you're getting into DevOps or containerization, this is the hands-on practical you're looking for!

Automatically Clean Up a Docker Container

If you're running short-lived containers (like Alpine Linux), and want to clean them up automatically once they exit, use:

docker run -it --rm alpine

The --rm flag removes the container once it exits, saving disk space and cleanup time.

Mounting the Host File System in a Container

Containers are isolated, so if you create a file in Container1, it’s not available in Container2. But what if you want to share files between the host and your container?

That’s where bind mounts come in.

Why Share Files?

Instead of rebuilding container images every time, you can mount host files/folders into the container using Docker volumes.

Syntax: Bind Mount using -v

docker run -v <host_path>:<container_path> image_name

Example: Mount a Host HTML Directory to Nginx

docker run -v ~/html:/var/www/html nginx

Example: Multiple Volumes

docker run -v ~/pgdata:/opt/data -v pg.conf:/etc/pg.conf postgres

Be sure to use absolute paths. Docker doesn't understand shortcuts like ~.

Task: Passing a File to a Container

Your app crane reads a file named customerdata.json during runtime. Previously, you had to bake that file into every container image. Now, you can pass it at runtime using volume mounts!

Step-by-step:

Modify the file:

vim ~/workspace/customerdata.json

Update the Company Name to: The File Store

Run the container:

docker run -v ~/workspace/customerdata.json:/customerdata.json crane

What happens under the hood?

When you mount a file to /customerdata.json, it overrides the internal default file in the image.

The container still works if you don’t pass the file — it just falls back to the default.

Persistent Volumes

Bind mounts are one-time mounts, but Docker also supports persistent named volumes using docker volume or Docker Compose. These help preserve data across container restarts or recreations.

Building a Custom Jenkins Image with Dockerfile

Let’s build a custom Docker image for Jenkins using a Dockerfile.

Dockerfile (Example):

FROM openjdk:11-jdk

LABEL maintainer="Ankit"
LABEL env=production

ENV apparea=/home/ankit/Practice

RUN mkdir -p $apparea

ADD https://get.jenkins.io/war/2.397/jenkins.war $apparea

WORKDIR $apparea

EXPOSE 8080

CMD ["java", "-jar", "jenkins.war"]

Build the Docker Image:

sudo docker build -t jenkins-custom .

Run the Jenkins Container:

sudo docker run -d -p 8080:8080 jenkins-custom

Check Running Containers:

sudo docker ps -a

Docker vs Dockerfile

Feature	Dockerfile	Docker Compose
Focus	Build a single image	Run multiple containers
File Name	Dockerfile (no extension)	docker-compose.yml
Commands	FROM, RUN, CMD, COPY, etc.	services, volumes,etc
Use Case	Single-container builds	Multi-container applications

What is docker build?

The docker build command creates Docker images from a Dockerfile.

Syntax:

docker build -t <image-name> .

-t lets you tag the image.

. is the build context (typically the current directory).

Common Dockerfile Instructions

Instruction	Purpose
FROM	Base image (e.g., Ubuntu, Alpine)
RUN	Execute commands (e.g., install tools)
COPY	Copy files from host to image
ADD	Like COPY but supports remote URLs
CMD	Default command for container
ENTRYPOINT	Similar to CMD but allows arguments
EXPOSE	Document container ports

Final Thoughts

With just a few Docker commands and a solid Dockerfile, you can:

Mount files from your host system
Avoid rebuilding images repeatedly
Build production-ready images like Jenkins
Simplify container deployment

Have questions or want a full docker-compose.yml example in the next post? Drop a comment or follow me!

Thanks for reading! 🙌

🔗 Follow my work:

Docker #DevOps #Containers #Jenkins #Dockerfile #Volumes #BindMount #OpenSource #Learning #DevOps #Docker #CI_CD #Kubernetes #HandsOnDevOps #DockerLearning #OpenToWork #BuildInPublic #TechLearning