docker run nginx

A few seconds later, you see a running container.

It feels simple.

But Docker didn't just "start Nginx."

Between pressing Enter and seeing that container running, Docker performs a series of operations involving images, the Docker daemon, storage, networking, isolation, and processes.

That made me curious:

What actually happens when we run docker run?

Let's go under the hood.

First, What Does docker run Actually Mean?

When we execute:

docker run nginx

we are essentially asking Docker to:

Find the nginx image, create a new container from it, configure the container, and start its main process.

A useful way to visualize it is:

docker run nginx
        |
        v
Docker CLI
        |
        v
Docker Daemon
        |
        v
Check for nginx image
        |
   +----+----+
   |         |
Exists     Doesn't exist
   |         |
   |      Pull image
   |         |
   +----+----+
        |
        v
Create container
        |
        v
Configure filesystem & networking
        |
        v
Start container process
        |
        v
Nginx is running

Now let's break this down.

Step 1 — You Run the Command

Everything starts here:

docker run nginx

The command is executed through the Docker CLI.

The CLI is the interface we use to communicate with Docker.

But here's something important:

The Docker CLI doesn't do all the work itself.

It communicates with the Docker daemon, which is responsible for actually managing containers, images, networks, and other Docker resources.

So conceptually:

You
 ↓
Docker CLI
 ↓
Docker Daemon

Step 2 — Docker Checks for the Image

Docker now needs to find the nginx image.

It first checks whether the image already exists locally.

You can see your local images with:

docker images

If nginx is already available, Docker can use it.

If it isn't available locally, Docker needs to retrieve it from a container registry.

Step 3 — Docker Pulls the Image If Necessary

If Docker can't find the image locally, it pulls it from a registry.

For example:

docker pull nginx

The default registry most developers encounter is Docker Hub.

The image is downloaded in layers.

You may have seen output similar to:

Pull complete
Pull complete
Pull complete

These layers are one of the reasons Docker images can be efficient.

Different images can share common layers instead of storing duplicate data.

Step 4 — Docker Creates the Container

This is where an important distinction comes in.

An image is not a container.

Think about it like this:

Docker Image = Blueprint
Container = House built from the blueprint

The image contains what is needed to create the application environment.

The container is the running instance created from that image.

So when you execute:

docker run nginx

Docker uses the nginx image to create a new container.

You can verify the running container with:

docker ps

Step 5 — Docker Prepares the Container Environment

Before starting the application, Docker needs to prepare the environment in which the container will run.

This includes things such as:

• Filesystem

• Networking

• Environment variables

• Resource configuration

• Process isolation

This is one of the reasons containers are more than just "lightweight virtual machines."

Containers use operating-system-level isolation mechanisms to separate processes and resources.

Step 6 — The Container Gets Its Own Filesystem View

The container needs a filesystem to work with.

Docker builds this environment from the image layers and creates a writable layer for the container.

This means multiple containers can be created from the same image while maintaining their own changes.

For example:

                 Nginx Image
                     |
          +----------+----------+
          |                     |
          v                     v
     Container A           Container B
     Writable Layer        Writable Layer

Both containers can use the same underlying image while having their own container-specific writable layer.

Step 7 — Docker Sets Up Networking

Docker also creates the networking environment required by the container.

For a basic container:

docker run nginx

Docker typically connects the container to its default network.

However, there's an important detail.

If you run:

docker run -p 8080:80 nginx

you're explicitly mapping:

Host Port 8080
       |
       v
Container Port 80

So when you visit:

http://localhost:8080

the request can reach Nginx running inside the container.

This is one of those Docker concepts that becomes much easier once you understand what's happening underneath.

Step 8 — Docker Starts the Main Process

Now comes the part that makes the container actually "run."

Docker starts the process defined by the image's configuration.

For the Nginx image, that means starting the Nginx process.

This leads to another important concept:

A container is fundamentally about running a process.

It's not just a packaged folder.

Docker creates an isolated environment and starts the application's process inside it.

