DEV Community: Md Mohiuddin

Docker Compose: Run Your Whole App with One Command

Md Mohiuddin — Tue, 18 Aug 2026 14:19:02 +0000

From multiple docker run commands to one declarative YAML file.

A real application rarely consists of just one container.

You might have:

Web App
   ↓
Database
   ↓
Redis
   ↓
Message Queue

Starting and configuring all of these containers manually can quickly become painful.

That's where Docker Compose comes in.

In this article, we'll learn how Docker Compose simplifies multi-container applications and how to define an entire application stack in a single YAML file.

Why Docker Compose Matters

Think back to a typical multi-container setup.

You might need commands like:

docker network create mongo-network
docker volume create mongo-data

docker run -d \
  --name mongo \
  --network mongo-network \
  -v mongo-data:/data/db \
  -e MONGO_INITDB_ROOT_USERNAME=admin \
  -e MONGO_INITDB_ROOT_PASSWORD=password123 \
  mongo

docker run -d \
  --name mongo-express \
  --network mongo-network \
  -e ME_CONFIG_MONGODB_SERVER=mongo \
  -e ME_CONFIG_MONGODB_ADMINUSERNAME=admin \
  -e ME_CONFIG_MONGODB_ADMINPASSWORD=password123 \
  -p 8081:8081 \
  mongo-express

It works.

But it's:

Long
Difficult to remember
Easy to mistype
Hard to share
Difficult to maintain

Now imagine having six or ten services.

You don't want to manage your application this way.

Docker Compose lets you describe the entire application in a single file.

Then:

docker compose up

And your application stack starts.

That's the real power of Compose.

What Is Docker Compose?

Docker Compose is a tool for defining and running multi-container Docker applications.

Instead of manually running individual containers, you describe your desired application architecture in a YAML file.

For example:

services:
  web:
    build: .

  database:
    image: mongo

  cache:
    image: redis

Compose reads this configuration and creates the required containers, networks, and volumes.

The important idea is:

Define your application once, then let Docker Compose create and manage it.

Imperative vs Declarative

Docker Compose introduces an important DevOps concept.

Imperative

With individual Docker commands, you tell Docker what to do.

docker network create app-network
docker volume create database-data
docker run ...
docker run ...

You're specifying the steps.

Declarative

With Compose, you describe what you want.

services:
  web:
    build: .

  database:
    image: mongo

You're saying:

"I want a web service and a database service."

Compose determines how to create them.

This declarative approach becomes extremely important later when you learn:

Kubernetes
Terraform
Infrastructure as Code
CI/CD configuration

The `docker-compose.yml` File

Docker Compose uses YAML configuration.

A simple file looks like this:

services:
  web:
    image: nginx

  database:
    image: mongo

The main section is:

services:

Each service represents a container.

For example:

services:
  web:
    image: nginx

  database:
    image: mongo

  cache:
    image: redis

This describes three services:

        Docker Compose
              |
      +-------+-------+
      |       |       |
     Web   Database  Cache
    nginx    mongo   redis

YAML Indentation Matters

YAML uses indentation to represent structure.

Use spaces, not tabs.

For example:

services:
  web:
    image: nginx
    ports:
      - "8080:80"

Incorrect indentation can cause YAML parsing errors.

Defining a Service

Let's look at a realistic service:

services:
  mongo:
    image: mongo
    container_name: mongo
    restart: unless-stopped

    environment:
      MONGO_INITDB_ROOT_USERNAME: admin
      MONGO_INITDB_ROOT_PASSWORD: password123

    ports:
      - "27017:27017"

    volumes:
      - mongo-data:/data/db

Most of these options map directly to docker run flags you've already learned.

`image`

image: mongo

This tells Compose which Docker image to use.

It's similar to:

docker run mongo

You can also specify a version:

image: mongo:8

Pinning versions is generally better than relying on a moving latest tag for production workloads.

`container_name`

container_name: mongo

This gives the container a predictable name.

It's similar to:

docker run --name mongo

In Compose projects, you often don't need container_name because Compose already provides predictable service-based naming and DNS.

`environment`

Environment variables can be defined like this:

environment:
  MONGO_INITDB_ROOT_USERNAME: admin
  MONGO_INITDB_ROOT_PASSWORD: password123

This is equivalent to:

-e MONGO_INITDB_ROOT_USERNAME=admin
-e MONGO_INITDB_ROOT_PASSWORD=password123

For real applications, avoid committing production secrets directly into your Compose file. Environment files or secret-management solutions are better choices.

`ports`

Port mappings use the same familiar syntax:

ports:
  - "8080:80"

This means:

Host              Container
8080      --->       80

It's the Compose equivalent of:

-p 8080:80

`volumes`

Volumes provide persistent storage:

volumes:
  - mongo-data:/data/db

This connects the named volume mongo-data to /data/db inside the MongoDB container.

At the bottom of the Compose file, declare the volume:

volumes:
  mongo-data:

`build` — Building Your Own Application

For your own application, use build: instead of image:.

Suppose your project looks like this:

my-app/
├── Dockerfile
├── app.py
├── requirements.txt
└── docker-compose.yml

Your Compose file can contain:

services:
  web:
    build: .
    ports:
      - "5000:5000"

The:

build: .

means:

Build the image using the Dockerfile in the current directory.

`depends_on`

Suppose your web application needs MongoDB.

You can write:

services:
  web:
    build: .
    depends_on:
      - mongo

  mongo:
    image: mongo

This tells Compose to start MongoDB before starting the web container.

But remember:

depends_on controls startup order, not application readiness.

A database can still be initializing after its container has started.

For more reliable startup behavior, healthcheck can be used.

Docker Compose Networking

One of Docker Compose's biggest advantages is automatic networking.

When you start a Compose project, Compose creates a network for the application by default.

Services can communicate with each other using their service names.

For example:

services:
  web:
    build: .

  mongo:
    image: mongo

The web container can connect to MongoDB using:

mongo

as the hostname.

You don't need to know MongoDB's container IP address.

Conceptually:

+-----------------------------+
|      Compose Network        |
|                             |
|   +--------+   +---------+  |
|   |  web   |-->|  mongo  |  |
|   +--------+   +---------+  |
|                             |
+-----------------------------+

Defining a Custom Network

You can also explicitly define your network:

services:
  web:
    build: .
    networks:
      - app-network

  mongo:
    image: mongo
    networks:
      - app-network

networks:
  app-network:

Now both services belong to app-network and can communicate with each other.

Restart Policies

Compose makes it easy to define what should happen when a container stops.

restart: unless-stopped

Common policies include:

Policy	Behavior
`no`	Never automatically restart
`always`	Always restart
`unless-stopped`	Restart unless manually stopped
`on-failure`	Restart when the process exits with an error

For many long-running services:

restart: unless-stopped

is a useful default.

The Most Important Compose Commands

Start the Application

docker compose up

Run in the Background

docker compose up -d

Build Before Starting

docker compose up --build

Check Service Status

docker compose ps

View Logs

docker compose logs

View Logs for One Service

docker compose logs mongo

Follow Logs

docker compose logs -f mongo

`docker compose stop` vs `docker compose down`

This distinction is extremely important.

`docker compose stop`

docker compose stop

Stops the containers but doesn't remove them.

You can start them again with:

docker compose start

`docker compose down`

docker compose down

Stops and removes the containers and the Compose-created network.

By default, named volumes are preserved.

That means your database data can remain intact.

Be Careful With `down -v`

You can also run:

docker compose down -v

The -v option removes the Compose-managed volumes.

If your database uses those volumes, your database data can be deleted.

Use this command carefully, especially on production systems.

A Complete Real-World Example

Imagine we have:

Flask application
MongoDB
Mongo Express
Persistent MongoDB storage
Custom application network
Restart policies

Our Compose file can look like this:

services:
  web:
    build: .
    container_name: flask-app
    restart: unless-stopped

    ports:
      - "5000:5000"

    depends_on:
      - mongo

    networks:
      - app-network

  mongo:
    image: mongo
    container_name: mongo
    restart: unless-stopped

    environment:
      MONGO_INITDB_ROOT_USERNAME: admin
      MONGO_INITDB_ROOT_PASSWORD: password123

    ports:
      - "27017:27017"

    volumes:
      - mongo-data:/data/db

    networks:
      - app-network

  mongo-express:
    image: mongo-express
    container_name: mongo-express
    restart: unless-stopped

    environment:
      ME_CONFIG_MONGODB_SERVER: mongo
      ME_CONFIG_MONGODB_ADMINUSERNAME: admin
      ME_CONFIG_MONGODB_ADMINPASSWORD: password123

    ports:
      - "8081:8081"

    depends_on:
      - mongo

    networks:
      - app-network

networks:
  app-network:

volumes:
  mongo-data:

Now we have an entire application architecture described in one file:

                 Docker Compose
                       |
          +------------+------------+
          |            |            |
       Flask App     MongoDB    Mongo Express
          |            |            |
          +------------+------------+
                       |
                 app-network
                       |
                  mongo-data
                    volume

Start everything with:

docker compose up -d

Check the services:

docker compose ps

View all logs:

docker compose logs

Stop everything:

docker compose down

And bring it back:

docker compose up -d

Your MongoDB data remains because the named volume wasn't removed.

Why Compose Is a Big Step Forward

Before Compose, your workflow looked like this:

Remember commands
      ↓
Create network
      ↓
Create volume
      ↓
Start database
      ↓
Start application
      ↓
Start admin UI
      ↓
Check configuration

With Compose:

docker compose up -d
        ↓
     Everything

More importantly, the architecture is now stored as code.

You can:

Commit it to Git
Review changes
Share it with teammates
Reproduce the environment
Use it in development
Use it in CI/CD workflows

That's a major shift in how you manage applications.

Docker Compose Is Infrastructure as Code Practice

You may not think of a Compose file as infrastructure code yet.

But it is teaching you the right mindset.

Instead of:

"I remember how I configured this server."

You say:

"The configuration is defined in Git."

Instead of:

"Run these 12 commands in this exact order."

You say:

"Here is the desired state."

This mindset becomes extremely important when you move into:

CI/CD
Kubernetes
Terraform
Ansible
Cloud infrastructure

Docker Compose is one of the first practical places where you'll experience this shift.

Final Thoughts

Docker made it easy to package applications into containers.

Docker networking made it possible for containers to communicate.

Docker volumes made persistent data possible.

And Docker Compose brings all of these concepts together into one manageable application definition.

The biggest lesson today isn't just learning:

docker compose up

It's learning to describe infrastructure declaratively.

Instead of manually managing containers one by one, you define the entire application stack as code and let Docker Compose handle the implementation.

That's the real bridge from simply using Docker to thinking like a DevOps engineer.

Define it once. Version it. Share it. Reproduce it.

Dockerfiles: Build Your Own Images

Md Mohiuddin — Sun, 16 Aug 2026 17:29:39 +0000

Running Docker images is useful. Building your own images is where you start becoming a real Docker practitioner.

How do you package your own application into a Docker image?

That's what Dockerfiles are for.

A Dockerfile turns your application's code, dependencies, runtime, and startup instructions into a reproducible Docker image.

In this article, you'll learn:

What a Dockerfile is
The most important Dockerfile instructions
How FROM, WORKDIR, COPY, RUN, EXPOSE, and CMD work
Why Dockerfile instruction order matters
How Docker build caching works
How to build and run your own image
Why .dockerignore is important

From Docker User to Docker Author

Until now, you've mostly worked with images created by other people.

For example:

docker run nginx
docker run redis
docker run mongo

These commands use images that already exist.

Today, you'll create an image for an application yourself.

That changes the way you think about Docker.

Instead of asking:

"How do I run this image?"

You'll start asking:

"How should I package this application into an image?"

This is an important step because Dockerfiles appear everywhere in modern software delivery.

They are used by:

Development teams
CI/CD pipelines
Cloud platforms
Kubernetes deployments
Container registries
Production environments

Once you understand Dockerfiles, you have a skill that carries directly into the rest of your DevOps journey.

What Is a Dockerfile?

A Dockerfile is a plain-text file containing instructions that Docker uses to build an image.

Think of it as a recipe.

Dockerfile
     |
     v
+-----------------------+
| Base image            |
| Dependencies          |
| Application code      |
| Configuration         |
| Startup command       |
+-----------------------+
     |
     v
Docker Image

A Dockerfile describes:

Which base image to use
Where the application should live
Which dependencies need to be installed
Which files should be copied
Which port the application uses
Which command should run when the container starts

Because the Dockerfile is just a text file, you can commit it to Git alongside your application source code.

That gives you a reproducible way to build the same image again and again.

`FROM` — Choose the Base Image

Every Dockerfile normally starts with FROM.

Example:

FROM python:3.12-slim

FROM tells Docker which existing image should be used as the starting point.

In this example, we're starting with Python 3.12 on a slim Linux base.

The choice of base image matters.

A smaller image generally means:

Faster downloads
Smaller storage requirements
Smaller deployment artifacts
Fewer unnecessary packages

Common Python base images include:

Base Image	Characteristics
`python:3.12`	Full Python image with more system packages
`python:3.12-slim`	Smaller image with fewer unnecessary packages
`python:3.12-alpine`	Very small Alpine-based image

For many applications, a slim image is a good starting point.

Why Avoid `latest`?

You could write:

FROM python:latest

But the meaning of latest can change over time.

A future build could use a different Python version than today's build.

For reproducibility, explicit versions are usually better:

FROM python:3.12-slim

The more controlled your base image is, the more predictable your builds become.

`WORKDIR` — Set the Working Directory

Next, define where your application will live inside the image.

WORKDIR /app

This is similar to using cd on Linux.

After this instruction, subsequent commands operate relative to /app.

For example:

WORKDIR /app

COPY requirements.txt .
COPY app.py .

The files will be copied into:

/app/requirements.txt
/app/app.py

Docker also creates the directory if it doesn't already exist.

Using WORKDIR is cleaner than repeatedly writing:

RUN mkdir /app
RUN cd /app

The second approach is also misleading because each RUN instruction executes in its own build step.

WORKDIR is the standard and predictable way to define the working directory.

