DEV Community: Chetan Inaganti

Docker for Beginners: Images, Containers, Ports, and Volumes Explained

Chetan Inaganti — Sat, 08 Aug 2026 06:00:04 +0000

Docker for Beginners: Images, Containers, Ports, and Volumes Explained

If you've ever followed a programming tutorial and seen something like:

docker run ...

you've probably wondered:

What exactly is Docker doing?

I had the same question when I started learning Docker.

At first, I thought Docker was simply a way to "run applications in containers."

But there is much more to it.

Once I understood four concepts — images, containers, ports, and volumes — Docker became much easier to understand.

So let's break it down from the beginning.

What Is Docker?

Docker is a platform for building, packaging, and running applications in isolated environments called containers.

The basic idea is simple:

Package an application together with the things it needs to run, and make that package portable.

For example, imagine you build a Python application.

Your application might depend on:

Python 3.12
FastAPI
Uvicorn
Several Python packages
Environment variables
Certain system libraries

On your computer, everything works.

Then someone else downloads your project.

They install a different Python version.

A package is missing.

Something behaves differently.

Now you have:

"It works on my machine."

Docker helps reduce this problem by allowing you to define the environment your application should run in.

The Four Concepts You Need to Understand

Before learning Docker commands, understand these four things:

Docker Image
      ↓
Docker Container
      ↓
Ports
      ↓
Volumes

Let's look at each one.

1. What Is a Docker Image?

A Docker image is a packaged, read-only template used to create containers.

Think of it like a blueprint.

For example:

Docker Image
│
├── Ubuntu
├── Python
├── Application code
├── Dependencies
└── Configuration

An image contains the instructions and filesystem needed to create a container.

You can download images from container registries such as Docker Hub.

For example:

docker pull nginx

This downloads the Nginx image.

You can see your downloaded images with:

docker images

You might see something like:

REPOSITORY    TAG       IMAGE ID       SIZE
nginx         latest    abc123...      ...

2. What Is a Container?

A container is a running instance of an image.

This distinction is important.

Think about it like this:

Image       = Blueprint
Container   = Running thing created from the blueprint

For example:

docker run nginx

Docker takes the Nginx image and creates a container from it.

You can see running containers with:

docker ps

To see both running and stopped containers:

docker ps -a

You might see:

CONTAINER ID   IMAGE   STATUS
abc123         nginx   Up 2 minutes

Image vs Container

This is one of the most important Docker concepts.

Image	Container
Template	Running instance
Read-only	Has a writable container layer
Used to create containers	Created from an image
Can be stored in a registry	Exists on your Docker host

A single image can be used to create multiple containers.

For example:

          Nginx Image
          /    |    \
         /     |     \
        ↓      ↓      ↓
   Container  Container  Container

3. What Are Ports?

Here's where Docker can initially feel confusing.

Suppose you have a web application running inside a container.

Your application might listen on:

Port 8000

But that port belongs to the container's network environment.

Your browser needs a way to access it from your computer.

That's where port mapping comes in.

For example:

docker run -p 8080:80 nginx

This means:

Your computer       Container
     8080      →       80

So when you visit:

http://localhost:8080

Docker forwards the traffic to port 80 inside the container.

The general syntax is:

-p HOST_PORT:CONTAINER_PORT

For example:

-p 8080:80

means:

Host:      8080
Container: 80

This distinction is extremely important when working with web applications.

4. What Are Volumes?

Containers are designed to be replaceable.

But sometimes your application needs to keep data.

Imagine you run a PostgreSQL database inside a container.

If the container is removed, you don't want your database data to disappear with it.

That's where volumes come in.

A volume stores persistent data outside the container's writable layer.

You can create one with:

docker volume create mydata

Then attach it to a container:

docker run -v mydata:/data some-image

Conceptually:

Container
    │
    │ writes data
    ↓
 Docker Volume
    │
    ↓
Persistent storage

So even if the container is removed, the volume can remain.

Let's Run Our First Container

Let's start with something simple.

Run:

docker run hello-world

Docker will:

Look for the hello-world image locally.
Download it if necessary.
Create a container from the image.
Start the container.
The container prints its message.
The process exits.