Image vs Container

This distinction is worth remembering.

A simple analogy:

Image = Recipe

Container = Meal prepared using that recipe

You can prepare multiple meals using the same recipe.

Similarly, you can create multiple containers from the same image.

What If the Container Stops?

Here's another interesting part.

If you run:

docker ps

you'll only see currently running containers.

To see stopped containers too:

docker ps -a

Why?

Because the container itself can still exist even after its main process has stopped.

You can then start it again using:

docker start <container-id>

This helped me understand that:

Container lifecycle and application lifecycle are closely connected.

When the main process ends, the container generally stops.

The Complete Journey

So the next time you run:

docker run nginx

think about everything happening underneath:

You
 |
 | docker run nginx
 v
Docker CLI
 |
 v
Docker Daemon
 |
 v
Check local image
 |
 +---- Image exists
 |          |
 |          v
 |     Use existing image
 |
 +---- Image doesn't exist
            |
            v
        Pull image
            |
            v
      Create container
            |
            v
   Prepare filesystem
            |
            v
    Configure networking
            |
            v
     Start main process
            |
            v
       Nginx running

One command.

A surprisingly long chain of operations.

Why Understanding This Matters in DevOps

When I first learned Docker, I focused on commands:

docker build
docker run
docker ps
docker stop
docker rm

But knowing commands is only one part of working with Docker.

Understanding what happens underneath makes troubleshooting much easier.

For example, when a container doesn't work, I can start asking better questions:

Is the image available?

Did the container actually start?

Is the application process running?

Is the port mapped correctly?

Is the container connected to the expected network?

What do the container logs say?

Instead of randomly trying commands, I can start investigating the actual layer where the problem exists.

This Became Important in My CI/CD Project

While building my own CI/CD pipeline, Docker wasn't just something I was learning separately.

It became part of the delivery process.

The simplified flow looked like:

Git Push
   ↓
Jenkins
   ↓
Maven Build
   ↓
SonarQube
   ↓
Docker Build
   ↓
Docker Image
   ↓
Container
   ↓
AWS EC2

Understanding Docker at this level makes the pipeline easier to reason about.

The pipeline isn't simply "running Docker."

It's building an artifact, creating an environment from that artifact, and eventually running the application as a container.

What I Took Away From This

Before digging into Docker internals, I thought:

docker run nginx

meant:

"Start Nginx."

Now I think of it differently.

It means:

"Take this image, create an isolated container environment from it, configure the required resources and networking, and start the application's process."

That's a much better mental model.

And this is becoming a recurring theme in my DevOps journey.

The command is only the surface.

The interesting part is what happens underneath.

git push

A few seconds later, your code appears on GitHub.

It feels almost magical.

But behind that simple command is a surprisingly sophisticated sequence of events.

When I first started learning DevOps, I treated git push as nothing more than "upload my code."

Now, after building CI/CD pipelines and working with Git daily, I see it very differently.

Let's take a look under the hood.

Step 1 — Git Finds What Has Changed

The first thing Git does isn't upload anything.

Instead, it compares your local branch with the remote branch.

It asks a simple question:

"Which commits does the remote repository not have yet?"

Only those missing commits will be prepared for transfer.

This is one reason Git remains incredibly efficient even for large repositories.

Step 2 — Git Creates a Packfile

Git doesn't upload every individual file.

Instead, it creates what's called a packfile.

Inside this compressed package are:

• Commits

• Trees (directory structure)

• Blobs (file contents)

Because of this compression, Git transfers only the required information while minimizing network traffic.

This is one of Git's biggest strengths.

Step 3 — Authentication

Before GitHub accepts anything, it verifies your identity.

Depending on your configuration, this usually happens through:

• SSH Keys

• Personal Access Tokens (HTTPS)

If authentication fails, the push stops immediately.

No code is transferred.

Step 4 — Secure Communication

Now the data begins travelling across the internet.

Most developers push using one of two protocols:

• SSH (Port 22)

• HTTPS (Port 443)