`COPY` — Bring Application Files Into the Image

The COPY instruction transfers files from your build context into the image.

Example:

COPY requirements.txt .
COPY . .

The first argument is the source.

The second argument is the destination.

Because we previously defined:

WORKDIR /app

this:

COPY requirements.txt .

means:

Host:
requirements.txt

        |
        v

Container:
/app/requirements.txt

You can also copy the entire application:

COPY . .

But there is an important reason why you should not always do this immediately.

We'll come back to that when we discuss build caching.

`RUN` — Execute Commands During the Build

RUN executes a command while Docker is building the image.

For a Python application:

RUN pip install --no-cache-dir -r requirements.txt

This installs the application's dependencies into the image.

Other examples include:

RUN apt-get update

RUN npm install

RUN pip install flask

The important thing to remember is:

RUN happens during image building.

For example:

docker build -t my-app .

During this process, Docker executes the RUN instructions.

The resulting changes become part of the image.

`RUN` vs `CMD`

This distinction is extremely important.

RUN happens when the image is built.

CMD happens when the container is started.

Think about it this way:

docker build
     |
     +--> RUN instructions
     |
     v
Docker Image
     |
     | docker run
     v
Container
     |
     +--> CMD

Example:

RUN pip install -r requirements.txt

This installs dependencies during the build.

Then:

CMD ["python", "app.py"]

starts the application when the container runs.

`EXPOSE` — Document the Application Port

Suppose your application listens on port 5000.

You can document that in the Dockerfile:

EXPOSE 5000

But there's an important detail:

EXPOSE does not publish the port.

It is primarily metadata/documentation that tells readers and tooling which port the application expects to use.

To actually make the application reachable from your host, use -p:

docker run -p 5000:5000 my-flask-app

The mapping means:

Host                  Container

5000  ------------->  5000

So:

http://localhost:5000

can reach the application inside the container.

`CMD` — Define the Default Startup Command

CMD defines what should run when a container starts.

For a Python application:

CMD ["python", "app.py"]

This is different from RUN.

RUN happens during the build.

CMD happens when the container starts.

For example:

docker build -t my-flask-app .

creates the image.

Then:

docker run my-flask-app

starts a container and executes:

python app.py

Prefer Exec Form

The recommended form is:

CMD ["python", "app.py"]

rather than:

CMD python app.py

The JSON-array form is called the exec form.

It allows the application process to receive operating system signals more directly, which is important for graceful shutdown.

For example, when you run:

docker stop my-app

Docker can send the termination signal to the application process.

A Complete Dockerfile

Imagine this project:

my-flask-app/
├── app.py
├── requirements.txt
└── Dockerfile

The Dockerfile could look like this:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000

CMD ["python", "app.py"]

Read it from top to bottom:

FROM
  ↓
Choose Python

WORKDIR
  ↓
Move into /app

COPY requirements.txt
  ↓
Bring in dependencies

RUN pip install
  ↓
Install dependencies

COPY .
  ↓
Bring in application code

EXPOSE
  ↓
Document application port

CMD
  ↓
Start the application

This simple file describes the complete environment required to run the application.

Why Dockerfile Instruction Order Matters

This is one of the most important Docker concepts to understand.

Docker images are built in layers.

For example:

Layer 5: CMD ["python", "app.py"]
Layer 4: COPY . .
Layer 3: RUN pip install ...
Layer 2: COPY requirements.txt .
Layer 1: FROM python:3.12-slim

Docker can cache these layers.

That means if something hasn't changed, Docker can reuse the previous result instead of doing the work again.

This makes builds much faster.

Understanding Docker Build Cache

Imagine your application has 20 Python dependencies.

Installing them could take some time.

Now imagine you change one line of app.py.

You rebuild the image.

Do you really want Docker to reinstall all 20 dependencies?

No.

That's why we structure the Dockerfile like this:

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

The dependency file is copied first.

The application code is copied later.

Now consider what happens when you change only:

app.py

Docker sees that:

requirements.txt

has not changed.

So it can reuse the cached dependency installation layer.

Only the later application layer needs to be rebuilt.

A Common Dockerfile Mistake

A beginner might write:

FROM python:3.12-slim

WORKDIR /app

COPY . .

RUN pip install --no-cache-dir -r requirements.txt

CMD ["python", "app.py"]

This works.

But it can be inefficient.

Why?

Because COPY . . includes your application code.

Every time any source file changes, Docker may invalidate that layer and everything after it.

That means:

Change app.py
      |
      v
COPY . . changes
      |
      v
pip install runs again

That is unnecessary.

The Better Dockerfile

Instead, separate dependencies from application code:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000

CMD ["python", "app.py"]

Now:

requirements.txt changes
        |
        v
Reinstall dependencies


app.py changes
        |
        v
Reuse dependency cache

This simple ordering decision can make a huge difference during development and CI/CD builds.

The General Rule

A useful principle is:

Put instructions that change rarely before instructions that change frequently.

For example:

Base image
    ↓
System dependencies
    ↓
Application dependencies
    ↓
Application source code

The less frequently changing layers are placed earlier so Docker can reuse them as often as possible.

Building Your Docker Image

Once you have a Dockerfile, build the image:

docker build -t my-flask-app .

Let's break this down.

`docker build`

Tells Docker to build an image.

`-t my-flask-app`

Assigns a name to the image.

The -t option means tag.

You can also specify a version:

docker build -t my-flask-app:1.0 .

This is useful because explicit image versions make deployments easier to reproduce.

`.`

The dot specifies the build context.

It tells Docker:

"Use the current directory as the build context."

Docker can access files from this context when processing instructions such as COPY.

Check Your New Image

After the build completes:

docker images

You should see something similar to:

REPOSITORY      TAG       IMAGE ID       CREATED        SIZE
my-flask-app    latest    abc123def456   10 seconds ago  150MB

You can also use an explicit version:

docker build -t my-flask-app:1.0 .

Then:

docker images

might show:

REPOSITORY      TAG       IMAGE ID
my-flask-app    1.0       abc123def456

Versioning your images becomes especially important once you start using registries and CI/CD pipelines.

Run Your Application

Now start a container:

docker run -d   --name my-app   -p 5000:5000   my-flask-app:1.0

Check that it's running:

docker ps

Check the application logs:

docker logs my-app

Then test it:

curl http://localhost:5000

Or open this in your browser:

http://localhost:5000

You've now taken your own application and turned it into a Docker container.

`.dockerignore` — Your Docker Build's `.gitignore`

If you've worked with Git, you already know about:

.gitignore

It prevents unwanted files from being tracked by Git.

Docker has a similar concept:

.dockerignore

It prevents unwanted files from being included in the Docker build context.

For example:

__pycache__/
*.pyc
.git/
.gitignore
.env
node_modules/
*.log

This is important for several reasons.

Smaller Build Context

You don't need to send unnecessary files to Docker.

For example:

.git/
node_modules/
logs/

can be very large.

Ignoring them makes builds more efficient.

Smaller Images

If unnecessary files aren't copied into the image, the resulting image can be smaller.

Security

Most importantly, don't accidentally copy secrets.

For example:

.env

might contain:

DATABASE_PASSWORD=secret
API_KEY=abc123

You do not want those credentials baked into your Docker image.

Just as you should never commit secrets to Git, you should also avoid putting secrets into container images.

A Practical `.dockerignore`

A basic Python project might use:

__pycache__/
*.pyc
.git/
.gitignore
.env
.venv/
venv/
*.log

For a Node.js application:

node_modules/
.git/
.env
*.log

The exact contents depend on your project.

The principle is simple:

Only send Docker the files it actually needs.

`COPY` vs `ADD`

You may also see another Dockerfile instruction:

ADD

ADD provides some additional behavior, such as handling local archives.

However, for normal file copying, COPY is generally preferred because its behavior is simpler and more predictable.

Use:

COPY

for ordinary application files.

Use ADD only when you specifically need one of its additional features.

Common Dockerfile Mistakes

Using `latest` Everywhere

Avoid:

FROM python:latest

when reproducibility matters.

Prefer:

FROM python:3.12-slim

Copying Everything Too Early

Avoid:

COPY . .
RUN pip install -r requirements.txt

when you can separate dependencies first.

Prefer:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Confusing `EXPOSE` With Port Publishing

This:

EXPOSE 5000

does not make the application available on your host.

You still need:

docker run -p 5000:5000 my-app

Putting Secrets in the Image

Never do this:

ENV API_KEY="my-secret-key"

or:

COPY .env .

Secrets should be provided at runtime through appropriate secret-management mechanisms rather than baked into an image.

Forgetting `.dockerignore`

Without .dockerignore, you may accidentally send:

Git history
Dependencies
Logs
Local virtual environments
Environment files
Secrets

to the Docker build context.

The Dockerfile Mental Model

At this point, you can think about a Dockerfile as a pipeline:

Base Image
    |
    v
Working Directory
    |
    v
Application Dependencies
    |
    v
Application Code
    |
    v
Runtime Configuration
    |
    v
Startup Command
    |
    v
Docker Image
    |
    v
Docker Container

Each stage has a specific purpose.

Once this mental model becomes familiar, Dockerfiles stop looking like mysterious configuration files.

They become simple instructions describing how your application should be packaged.

From Dockerfile to CI/CD

Dockerfiles become even more powerful when combined with CI/CD.

Imagine a Git push:

Developer
    |
    v
Git Push
    |
    v
CI Pipeline
    |
    v
docker build
    |
    v
Docker Image
    |
    v
Container Registry
    |
    v
Deployment

This is one of the most common patterns in modern software delivery.

Later in your DevOps journey, you'll build CI/CD pipelines that automatically:

Build Docker images
Run tests
Tag images
Push images to a registry
Deploy them to an environment

The Dockerfile you write today becomes one of the core building blocks of that pipeline.

Hands-On Challenge

Create a simple Python application.

Your project should look like this:

docker-demo/
├── app.py
├── requirements.txt
├── Dockerfile
└── .dockerignore

Create app.py:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello from Docker!"

app.run(host="0.0.0.0", port=5000)

Create requirements.txt:

flask

Create the Dockerfile:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000

CMD ["python", "app.py"]

Create .dockerignore:

__pycache__/
*.pyc
.git/
.env
venv/
.venv/

Build the image:

docker build -t docker-demo:1.0 .

Run it:

docker run -d   --name docker-demo   -p 5000:5000   docker-demo:1.0

Check the container:

docker ps

Check the logs:

docker logs docker-demo

Test the application:

curl http://localhost:5000

You should get:

Hello from Docker!

Final Thoughts

Docker becomes much more useful once you stop relying only on images created by others.

A Dockerfile gives you a reproducible way to package your own application with its runtime and dependencies.

The most important concepts from today are:

FROM defines the base image
WORKDIR defines the working directory
COPY brings files into the image
RUN executes commands during the build
EXPOSE documents the application's port
CMD defines the default startup command
Docker layers make build caching possible
Instruction order can dramatically improve build performance
.dockerignore keeps unnecessary and sensitive files out of the build context

The most important habit to take away is this:

Build images to be reproducible, small, secure, and easy to rebuild.

Once you can confidently write a Dockerfile for your own application, you're no longer just running containers.

You're building the containers that power the rest of your DevOps workflow.

Docker Networking & Volumes: Connecting Containers and Persisting Data

Md Mohiuddin — Fri, 14 Aug 2026 12:37:43 +0000

Learn how containers communicate with each other and how to keep data alive even after containers are removed.

Modern applications rarely run as a single container. A typical application might include a web application, a database, a cache layer, and background workers. For these services to work together, containers need a reliable way to communicate and share data.

In this article, we'll learn:

How Docker networking works
How containers discover each other
Docker network drivers
Persistent storage with Docker volumes
Essential networking and volume commands
A real-world multi-container example

By the end, we'll understand two of the most important concepts in Docker: networking and data persistence.

Why Docker Networking Matters

Every container runs inside its own isolated network namespace.

This isolation improves security and prevents conflicts, but it also creates an important challenge:

If containers are isolated, how does a web application connect to a database?

Imagine a web application running inside one container and MongoDB running inside another. Without networking, they cannot communicate.

Docker solves this problem using Docker Networks.

A Docker network allows containers to communicate with each other while remaining isolated from unrelated containers.

Web App Container
        |
        v
   Docker Network
        |
        v
Database Container

Without a shared network, containers cannot easily find or communicate with each other.

Docker Network Drivers

Docker supports several network drivers, but most developers primarily use three.

Bridge Network

A bridge network creates a private virtual network on the Docker host.

Containers connected to the same bridge network can communicate with each other securely.

Create a custom bridge network:

docker network create my-app-network

Benefits of bridge networks:

Container-to-container communication
Isolation from other applications
Built-in DNS resolution
Easy management

For most Docker projects, a user-defined bridge network is the recommended choice.

Host Network

With the host driver, the container shares the host machine's network stack directly.

docker run --network host nginx

Advantages:

Slightly better networking performance
No port mapping required

Disadvantages:

Reduced isolation
Potential port conflicts
Less flexibility

For most applications, bridge networks are the better option.

None Network

The none driver completely disables networking.

docker run --network none alpine

A container using this driver:

Cannot access the internet
Cannot communicate with other containers
Cannot accept incoming connections

This is useful for highly restricted workloads that require no network access.

The Most Important Feature: Service Discovery

One of Docker's most powerful networking features is built-in DNS resolution.

Instead of connecting containers by IP address, we can connect them using container names.

The Problem with IP Addresses

Container IP addresses are assigned dynamically.

If a container restarts, its IP address can change.

Hardcoding IP addresses creates fragile configurations that eventually break.

For example:

192.168.1.25 → MongoDB

If MongoDB restarts and receives a new IP address, the application can no longer connect.

The Better Approach

Create a custom network:

docker network create my-app-network

Run MongoDB:

docker run -d \
  --name mongo \
  --network my-app-network \
  mongo

Run Mongo Express:

docker run -d \
  --name mongo-express \
  --network my-app-network \
  -e ME_CONFIG_MONGODB_SERVER=mongo \
  -p 8081:8081 \
  mongo-express

