Docker Fundamentals: The Tip of the Iceberg

Source: Dev.to

Introduction

In this AI era, where everything is “AI this” and “AI that,” the industry needs people who can manage, plan, and monitor system architecture more than ever. That’s why I chose to learn something new—SRE, DevOps, and solution architecture—and containerizing apps is just the tip of the iceberg. Docker lets you containerize your app, eliminating the infamous “It works on my machine” problem.

Core Docker Concepts

Images

A Docker image is a packaged application. Think of it like a video‑game disc: the image holds everything needed to run the app.

Containers

A Docker container is the runtime instance of an image—like a PlayStation that runs the disc. Containers share the host OS kernel, making them much smaller than virtual machines, which include a full OS. Typical Docker images and containers are measured in megabytes (MB), whereas VMs are often gigabytes (GB).

Dockerfile

A Dockerfile lives in your project and contains the instructions to build an image. By specifying a base image (e.g., node:xx-alpine, ubuntu:xx) and the steps needed to set up the environment, you can create a reproducible image that other engineers can run without replicating your local setup.

Basic Docker Commands

Run an image (whether you built it or pulled it from Docker Hub):

docker run {image_name}

List currently running containers:

docker ps

List all containers, including stopped ones:

docker ps -a

Build an image from your project (ensure a Dockerfile exists in the directory):

docker build -t my-project .

This creates an image named my-project.

Next Steps

Docker’s capabilities go far beyond these basics. You can orchestrate multiple containers, manage networking, handle storage, and more. I’ll cover those topics in next week’s post about Docker Compose—stay tuned!