You can check what happened with:

docker ps -a

You'll see the container even though it has stopped.

This was one of the first Docker commands I tried while learning Docker.

Running Nginx

Let's try something that stays running.

Run:

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

Let's break this command down.

docker run

Create and start a container.

-d

Run it in detached mode, meaning the container runs in the background.

-p 8080:80

Map port 8080 on your computer to port 80 in the container.

--name my-nginx

Give the container a memorable name.

nginx

Use the Nginx image.

Now open:

http://localhost:8080

You should see the Nginx welcome page.

Managing the Container

See running containers:

docker ps

Stop the container:

docker stop my-nginx

Start it again:

docker start my-nginx

Remove it:

docker rm my-nginx

See its logs:

docker logs my-nginx

Inspect detailed information:

docker inspect my-nginx

These commands are worth learning because you'll use them constantly.

Where Does the Nginx Image Come From?

When you run:

docker run nginx

Docker first checks whether the image exists locally.

If it doesn't, Docker pulls the image from a container registry.

The general workflow looks like this:

Docker Hub
    │
    │ docker pull
    ↓
Docker Image
    │
    │ docker run
    ↓
Docker Container

A registry is essentially a place where container images can be stored and distributed.

What Is a Dockerfile?

So far we've been using existing images.

But what if we want to package our own application?

That's where a Dockerfile comes in.

A Dockerfile is a text file containing instructions for building a Docker image.

For example:

FROM python:3.12

WORKDIR /app

COPY . .

RUN pip install -r requirements.txt

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

Let's understand it.

FROM

FROM python:3.12

This specifies the base image.

We're starting with a Python 3.12 environment.

WORKDIR

WORKDIR /app

This sets the working directory inside the image.

COPY

COPY . .

This copies files from our project into the image.

RUN

RUN pip install -r requirements.txt

This executes a command while the image is being built.

Here, we're installing Python dependencies.

CMD

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

This specifies the default command that runs when a container starts from the image.

Building Our Own Image

Suppose our project looks like this:

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

From inside the project directory, run:

docker build -t my-python-app .

The -t option gives the image a name.

The . tells Docker to use the current directory as the build context.

Now check your images:

docker images

You should see:

my-python-app

We can now create a container from it:

docker run my-python-app

The Docker Workflow

At this point, the whole process starts to make sense.

             Dockerfile
                 │
                 │ docker build
                 ↓
            Docker Image
                 │
                 │ docker run
                 ↓
           Docker Container
                 │
          ┌──────┴──────┐
          ↓             ↓
        Ports         Volumes
          ↓             ↓
       Network       Persistent
       access          data

This is the mental model I wish I had when I first started learning Docker.

A Simple Mental Model

If you remember nothing else from this article, remember this:

Dockerfile

Instructions for building an image.

Image

A packaged template for an application.

Container

A running instance of an image.

Port

A way to make a container's network service accessible.

Volume

Persistent storage that can outlive a container.

The Commands I Would Learn First

You don't need to memorize every Docker command.

Start with these:

docker --version

docker pull IMAGE

docker images

docker run IMAGE

docker ps

docker ps -a

docker stop CONTAINER

docker start CONTAINER

docker logs CONTAINER

docker exec -it CONTAINER bash

docker build -t IMAGE .

docker rm CONTAINER

docker rmi IMAGE

docker volume ls

Once these become familiar, learning more Docker features becomes much easier.

What I Learned

The biggest thing I learned while starting Docker is that the commands aren't the difficult part.

The mental model is.

Once I understood:

Dockerfile
    ↓
Image
    ↓
Container
    ↓
Ports + Volumes

the commands started making much more sense.

Docker stopped feeling like a collection of random commands and started feeling like a system.

What's Next?

This is only the beginning.

The next step for me is taking something I've actually built and putting it inside a container.

For example:

FastAPI Application
        ↓
     Dockerfile
        ↓
   Docker Image
        ↓
    Container
        ↓
      Port
        ↓
    Web API

That's where Docker becomes much more interesting.

Final Thoughts

If you're learning Docker right now, don't try to memorize 100 commands.