Notice this environment variable:

ME_CONFIG_MONGODB_SERVER=mongo

Mongo Express connects to MongoDB using the container name.

Docker automatically resolves:

mongo → container IP address

This feature is called service discovery.

Instead of relying on changing IP addresses, containers communicate using stable names.

Essential Docker Network Commands

List all networks:

docker network ls

Create a network:

docker network create my-app-network

Inspect a network:

docker network inspect my-app-network

Connect a running container:

docker network connect my-app-network my-container

Disconnect a container:

docker network disconnect my-app-network my-container

Remove a network:

docker network rm my-app-network

These commands are the foundation of Docker networking and are frequently used when troubleshooting multi-container applications.

Why Docker Volumes Matter

Containers are designed to be disposable.

If a container is removed, any data stored inside its writable layer is lost forever.

For applications such as databases, this is a major problem.

Imagine storing customer information in MongoDB and then deleting the container.

Without persistent storage:

Container removed = Data lost

This is where Docker Volumes become essential.

Docker Volumes allow data to exist independently from containers.

Even if a container is removed and recreated, the data remains intact.

Types of Docker Storage

Docker provides multiple ways to persist data.

Named Volumes

Named volumes are the recommended approach for most production workloads.

Create a volume:

docker volume create mongo-data

Use the volume:

docker run -d \
  --name mongo \
  -v mongo-data:/data/db \
  mongo

Benefits:

Managed by Docker
Portable across environments
Easy backups and maintenance
Cleaner configuration

For databases and production applications, named volumes are usually the best choice.

Bind Mounts

Bind mounts connect a specific host directory to a container.

Example:

docker run -d \
  -v /home/user/data:/data/db \
  mongo

Benefits:

Direct access to files from the host
Great for development workflows
Easy editing of source code

Drawbacks:

Depends on host filesystem paths
Less portable
Can introduce permission issues

Bind mounts are commonly used during development, while named volumes are preferred for production workloads.

Understanding Volume Mapping

Volume syntax follows this format:

-v source:destination

Example:

-v mongo-data:/data/db

mongo-data   → Host side
/data/db     → Container side

If the container writes data to /data/db, that data is stored in the Docker volume named mongo-data.

This is similar to Docker port mapping:

-p 8080:80

8080 → Host port
80   → Container port

The same "host-to-container" concept applies to both networking and storage.

Essential Docker Volume Commands

List all volumes:

docker volume ls

Create a volume:

docker volume create my-volume

Inspect a volume:

docker volume inspect my-volume

Remove a volume:

docker volume rm my-volume

Remove unused volumes:

docker volume prune

⚠️ Use docker volume prune carefully.

It permanently deletes unused volumes and can remove important data if executed without checking first.

A good habit is to review existing volumes before deleting anything.

Building a Real Multi-Container Application

Let's combine networking and volumes into a realistic example.

Step 1: Create a Network

docker network create my-app-network

Step 2: Create a Volume

docker volume create mongo-data

Step 3: Start MongoDB

docker run -d \
  --name mongo \
  --network my-app-network \
  -v mongo-data:/data/db \
  mongo

Step 4: Start Mongo Express

docker run -d \
  --name mongo-express \
  --network my-app-network \
  -e ME_CONFIG_MONGODB_SERVER=mongo \
  -p 8081:8081 \
  mongo-express

What happens here?

MongoDB stores its data in a persistent volume.
Mongo Express shares the same Docker network.
Mongo Express discovers MongoDB using the hostname mongo.
Data survives container recreation.
Both services remain isolated from unrelated containers.

This is a real-world pattern used in countless Docker applications.

How Networking and Volumes Work Together

A successful containerized application usually needs both networking and persistence.

Networking provides:

Communication between services
Service discovery
Isolation between applications

Volumes provide:

Persistent storage
Data durability
Independence from container lifecycle

Without networking, services cannot communicate.

Without volumes, important data disappears when containers are removed.

Together, they form the foundation of modern containerized applications.

Final Thoughts

Running a single container is useful, but real-world applications require much more.

A web application needs to communicate with databases, caches, and supporting services. At the same time, important data must survive container restarts, updates, and redeployments.

Docker Networks solve communication challenges through service discovery and isolation.

Docker Volumes solve persistence challenges by separating data from container lifecycles.

These two concepts are fundamental building blocks for everything that comes next:

Docker Compose
CI/CD pipelines
Kubernetes
Cloud-native applications

Master Docker networking and volumes, and we'll be well prepared to build and operate real-world containerized applications.

Serving Data Cloud Data to CRM-Only Users in Salesforce

Md Mohiuddin — Thu, 13 Aug 2026 17:45:44 +0000

How to securely expose Salesforce Data Cloud data to CRM-only users
without giving those users direct Data Cloud access.

A common Salesforce architecture problem looks simple at first:

A Lightning component needs to display Data Cloud data, but the users
viewing the component are CRM-only users who don't have Data Cloud
access.

At first glance, it seems like ConnectApi.CdpQuery should solve the
problem. Unfortunately, the query runs in the context of the browsing
user. If that user doesn't have the required Data Cloud access, the
query is rejected.

This article walks through an alternative architecture using:

Apex
Lightning Web Components (LWC)
Named Credentials
External Credentials
An External Client App
A dedicated integration identity
Custom Permissions
Public Groups
Apex-controlled row-level filtering

The result is a component that can show the same Data Cloud dataset to
CRM users while applying different row-level rules based on the
Salesforce user's public-group membership.

The Problem

Imagine a Data Cloud data model object containing member plans:

ssot__MemberPlan__dlm

Suppose the dataset contains:

EPO  → 5 rows
HMO  → 5 rows
POS  → 5 rows
PPO  → 5 rows
----------------
Total → 20 rows

Now imagine two CRM users:

User Data Cloud Access Public Group Expected Result

User 1 No Not a member All 20 plans
User 2 No Member_Plan_HMO_Only 5 HMO plans

Both users should be able to use the same Lightning component.

However, neither user should authenticate directly to Data Cloud.

That creates the core architecture challenge.

Why `ConnectApi.CdpQuery` Isn't Enough

A natural first attempt is to query Data Cloud directly from Apex:

ConnectApi.CdpQuery.queryDataCloud(...);

The problem is that the query executes as the current Salesforce user.

If User 2 is a CRM-only user without Data Cloud access, Data Cloud sees:

User 2
   |
   v
Data Cloud Query
   |
   v
Access denied

The component cannot simply "borrow" another user's Data Cloud
permissions.

We therefore need a different execution identity.

The Core Idea: Separate Execution Identity From Browsing User

The architecture separates two concepts:

Browsing user

The Salesforce CRM user who clicked the component.

Integration identity

A dedicated Salesforce user whose credentials are used to access Data
Cloud.

The browser user never receives the integration user's credentials.

Instead, Salesforce's Named Credential framework handles authentication
for the outbound request.

The resulting architecture looks like this:

CRM User
   |
   | Lightning Component
   v
Apex Controller
   |
   |-- Gate 1: Custom Permission
   |
   | Named Credential
   v
External Credential
   |
   | Client Credentials
   v
External Client App
   |
   | Run As
   v
Integration User
   |
   v
Data Cloud

This gives us an important separation:

Who is viewing the component?
        ↓
Salesforce CRM user

Who queries Data Cloud?
        ↓
Integration user

The Important Trap

There is an easy-to-miss permission boundary here.

A Named Credential can authenticate the outbound call using a named
principal, but the Apex transaction is still executing as the current
Salesforce user.

That means the browsing user must be permitted to use the stored
External Credential principal.

Without that grant, the callout can fail even when:

The External Client App is configured correctly
The integration user has Data Cloud access
The Named Credential is configured correctly
The current user is an administrator

This is one of the most common reasons this architecture appears
correctly configured but doesn't work.

The flow therefore has two different permission gates.

Gate 1
CRM User
   |
   | Custom Permission
   v
Can the user call the feature?

Gate 2
CRM User
   |
   | External Credential Principal Access
   v
Can the Apex transaction use the stored credential?

        ↓

Integration Identity
        ↓

Data Cloud

How the Identity Swap Works

Two pieces make the identity swap possible.

1. The Named Principal

The External Credential uses a named principal.

The authentication flow uses client credentials against a Salesforce
External Client App whose Run As user has the required Data Cloud
access.

The resulting token belongs to the integration identity.

It does not belong to the CRM user who clicked the component.

2. The Core Salesforce Domain

The Data Cloud Query API is accessed through the Salesforce core domain:

/services/data/v64.0/ssot/queryv2

The Named Credential points to the Salesforce My Domain.

The Apex code can therefore make one authenticated callout without
asking the CRM user to authenticate separately to Data Cloud.

The Request Flow

The complete request looks like this:

Step What Happens

1 User calls getMemberPlans()
2 Apex checks View_Member_Plan_Data
3 Apex calls the DataCloud_Core Named Credential
4 Salesforce verifies External Credential Principal Access
5 Named Credential injects the integration identity
6 Data Cloud executes the query as the integration user
7 Apex applies CRM-side row-level rules
8 LWC displays the permitted rows

The critical point is that Data Cloud sees the integration identity,
while Apex still knows who the actual CRM user is.

Row-Level Access in Apex

Because the integration user has broad access to the Data Cloud dataset,
Data Cloud itself cannot distinguish User 1 from User 2.

Therefore, row-level access must be enforced in Apex.

For this example, a public group determines whether the user is
restricted to HMO plans.

Member_Plan_HMO_Only
          |
          +---- User 2

The Apex controller determines the current user:

UserInfo.getUserId()

and checks whether that user belongs to the restricted public group.

The resulting behavior is:

User Group Membership Query Scope

User 1 Not in group All plan types
User 2 In group HMO only

Keep the Restriction Server-Side

One of the most important security principles in this design is:

The client never decides which rows it is allowed to see.

The restriction is derived inside Apex.

For example:

private static final String RESTRICTED_GROUP =
    'Member_Plan_HMO_Only';

private static final String RESTRICTED_PLAN_TYPE =
    'HMO';

The controller derives the restriction from:

UserInfo.getUserId()

rather than accepting a value from the LWC.

That means the client cannot simply send:

planType = "ALL"

and bypass the restriction.

Protecting the Query From Injection

There is another important consideration.

If the Data Cloud Query API accepts raw SQL and doesn't provide the same
bind-variable experience you might expect from ordinary Apex SOQL, query
construction needs additional protection.

Never blindly concatenate user-controlled values into the query.

For example, don't build a query like:

String query =
    'SELECT ... WHERE PlanType = \'' +
    userSuppliedValue +
    '\'';

Instead, use strict allowlisting.

The principle should be:

Input
  |
  v
Is it an allowed value?
  |
  +-- No --> Reject
  |
  +-- Yes
        |
        v
     Build query

For the restricted plan type, the value should come from server-side
constants rather than from the browser.

The same principle applies to any optional filter such as groupNumber.

Allowlist and reject. Don't sanitize and continue.

The Setup Architecture

The setup has several components:

External Client App
        |
        | OAuth Client Credentials
        v
External Credential
        |
        | Named Principal
        v
Named Credential
        |
        v
Apex Controller
        |
        v
Data Cloud Query API

There are also two Salesforce-side access controls:

Custom Permission
       +
External Credential Principal Access

Together they determine whether a CRM user can invoke the feature and
use the stored integration credential.

Step 1 --- Choose the Run-As User

The Run-As user performs the Data Cloud queries.

This user's access therefore becomes the effective Data Cloud access
boundary for the integration.

For a production implementation:

Prefer a dedicated integration user with only the Data Cloud access
required by this feature.

Avoid using a highly privileged personal administrator account.

A good principle is:

Integration User
      |
      +-- Read required Data Cloud data
      +-- Nothing unnecessary

This limits the blast radius if the integration is misconfigured.

Step 2 --- Create the External Client App

In Salesforce Setup:

Setup
  → External Client App Manager
  → New External Client App

Example configuration:

Setting Value

Name Data Cloud MemberPlan Integration
Enable OAuth Enabled
Callback URL Salesforce OAuth success URL
Scopes api, cdp_query_api, refresh_token / offline_access
Flow Enablement Client Credentials Flow

Then configure OAuth policies.

The important setting is:

Run As = Integration User

The client credentials flow uses this Run-As identity.

After creating the app, obtain the:

Consumer Key
Consumer Secret

Allow Time for Propagation

After creating or changing the External Client App, allow time for the
configuration to propagate before troubleshooting authentication.

An authentication failure immediately after configuration doesn't
necessarily mean the credentials are wrong.

Step 3 --- Create the External Credential

Navigate to:

Setup
  → Named Credentials
  → External Credentials
  → New

Example:

Setting Value

Label DataCloud_IntegrationUser
Name DataCloud_IntegrationUser
Authentication Protocol OAuth 2.0
Flow Type Client Credentials with Client Secret
Identity Provider URL <My Domain>/services/oauth2/token
Scope Leave blank

Important: Leave Scope Blank

For this architecture, don't populate the Scope field in the External
Credential.

The OAuth scopes are defined on the External Client App.

If the token endpoint rejects a scope parameter in this flow,
authentication can fail with an error such as:

invalid_request
scope parameter not supported

Create the External Credential Principal

Under Principals, create the named principal:

Parameter Name:
DataCloudIntegration

Then provide:

Consumer Key
Consumer Secret

Save the principal and authenticate it.

The principal should report:

Configured

before continuing.

Step 4 --- Create the Named Credential

Create a Named Credential:

Label:
DataCloud Core

Name:
DataCloud_Core

The name is important because the Apex controller references it
directly.

Example:

Setting Value

Label DataCloud Core
Name DataCloud_Core
URL <My Domain>
Enabled for Callouts Yes
External Credential DataCloud_IntegrationUser
Generate Authorization Header Yes

The Apex code can then reference:

callout:DataCloud_Core

The Named Credential handles authentication instead of requiring
credentials to be embedded in Apex.

Step 5 --- Grant External Credential Principal Access

This is the step that's easiest to miss.

The Apex transaction needs permission to use the stored External
Credential principal.