Both provide encrypted communication, ensuring your commits remain secure during transmission.

Step 5 — GitHub Performs Validation

Receiving the data isn't enough.

GitHub now validates several things.

For example:

• Does the repository exist?

• Does the branch exist?

• Does the user have permission?

• Are branch protection rules satisfied?

If any of these checks fail, GitHub rejects the push.

Step 6 — Updating the Remote Repository

Once every validation passes successfully, GitHub updates the branch reference.

Your commits now become part of the remote repository.

At this point, everyone collaborating on the project can access the latest changes.

Step 7 — The Hidden DevOps Pipeline

For many organizations, this is where the interesting part begins.

A single git push can automatically trigger an entire CI/CD workflow.

For example:

Developer
      │
      ▼
git push
      │
      ▼
GitHub Repository
      │
      ▼
Webhook
      │
      ▼
Jenkins Pipeline
      │
      ▼
Build
      │
      ▼
Run Tests
      │
      ▼
SonarQube Analysis
      │
      ▼
Docker Image
      │
      ▼
Deploy to AWS EC2

What looks like a simple Git command can actually start an automated software delivery process.

That realization completely changed how I viewed Git.

Why Understanding This Matters

As beginners, we often focus on memorizing commands.

Experienced engineers ask a different question:

"What happens after I run this command?"

That mindset leads to a much deeper understanding of systems.

And in DevOps, understanding systems is often more valuable than memorizing tools.

Finally

Today, whenever I type:

git push

I no longer think:

"I'm uploading my code."

Instead, I think:

"I'm triggering a chain of systems that will validate, build, test, and possibly deploy my application."

A single command.

An entire ecosystem working behind the scenes.

And that's exactly what makes DevOps fascinating.

Pipeline green = Everything is working.

If Jenkins showed a successful build, I assumed:

• The application was fine

• Deployment worked

• The system was healthy

But after working on real setups, I realized something important:

A successful pipeline only means the steps executed successfully.

It does not guarantee the outcome is correct.

And honestly, that changed the way I think about DevOps.

The first time I realized this

One of my deployments looked completely successful.

Build stage ✔
Docker stage ✔
Deployment stage ✔

Everything was green.

But when I opened the application—

nothing worked.

The service wasn’t accessible.

At first, I thought Jenkins had failed silently.

But after debugging further, the actual issues were:

• Security group misconfiguration

• Container startup failure

• Port accessibility problems

The pipeline had technically succeeded.

The system had not.

Another Example: Maven Test Failures

In another instance, the pipeline failed due to Maven tests.

The Jenkins setup itself was correct.

But the build failed due to:

Failed to execute goal maven-surefire-plugin:test

That moment helped me understand something important:

Sometimes the pipeline is healthy.

The code is not.

CI/CD Pipelines Don’t Just Deploy Code

Earlier, I viewed pipelines as automation tools.

Now I see them differently.

Pipelines are validation systems.

They verify:

• Build quality

• Test execution

• Deployment flow

• System consistency

A failed pipeline is not always “bad.”

Sometimes it’s the system protecting production.

What I Started Checking After Deployments

Earlier, my workflow ended at:

✔ Jenkins build successful

Now I validate much more:

• Is the application actually running?

• Is the service reachable?

• Are ports exposed correctly?

• Did the container start properly?

• Is the server accessible?

That small mindset shift changed how I debug systems.

Why This Matters in DevOps

One thing I’m slowly learning:

Automation alone is not enough.

A pipeline can automate mistakes very efficiently if validation is missing.

That’s why observability, testing, logging, and verification matter so much in real systems.

What This Journey Taught Me

The deeper I go into DevOps, the more I realize:

The hardest part is not running tools.

It’s understanding systems.

Because tools only execute instructions.

Engineers have to understand outcomes.

Final Thoughts

Today, when I see a green pipeline, I no longer immediately assume success.

Instead, I ask:

• Did the deployment actually work?

• Is the application healthy?

• Can users access the system?