Start with the fundamentals:

Images → Containers → Ports → Volumes

Understand what each one does.

Then build something.

That's when Docker starts to click.

What About You?

When did Docker finally start making sense to you?

And if you're just starting:

What part of Docker is confusing you right now?

I'd be interested to hear about it in the comments.

This is the second article in my journey toward building a modern development environment.

Part 1: From Windows to WSL (Ubuntu) + Docker

More articles coming as I learn and build.

I Switched from Windows to WSL for Development—Here's What Changed

Chetan Inaganti — Wed, 05 Aug 2026 13:01:49 +0000

I Switched from Windows to WSL for Development—Here's What Changed

After years of developing directly on Windows, I finally switched to Windows Subsystem for Linux (WSL). I expected a small improvement—but it completely changed how I build software.

Why I Decided to Switch

I'm a third-year Computer Science student who spends most of my time building projects in Python, FastAPI, AI, Docker, and Android development.

As my projects became larger, I noticed something interesting:

Almost every tutorial, GitHub repository, and deployment guide assumed I was using Linux.

While Windows worked fine, I often had to find Windows-specific fixes or modify commands before they would work.

I wanted an environment that matched what developers actually use in production.

That's when I decided to install Windows Subsystem for Linux (WSL).

My Development Setup

Here's my current setup:

💻 Windows 11
🐧 Ubuntu running inside WSL
💙 VS Code with the Remote - WSL extension
🐳 Docker Desktop
🐍 Python
⚡ FastAPI
🌿 Git & GitHub

Now I can enjoy Windows for everyday tasks while developing inside a real Linux environment.

Best of both worlds.

What Improved

1. Everything Feels More Natural

Most developer documentation is written for Linux.

Instead of translating every command, I can simply copy and paste commands directly from tutorials.

Examples like:

sudo apt update
sudo apt install
chmod +x
ssh
curl

work exactly as expected.

That alone has saved me a surprising amount of time.

2. Docker Finally Made Sense

I recently started learning Docker.

Almost every Docker tutorial assumes you're running Linux.

Inside WSL, Docker behaves exactly the way the documentation expects.

Creating images, running containers, mounting volumes, and using the terminal all feel much more straightforward.

3. VS Code Integration Is Excellent

One feature I didn't expect to enjoy this much was VS Code's Remote - WSL extension.

Opening a project inside WSL automatically gives me:

Linux terminal
Linux Python interpreter
Linux Git
Linux Docker
Better compatibility with development tools

without ever leaving VS Code.

It feels almost like using a native Linux machine.

4. Learning Linux Became Easier

Before switching, Linux was just another subject I wanted to learn.

Now I use it every day.

Simple commands like:

ls
cd
pwd
mkdir
cp
mv
grep
find

have become part of my daily workflow.

The best way to learn Linux is by actually using it.

5. My Development Workflow Feels Cleaner

Instead of installing every tool directly on Windows, I now keep my development environment inside Linux.

That separation makes everything feel more organized.

It also gives me more confidence that my projects will behave similarly when deployed to cloud servers.

Challenges I Faced

The transition wasn't completely smooth.

Some things confused me at first:

Understanding Linux file paths
File permissions
WSL networking
Docker permissions
Knowing whether files lived in Windows or Linux

Fortunately, most of these issues were solved after spending a little time reading the documentation and experimenting.

What I'm Learning Next

Now that my environment is ready, I'm focusing on:

Docker
FastAPI
Machine Learning
AI Agents
System Design
Open Source

Having a proper Linux development environment makes learning these technologies much easier.

My Advice for Students

If you're a Computer Science student interested in:

Backend Development
Artificial Intelligence
Machine Learning
DevOps
Cloud Computing
Open Source

I genuinely think learning WSL is worth the effort.

You don't need to replace Windows.

You simply gain access to a Linux environment that integrates beautifully with your existing workflow.

Final Thoughts

Switching to WSL wasn't just about installing another tool.

It changed how I approach software development.

I'm still learning every day, but moving closer to a Linux-based workflow has already made me more comfortable with modern development tools.

If you're thinking about making the switch, I'd say give it a try.