The permission set can contain an External Credential Principal Access
entry similar to:

<externalCredentialPrincipalAccesses>
    <enabled>true</enabled>
    <externalCredentialPrincipal>
        DataCloud_IntegrationUser-DataCloudIntegration
    </externalCredentialPrincipal>
</externalCredentialPrincipalAccesses>

The value follows this pattern:

<ExternalCredentialName>-<PrincipalName>

For this example:

DataCloud_IntegrationUser-DataCloudIntegration

The names must match the actual org configuration.

This access grant does not give the CRM user Data Cloud access.

It only allows the Apex transaction to use the stored credential.

Deploying the Metadata

Once the org-level configuration exists, deploy the Salesforce metadata.

For example:

sf project deploy start -o dataCloud \
  -d force-app/main/default/classes \
  -d force-app/main/default/lwc/memberPlanViewer \
  -d force-app/main/default/customPermissions \
  -d force-app/main/default/permissionsets \
  -d force-app/main/default/groups

The important sequencing rule is:

External Client App
        ↓
External Credential
        ↓
Named Credential
        ↓
Metadata deployment

Don't deploy metadata that references an External Credential principal
before that principal exists.

Verifying the Principal Name

If you need to verify the External Credential principal in the org,
query the metadata:

sf data query -o dataCloud -t \
  -q "SELECT ParameterName, ParameterType
      FROM ExternalCredentialParameter
      WHERE ExternalCredential.DeveloperName = 'DataCloud_IntegrationUser'"

Use the Named Principal row when determining the principal name.

Running the Tests

The controller tests can be fully mocked, meaning they don't need live
Data Cloud connectivity.

For example:

sf apex run test \
  -o dataCloud \
  -n MemberPlanDataCloudControllerTest \
  -w 10 \
  -r human

This is important because your unit tests should verify the Apex
behavior without depending on an external Data Cloud service.

Step 6 --- Assign the Permission Set

The CRM user needs the permission set that grants access to the feature.

For example:

sf org assign permset \
  -o dataCloud \
  -n Member_Plan_Viewer \
  --on-behalf-of <user2-username>

Anyone who executes the Apex controller, including an administrator
testing the feature, must have the required permission set.

Configure the Restricted Public Group

The public group controls the row-level restriction.

Example:

Member_Plan_HMO_Only

Add the users who should only see HMO plans.

This membership is org data, not metadata.

Therefore, it does not automatically deploy with your source code.

You can manage membership through:

Setup
  → Public Groups
  → Member Plan HMO Only
  → Manage Members

Or through Salesforce CLI.

The key rule is:

User in group
    ↓
HMO only

User not in group
    ↓
All plans

Place the Component on a Lightning Page

Once the backend configuration is complete:

App Builder
    ↓
Lightning Page
    ↓
Member Plans (Data Cloud)

The LWC calls the Apex controller.

The user doesn't need to authenticate directly to Data Cloud.

Verifying the Architecture

Before running the complete demo, verify the authentication layer first.

Layer 1 --- Verify the Integration Identity

A simple callout can be used to inspect the identity:

HttpRequest r = new HttpRequest();

r.setEndpoint(
    'callout:DataCloud_Core/services/oauth2/userinfo'
);

r.setMethod('GET');

System.debug(
    LoggingLevel.ERROR,
    new Http().send(r).getBody()
);

The important result is that the returned identity should be the
configured Run-As user rather than the CRM user executing the Apex
transaction.

That demonstrates that the identity swap is working.

Layer 2 --- Test the Complete Chain

Then call the actual controller:

System.debug(
    LoggingLevel.ERROR,
    JSON.serialize(
        MemberPlanDataCloudController.getMemberPlans(null, 5)
    )
);

You want to see something equivalent to:

success = true
rowCount > 0

This confirms the complete path:

CRM User
   ↓
Custom Permission
   ↓
Principal Access
   ↓
Named Credential
   ↓
Integration Identity
   ↓
Data Cloud
   ↓
Apex Row Filtering
   ↓
LWC

The Demo

The most useful demonstration uses two CRM users.

User 1

Permission:
Yes

Public Group:
No

Result:
20 rows

Plans:
EPO
HMO
POS
PPO

User 2

Permission:
Yes

Public Group:
Member_Plan_HMO_Only

Result:
5 rows

Plans:
HMO only

The important observation is:

Both users are querying Data Cloud through the same integration
identity.

The difference comes entirely from the CRM-side row-level rule.

The Most Important Comparison

If an existing dataCloudAccountViewer component uses:

ConnectApi.CdpQuery

it runs as the browsing user.

Therefore:

CRM-only User
     |
     v
ConnectApi.CdpQuery
     |
     v
Data Cloud
     |
     v
NO ACCESS

The new architecture behaves differently:

CRM-only User
     |
     v
Apex
     |
     v
Named Credential
     |
     v
Integration Identity
     |
     v
Data Cloud

That contrast demonstrates exactly why the Named Credential architecture
is necessary.

Security: Read This Before Shipping

This architecture changes where authorization happens.

Data Cloud's normal per-user access model does not determine which rows
this component returns once the query is executed under the integration
identity.

Therefore:

Every access decision made by the component must be deliberately
enforced in Salesforce Apex.

The important controls are:

Control Where It Is Enforced

Who can call the feature Custom Permission
Who can use the credential External Credential Principal Access
Which rows a user can see Public Group + Apex
Which columns are returned Explicit SELECT
Filter safety Strict allowlist
Data Cloud query identity Integration User

Principle of Least Privilege

The integration user is extremely important.

The integration identity can potentially see everything the component
queries.

Therefore, don't treat it like an ordinary application user.

In production:

Use a dedicated integration identity.
Grant only the required Data Cloud access.
Limit the dataset the application can query.
Keep the Apex authorization rules explicit.
Avoid giving the integration user unrelated privileges.

The integration user's permissions define the potential blast radius of
the integration.

Never Trust Client-Supplied Authorization

A dangerous design would be:

getMemberPlans({
    planType: 'ALL'
});

and then allowing Apex to decide whether the user is permitted based on
that value.

The client should never determine authorization.

Instead:

Current Salesforce User
        |
        v
UserInfo.getUserId()
        |
        v
Check Public Group
        |
        v
Determine Scope
        |
        v
Build Safe Query

The authorization decision belongs on the server.

Audit Consideration

There is an important trade-off with this architecture.

Data Cloud audit trails will see the integration identity performing the
query.

They won't automatically identify the CRM user who originally clicked
the component.

If business auditing requires end-user attribution, log the CRM user
separately on the Salesforce side.

For example:

UserInfo.getUserId()

can be included in an appropriate application audit record.

This gives you two identities:

Data Cloud audit
    → Integration User

CRM application audit
    → Actual Salesforce User

Troubleshooting

When something goes wrong, identify which layer failed.

Symptom Likely Cause

We couldn't access the credential(s)… External Credential Principal Access is
missing

View_Member_Plan_Data error Permission set isn't assigned

scope parameter not supported External Credential Scope field is
populated

invalid_grant during authentication Client Credentials Flow or Run-As
configuration is incorrect

HTTP 401 Consumer credentials are wrong or the
client app hasn't propagated

HTTP 403 Run-As user lacks Data Cloud access or
required OAuth scope

HTTP 404 API version or Data Cloud provisioning
issue

Query succeeds with 0 rows Data Cloud dataset contains no matching
data

Group member sees all plans Public Group membership isn't configured
correctly

Everyone sees HMO only Group membership or nested group
configuration is too broad

A Note About HTTP Status Codes

One detail is especially important for the Data Cloud Query API.

The /ssot/queryv2 endpoint can return:

HTTP 201

for a successful query.

Don't assume every successful query must return HTTP 200.

If your Apex query helper accepts both successful statuses, don't
accidentally tighten the check to:

statusCode != 200

and break valid Data Cloud responses.

Common Configuration Mistakes

Mistake 1: Forgetting Principal Access

Everything appears configured correctly, but every user gets:

We couldn't access the credential(s)

Check the permission set's External Credential Principal Access.

Mistake 2: Giving the CRM User Data Cloud Permissions

The goal of this architecture is not to give CRM users direct Data Cloud
access.

The CRM user only needs the Salesforce permissions required to invoke
the feature and use the stored credential.

The integration identity handles Data Cloud access.

Mistake 3: Putting the OAuth Scope in the Wrong Place

If the External Credential's Scope field is populated when the token
endpoint doesn't accept that parameter, authentication can fail.

Keep the configuration aligned with the OAuth flow supported by the
External Client App.

Mistake 4: Using a Personal Admin as the Integration Identity

This works for a demo but creates unnecessary risk in production.

Use a dedicated integration identity with least privilege.

Mistake 5: Trusting LWC Parameters

Never allow the browser to decide:

Which rows?
Which plan type?
Which user?
Which authorization level?

The browser is an untrusted boundary.

Derive authorization from the Salesforce execution context.

The Complete Architecture

Putting everything together:

                    CRM User
                       |
                       v
              Lightning Web Component
                       |
                       v
             MemberPlanDataCloudController
                       |
             +---------+---------+
             |                   |
             v                   v
     Custom Permission     Public Group
       Gate 1              Row Scope
             |                   |
             +---------+---------+
                       |
                       v
              Named Credential
                DataCloud_Core
                       |
                       v
             External Credential
          DataCloud_IntegrationUser
                       |
                       v
              External Client App
                       |
                       | Run As
                       v
                Integration User
                       |
                       v
                  Data Cloud
                       |
                       v
            ssot__MemberPlan__dlm
                       |
                       v
                Apex filtering
                       |
                       v
                     LWC

This architecture provides a clear separation between:

Authentication
Credential storage
Feature authorization
Row-level authorization
Data Cloud access
User experience

When This Pattern Makes Sense

This architecture is useful when:

CRM users need selected Data Cloud data.
Those users should not receive direct Data Cloud access.
A controlled integration identity can safely access the required data.
Row-level access can be expressed and enforced in Apex.
The application needs a Lightning-based user experience.

It is especially useful for controlled internal applications where the
Data Cloud dataset and authorization rules are well understood.

When to Be Careful

This pattern should not be treated as a shortcut around Data Cloud
security.

If the integration identity can see sensitive information, your Apex
layer becomes part of the security boundary.

Before shipping, carefully review:

Integration-user permissions
Apex authorization
Public-group membership
Query construction
Returned fields
Audit requirements
Error handling
Logging
Data classification

A credential swap doesn't eliminate authorization---it moves
responsibility for certain access decisions into your application.

Key Takeaways

The most important ideas are simple:

1. The browsing user and query identity can be different

The CRM user can use the component without directly authenticating to
Data Cloud.

2. Named Credentials provide the authentication boundary

The Named Credential supplies the integration identity for the outbound
request.

3. Principal Access is a separate permission

The executing Salesforce user must be allowed to use the stored External
Credential principal.

4. Row-level authorization must be server-side

If Data Cloud sees the integration identity, your Apex code must enforce
the CRM user's row-level restrictions.

5. Never trust client input for authorization

Derive access from the Salesforce execution context, such as:

UserInfo.getUserId()

6. Use least privilege

The integration identity should have only the Data Cloud access required
by the application.

7. Test each layer independently

Verify:

Credential
   ↓
Identity
   ↓
Data Cloud Query
   ↓
Apex Filtering
   ↓
LWC

before troubleshooting the entire chain at once.

Final Thoughts

Serving Data Cloud data to CRM-only users is less about finding a single
magic API and more about understanding identity, authorization, and
trust boundaries.

The key architectural decision is to separate:

Who is using the application?

from:

Who is querying Data Cloud?

A Named Credential and integration identity solve the authentication
problem.

A custom permission controls who can use the feature.

A public group provides the business rule for row-level scope.

Apex becomes the enforcement layer that connects all of them.

The result is a controlled architecture where a CRM-only user can view
Data Cloud information without being granted direct Data Cloud
access---and different users can receive different data from the same
component based on server-side authorization rules.

Authentication tells you who is making the call. Authorization
decides what they are allowed to see. In this architecture, keeping
those two responsibilities separate is the key to making the design
work safely.

Docker Commands Every DevOps Engineer Should Know

Md Mohiuddin — Wed, 12 Aug 2026 11:29:29 +0000

Learning Docker isn't just about running containers—it's about becoming fluent in the commands you'll use every day in real-world DevOps environments.

These are the Docker commands you'll use repeatedly throughout your DevOps career for troubleshooting, debugging, monitoring, and managing containers. Think of this as the Docker equivalent of learning Linux commands like ps, top, grep, and tail.

Let's dive in.

Why Docker Command Fluency Matters

Anyone can copy and paste a docker run command from documentation.

The real skill begins when:

A container suddenly stops working
An application crashes after deployment
You need to inspect logs
You need to troubleshoot inside a running container
Multiple containers are running simultaneously

In these situations, command-line fluency becomes incredibly valuable.

The commands in this article form the foundation of everyday Docker operations.

Viewing Running Containers with `docker ps`

The first command every Docker user should know is:

docker ps

This shows all currently running containers.

Common Variations

docker ps
docker ps -a
docker ps -q
docker ps --filter "status=exited"

What They Do

Command	Purpose
`docker ps`	Show running containers
`docker ps -a`	Show all containers, including stopped ones
`docker ps -q`	Show only container IDs
`docker ps --filter "status=exited"`	Show only stopped containers

Understanding Docker PS Output

Example:

CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                  NAMES
a1b2c3d4e5f6   nginx     "/docker-entrypoint…"    5 minutes ago   Up 5 minutes   0.0.0.0:8080->80/tcp   my-nginx

Here's what each column means:

Column	Description
CONTAINER ID	Unique identifier for the container
IMAGE	Image used to create the container
COMMAND	Process running inside the container
STATUS	Current container state
PORTS	Port mappings between host and container
NAMES	Human-friendly container name

Why `docker ps -a` Is Important

Suppose a container crashes.

Running:

docker ps

won't show it because it's no longer running.

Instead use:

docker ps -a

to find stopped containers and begin troubleshooting.

This is often the first step when debugging container issues.

Viewing Local Images with `docker images`

