DEV Community: prash 1

# My First Docker Container: Installation and Essential Commands

prash 1 — Fri, 07 Aug 2026 08:20:46 +0000

My First Docker Container: Installation and Essential Commands

In the previous article, we learned what Docker is and why it became one of the most important tools in modern software development and DevOps.

Now it’s time to do something practical.

In this article, we will install Docker and run our first Docker container. By the end, you will understand the most important Docker commands that every beginner should know.

Installing Docker

Docker is available for Windows, macOS, and Linux.

Windows

Download Docker Desktop from the official Docker website and complete the installation.

After installation, open Docker Desktop and wait until Docker starts successfully.

Linux (Ubuntu)

Update the package list:

sudo apt update

Install Docker:

sudo apt install docker.io -y

Start the Docker service:

sudo systemctl start docker

Enable Docker to start automatically after reboot:

sudo systemctl enable docker

Check whether Docker is installed correctly:

docker --version

You should see an output similar to:

Docker version 28.x.x

Running your first Docker command

The easiest way to test Docker is:

docker run hello-world

This command downloads a small image called hello-world and runs it.

You should see a welcome message confirming that Docker is working correctly.

Congratulations! You have just run your first Docker container.

Understanding what happened

The command:

docker run hello-world

actually performs several steps automatically.

Docker looks for the hello-world image locally.
If it is not available, Docker downloads it from Docker Hub.
Docker creates a container from that image.
Docker starts the container.
The container prints a message and exits.

This single command demonstrates the basic Docker workflow.

Docker images

A Docker image is a template used to create containers.

To see downloaded images:

docker images

Example output:

REPOSITORY    TAG       IMAGE ID       CREATED       SIZE
hello-world   latest    abc123xyz      2 weeks ago   13KB

The most important columns are:

Repository – image name
Tag – version
Image ID – unique identifier
Size – image size

Downloading an image manually

Instead of running a container immediately, you can download an image first.

For example:

docker pull nginx

This downloads the Nginx web server image.

Verify:

docker images

You should now see the Nginx image.

Running a container

To create and start a container:

docker run nginx

Docker starts the Nginx web server.

However, the terminal becomes occupied because the container is running in the foreground.

Stop it with:

Ctrl + C

Running a container in the background

Use the -d option (detached mode):

docker run -d nginx

Docker returns a long container ID.

The container continues running in the background.

Viewing running containers

To see active containers:

docker ps

Example:

CONTAINER ID   IMAGE   STATUS
a12b34c56d78   nginx   Up 2 minutes

Useful columns:

Container ID
Image
Status

Viewing all containers

Even stopped containers are stored on your system.

To see them:

docker ps -a

This shows:

running containers
stopped containers
exited containers

Stopping a container

First, find the container ID:

docker ps

Then stop it:

docker stop container_id

Example:

docker stop a12b34c56d78

Docker stops the running container.

Starting a stopped container

To start it again:

docker start container_id

Example:

docker start a12b34c56d78

The container resumes execution.

Removing a container

A stopped container can be deleted.

docker rm container_id

Example:

docker rm a12b34c56d78

If the container is running, stop it first.

Removing an image

To delete an image:

docker rmi nginx

If a container is using the image, Docker will prevent removal.

Delete the container first, then remove the image.

Running Ubuntu interactively

One of the most useful beginner commands is:

docker run -it ubuntu

The options mean:

-i = interactive
-t = terminal

You enter a shell inside the Ubuntu container.

Try:

ls
pwd
echo Hello Docker

To exit:

exit

The container stops after exiting the shell.

Giving a container a name

Instead of using random IDs:

docker run -d --name mynginx nginx

Now the container has the name mynginx.

Stop it:

docker stop mynginx

Start it:

docker start mynginx

Remove it:

docker rm mynginx

Names are much easier to remember than container IDs.

Checking container logs

To view application logs:

docker logs mynginx

This is extremely useful for debugging.

For continuous log monitoring:

docker logs -f mynginx

Press Ctrl + C to stop following the logs.

Executing commands inside a running container

Suppose Nginx is running.

Open a shell inside it:

docker exec -it mynginx bash

Some images use sh instead of bash:

docker exec -it mynginx sh

Now you are working inside the running container.

Exit with:

exit

The five commands you should memorize

If you are completely new to Docker, focus on these commands first.

Download an image:

docker pull nginx

Run a container:

docker run -d --name mynginx nginx

View containers:

docker ps

Stop a container:

docker stop mynginx

Remove a container:

docker rm mynginx

These commands cover most beginner Docker tasks.

A quick practice exercise

Try this sequence yourself:

docker pull nginx
docker run -d --name web nginx
docker ps
docker logs web
docker stop web
docker start web
docker exec -it web bash
exit
docker stop web
docker rm web

Running these commands once is far better than reading them ten times.

What’s next?

In the next article, we will learn Docker architecture in detail. We will understand images, containers, Docker Hub, and the Docker engine, and see what happens behind the scenes when you run a Docker command.

The more you practice these basic commands, the easier Docker will become.

Happy learning!

# Docker for Absolute Beginners: What It Is and Why It Matters

prash 1 — Fri, 07 Aug 2026 08:18:54 +0000

Docker for Absolute Beginners: What It Is and Why It Matters

If you are starting your DevOps or cloud journey, Docker is one of the most important tools you will learn. I remember being confused when people said, “It works on my machine.” Docker was created to solve exactly that problem.

In this article, I will explain Docker in the simplest possible way. No complicated definitions, no advanced commands. Just the core concept that every beginner should understand.

The problem before Docker

Imagine two developers working on the same project.

Developer A builds the application on their laptop, and everything works perfectly.

Developer B copies the project and tries to run it, but gets errors.

Why?

Because their environments are different.

Maybe one has Python 3.12 while the other has Python 3.10.

Maybe one has MySQL installed and the other doesn’t.

Maybe some library versions are different.

These differences create deployment problems.

Docker solves this by packaging the application together with everything it needs.

What is Docker?

Docker is a platform that allows you to package an application and all its dependencies into a container.

Think of a container as a lightweight box that contains:

your application
required libraries
runtime environment
configuration
dependencies

Because everything is inside the container, the application behaves the same on any system that has Docker installed.

A simple real-life example

Imagine you are moving a fully furnished room.

Instead of carrying the bed, table, chair, and wardrobe separately, you place everything inside a shipping container.

That container can be transported anywhere.

Docker containers work in a similar way.

Your application is packed inside a container and can run on:

your laptop
your friend’s computer
a company server
AWS
Azure
Google Cloud

without changing the application itself.

What is a container?

A container is a running instance of a Docker image.

An image is a blueprint.

A container is the actual running application.

For example:

Ubuntu image
Python image
Nginx image
MySQL image

When you start an image, Docker creates a container from it.

Docker image vs Docker container

This is the most important beginner concept.

Docker image

A Docker image is a template.

It contains the application and everything needed to run it.

Docker container

A container is a running copy of an image.

You can create multiple containers from the same image.

For example, one Nginx image can create three Nginx containers.

Why Docker became so popular

Docker became popular because it solves several real-world problems.

Consistency

The application works the same everywhere.

Isolation

Each container has its own environment.

Fast deployment

Containers start much faster than virtual machines.

Easy scaling

You can create multiple containers quickly.

Better resource usage

Containers use fewer system resources.

Virtual machine vs Docker

Before Docker, virtualization was commonly used.

Virtual machine

A virtual machine contains:

guest operating system
libraries
application

Each VM requires a full operating system.

This makes VMs relatively heavy.

Docker container

Containers share the host operating system kernel.

They only package the application and its dependencies.

This makes containers lightweight and fast.

A simple comparison:

Virtual Machine	Docker Container
Includes full OS	Shares host OS
Heavy	Lightweight
Slower startup	Fast startup
More memory	Less memory
Large disk usage	Small disk usage

How Docker works

Docker has three main components.

Docker client

The commands you type.

For example:

docker run nginx

Docker daemon

The background service that creates and manages containers.

Docker registry

A place where images are stored.

The default public registry is Docker Hub.

When you run:

docker pull nginx

Docker downloads the Nginx image from Docker Hub.

The Docker workflow

A beginner-friendly workflow looks like this.

Step 1: Write application

Create your application.

Step 2: Create Dockerfile

Describe how the application should be packaged.

Step 3: Build image

Docker creates an image.

Step 4: Run container

Docker starts the application inside a container.

The flow is:

Application → Dockerfile → Image → Container

A practical example

Suppose you have a small Python application.

Without Docker:

install Python
install pip
install dependencies
configure environment
run application

With Docker:

build image
run container

That’s it.