You might be surprised by how quickly it becomes part of your daily routine.

What About You?

Do you develop on Windows, Linux, or macOS?
Have you tried WSL?
What's one tool that improved your workflow the most?

I'd love to hear your experiences in the comments.

Happy coding! 🚀

Tags

#wsl #linux #docker #python

Building My Neon Cyberpunk AI Portfolio from Scratch – A 2nd-Year CS Student's Glow-Up Journey✨

Chetan Inaganti — Thu, 12 Feb 2026 20:29:11 +0000

Hey dev fam! 👋 I'm Chetan Inaganti, a 2nd-year B.Tech Computer Science Engineering student at Sir Padampat Singhania University (SPSU). Deep into edtech, databases, and AI. Always learning—blending class theory with real builds in creative collabs.

Hunting strong 2026 internships/roles while sharing my journey on dev.to. If you're a student grinding portfolios, this is your guide—I went from empty GitHub to a futuristic neon site that screams "hire me." Let's break it down basics-first, with code, so you can build yours and level up.

Live demo: https://chetan-code-lrca.github.io/Portfolio/
Repo: https://github.com/Chetan-code-lrca/Portfolio

Why I Built This (The Career Glow-Up Motivation)
As a 2nd-year, resumes feel flat—recruiters want proof you ship. Inspired by dev.to posts like Scrimba's minimal examples, I aimed for unique: Neon cyberpunk to stand out in India's AI scene (most are plain white). Zero backend, pure HTML/CSS for speed—loads <1s on 4G.

Step 1: Basics – Setup & Structure (Even If Easy, Start Here)
Cloned my empty repo in VS Code: git clone https://github.com/Chetan-code-lrca/Portfolio
Created files: index.html, style.css, images/ folder (tinypng.com for compression).
Core HTML with div sections (modular for easy updates)