Containers run from images.

To see which images exist on your machine:

docker images

Example output:

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
nginx        latest    a1b2c3d4e5f6   2 weeks ago   142MB
redis        latest    f6e5d4c3b2a1   3 weeks ago   117MB

Understanding the Columns

Column	Description
REPOSITORY	Image name
TAG	Version label
IMAGE ID	Unique image identifier
CREATED	When the image was built
SIZE	Storage size

Understanding Docker Tags

Docker images use tags to identify versions.

Examples:

docker pull nginx:1.25
docker pull nginx:alpine
docker pull nginx:latest

Why You Should Avoid `latest` in Production

Many beginners deploy:

docker pull nginx:latest

The problem?

latest changes over time.

Tomorrow it might point to a completely different image.

Instead, use explicit versions:

docker pull nginx:1.25.3

This guarantees consistent deployments and improves reproducibility.

Managing Container Lifecycles

Docker containers move through different states.

The most common lifecycle commands are:

docker stop my-nginx
docker start my-nginx
docker restart my-nginx
docker kill my-nginx
docker rm my-nginx

What Each Command Does

Stop a Container

docker stop my-nginx

Gracefully shuts down the container.

Start a Container

docker start my-nginx

Starts a previously stopped container.

Restart a Container

docker restart my-nginx

Stops and starts the container in one command.

Force Kill a Container

docker kill my-nginx

Immediately terminates the container.

Use this only when a normal stop fails.

Remove a Container

docker rm my-nginx

Permanently deletes a stopped container.

Visualizing the Container Lifecycle

docker run
     |
     v
  RUNNING
     |
docker stop
     |
     v
  STOPPED
     |
docker start
     |
     v
  RUNNING

docker rm
     |
     v
   DELETED

A common misconception is:

Stopping a container deletes it.

It doesn't.

A stopped container still exists.

Only docker rm permanently removes it.

Cleaning Up Docker Resources

As you practice Docker, you'll accumulate containers and unused resources.

Docker provides cleanup commands.

Remove All Stopped Containers

docker container prune

Remove All Containers

docker rm $(docker ps -aq)

Clean Everything Unused

docker system prune

This removes:

Stopped containers
Unused networks
Dangling images
Build cache

It's a great command when you want a clean Docker environment.

Viewing Container Logs

When containers misbehave, logs are your best friend.

The command:

docker logs my-nginx

shows everything the container has written to standard output and standard error.

Useful Log Options

docker logs my-nginx
docker logs -f my-nginx
docker logs --tail 50 my-nginx
docker logs --since 10m my-nginx
docker logs -t my-nginx

Common Usage

Follow logs in real time:

docker logs -f my-nginx

This works similarly to:

tail -f logfile.log

on Linux.

Why Docker Logs Are So Important

When a container:

Crashes
Fails startup
Returns errors
Behaves unexpectedly

Your first troubleshooting step should usually be:

docker logs <container-name>

The logs often contain the exact error message causing the issue.

Entering a Running Container with `docker exec`

One of Docker's most powerful commands is:

docker exec -it my-nginx /bin/bash

This opens an interactive shell inside the container.

Think of it as SSH for containers.

Understanding the Flags

docker exec -it my-nginx /bin/bash

`-i`

Keeps standard input open.

`-t`

Allocates a terminal session.

Together they create an interactive shell experience.

Some Containers Don't Have Bash

Minimal images such as Alpine Linux often don't include Bash.

If this fails:

docker exec -it container-name /bin/bash

try:

docker exec -it container-name sh

instead.

This is completely normal.

Useful Commands Inside Containers

Once inside a container, you can use standard Linux commands.

ls /
cat /etc/nginx/nginx.conf
ps aux
pwd

To exit:

exit

The shell closes, but the container continues running.

Running Multiple Containers

One of Docker's greatest strengths is isolation.

You can run multiple services on the same machine.

Example:

docker run -d --name my-nginx -p 8080:80 nginx
docker run -d --name my-redis -p 6379:6379 redis
docker run -d --name my-mongo -p 27017:27017 mongo

Each service runs independently.

Understanding Port Conflicts

Notice each container uses a different host port:

8080 -> nginx
6379 -> redis
27017 -> mongo

Docker won't allow:

8080 -> nginx
8080 -> redis

because only one process can listen on a host port at a time.

If you try, Docker will return:

port is already allocated

Seeing Everything Running

Use:

docker ps

to view all active containers.

Example:

CONTAINER ID   IMAGE
abc123         nginx
def456         redis
ghi789         mongo

This confirms all services are running successfully.

Real-World DevOps Workflow

A typical troubleshooting session might look like this:

docker ps
docker logs my-app
docker exec -it my-app sh
docker restart my-app

Notice how these commands work together.

You inspect.

You investigate.

You fix.

You verify.

This workflow becomes second nature over time.

Final Thoughts

Docker containers are only useful if you know how to manage them effectively.

The commands covered in this article are the foundation of everyday Docker operations:

docker ps
docker images
docker stop
docker start
docker rm
docker logs
docker exec

Master these commands and you'll be far more comfortable troubleshooting, debugging, and operating containerized applications.

As you continue your DevOps journey, these commands will become muscle memory—and they'll prepare you for the next step: building your own Docker images and applications.

Great Docker users don't memorize commands. They understand how containers behave and know exactly which command to reach for when something goes wrong.

Docker Explained: Containers, Images & Why They Changed Everything

Md Mohiuddin — Tue, 11 Aug 2026 13:30:52 +0000

Over the last decade, Docker has transformed how software is built, shipped, and deployed. Today, almost every modern platform, cloud environment, CI/CD pipeline, and Kubernetes cluster relies on containers in some way.

If you've ever heard developers say:

"It works on my machine."

Docker was built to solve exactly that problem.

In this article, we'll explore:

What containers actually are
How Docker works under the hood
Images vs Containers
Why containers are lighter than virtual machines
Docker architecture explained
Running your first Docker containers

Let's dive in.

Why Docker Matters

Before Docker became mainstream, deploying applications was often frustrating.

A developer might have:

Python 3.10 installed locally
Specific system libraries
Certain environment variables
Particular package versions

Everything worked perfectly on their laptop.

Then the same application would fail in staging or production because the environment was slightly different.

This became known as:

"Works on my machine."

Docker solves this problem by packaging the application and everything it needs to run into a single portable unit.

No matter where that container runs, the environment remains consistent.

What Is a Container?

A container is:

A portable package that contains application code, dependencies, libraries, runtime components, and configuration required to run an application consistently across environments.

Think of it like a shipping container.

The contents inside don't matter.

As long as the container exists, it can be moved anywhere and still contain everything required.

Software containers work the same way.

A container can run:

On a developer laptop
In a test environment
On a cloud server
Inside Kubernetes

without modification.

The Linux Magic Behind Containers

Docker didn't invent containers from scratch.

It built upon powerful Linux kernel features.

Namespaces

Namespaces create isolation.

Each container gets its own view of:

Processes
Networking
Filesystems
Users

From inside the container, it feels like its own machine.

Even though multiple containers share the same host.

Control Groups (cgroups)

Control Groups (cgroups) manage resources.

They allow Docker to control:

CPU usage
Memory usage
Disk I/O
Resource limits

This prevents one container from consuming all available resources.

Together, namespaces and cgroups create the foundation of containerization.

Docker Architecture Explained

Many beginners think the Docker CLI does all the work.

It doesn't.

Docker uses a client-server architecture.

Docker Client (CLI)
        |
        | API Request
        v
Docker Daemon (dockerd)
        |
        |-- Images
        |-- Containers
        |
        |-- Pull/Push
        v
     Docker Hub

Let's break down each component.

Docker Client

The Docker Client is the command you type.

docker run nginx

The client simply sends instructions to the Docker daemon.

It does not run containers directly.

Docker Daemon (dockerd)

The Docker daemon is the engine behind Docker.

It handles:

Building images
Running containers
Creating networks
Managing storage volumes
Communicating with registries

Whenever you execute a Docker command, the daemon performs the actual work.

Docker Images

A Docker image is:

A read-only blueprint used to create containers.

Images contain:

Operating system layers
Runtime dependencies
Application code
Startup configuration

An image is not running.

It's simply a template.

Think of it like a class in object-oriented programming.

Docker Containers

A container is:

A running instance of an image.

Using the same image, you can launch multiple containers.

nginx image
   |
   |--> Container A
   |--> Container B
   |--> Container C

Each container runs independently while sharing the same underlying image.

Think of a container as an object created from a class.

Docker Hub and Image Registries

Docker images need a place to live.

That's where registries come in.

The most popular registry is Docker Hub.

Common commands include:

docker pull nginx

Downloads an image.

docker push my-image

Uploads an image.

You can think of Docker Hub as GitHub for Docker images.

Understanding Docker Image Layers

One of Docker's most powerful features is layered images.

Each image consists of multiple read-only layers.

Writable Container Layer
------------------------
COPY app.py .
------------------------
RUN pip install ...
------------------------
FROM python:3.12-slim

Each Dockerfile instruction creates a new layer.

When a container starts, Docker adds a writable layer on top.

All runtime changes happen there.

The original image remains unchanged.

Why Layers Matter

Faster Builds

Docker caches layers.

If only application code changes, Docker reuses dependency layers.

This dramatically speeds up rebuilds.

Shared Storage

Suppose two images both use:

python:3.12-slim

Docker stores that base layer only once.

This saves disk space.

Disposable Containers

Containers can be destroyed and recreated instantly.

Because images never change, every new container starts from a clean state.

This consistency is one of Docker's biggest strengths.

Containers vs Virtual Machines

Many newcomers confuse containers with virtual machines.

They solve similar problems differently.

Virtual Machine	Docker Container
Includes a full guest OS	Shares host kernel
Larger in size	Much smaller
Slower startup	Fast startup
Strong isolation	Lightweight isolation
Consumes more resources	More efficient

Virtual Machine

Application
Guest OS
Hypervisor
Host OS
Hardware

Docker Container

Application
Libraries
Docker Engine
Host OS Kernel
Hardware

Containers share the host kernel.

This is why they start in seconds instead of minutes.

Installing Docker

Windows and macOS

Install Docker Desktop.

It includes:

Docker CLI
Docker Engine
Docker Desktop UI
Lightweight Linux VM

Linux

Install Docker Engine directly.

Linux already provides the kernel Docker needs.

No additional VM layer is required.

Follow the installation guide for your distribution.

Your First Docker Container

The classic first command is:

docker run hello-world

A lot happens behind the scenes.

Docker checks for the image locally.
If it doesn't exist, Docker downloads it.
Docker creates a container.
The container runs.
The program exits successfully.

Congratulations.

You just ran your first container.

Running a Real Application

Let's run Nginx.

docker run -d -p 8080:80 --name my-nginx nginx

`-d`

Runs the container in detached mode.

`-p 8080:80`

Maps ports.

Host Port      Container Port
8080     -->        80

Traffic reaching your machine on port 8080 gets forwarded to Nginx running inside the container.

`--name my-nginx`

Assigns a custom container name.

`nginx`

Specifies the image to run.

If it doesn't exist locally, Docker downloads it automatically.

Managing Containers

docker ps
docker ps -a
docker logs my-nginx
docker stop my-nginx
docker start my-nginx
docker rm my-nginx

Then open:

http://localhost:8080

You should see the Nginx welcome page.

Why Docker Won

Traditional Installation

sudo apt update
sudo apt install nginx

Requirements:

Linux server
Package management
System configuration

Docker Installation

docker run -d -p 8080:80 nginx

Requirements:

Docker installed

Cleanup:

docker rm my-nginx

Done.

No leftover configuration files.

No package cleanup.

No dependency conflicts.

The Bigger Picture

Docker didn't become popular because it was trendy.

It became popular because it solved real engineering problems:

Consistent environments
Faster deployments
Better resource utilization
Easier scaling
Simpler application packaging

Today Docker sits at the center of modern DevOps.

CI/CD pipelines build Docker images.
Cloud platforms deploy Docker containers.
Kubernetes orchestrates containers at scale.

Learning Docker isn't just learning another tool.

It's learning the foundation of modern software delivery.

Final Thoughts

Docker changed how software is shipped.

By packaging applications together with their dependencies, containers eliminate environment inconsistencies and make deployments predictable.

As you continue your DevOps journey, you'll discover that Docker is not the destination—it's the foundation.

Everything from CI/CD pipelines to Kubernetes builds upon the concepts you've learned here.

Learn Docker deeply. It will pay dividends throughout your entire DevOps career.

Pull Requests, Code Reviews & Git Rebase

Md Mohiuddin — Sun, 09 Aug 2026 17:54:48 +0000

If you've already learned Git commits, branching, and merging, you've mastered the mechanics of version control. But knowing Git alone doesn't make you effective on a real engineering team.

In this article, we'll cover:

What Pull Requests (PRs) actually are
How professional code reviews work
Why .gitignore is essential
The dangers of committing secrets
When to use git merge vs git rebase

These are the practices that transform a personal project into a professional software project.

Why This Matters

Imagine you're building a feature for a production application.

You create a branch, write code, test it, and everything works.

Should you push directly to main?

In most professional teams, the answer is no.

Instead, your code goes through a review process where:

Other developers inspect your changes
Automated tests run
Discussions happen around implementation decisions
Quality checks prevent bugs from reaching production

That process starts with a Pull Request.

Understanding Pull Requests

A Pull Request (PR) is not a Git feature.

It is a feature provided by platforms like GitHub, GitLab, and Bitbucket.

A PR is essentially a request that says:

"I've completed work on this branch. Please review it and merge it into the target branch."

What a Pull Request Contains

A good PR provides much more than code.

The Diff

A visual representation of every change introduced by the branch.

You'll see:

Added lines
Removed lines
Modified files

This allows reviewers to inspect exactly what changed.

Description and Context

A PR should explain:

What changed
Why it changed
How it was tested

Remember:

The code shows what changed. The PR description explains why it changed.

Review Discussion

Reviewers can:

Comment on specific lines
Ask questions
Suggest improvements
Request changes