This is why Docker is heavily used in DevOps and cloud engineering.

Where Docker is used

Docker is used almost everywhere.

Web applications
APIs
Databases
Microservices
CI/CD pipelines
Cloud deployments
Testing environments
Machine learning applications

Companies like Netflix, Spotify, Uber, and many startups use container-based deployments.

Common beginner misconceptions

Docker is a virtual machine

No.

Docker uses containers, not traditional virtual machines.

Docker replaces Linux

No.

Docker runs on Linux and also works on Windows and macOS.

Docker is only for DevOps

No.

Developers, testers, data engineers, and ML engineers also use Docker.

The one concept you must remember

If you remember only one sentence from this article, remember this:

A Docker image is a blueprint, and a Docker container is a running application created from that blueprint.

Everything else becomes much easier after understanding this idea.

What’s next?

In the next article, we will install Docker and create our first container. We will learn the basic commands that every Docker user should know.

If you’re beginning your DevOps journey, Docker is one of the best investments you can make. Spend time understanding the fundamentals, and the advanced topics will become much easier later.

Happy learning!

DOCKER

prash 1 — Fri, 24 Jul 2026 08:54:42 +0000

Here's a follow-up post continuing the series — same voice, picking up where the Linux post left off:

Docker Made Sense the Day I Stopped Treating It Like Magic

After my last post on falling in love with Linux, a few people asked the obvious next question: "okay, but when do I actually get to Docker?"

Here's the honest answer — I jumped into Docker way too early the first time, before Linux made sense, and it felt like memorizing spells. docker run. docker build. docker-compose up. Things worked when I copy-pasted commands, and broke in ways I couldn't explain when I didn't. It wasn't until I understood Linux processes, filesystems, and networking that Docker stopped being magic and started being obvious.

Docker Isn't a New Thing. It's a Trick on Top of Old Things.

This was the single biggest unlock for me: Docker isn't some separate virtual computer running inside your computer. A container is just a regular Linux process, with some clever isolation layered on top — its own view of the filesystem, its own network namespace, its own process tree. That's it.

Once I understood that, questions that used to confuse me stopped being mysterious:

"Why does my container see a different filesystem?" — because of Linux namespaces, not because Docker built a tiny VM.
"Why did my container die immediately after starting?" — because the one process it was running exited, and containers live and die with their main process, just like any other Linux process.
"Why is my container using so much memory?" — because cgroups are throttling or reporting resource usage, the same mechanism Linux itself uses.

Docker didn't invent isolation. It packaged existing Linux features into something usable.

The Commands That Actually Matter Here Too

Same philosophy as the Linux post — don't memorize everything, get fluent in a small core set first.

Building and running:

docker build -t myapp .
docker run -p 3000:3000 myapp

Seeing what's actually going on:

docker ps          # what's running right now
docker ps -a       # what's running or has exited
docker logs -f myapp   # this is your tail -f from the Linux post

Getting inside a running container to debug it:

docker exec -it myapp /bin/bash

The first time I ran this and realized I was just... inside a normal Linux shell, looking at normal Linux files, using the same ls, cat, and grep I'd already learned — that's when Docker really clicked. It wasn't a new skill. It was the same skill, in a slightly different box.

Cleaning up (because disk space disappears fast):

docker system prune
docker image prune

Why This Sets You Up for Kubernetes

Here's the part that made the next step obvious: Kubernetes doesn't run "apps." It runs containers. Every pod is one or more containers, scheduled onto a node, which is — you guessed it — a Linux machine. The docker logs, docker exec, and resource concepts you just learned map almost directly onto kubectl logs, kubectl exec, and Kubernetes resource limits.

Learn Docker on top of Linux, and Kubernetes stops looking like a new mountain. It starts looking like the same mountain, just with more automation strapped onto it.

What I'd Tell Someone Starting Docker Today

Don't start with Docker Compose and fifteen services wired together. Start with one container. Build it. Break it. Exec into it and poke around like it's just another Linux box — because it is. Once building and debugging a single container feels boring and routine, multi-container setups and orchestration stop being scary and start being the next logical step.

Next up: I'll go through the CI/CD pipeline basics I wish I'd understood before I started copy-pasting YAML from Stack Overflow.

DEVOPS

prash 1 — Tue, 21 Jul 2026 19:07:02 +0000

Why Every DevOps Engineer Needs to Fall in Love With Linux (Before Anything Else)

