Notes on Docker and virtual Machines

Virtual Machines

  • Physical infrastructure sits at the base (your computer or cloud hardware), with an OS on top, and then a hypervisor that enables virtualization.
  • Virtualization lets you run multiple OS instances concurrently on a single machine — e.g. Ubuntu, Fedora, and Arch Linux all running on one Windows host.
  • In the cloud, physical servers are shared hardware. When you provision a VM via a cloud console, you get a guest VM on the hypervisor, while other users get their own separate guest VMs on the same hardware.
  • Each VM has its own binaries, libraries, and application installed on top of it.
  • A virtual machine is a software emulation of a physical machine.
  • VMs are fully isolated from each other and from the host — providing security and stability.

Containers

  • Same physical server underneath, same OS layer on top — but instead of a hypervisor, there’s a container engine.
  • The container engine runs multiple container instances on a single OS kernel (similar to how a hypervisor manages VMs).
  • Containers are a lightweight alternative to VMs — all required libraries and binaries are packed within the container itself.
  • Containers share the host OS kernel, making them more efficient and portable than VMs.

Docker Workflow

1. Dockerfile

  • A set of instructions specifying:
    • Which OS to use as the base image
    • Which dependencies to install
    • Which files to copy and where
    • How to build and run the application

2. Docker Image

  • Created by running docker build against a Dockerfile.
  • Contains built versions of all libraries, dependencies, app code, and the OS.
  • Can be shipped from one environment to another.
  • Note: You ship images, not containers — containers cannot be moved between environments directly.

3. Docker Registry

  • Acts like a version control system (e.g. GitHub) but for images.
  • Images are stored here before being deployed to dev, test, or prod environments.
  • Docker Hub is the default public registry for storing and distributing Docker images.

4. Building & Running in Environments

  • Pull an image from the registry using docker pull.
  • Build and run it in the target environment using docker run.

Docker Architecture

Source Code + Dockerfile
        ↓
   Docker Client
        ↓  (issues command)
   Docker Daemon (dockerd)
        ↓  (builds image)
   Local Docker Host (image stored here)
        ↓  (docker push)
   Image Registry (e.g. Docker Hub)
        ↓  (docker pull on target env)
   Docker Daemon (on target env)
        ↓  (instructs)
   Container Runtime → Container spun up

How it works step by step

  1. You have source code and a Dockerfile locally or on GitHub.
  2. Running docker build sends the command to the Docker daemon (dockerd).
  3. The daemon builds the image using the Dockerfile instructions and stores it locally on the Docker host.
  4. Running docker push sends the image from the local host to the image registry.
  5. On another environment, docker pull fetches the image from the registry.
  6. Running docker run tells the daemon to instruct the container runtime, which spins up the container.

Key Commands

Command Description
docker build Build a Docker image from a Dockerfile
docker push Push a local image to the registry
docker pull Pull an image from the registry to the current environment
docker run Run a container from an image