This creates a permanent record of engineering decisions.

Automated Checks

Most modern teams connect CI/CD pipelines to Pull Requests.

Common checks include:

Unit tests
Integration tests
Linting
Security scans
Build verification

If these checks fail, the PR usually cannot be merged.

Merge Controls

Once reviews are complete and checks pass, the PR can be merged.

Behind the scenes, the platform performs the merge operation for you.

Why Pull Requests Exist

Quality Control

Fresh eyes catch bugs.

Reviewers often identify:

Edge cases
Logic flaws
Performance concerns
Security issues

before users ever encounter them.

Knowledge Sharing

Code reviews help teams stay informed about:

New features
Architecture decisions
Business rules
Coding standards

Reviewing code is one of the fastest ways to learn a codebase.

Historical Context

Months later, someone may ask:

Why was this implemented this way?

The answer often lives in the PR discussion.

Automation Gateway

PRs provide a natural checkpoint for CI/CD pipelines.

Before code reaches production:

Tests run
Builds run
Security checks run

This reduces deployment risk significantly.

Creating a Pull Request

Step 1: Create a Feature Branch

git switch -c feature/add-backup-script

Step 2: Make Changes and Commit

git add backup.sh

git commit -m "Add automated backup script with cron scheduling"

Step 3: Push the Branch

git push -u origin feature/add-backup-script

The -u flag links your local branch to the remote branch so future pushes can simply use:

git push

Step 4: Open the Pull Request

On GitHub:

Click Compare & Pull Request
Select the target branch (main)
Select your feature branch
Add a title
Write a meaningful description
Submit the PR

Writing Better PR Descriptions

A strong PR description answers four questions:

What changed?

Brief summary of the implementation.

Why was it needed?

Business or technical motivation.

How was it tested?

Evidence that the change works.

What should reviewers focus on?

Any area that may need extra attention.

Code Reviews: How Professionals Review Code

Code review is not about proving someone wrong.

It's about improving the software.

Focus on the Code, Not the Person

Avoid personal criticism.

Instead of:

You wrote this incorrectly.

Prefer:

This function could be simplified by...

Separate Requirements from Suggestions

Many teams use:

Nit:

for non-blocking suggestions.

Ask Questions

Instead of making assumptions, ask:

What happens if this input is empty?

Questions encourage discussion and often reveal hidden edge cases.

Receiving Review Feedback

Every developer receives feedback.

Good engineers:

Respond to comments
Explain decisions
Make improvements
Discuss disagreements respectfully

Code review is a conversation, not a battle.

Understanding .gitignore

One of the most important files in any repository is:

.gitignore

This file tells Git:

Never track these files.

Why .gitignore Matters

Without it, developers accidentally commit:

Secrets
Build artifacts
Dependency folders
Personal editor settings
Operating system files

Example .gitignore

# Secrets
*.pem
*.key
.env
id_rsa
id_ed25519

# Logs
*.log
logs/

# Dependencies
node_modules/
__pycache__/
venv/

# IDE Files
.vscode/
.idea/

# Terraform
*.tfstate
*.tfstate.backup
.terraform/

Never Commit Secrets

This is one of the most important rules in software engineering.

Why Deleting Later Doesn't Work

If a secret appears in Git history, it remains in history even after being removed from later commits.

Anyone with repository access can still retrieve it.

What Happens When Secrets Leak?

Automated bots constantly scan public repositories for:

API keys
Database credentials
AWS access keys
Tokens
Private keys

Often within minutes of a push.

Prevention Best Practices

Create .gitignore before starting a project
Use environment variables
Never hardcode credentials
Review changes before committing

Always run:

git status

and ideally:

git diff --staged

before every commit.

Git Rebase: An Alternative to Merge

Most developers learn merging first.

But Git also provides:

git rebase

Example

git switch feature/my-work

git rebase main

This replays your commits on top of the latest version of main.

Before Rebase

main:      A --- B --- C
                         \
feature:                  D --- E

After Rebase

main:      A --- B --- C
                         \
feature:                   D' --- E'

Git creates entirely new commits with new hashes.

Merge vs Rebase

Merge	Rebase
Preserves exact history	Creates linear history
Adds merge commits	Avoids merge commits
Safe for shared branches	Rewrites history
Great for team collaboration	Great for cleaning personal branches

The Golden Rule of Rebase

Never rebase a branch that other developers are already using.

A simple rule:

Rebase your own branches. Merge shared branches.

Final Thoughts

Learning Git commands is only the beginning.

Professional software development requires:

Pull Requests
Code Reviews
Secure Git practices
Proper .gitignore usage
Understanding when to merge and when to rebase

These skills help teams collaborate effectively, maintain quality, and deploy software with confidence.

Great developers don't just write code. They create systems that make collaboration, quality, and safety easier for everyone on the team.

Git Branching & Merging: The Foundation of Team Collaboration in Git

Md Mohiuddin — Thu, 06 Aug 2026 16:57:04 +0000

Git becomes truly powerful when multiple developers can work on different features at the same time without interfering with each other's work. That's exactly what branching and merging solve.

In this article, we'll explore how Git branches work, how to merge changes safely, resolve conflicts, collaborate through GitHub, and understand the workflow used by modern development teams.

Why Branching Matters

Imagine a team working on a web application:

One developer is building a login page.
Another is fixing a payment bug.
A third is improving performance.

If everyone worked directly on the same branch, changes would constantly collide, making development chaotic and risky.

Git branching allows developers to work independently in isolated environments and merge their changes only when they're ready.

This is the foundation of modern software collaboration.

What Is a Git Branch?

Many beginners think a branch is a complete copy of a project.

It isn't.

A Git branch is simply a lightweight pointer to a commit.

Consider a project history:

A --- B --- C
              ^
            main

Here, main points to the latest commit (C).

When you create a new branch:

A --- B --- C
              ^
            main
              ^
        feature-login

Git creates another pointer.

No files are copied.

No duplicate project is created.

Just another reference to the same commit.

How Branches Grow

Once you switch to the new branch and start making commits:

main:    A --- B --- C
                        ^
                      main

feature-login:
                    D --- E
                          ^
                    feature-login

Only the feature branch moves forward.

The main branch remains unchanged.

This allows you to experiment, develop features, and fix bugs without affecting the stable codebase.

Why Git Branches Are So Fast

Since a branch is only a pointer:

Creating a branch takes milliseconds.
Switching branches is extremely fast.
Large repositories don't become slower when creating branches.

Unlike older version control systems where branching was expensive, Git encourages creating branches frequently.

Creating a branch for every feature or bug fix is considered a best practice.

Creating and Switching Branches

View Existing Branches

git branch

Output:

* main

The * indicates the current branch.

Create a New Branch

git branch feature-login

This creates the branch but does not switch to it.

Switch to a Branch

git switch feature-login

Or:

git checkout feature-login

Create and Switch in One Command

git switch -c feature-login

Older equivalent:

git checkout -b feature-login

Delete a Branch

Safe delete:

git branch -d feature-login

Force delete:

git branch -D feature-login

Use force deletion carefully because it can remove unmerged work.

Branch Naming Best Practices

Professional teams typically follow naming conventions.

Examples:

feature/PROJ-123-user-authentication

bugfix/PROJ-456-fix-login-error

hotfix/critical-payment-issue

Benefits:

Easy to understand purpose
Connected to Jira tickets
Easier code reviews
Better repository organization

Understanding Git Merge

Once your work is complete, you'll want to bring it back into main.

First switch to the target branch:

git switch main

Then merge:

git merge feature-login

Git now combines both histories.

Fast-Forward Merge

This happens when no new commits exist on main.

Before merge:

main:
A --- B --- C

feature:
A --- B --- C --- D --- E

After merge:

A --- B --- C --- D --- E
                              ^
                      main & feature

Git simply moves the main pointer forward.

No special merge commit is created.

This is called a Fast-Forward Merge.

Three-Way Merge

Real projects usually look like this:

main:
A --- B --- C

feature:
      \
       D --- E

While you were working, someone else added commits to main.

Git must now combine both histories.

Result:

A --- B --- C ----------- M
          \             /
           D --- E ----

M is a merge commit.

It contains two parent commits:

One from main
One from feature

This process is called a Three-Way Merge.

What Is a Merge Conflict?

Sometimes Git can't determine which change should win.

Example:

Main Branch

Welcome to our application

Feature Branch

Welcome to our awesome application

Both modified the same line.

Git stops and asks for help.

This is called a Merge Conflict.

What a Conflict Looks Like

Git inserts markers directly into the file:

<<<<<<< HEAD
Welcome to our application
=======
Welcome to our awesome application
>>>>>>> feature-login

Understanding the Markers

<<<<<<< HEAD

Current branch version.

=======

Separator.

>>>>>>> feature-login

Incoming branch version.

Resolving Merge Conflicts

Step 1: Open the File

Review both versions.

Step 2: Decide the Final Content

Example:

Welcome to our awesome application

Step 3: Remove Conflict Markers

Delete:

<<<<<<<
=======
>>>>>>>

Step 4: Stage the Resolved File

git add app.txt

Step 5: Complete the Merge

git commit

Git automatically generates a merge message.

Don't Fear Merge Conflicts

Many beginners panic when they see conflicts.

Don't.

Merge conflicts are:

Normal
Expected
Common in every team

Even senior engineers resolve conflicts regularly.

The skill isn't avoiding them.

The skill is understanding and resolving them confidently.

Understanding Remote Repositories

Everything so far has been local.

To collaborate, we use remote repositories hosted on platforms like:

GitHub
GitLab
Bitbucket

The most common remote name is:

origin

Pushing Changes to GitHub

Upload local commits:

git push origin main

This sends your local commits to GitHub.

Pulling Changes From GitHub

Download and merge changes:

git pull origin main

This keeps your local branch up to date.

What `git pull` Actually Does

Many developers use git pull daily without knowing what it really does.

Internally:

git pull
=
git fetch
+
git merge

Fetch

Downloads new commits.

git fetch

No files are changed.

No merge occurs.

Git simply updates its knowledge of the remote repository.

Merge

After fetching:

git merge

Git combines the changes into your current branch.

Why Pull Before Push?

Imagine:

You create new commits.
A teammate pushes changes first.
You try pushing.

Git rejects it:

! [rejected] main -> main (fetch first)

Git is protecting shared history.

Solution:

git pull origin main

Resolve conflicts if necessary.

Then:

git push origin main

Understanding GitHub Flow

GitHub Flow is one of the most widely used collaboration workflows.

It is simple, lightweight, and works perfectly with CI/CD pipelines.

Step 1: Create a Branch

git switch -c feature-login

Step 2: Make Commits

Example:

git add .
git commit -m "feat: add login page"

Step 3: Push the Branch

git push origin feature-login

This backs up your work and makes it visible to teammates.

Step 4: Open a Pull Request (PR)

A Pull Request is a request to merge your branch into main.

It allows:

Discussion
Review
Feedback
Collaboration

Step 5: Code Review

Teammates review:

Code quality
Architecture
Bugs
Security concerns

Suggestions are discussed before merging.

Step 6: Automated Checks Run

Modern CI/CD pipelines automatically run:

Unit tests
Linting
Security scans
Build verification

Only passing code can be merged.

Step 7: Merge Into Main

Once approved:

feature-login → main

The changes become part of the main codebase.

Step 8: Deploy

Many organizations automatically deploy after merging into main.

Merge → CI/CD Pipeline → Deployment

Step 9: Delete the Branch

After merging:

git branch -d feature-login

The branch has served its purpose.

Visualizing GitHub Flow

main:
A --- B ----------------------- M
          \                   /
           C --- D --- E ----
                feature-login

Workflow:

Create branch
Commit changes
Push branch
Open PR
Review
Run automated checks
Merge
Deploy
Delete branch

Why GitHub Flow Is So Popular

Simplicity

Only one long-lived branch:

main

Everything else is temporary.

CI/CD Friendly

Every Pull Request becomes a checkpoint for:

Testing
Validation
Security scanning

Encourages Code Reviews

Changes reach production only after another engineer reviews them.

This improves:

Quality
Knowledge sharing
Team collaboration

Key Takeaways

A branch is simply a movable pointer to a commit.
Branches allow isolated development without affecting main.
Merging combines work from multiple branches.
Fast-forward merges occur when histories haven't diverged.
Three-way merges create a merge commit when histories differ.
Merge conflicts happen when Git can't decide between overlapping changes.
git pull = git fetch + git merge.
git push shares your commits with a remote repository.
GitHub Flow is the modern workflow used by most teams and integrates naturally with CI/CD.

Master branching and merging, and you've learned the workflow that powers nearly every professional software team in the world.

Happy Coding! 🚀

Git Fundamentals: The Foundation of Modern DevOps

Md Mohiuddin — Wed, 05 Aug 2026 15:45:38 +0000

From CI/CD pipelines and Infrastructure as Code to Kubernetes deployments and application releases, almost every automation workflow begins with a change in a Git repository. A commit, push, merge, or tag can trigger an entire deployment pipeline automatically.

Understanding Git isn't just about version control—it's about understanding the foundation that modern software delivery is built on.

Why Git Matters in DevOps

Think about the Software Development Life Cycle (SDLC):

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor

Git sits at the center of this workflow.

When code changes are committed and pushed:

CI/CD pipelines automatically start
Tests run automatically
Docker images get built
Deployments can be triggered
Infrastructure changes can be tracked
Teams can collaborate safely

In many organizations, Git becomes the single source of truth for both application code and infrastructure configuration.

What Is Git?

Git is a Distributed Version Control System (DVCS) that tracks changes to files over time.

It allows developers to:

Track project history
Revert mistakes
Collaborate with teams
Create isolated branches
Maintain a complete record of changes

Unlike older centralized systems, Git is distributed.

What Does "Distributed" Mean?

Every copy of a Git repository contains the complete project history.

This means:

You can work offline
You can create commits without internet access
Every clone acts as a backup
There is no single point of failure

When you clone a repository, you're not just downloading files—you're downloading the entire project history.

This is why platforms like GitHub, GitLab, and Bitbucket are not Git itself.

Git is the version control system.

