Sitemap

Docker — The short rundown

4 min readFeb 7, 2026

--

Docker containers are isolated processes that run applications in a lightweight environment. Docker containers are considered lightweight because they share the host OS kernel, don’t include a full operating system. Containers start fasters and are resource-efficient(uses less CPU, RAM and disk than VMs). Virtual machines have their own kernel and a full guest operating system. The OS inside a Docker container must be compatible with the host OS kernel(for example, Linux containers require a Linux kernel). A container exists as long as its main process is running. If that process stops, the container exits. A process running inside a Docker container is assigned a PID within the container’s namespace, but it is also visible on the host system with a different PID.

DOCKER                         VIRTUAL MACHINE

App Ap & Libraries
Libraries Guest OS (own kernal)
Docker Engine Hypervisor
Host Kernel Host Kernel
Hardware Hardware

Docker Networks

There are 3 possible networks: Bridge, None and Host.
Bridge is the default network mode. In Bridge mode, each container runs in its own network namespace(its own IP addresses, interfaces, routing table, ports, firewall rules and DNS settings) and gets a private internal IP address, usually in the 172.17.*.* range. Containers connected to the same bridge network can communicate with each other and they can refer to one another by container name. Multiple containers can run applications on the same internal port because each container has its own isolated network stack. However, to access a container from outside, you must explicitly map its internal port to a port on the host server:
docker run -p <hostPort>:<containerPort>.

None mode disables networking completely. The container has no external network access and cannot communicate with other container or the outside world. This network can be used for running security critical tasks.

Host mode removes network isolation between the container and the host. The container shares the host’s network stack, so ports are not mapped, they are directly exposed on the host. As a result, multiple containers cannot run applications on the same port because they would conflict with each other on the host network.

Dockerfile is a recipe for building a Docker image.

# Start from a base image
FROM openjdk:17-jdk-slim

# Set working directory inside the container
WORKDIR /app

# Copy files from host to container
COPY target/my-app.jar app.jar

# Expose application port
EXPOSE 8080

# Command to run when container starts
CMD ["java", "-jar", "app.jar"]

CMD specifies the default command that runs when a container starts. This command becomes the main process of the container.

Both syntaxes are supported:
CMD command arg1 arg2 or CMD [“command”, “arg1”, “arg1”]

Get DevNotes’s stories in your inbox

Join Medium for free to get updates from this writer.

If you run a container like this:
docker run <image> <command> <arg1>
the command provided at runtime overrides the CMD instruction defined in the Dockerfile.

FROM ubuntu

# sleep 5
ENTRYPOINT ["sleep"]
CMD ["5"]

ENTRYPOINT defines the command that runs when a container starts.

When you run: docker run <image> <arg1>, the arguments provided after the image name are appended to the ENTRYPOINT command defined in the Dockerfile.

If both ENTRYPOINT and CMD are defined, the CMD values act as default arguments for ENTRYPOINT and can be overriden by providing arguments at runtime.

To override the ENTRYPOINT instruction itself, you can use:
docker run --entrypoint <command> <image> <arg>.

In Docker, a volume defines a mount point in the container. It tells Docker that a certain directory should store data outside the container. This is useful when you want to persist data so it is not lost if the container is removed.

You can create a named volume (located under /var/lib/docker/volumes as it is managed by docker) using the -v flag:
docker volume create <volume-name>
docker run -v <volume-name>:<containerPath> <image>

Alternatively, you can use the --mount syntax for more explicit control:
docker run --mount type=bind, source=<hostPath>, target=<containerPath> <image>

Docker commands

# Build an image from a Dockerfile in the current directory
docker build -t <image> .

# Run a container from an image
docker run <image>

# Set environment variables
docker run -e <ENV_VAR>=<value> <image>

# Use the host network
docker run --network=host <image>

# Connect to a Docker daemon on another host
docker -H <host:port> run <image>

# limit cpu and memory usage
docker run --cpus=".5" <image>
docker run --memory="100m" <image>

# Run a container in detached mode with port mapping
docker run -d -p <host-port>:<container-port> --name registry <image>


docker inspect <image> # Inspect image or container details
docker history <image> # Show steps/layers used to build the image


docker ps # Show running containers
docker ps -a # Show all containers (running + stopped)


docker push <remote-host>:<remote-port>/<image>
docker pull <remote-host>:<remote-port>/<image>

# Stop, remove, and manage containers
docker stop <container-id-or-name>
docker rm <container-id-or-name>

docker images # List local images
docker rmi <image> # Remove an image

docker run -d <image> # Run container in detached mode
docker attach <container-id> # Attach to a running container
docker exec -it <image> /bin/bash # Run container interactively with a shell
docker logs <container-id-or-name> # View container logs

--

--