• Did the infrastructure behave correctly?

That mindset changed how I approach CI/CD completely.

And honestly, it made the learning journey far more interesting.

LinkedIn: https://bit.ly/41vlNEW

Jenkins.
Docker.
AWS.
Terraform.

But while building real projects, I kept running into problems that none of those tools alone could solve.

Most of the time, the answer was somewhere inside Linux.

That’s when I realized:

DevOps tools may automate systems.
But Linux helps you understand them.

Over the past few weeks, while working on CI/CD pipelines, Docker containers, EC2 deployments, and Terraform setups, a few Linux commands became part of my daily workflow.

These weren’t just commands I memorized.

They became the commands that helped me debug, fix, and understand systems better.

1. chmod — Fixing SSH Key Permission Issues

One of the first real problems I faced was while connecting to an AWS EC2 instance using SSH.

The instance was running.
The public IP was correct.

But SSH kept failing.

The issue turned out to be incorrect permissions on the .pem key file.

The fix:

chmod 400 petclinic-key.pem

This command restricts access to the key file and allows SSH to use it securely.

This was one of the moments where Linux stopped feeling “optional.”

2. ls — Understanding Files and Permissions

Simple, but essential.

While working with Terraform files, Docker configurations, and Jenkins setups, I constantly used:

ls -l

This helped me:

• Check file permissions

• Verify scripts

• Confirm generated files

• Understand ownership and access

It became one of the fastest ways to debug environment issues.

3. cd and pwd — Navigating Projects Efficiently

During CI/CD setup, multiple directories quickly become confusing.

Using:

pwd

helped confirm the current working directory.

And:

cd

became second nature while moving between:

• Jenkins workspace

• Terraform folders

• Docker project directories

Basic commands, but used constantly.

4. systemctl — Managing Services

When services failed unexpectedly, this command became extremely important.

Example:

systemctl status docker

This helped me:

• Check if Docker is running

• Verify service states

• Troubleshoot startup issues

Other useful variations:

systemctl start docker
systemctl restart docker

Understanding services made debugging much easier.

5. docker logs — Understanding Container Failures

Sometimes containers exited immediately without clear errors.

Instead of guessing, I started checking logs:

docker logs <container-id>

This exposed:

• Application startup failures

• Port conflicts

• Missing configurations

• Runtime exceptions

This command saved hours of blind troubleshooting.

6. ps — Checking Running Processes

When applications behaved unexpectedly, I used:

ps -ef

This helped identify:

• Running processes

• Stuck services

• Background tasks

A small command, but very useful while debugging deployments.

7. top — Watching System Resources

While testing deployments on EC2, I became curious about resource usage.

Using:

top

helped monitor:

• CPU usage

• Memory consumption

• Running processes

This was one of the first steps toward understanding system performance.

8. grep — Searching Faster

Logs can become overwhelming very quickly.

Using:

grep

helped filter important information from large outputs.

Example:

docker logs container-id | grep ERROR

This made debugging much faster.

9. mkdir and rm — Managing Project Structure

Simple commands, but heavily used while creating environments and cleaning up setups.

Examples:

mkdir terraform-ec2
rm -rf old-folder

These became part of daily project management.

What Linux Actually Taught Me

Before these projects, Linux felt like:

“A set of commands to memorize.”

Now it feels different.

Linux is not just an operating system in DevOps.

It’s the layer where:

• Services run

• Containers execute

• Permissions matter

• Logs exist

• Systems reveal problems

The more I worked on real setups, the more Linux stopped feeling theoretical.

It became practical.

Final Thoughts

One thing I’ve learned during this journey:

Most DevOps debugging eventually leads back to Linux.

Not because the tools are bad.

But because Linux is where those tools operate.

The better I understand Linux, the easier it becomes to understand systems.

And honestly, that has been one of the biggest shifts in my learning journey so far.

LinkedIn: https://bit.ly/41vlNEW

Tags

#devops #linux #AWS #docker #terraform #jenkins #cicd