GitHub and similar platforms simply provide a shared remote location where teams can collaborate.

Understanding Git's Snapshot Model

One of the most misunderstood concepts in Git is how it stores history.

Many beginners assume Git stores only the differences between files.

That's not how Git works.

Git Stores Snapshots

Every commit represents a complete snapshot of the project at a specific moment.

Commit A → Commit B → Commit C

Snapshot   Snapshot   Snapshot
of all     of all     of all
files      files      files

Think of each commit as a photograph of your project.

When you return to a previous commit, Git simply restores that snapshot.

This design makes operations like:

Switching branches
Viewing history
Restoring previous versions

extremely fast and efficient.

Behind the scenes, Git avoids storing duplicate file data when files haven't changed, making storage efficient while maintaining the snapshot model.

The Three Areas of a Git Project

To understand Git properly, you need to understand its three working areas.

Working Directory
        |
     git add
        ↓
Staging Area
        |
   git commit
        ↓
Repository

1. Working Directory

This is where you actively edit files.

Any changes made here are considered unstaged changes.

2. Staging Area

The staging area acts as a preparation zone.

You decide exactly which changes should be included in the next commit.

This allows you to create clean and focused commits instead of committing everything at once.

3. Repository

The repository contains committed snapshots and project history.

Once changes are committed, they become part of Git's permanent history.

Creating a Git Repository

To start tracking a project with Git:

git init

This command creates a hidden .git directory.

The .git folder stores:

Commit history
Branch information
Configuration
Repository metadata

Without the .git folder, Git history does not exist.

Configure Your Identity

Git records who created each commit.

Set your identity once per machine:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

git status: Your Most Important Command

If there's one Git command you'll use constantly, it's:

git status

This command tells you:

Which files have changed
Which files are staged
Which files are untracked
What will happen next

Whenever you're unsure about your repository's state:

git status

is the first command to run.

Staging Changes with git add

Before creating a commit, changes must be staged.

Stage a Single File

git add file.txt

Stage Multiple Files

git add file1.txt file2.txt

Stage Everything

git add .

Interactive Staging

git add -p

This allows you to choose specific portions of a file to stage.

Be Careful with git add .

While convenient, git add . stages everything.

Always verify what's staged:

git status

before creating a commit.

Creating Snapshots with git commit

Once changes are staged:

git commit -m "Add user authentication endpoint"

This creates a permanent snapshot of the project.

The -m flag allows you to write the commit message directly in the command.

Without it, Git opens your default text editor.

Writing Better Commit Messages

Good commit messages save time for both you and your team.

Avoid Messages Like:

fix
update
changes
test
final
final-final

Prefer Messages Like:

feat: add user authentication endpoint

fix: resolve null pointer exception in payment service

docs: update installation guide

refactor: simplify database connection logic

test: add unit tests for user service

chore: upgrade nginx package version

ci: add GitHub Actions deployment workflow

This makes history easier to read and understand.

Viewing Project History with git log

Git provides several ways to inspect history.

Full History

git log

Displays:

Commit hash
Author
Date
Commit message

Compact View

git log --oneline

Example:

a1b2c3d Add authentication
e4f5g6h Fix API validation
i7j8k9l Initial project setup

Visual Branch Graph

git log --oneline --graph

Useful when working with multiple branches.

Show Actual Code Changes

git log -p

Displays the content changes for each commit.

Filter by Author

git log --author="John"

Filter by File

git log -- filename.txt

Shows only commits that modified a specific file.

Understanding Commit Hashes

Every commit has a unique identifier called a commit hash.

Example:

a1b2c3d4e5f67890abcdef1234567890

The hash is generated from:

Commit content
Metadata
Parent commit information

Even the smallest change creates a completely different hash.

In practice, you'll usually use only the first few characters:

git checkout a1b2c3d

Git can usually identify the correct commit from a short unique prefix.

Key Takeaways

Git is much more than a tool for saving code.

It is:

The foundation of CI/CD pipelines
The source of truth for modern infrastructure
The backbone of collaborative software development
The trigger behind most DevOps automation

Before learning branches, pull requests, Docker, Kubernetes, or Terraform, it's important to understand how Git stores history and manages changes.

Master these fundamentals, and every DevOps tool that follows will make much more sense.

Happy learning! 🚀

Virtualization & Containers — Understanding the Technology That Made Cloud and Docker Possible

Md Mohiuddin — Tue, 04 Aug 2026 16:04:30 +0000

Before diving into Git, Docker, and Kubernetes, it's worth understanding the technology that made modern cloud computing possible: Virtualization.

More importantly, understanding virtualization makes it much easier to understand why containers became so popular and why Docker transformed modern software deployment.

Why This Topic Matters

Virtualization sits between traditional infrastructure and modern containerized environments.

Without virtualization:

Cloud computing wouldn't exist in its current form
AWS EC2 instances wouldn't be possible
Running multiple servers on shared hardware would be difficult and expensive

Understanding virtualization helps answer a fundamental question:

Why did the industry move from Virtual Machines to Containers?

What Is Virtualization?

Virtualization is a technology that allows multiple isolated operating systems to run on a single physical machine.

Instead of dedicating one physical server to one application, virtualization enables multiple independent systems to share the same hardware resources.

The virtualization layer abstracts:

CPU
Memory (RAM)
Storage
Networking

This allows several virtual environments to coexist while behaving as separate machines.

Before Virtualization

A common approach was:

One physical server
One application
Large amounts of unused resources

Organizations often purchased many servers that spent most of their time underutilized.

After Virtualization

One powerful physical machine can host multiple virtual servers, significantly improving hardware utilization and reducing infrastructure costs.

What Is a Virtual Machine (VM)?

A Virtual Machine is a complete computer running inside another computer.

Each VM contains:

A full operating system
Its own kernel
Virtual CPU
Virtual memory
Virtual disk
Applications and services

From the VM's perspective, it believes it's running on actual hardware.

The layer that creates this illusion is called the Hypervisor.

Understanding Hypervisors

A Hypervisor is responsible for creating, managing, and isolating Virtual Machines.

It allocates physical resources and ensures one VM cannot interfere with another.

Type 1 Hypervisor (Bare Metal)

Runs directly on physical hardware.

┌─────────┐ ┌─────────┐ ┌─────────┐
│  VM 1   │ │  VM 2   │ │  VM 3   │
└─────────┘ └─────────┘ └─────────┘
┌─────────────────────────────┐
│      Type 1 Hypervisor      │
└─────────────────────────────┘
┌─────────────────────────────┐
│     Physical Hardware       │
└─────────────────────────────┘

Examples:

VMware ESXi
Hyper-V
Xen
AWS Infrastructure
Google Cloud Infrastructure
Azure Infrastructure

Benefits

Better performance
Lower overhead
Designed for production environments
Ideal for large-scale cloud platforms

Type 2 Hypervisor (Hosted)

Runs as an application on top of a host operating system.

┌─────────┐ ┌─────────┐
│  VM 1   │ │  VM 2   │
└─────────┘ └─────────┘
┌─────────────────────┐
│  Type 2 Hypervisor  │
└─────────────────────┘
┌─────────────────────┐
│      Host OS        │
└─────────────────────┘
┌─────────────────────┐
│ Physical Hardware   │
└─────────────────────┘

Examples:

VirtualBox
VMware Workstation
VMware Fusion
Parallels

Common Use Cases

Learning environments
Local development
Testing different operating systems

If you've ever run Ubuntu inside VirtualBox, you've already used a Type 2 Hypervisor.

Why Virtualization Was Revolutionary

Virtualization solved several major infrastructure challenges.

Better Resource Utilization

Multiple servers can share the same hardware.

Isolation

Problems inside one VM typically don't affect others.

Faster Provisioning

Creating a VM takes minutes instead of waiting for new hardware.

Snapshots and Rollbacks

Save a VM's state and restore it whenever needed.

Foundation of Cloud Computing

Virtualization enabled cloud providers to securely offer virtual servers to millions of customers on shared infrastructure.

The Limitations of Virtual Machines

Virtual Machines solved many problems, but they introduced new challenges.

Heavy Resource Usage

Every VM requires:

Its own operating system
Its own kernel
Background services
System processes

Even before your application starts, significant resources are already consumed.

Slower Startup Times

VMs must boot an entire operating system.

Startup times often range from:

30 seconds
Several minutes

Large Images

VM images often measure in gigabytes.

This makes them slower to:

Store
Transfer
Deploy

Poor Fit for Microservices

Modern applications frequently consist of dozens of small services.

Running every service inside its own VM becomes expensive and inefficient.

How Containers Changed Everything

Containers solve the same problem as Virtual Machines:

Running isolated workloads on shared hardware.

The difference lies in how isolation is achieved.

Virtual Machines

Every VM includes:

Application
Libraries
Guest Operating System
Guest Kernel

Containers

Containers include:

Application
Required Libraries

But they share the host operating system kernel.

Virtual Machines Architecture

┌─────┐ ┌─────┐ ┌─────┐
│ App │ │ App │ │ App │
├─────┤ ├─────┤ ├─────┤
│Bins/│ │Bins/│ │Bins/│
│Libs │ │Libs │ │Libs │
├─────┤ ├─────┤ ├─────┤
│Guest│ │Guest│ │Guest│
│ OS  │ │ OS  │ │ OS  │
└─────┘ └─────┘ └─────┘
┌─────────────────────┐
│     Hypervisor      │
└─────────────────────┘
┌─────────────────────┐
│ Physical Hardware   │
└─────────────────────┘

Containers Architecture

┌─────┐ ┌─────┐ ┌─────┐
│ App │ │ App │ │ App │
├─────┤ ├─────┤ ├─────┤
│Bins/│ │Bins/│ │Bins/│
│Libs │ │Libs │ │Libs │
└─────┴─┴─────┴─┴─────┘
┌─────────────────────┐
│  Container Engine   │
│      Docker         │
└─────────────────────┘
┌─────────────────────┐
│  Shared Host Kernel │
└─────────────────────┘
┌─────────────────────┐
│ Physical Hardware   │
└─────────────────────┘

Why Containers Became So Popular

Because containers share the host kernel, they provide several advantages.

Faster Startup

Containers typically start in milliseconds or a few seconds.

Smaller Images

Container images are often measured in megabytes rather than gigabytes.

Better Resource Efficiency

No duplicate operating systems consuming RAM and CPU.

Higher Density

One server can run dozens or hundreds of containers.

Perfect for Microservices

Containers make it easy to package, deploy, and scale individual services independently.

Containers vs Virtual Machines

Feature	Virtual Machines	Containers
Includes Full OS	✅ Yes	❌ No
Includes Own Kernel	✅ Yes	❌ No
Startup Speed	Slower	Faster
Resource Usage	Higher	Lower
Image Size	Larger	Smaller
Isolation	Stronger	Lighter
Density Per Server	Lower	Higher

Why Modern Infrastructure Uses Both

In production environments, containers and VMs often work together.

A common architecture looks like:

Physical Server
       ↓
Virtual Machine
       ↓
Docker Containers
       ↓
Applications

This approach combines:

VM-level isolation
Container efficiency
Better scalability
Stronger security boundaries

This is exactly how many Kubernetes environments run today.

Looking Ahead to Docker

The concepts from today directly map to Docker.

Virtualization Concept	Docker Equivalent
Hypervisor	Container Runtime
VM Image	Docker Image
Running VM	Running Container
Guest OS	Shared Host Kernel
VirtualBox	Docker Engine

Understanding this mapping makes Docker significantly easier to learn.

Final Thoughts

Virtualization transformed infrastructure by allowing multiple servers to share the same hardware.

Containers took that idea further by removing the need for a separate operating system in every workload.

The result was:

Faster deployments
Lower resource consumption
Better scalability
Cloud-native architectures

devops #linux #virtualization #containers #docker #cloudcomputing #aws #kubernetes

🌐 HTTP, HTTPS, Load Balancers & Firewalls: Networking Concepts Every DevOps Engineer Should Know

Md Mohiuddin — Mon, 03 Aug 2026 12:46:47 +0000

Networking doesn't stop at IP addresses, DNS, and ports.

Once a client successfully reaches a server, several other technologies come into play:

HTTP and HTTPS enable communication between clients and servers
Load balancers distribute traffic across multiple servers
Firewalls control who is allowed to access services

These concepts form the foundation of modern web applications, cloud infrastructure, Kubernetes environments, and production systems.

In this article, we'll explore:

What HTTP is and how it works
Common HTTP methods and status codes
How HTTPS secures communication
Why load balancers are essential
How firewalls protect infrastructure
Essential UFW commands for Linux servers

What Is HTTP?

HTTP (HyperText Transfer Protocol) is the communication protocol used by web browsers and servers.

It follows a simple request-response model:

A client sends a request.
The server processes the request.
The server returns a response.

HTTP is stateless, meaning every request is independent and the server doesn't automatically remember previous requests.

Anatomy of an HTTP Request

Example request:

GET /search?q=devops HTTP/1.1
Host: www.google.com
User-Agent: curl/8.1.2
Accept: text/html

An HTTP request consists of:

Component	Purpose
Method	Action to perform
Path	Resource being requested
Version	HTTP protocol version
Headers	Metadata about the request
Body	Optional request data

Anatomy of an HTTP Response

Example response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 15258
Server: nginx

Response components:

Component	Purpose
Status Line	Status code and message
Headers	Metadata about the response
Body	Actual content returned

Common HTTP Methods

Different methods tell the server what action to perform.

Method	Purpose	Example
GET	Retrieve data	Load a webpage
POST	Create new data	Submit a form
PUT	Replace a resource	Update a profile
PATCH	Modify part of a resource	Update an email address
DELETE	Remove a resource	Delete an account

Understanding HTTP Status Codes

Status codes tell us the result of a request.

Status Code Categories

Range	Category
1xx	Informational
2xx	Success
3xx	Redirection
4xx	Client Errors
5xx	Server Errors

Common Status Codes Every DevOps Engineer Should Know

Code	Meaning
200	OK
201	Created
301	Permanent Redirect
302	Temporary Redirect
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
429	Too Many Requests
500	Internal Server Error
502	Bad Gateway
503	Service Unavailable
504	Gateway Timeout