Step 2: Neon Magic CSS (Cyberpunk Vibe)
Dark void (#0a0015), cyan glows (#00f0ff), right-to-left marquee. Hover pause for UX.

Step 3: Real Content (Photo, Certs, Projects)

Photo: Neon-bordered in hero.
Certs: 7 scrolling (ICIP, AMD Slingshot, Road Safety, ICC, RedHat Linux, etc.)—duplicated for seamless loop.
Projects: Rajasthan Helper (screenshot + GitHub) + placeholders. Update via simple edit/push.

Deploy: GitHub Pages (Settings > Pages > main/root > Save).

Unique twist: Cyberpunk over minimal—stands out, got me hackathon nods.

Roast zone: Too neon? Marquee laggy? What's weak—hit comments! Open to collabs.
Thanks for reading—star the repo if inspired. What's your portfolio story?

AI #MachineLearning #Portfolio #WebDev #CodingJourney

Hello DEV! 👋 I'm Chetan – Student Learning ML, Python & AI One Project at a Time

Chetan Inaganti — Wed, 11 Feb 2026 16:34:32 +0000

Hello DEV community! 👋

I'm Chetan Inaganti from Udaipur, Rajasthan 🇮🇳. I'm currently a student at Sir Padampat Singhania University (SPSU), where I'm balancing college coursework with self-learning in software development and AI/ML.

No prior formal coding background—just genuine excitement about how technology can solve everyday problems. I started this journey because I believe building smart applications (maybe even tools for local challenges in Rajasthan) can make a real difference one day.

Right now, I'm focusing on:

Python fundamentals and introductory machine learning (starting with scikit-learn for simple models)
C++ to build strong logic and understand OOP deeply
Creating small projects to turn theory into practice (not just watching tutorials)
Daily Git/GitHub commits to build consistency and track everything

My early wins:

Set up a pythonAI repo with basic ML experiments (simple predictions and data handling) → github.com/Chetan-code-lrca/pythonAI
Worked on OOP concepts (classes, inheritance) in CPP_using_OOP repo
Built a few personal GitHub Pages sites to learn HTML/CSS basics

Some beginner struggles (lessons learned):

Wasted hours debugging "ModuleNotFoundError: No module named 'numpy'" — classic forget-to-install mistake 😂
Got overwhelmed jumping between too many courses; now I stick to one resource until it clicks
Messed up my first few Git pushes (wrong branch panic) — branching is my friend now

I'm planning to share my honest progress here: what I'm building, code that works (and what doesn't), small snippets, and questions when I'm stuck. Whether you're a beginner in the same boat or someone with experience willing to share tips, I'd love to connect.

What was your biggest early coding hurdle? Any beginner-friendly ML or Python project ideas that helped you level up?

GitHub: github.com/Chetan-code-lrca

LinkedIn: linkedin.com/in/chetan-inaganti-563a41322

X: @Chetan007329

Thank you for reading — excited to learn and grow with this community! 🚀

Rajasthan Helper CLI – Real Weather, Festivals & Travel Tips Built on Free GitHub Copilot CLI

Chetan Inaganti — Mon, 09 Feb 2026 17:31:45 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Rajasthan Helper CLI — a colorful, terminal-first tool that brings Rajasthan/India travel info right to your command line:

weather [city] — real-time weather using free wttr.in API (temp, condition, feels-like, humidity, wind)
festival [month] — major Rajasthan festivals with facts and emojis (Holi, Diwali, Teej, Pushkar Fair, etc.)
tip [city] — curated travel & food tips for 10+ cities (Jaipur, Udaipur, Delhi, Jodhpur, Jaisalmer…)

Built entirely on the free tier of GitHub Copilot CLI in ~20 smart prompts — no paid subscription, no credit card.

It means a lot to me because it combines my love for Rajasthan culture with real dev skills (API integration, rich terminal UI, packaging).

Demo

(Shows --help, colorful weather panel for Jaipur, Holi festival card, Udaipur travel tips list)

My Experience with GitHub Copilot CLI

I started from zero: installed via npm install -g @github/copilot, login to my free GitHub account, ran /init to create instructions.md for consistent style.

Then I used one big prompt to generate the Click + rich structure, debugged packaging nightmares (TOML duplicates, missing folders, import errors) with targeted follow-ups, and finished with API + rich formatting.

Total: ~20 prompts.

The biggest surprise? How fast I went from nothing to a real, working CLI with API calls and beautiful output — all for free. It completely changed how I think about building tools.

Repo: https://github.com/Chetan-code-lrca/rajasthan-helper

Thanks for the challenge — this was an amazing learning journey!

Made by Chetan Inaganti (@Chetan007329)

DEV Community: Chetan Inaganti

Docker for Beginners: Images, Containers, Ports, and Volumes Explained

Docker for Beginners: Images, Containers, Ports, and Volumes Explained

What Is Docker?

The Four Concepts You Need to Understand

1. What Is a Docker Image?

2. What Is a Container?

Image vs Container

3. What Are Ports?

4. What Are Volumes?

Let's Run Our First Container

Running Nginx

Managing the Container

Where Does the Nginx Image Come From?

What Is a Dockerfile?

FROM

WORKDIR

COPY

RUN

CMD

Building Our Own Image

The Docker Workflow

A Simple Mental Model

Dockerfile

Image

Container

Port

Volume

The Commands I Would Learn First

What I Learned

What's Next?

Final Thoughts

What About You?

Related

I Switched from Windows to WSL for Development—Here's What Changed

I Switched from Windows to WSL for Development—Here's What Changed

Why I Decided to Switch

My Development Setup

What Improved

1. Everything Feels More Natural

2. Docker Finally Made Sense

3. VS Code Integration Is Excellent

4. Learning Linux Became Easier

5. My Development Workflow Feels Cleaner

Challenges I Faced

What I'm Learning Next

My Advice for Students

Final Thoughts

What About You?

Building My Neon Cyberpunk AI Portfolio from Scratch – A 2nd-Year CS Student's Glow-Up Journey✨

AI #MachineLearning #Portfolio #WebDev #CodingJourney

Hello DEV! 👋 I'm Chetan – Student Learning ML, Python & AI One Project at a Time

Rajasthan Helper CLI – Real Weather, Festivals & Travel Tips Built on Free GitHub Copilot CLI

What I Built

Demo

My Experience with GitHub Copilot CLI