When I started learning DevOps, I made the classic beginner mistake. I jumped straight into Docker tutorials, then AWS, then Kubernetes — because those are the tools that show up in every job description and every flashy YouTube thumbnail. Linux felt boring. Old. Something my seniors used because "that's just how it's always been done."

It took me exactly one broken container, one failed SSH connection, and one very confused 2 AM debugging session to realize I had it backwards.

Here's the truth nobody tells you early enough: Docker runs on Linux. AWS servers run on Linux. Your CI/CD pipelines run on Linux. Kubernetes nodes run on Linux. Skip Linux, and you're building a house on a foundation you don't understand.

The Terminal Isn't Scary — It's Honest

The first time I opened a terminal, it felt like staring into a black hole with a blinking cursor judging me. No buttons. No menus. Just... a prompt, waiting.

But here's what changed my mind: the terminal doesn't hide anything from you. When something breaks in a GUI, you get a vague error popup and a spinning wheel. When something breaks in Linux, you get a log file that tells you exactly what went wrong, on exactly which line, at exactly what time. Once I understood that, the terminal stopped being intimidating and started being the most honest tool I had.

The Commands That Actually Matter (Not All 200 of Them)

You don't need to memorize every Linux command that exists. I wasted weeks trying to do that. What you actually need is a small toolkit you can use without thinking:

Moving around and looking at things:

pwd          # where am I right now
ls -la       # what's in this folder (including hidden files)
cd /var/log  # go somewhere else

Reading files without opening a heavy editor:

cat file.txt
less file.txt
tail -f app.log     # this one alone will save you during every production incident

Finding things when you don't know where they are:

find / -name "app.log"
grep "ERROR" app.log

Understanding what's actually running:

ps aux
top
kill -9 1234

Permissions — the thing that confuses everyone at first:

chmod +x script.sh
sudo chown user:group file.txt

That's genuinely 80% of what I use, daily, even now. The rest I look up when I need it. Nobody has every flag of every command memorized — including senior engineers.

The Day I Understood Why Permissions Matter

Early on, I got a Permission denied error running a script and just typed sudo in front of everything to make it go away. It worked, so I moved on.

Later, on a real project, someone asked me why a config file had 777 permissions (basically, "anyone can read, write, or execute this"). I didn't have an answer. That's when I actually sat down and learned what chmod numbers mean — and realized I had been creating a security hole out of laziness, not understanding.

That's the thing about Linux — it doesn't stop you from shooting yourself in the foot. It trusts you to know what you're doing. Which means you actually have to learn what you're doing.

SSH: The Command That Makes You Feel Like a "Real" Engineer

There's a specific moment every DevOps beginner remembers — the first time you SSH into a remote server and it actually connects.

ssh username@server-ip

Suddenly you're not clicking around a dashboard anymore. You're inside a machine, potentially thousands of miles away, typing commands that actually do something. It's a small moment, but it's the moment Linux stops being "a thing I'm learning" and starts being "a tool I use."

Why This Matters Even More on AWS

If you're heading toward cloud/DevOps work like I was, here's the part that made everything click: every EC2 instance you launch is (almost always) a Linux server. Every container you build with Docker is running on a Linux kernel underneath, even if you're on a Mac or Windows laptop. Every Kubernetes node is Linux.

So when your app crashes at 2 AM and your manager asks "what happened," the answer isn't going to be found in a fancy AWS dashboard. It's going to be found in:

tail -f /var/log/app.log
journalctl -u myapp -f
df -h        # is the disk full?
free -m      # did it run out of memory?

Linux is where the real answers live. Everything else — Docker, Kubernetes, AWS — is just a nicer interface built on top of it.

What I'd Tell Someone Starting Today

Don't try to "finish" Linux before moving to Docker or AWS — you never really finish learning it, and that's fine. But do get comfortable enough that a terminal doesn't scare you. Get to the point where cd, ls, cat, grep, and chmod feel like typing your own name.

Break something on purpose. Delete a file you didn't need. Lock yourself out of a permission you set wrong. Fix it. That's how it actually sticks — not from reading a cheat sheet, but from being annoyed enough to figure it out yourself at 11 PM.

Because eventually, when a container won't start, or a deployment silently fails, or a server runs out of disk space — you won't be the person waiting for someone else to fix it.

You'll be the person who opens the terminal, types three commands, and just... knows.