Why 502, 503, and 504 Matter

These errors often indicate infrastructure issues rather than application bugs.

502 Bad Gateway

A proxy or load balancer received an invalid response from the backend service.

Common cause:

Backend application crashed
Service isn't running

503 Service Unavailable

The server is temporarily unable to handle requests.

Common cause:

Maintenance
Resource exhaustion
Overloaded server

504 Gateway Timeout

The backend service took too long to respond.

Common cause:

Slow database queries
Hung application processes
Network latency

These are among the most common production issues DevOps engineers troubleshoot.

What Is HTTPS?

HTTPS is HTTP running over TLS (Transport Layer Security).

The communication model remains exactly the same, but all data is encrypted before being transmitted.

Without HTTPS, attackers could potentially view:

Passwords
Cookies
API tokens
Personal information

HTTPS protects data while it's traveling across networks.

How TLS Works

A simplified TLS handshake looks like this:

Step 1: Client Hello

The client initiates a secure connection request.

Step 2: Server Certificate

The server provides a digital certificate proving its identity.

Step 3: Certificate Validation

The client verifies:

Certificate validity
Domain ownership
Trusted Certificate Authority (CA)

Step 4: Key Exchange

Client and server securely establish a shared encryption key.

Step 5: Encrypted Communication

All subsequent HTTP traffic becomes encrypted.

What Is an SSL/TLS Certificate?

A certificate binds:

A domain name
A public key

The certificate is digitally signed by a trusted Certificate Authority (CA).

Popular providers include:

Let's Encrypt
DigiCert
Sectigo

Without a valid certificate, browsers display security warnings.

What Is a Load Balancer?

A load balancer sits between clients and backend servers.

Instead of sending all traffic to a single server, it distributes requests across multiple servers.

                  ┌──────────────┐
Clients ────────► │ Load Balancer│
                  └──────┬───────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼

     Server 1       Server 2       Server 3

Why Load Balancers Are Important

Scalability

Traffic is distributed across multiple servers.

High Availability

Failed servers are automatically removed from rotation.

Zero-Downtime Deployments

Applications can be updated one server at a time without affecting users.

Common Load Balancing Algorithms

Round Robin

Requests are distributed evenly in sequence.

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3

Least Connections

Traffic goes to the server with the fewest active connections.

Useful when workloads vary significantly.

IP Hash

Traffic is routed based on the client's IP address.

Useful for session persistence.

What Is a Firewall?

A firewall controls incoming and outgoing network traffic using predefined rules.

Its purpose is to:

Allow legitimate traffic
Block unwanted traffic
Reduce attack surfaces

Firewalls can filter traffic based on:

Ports
Protocols
Source IP addresses
Destination IP addresses

The Default-Deny Security Principle

A strong security practice is:

Block Everything
↓
Allow Only What Is Needed

This approach minimizes exposure and reduces risk.

Managing Firewalls with UFW

Ubuntu provides a user-friendly firewall tool called UFW (Uncomplicated Firewall).

Check Firewall Status

sudo ufw status

Enable Firewall

sudo ufw enable

Disable Firewall

sudo ufw disable

Set Default Policies

sudo ufw default deny incoming
sudo ufw default allow outgoing

Allow Essential Services

Allow SSH

sudo ufw allow 22/tcp

Allow HTTP

sudo ufw allow 80/tcp

Allow HTTPS

sudo ufw allow 443/tcp

Allow a Specific IP Address

sudo ufw allow from 203.0.113.5

Remove a Firewall Rule

sudo ufw delete allow 80/tcp

View Detailed Firewall Rules

sudo ufw status verbose

Important Warning Before Enabling UFW

If you're connected via SSH, always allow port 22 before enabling the firewall.

Correct sequence:

sudo ufw allow 22/tcp
sudo ufw enable

Failing to do this can lock you out of your server.

Security Groups vs UFW

Cloud servers often have two firewall layers:

Cloud Security Groups

Examples:

AWS Security Groups
Azure NSGs
GCP Firewall Rules

These operate outside the virtual machine.

UFW / iptables

These operate inside the Linux operating system.

Using both provides stronger protection through defense in depth.

Bringing It All Together

When you visit a secure website:

DNS resolves the domain name.
Your browser connects to the server's IP.
Traffic is sent through port 443.
TLS encrypts the connection.
An HTTP request is sent.
A load balancer may distribute the request.
A backend server processes it.
Firewalls ensure only allowed traffic reaches the service.
The server returns an HTTP response.

Understanding this flow is essential for anyone working in DevOps, Cloud Engineering, Site Reliability Engineering, or System Administration.

The deeper you understand networking fundamentals, the easier it becomes to troubleshoot real-world production systems.

Happy Learning! 🚀

🌐 Networking Fundamentals Every DevOps Engineer Should Know (IP, DNS & Ports)

Md Mohiuddin — Sun, 02 Aug 2026 08:18:44 +0000

If you're learning DevOps, networking is not optional.

Every SSH connection, web request, Docker container, Kubernetes service, and cloud resource relies on networking behind the scenes.

When applications fail to communicate, deployments break, or services become unreachable, networking is often the first place engineers investigate.

In this article, I'll cover:

✅ What IP addresses are
✅ Public vs Private IPs
✅ Understanding Subnets and CIDR
✅ How DNS works
✅ Common DNS record types
✅ Understanding Ports
✅ The Client-Server Model
✅ Useful networking commands for troubleshooting

Let's dive in.

Why Networking Matters in DevOps

Almost every modern DevOps tool depends on networking.

Examples include:

SSH connections to servers
Web applications communicating with databases
Docker containers talking to each other
Kubernetes services routing traffic
CI/CD pipelines deploying applications
Cloud services communicating across regions

When something stops working, one of the first questions engineers ask is:

Is this a networking problem?

Understanding networking helps you answer that question quickly.

What Is an IP Address?

An IP (Internet Protocol) address is a unique identifier assigned to a device on a network.

It allows devices to locate and communicate with each other.

Example IPv4 address:

192.168.1.10

IPv4 addresses contain four numbers separated by dots.

Each section ranges from:

0 - 255

Without IP addresses, computers wouldn't know where to send data.

Public vs Private IP Addresses

There are two major categories of IP addresses.

Public IP

A public IP address is reachable from anywhere on the internet.

Examples:

Cloud servers
Public websites
Home internet routers

Your AWS EC2 instance will typically have a public IP so you can SSH into it remotely.

Private IP

Private IP addresses are only accessible within a local network.

Common private ranges:

10.0.0.0 – 10.255.255.255

172.16.0.0 – 172.31.255.255

192.168.0.0 – 192.168.255.255

You'll frequently encounter these ranges when working with:

AWS VPCs
Docker networks
Kubernetes clusters
Internal company networks

Localhost (Loopback Address)

A special IP address always refers to the current machine:

127.0.0.1

You'll often see:

localhost

which resolves to:

127.0.0.1

This allows you to test applications running on your own computer without using an external network.

Understanding Subnets

As networks grow, they are divided into smaller logical sections called subnets.

A subnet helps organize devices and control traffic efficiently.

CIDR Notation

Subnets are usually written using CIDR notation:

192.168.1.0/24

The /24 indicates the network portion of the address.

A /24 subnet provides:

256 IP addresses

from:

192.168.1.0

to:

192.168.1.255

Examples:

CIDR	Approx. Addresses
/16	65,536
/24	256
/28	16

You'll see CIDR blocks frequently when creating cloud networks and VPCs.

What Is DNS?

Humans prefer names.

Computers prefer IP addresses.

DNS (Domain Name System) translates domain names into IP addresses.

For example:

google.com

becomes something like:

142.250.xxx.xxx

This allows your browser to find the correct server.

How DNS Resolution Works

When you visit a website:

google.com

the lookup process generally follows these steps:

Your Device
      ↓
DNS Resolver
      ↓
Root Servers
      ↓
TLD Servers (.com)
      ↓
Authoritative DNS Server
      ↓
IP Address Returned

Finally, your computer connects to the returned IP address.

This entire process usually takes only milliseconds.

Common DNS Record Types

Record	Purpose
A	Domain → IPv4 Address
AAAA	Domain → IPv6 Address
CNAME	Domain Alias
MX	Mail Server Records
TXT	Verification & Security Records
NS	Name Server Information

As a DevOps engineer, you'll regularly manage DNS records when deploying applications.

Understanding Ports

An IP address identifies a machine.

A port identifies a service running on that machine.

Think of it like:

IP Address = Building Address
Port = Apartment Number

Multiple applications can run on the same server because each listens on a different port.

Common Ports Every DevOps Engineer Should Know

Port	Service
22	SSH
53	DNS
80	HTTP
443	HTTPS
3306	MySQL
5432	PostgreSQL
6379	Redis
27017	MongoDB

Examples:

192.168.1.10:22

SSH service

192.168.1.10:80

Web server

192.168.1.10:443

Secure website

The Client-Server Model

Most applications follow the client-server model.

A client sends a request.

A server receives the request and returns a response.

Example:

CLIENT                     SERVER

Browser  ───── Request ───► Nginx

Browser ◄──── Response ─── Nginx

Examples of clients:

Web browsers
Mobile apps
curl
API consumers

Examples of servers:

Nginx
Apache
Node.js applications
Databases

Useful Networking Commands

ping

Check whether a host is reachable.

ping google.com

Example output:

64 bytes from 142.x.x.x: time=14 ms

Useful for:

Basic connectivity testing
Measuring latency

Stop with:

Ctrl + C

nslookup

Perform a DNS lookup.

nslookup google.com

Output shows the IP address associated with the domain.

dig

A more advanced DNS troubleshooting tool.

Basic lookup:

dig google.com

Short output:

dig google.com +short

Lookup MX records:

dig google.com MX

View the full DNS resolution path:

dig +trace google.com

curl

Send HTTP requests directly from the terminal.

curl https://google.com

Show only response headers:

curl -I https://google.com

Verbose mode:

curl -v https://google.com

Save output to a file:

curl -o page.html https://google.com

curl -I is one of the most useful troubleshooting commands in DevOps.

Following the Journey of a Request

Let's see what happens when you run:

curl https://google.com

Step-by-step:

DNS resolves google.com to an IP address.
Your machine connects to that IP.
It uses port 443 for HTTPS.
A secure TLS connection is established.
The HTTP request is sent.
Google's server processes the request.
An HTTP response is returned.
curl displays the result.

DNS
 ↓
IP Address
 ↓
Port 443
 ↓
TLS Handshake
 ↓
HTTP Request
 ↓
HTTP Response

This flow is the foundation of nearly every web application you'll work with.

Final Thoughts

Networking is one of the most important skills in DevOps.

Understanding IP addresses, DNS, ports, and client-server communication gives you the foundation needed for cloud computing, Docker, Kubernetes, load balancers, CI/CD pipelines, and modern infrastructure.

The better you understand how systems communicate, the easier it becomes to troubleshoot real-world production issues.

If you have favorite networking commands or troubleshooting tips, feel free to share them in the comments.

Happy Learning! 🌐🚀

DEV Community: Md Mohiuddin

Docker Compose: Run Your Whole App with One Command

Why Docker Compose Matters

What Is Docker Compose?

Imperative vs Declarative

Imperative

Declarative

The docker-compose.yml File

YAML Indentation Matters

Defining a Service

image

container_name

environment

ports

volumes

build — Building Your Own Application

depends_on

Docker Compose Networking

Defining a Custom Network

Restart Policies

The Most Important Compose Commands

Start the Application

Run in the Background

Build Before Starting

Check Service Status

View Logs

View Logs for One Service

Follow Logs

docker compose stop vs docker compose down

docker compose stop

docker compose down

Be Careful With down -v

A Complete Real-World Example

Why Compose Is a Big Step Forward

Docker Compose Is Infrastructure as Code Practice

Final Thoughts

Dockerfiles: Build Your Own Images

From Docker User to Docker Author

What Is a Dockerfile?

FROM — Choose the Base Image

Why Avoid latest?

WORKDIR — Set the Working Directory

COPY — Bring Application Files Into the Image

RUN — Execute Commands During the Build

RUN vs CMD

EXPOSE — Document the Application Port

CMD — Define the Default Startup Command

Prefer Exec Form

A Complete Dockerfile

Why Dockerfile Instruction Order Matters

Understanding Docker Build Cache

A Common Dockerfile Mistake

The Better Dockerfile

The General Rule

Building Your Docker Image

docker build

-t my-flask-app

.

Check Your New Image

Run Your Application

.dockerignore — Your Docker Build's .gitignore

Smaller Build Context

Smaller Images

Security

A Practical .dockerignore

COPY vs ADD

Common Dockerfile Mistakes

Using latest Everywhere

Copying Everything Too Early

Confusing EXPOSE With Port Publishing

Putting Secrets in the Image

Forgetting .dockerignore

The Dockerfile Mental Model

From Dockerfile to CI/CD

Hands-On Challenge

Final Thoughts

Docker Networking & Volumes: Connecting Containers and Persisting Data

Why Docker Networking Matters

Docker Network Drivers

Bridge Network

The `docker-compose.yml` File

`image`

`container_name`

`environment`

`ports`

`volumes`

`build` — Building Your Own Application

`depends_on`

`docker compose stop` vs `docker compose down`

`docker compose stop`

`docker compose down`

Be Careful With `down -v`

`FROM` — Choose the Base Image

Why Avoid `latest`?

`WORKDIR` — Set the Working Directory

`COPY` — Bring Application Files Into the Image

`RUN` — Execute Commands During the Build

`RUN` vs `CMD`

`EXPOSE` — Document the Application Port

`CMD` — Define the Default Startup Command

`docker build`

`-t my-flask-app`

`.`

`.dockerignore` — Your Docker Build's `.gitignore`

A Practical `.dockerignore`

`COPY` vs `ADD`

Using `latest` Everywhere

Confusing `EXPOSE` With Port Publishing

Forgetting `.dockerignore`

Why `ConnectApi.CdpQuery` Isn't Enough