Software fundamentals

Docker

Docker packages software with the environment it needs so the software can run more consistently across different computers and stages of delivery.

Why Docker matters to technical marketers

You do not need to become a container infrastructure expert to market a technical product. You do need enough of a mental model to understand what customers, developers, and product teams mean when they talk about images, containers, registries, ports, and deployment.

Docker appears throughout the customer journey for software products. It can shape how someone evaluates a product, starts a trial, follows a tutorial, builds a demo, tests an integration, or deploys an application.

Write clearer content

Understand what installation instructions actually do instead of treating Docker commands as unexplained setup steps.

Design better demos

Recognize why a product team may use containers to make a demo repeatable and easier to reset.

Understand adoption friction

See where users may encounter image downloads, port conflicts, configuration mistakes, or missing persistent storage.

Communicate with technical teams

Ask more precise questions about packaging, local development, testing, deployment, and product distribution.

Marketing connection: Docker is often part of the product experience. A confusing container setup can weaken activation even when the product itself is excellent.

The problem Docker solves

Software rarely consists of application code alone. It may also depend on a particular programming language version, system libraries, operating system tools, configuration values, and other services.

A developer might create an application on one computer and then try to run it on a teammate’s laptop, a testing server, or a production system. Differences between those environments can cause the application to behave differently or fail completely.

Code and environment are different things

Code contains the instructions written by developers. The runtime environment contains the surrounding software and configuration required to execute those instructions.

For example, a web application might need:

The application’s source code
A specific version of Python, Node.js, Java, or another runtime
Third-party libraries
Operating system packages
Configuration values
A database or another supporting service

Copying only the source code does not guarantee that the destination computer has the correct environment.

The “works on my machine” problem

“Works on my machine” describes a common situation: software works on the developer’s computer but fails somewhere else because the two environments are not equivalent.

One machine might have a newer language version. Another might be missing a system library. A testing server might use a different configuration value. Small differences can produce large and frustrating results.

Docker’s core idea: Package the application and much of its required environment into a defined, portable unit rather than rebuilding that environment manually on every machine.

What a container is

A container is an isolated process that runs an application with a defined filesystem, dependencies, and configuration. It runs on a host computer but is separated from other processes in important ways.

A shipping container is a useful analogy. Different goods can be packed into standardized containers, and ports can handle those containers through a common process. In Docker, the standardized unit holds software rather than physical cargo.

The analogy has limits. A Docker container is not a heavy metal box and it is not a complete computer. Technically, it is a process isolated through operating system features. It generally shares the host system’s kernel rather than bringing an entire operating system with it.

What isolation gives you

A separate filesystem view for the application
A controlled set of installed dependencies
A defined network interface
A repeatable starting state
Reduced interference between different applications

Important: Isolation is not the same as complete independence. Containers still use host resources such as CPU, memory, storage, networking, and the host operating system’s kernel.

What an image is

A Docker image is a packaged, read-only template containing the files and instructions needed to start a container.

An image can include:

A base filesystem
A runtime such as Node.js or Python
Application files
Installed dependencies
A default command to run
Metadata describing how the image should behave

Image versus container

A useful analogy is a class and an instance, or a blueprint and a constructed object. The image defines what should exist. The container is a running—or stopped—instance created from that definition.

Image	Container
A packaged template	An instance created from that template
Normally read-only	Has a temporary writable layer
Can be stored in a registry	Runs on a host system
Can create many containers	Has its own name, state, and lifecycle

One image can be used to start many containers. Those containers begin from the same packaged definition but run as separate processes.

What a Dockerfile is

A Dockerfile is a text file containing instructions for building a Docker image. It makes the image-building process visible, repeatable, and reviewable.

A simplified Dockerfile for a static website could look like this:

FROM nginx:alpine

COPY . /usr/share/nginx/html

The first instruction selects an existing image that already contains the Nginx web server. The second copies website files into the location that Nginx serves.

Building this Dockerfile would produce a new image containing both the web server and the website files.

For Marketer Lab: This example is for understanding the model. Your current Cloudflare Pages setup already publishes the static files directly, so adding Docker to this website would introduce complexity without solving a current problem.

Container registries and Docker Hub

A container registry stores and distributes container images. It gives teams a central place to publish images and allows other systems to download them.

The relationship is similar to GitHub and Git repositories, but the stored artifact is different:

GitHub commonly stores source code and its change history.
A container registry stores built container images.

Docker Hub is a widely used public container registry. It hosts official images, vendor images, community images, and private repositories.

Other registries include GitHub Container Registry and registries provided by major cloud platforms. Organizations may also operate private registries.

Image names and tags

Images are usually identified with a repository name and a tag:

postgres:17

In this example, postgres is the image repository and 17 is the tag. A tag usually identifies a version or variant, but it is a movable label rather than a guarantee that the underlying image will never change.

You may also see:

postgres:17-alpine

This name describes a PostgreSQL 17 image built on a smaller Alpine Linux base.

Containers versus virtual machines

Containers and virtual machines both create separation, but they operate at different levels.

Containers	Virtual machines
Isolate processes	Virtualize complete computers
Share the host operating system kernel	Run a guest operating system with its own kernel
Usually start quickly	Usually take longer to start
Often use fewer resources	Usually require more memory and storage
Package an application and its userspace dependencies	Package an entire operating system environment

A virtual machine is closer to renting a separate furnished apartment with its own utilities. A container is closer to having an isolated workspace inside a shared building.

The technical connection is that a virtual machine includes a guest operating system, while containers usually share the host kernel. That shared foundation is one reason containers can be smaller and faster to start.

Not competitors in every situation: Containers often run inside virtual machines in cloud environments. The virtual machine provides the host, and the containers package individual applications.

Ports

A port is a numbered network endpoint. Applications listen on ports so other applications or users can connect to them.

A web server inside a container might listen on port 80. The container can map that internal port to a different port on the host computer, such as 8080.

Host computer: localhost:8080
                     ↓
Container:           port 80

The host port is what you use from your browser. The container port is where the application listens inside the container.

This separation lets multiple containers use the same internal port while exposing different host ports.

Common source of friction: Two applications cannot normally claim the same host port at the same time. When a tutorial says that a port is already in use, another process is probably using it.

Environment variables

Environment variables are named values supplied to a running process. Applications use them for configuration that may differ between environments.

Examples include:

APP_ENV=development
DATABASE_HOST=database
LOG_LEVEL=debug
API_URL=https://example.com

Keeping configuration separate from the image allows the same image to run with different settings in development, testing, and production.

Think of the image as a stage production and environment variables as instructions given for tonight’s performance. The underlying production remains the same, but certain details can change.

In technical terms, environment variables are passed into the container when it starts and are read by the application at runtime.

Security note: Environment variables are commonly used for secrets, but they do not automatically make secrets secure. Teams still need appropriate secret-management practices and access controls.

Volumes and persistent data

A container has a writable layer, but that layer is closely tied to the container. If the container is deleted, data stored only in that layer may be lost.

A volume stores data outside the container’s temporary writable layer. The volume can remain available even when a container is replaced.

Think of a container as a rented workspace and a volume as a storage locker outside that workspace. You can replace the workspace while keeping the contents of the locker.

Technically, Docker mounts the external storage into a location inside the container’s filesystem. The application reads and writes that location as though it were a normal folder.

Why this matters for databases

A database’s main job is to retain data. Running a database container without persistent storage means deleting the container could also delete the database files.

A volume lets the database process run in a replaceable container while its data survives separately.

Why databases often run in containers during local development

Developers frequently need databases such as PostgreSQL, MySQL, Redis, or ClickHouse while building an application. Installing and configuring each database directly on a laptop can create version conflicts and cleanup problems.

A container can provide a defined database version with a predictable configuration. A developer can start it when needed and remove the container when the project is finished.

Known version

The project can specify which database image and version it expects.

Less host setup

The database does not need to be installed directly into the laptop’s main operating system.

Repeatable onboarding

Team members can start from a more consistent database environment.

Easier cleanup

The container can be removed without manually uninstalling the database software.

Volumes are usually added when the local database data needs to survive container replacement.

Important distinction: Running a database in a container does not remove the need to understand database configuration, backups, security, memory use, or production operations.

Where containers are useful

Development

Containers can provide local databases, message queues, search engines, or complete application environments without installing every dependency directly on the developer’s computer.

Testing

Automated tests can start from defined images, reducing differences between test runs. A test system can create a temporary dependency, run the tests, and remove the container afterward.

Deployment

Teams can build an image once, test that image, store it in a registry, and deploy containers created from the same image. This reduces the risk of rebuilding the application differently at each stage.

Demos and tutorials

Containers can package a product with its dependencies so prospects, partners, or workshop participants can start a known environment more quickly.

This can be especially valuable for technical marketing because a repeatable demo protects the story being told. The audience spends less time diagnosing machine-specific setup problems.

A simple Docker workflow

Docker workflows vary, but the basic flow is:

Write or obtain a Dockerfile. The Dockerfile describes how to assemble an image.
Build an image. Docker follows the Dockerfile instructions and packages the result.
Run a container. Docker creates a container from the image and starts its main process.
Configure access. Ports, environment variables, and volumes connect the container to the outside world.
Test the running application. A person or automated system checks its behavior.
Publish the image when needed. The image is pushed to a registry so another machine can retrieve it.
Pull and run the image elsewhere. A testing or deployment system downloads the image and creates a new container from it.

Dockerfile
    ↓
Build
    ↓
Image
    ↓
Push to registry
    ↓
Pull onto another host
    ↓
Run container

A small local experiment may use only an existing image and a running container. A production workflow may involve automated builds, security scanning, private registries, orchestration systems, and multiple deployment environments.

What Docker does not do

Docker solves important packaging and runtime problems, but it is not a complete software delivery strategy.

Docker does not write the application. The code still needs to be designed, implemented, and tested.
Docker does not guarantee that software is correct. A container can package broken code consistently.
Docker does not make an application secure by default. Images, dependencies, permissions, secrets, networks, and hosts still require security work.
Docker does not automatically deploy or scale an application. Other systems and processes decide where containers run and how many are needed.
Docker does not preserve data automatically. Persistent data must be designed and stored appropriately.
Docker does not remove operating system differences completely. Containers depend on host capabilities, CPU architecture, and kernel compatibility.
Docker does not replace Git or GitHub. Git tracks source changes. A registry distributes built images.
Docker does not replace hosting. A container still needs a computer or platform on which to run.

Mental model: Docker packages and runs software. It does not replace every other part of building, testing, deploying, hosting, or operating that software.

Common Docker vocabulary

Docker: A platform and toolset for building, distributing, and running container images.
Container: An isolated process created from an image.
Image: A packaged, read-only template used to create containers.
Dockerfile: A text file containing instructions for building an image.
Build: The process of turning a Dockerfile and its supporting files into an image.
Registry: A service that stores and distributes container images.
Docker Hub: A widely used container registry operated as part of the Docker ecosystem.
Repository: A collection of related images in a registry, usually distinguished by tags.
Tag: A human-readable label for an image version or variant, such as 17 or latest.
Pull: Download an image from a registry.
Push: Upload an image to a registry.
Port mapping: A connection between a port on the host and a port inside a container.
Environment variable: A named runtime configuration value supplied to a process.
Volume: Storage managed outside a container’s temporary writable layer.
Host: The computer or virtual machine on which containers run.

Hands-on exercise: design a container mental model

You do not need to install Docker for this exercise. At this stage, the valuable skill is being able to inspect a product setup and identify the parts of the container model.

Scenario

Imagine Marketer Lab later gains a small application that saves lesson progress in PostgreSQL. A developer proposes this local setup:

The application code remains in the GitHub repository.
A Dockerfile describes the application image.
A PostgreSQL image is downloaded from Docker Hub.
One container runs the application.
Another container runs PostgreSQL.
The application is available at localhost:8080.
The application receives its database address through an environment variable.
A volume stores the PostgreSQL data.

Your task

Create a new feature branch through the GitHub web interface and add a section to this page titled My Docker Model. In that section, explain the scenario in your own words using one short paragraph and the following list:

Which artifact contains the application source code?
Which file describes how the application image is built?
Which two images are involved?
Which two containers are running?
What does port 8080 make accessible?
What configuration belongs in an environment variable?
Which data needs a volume, and why?
Which artifact would be pushed to a container registry?

Architecture challenge: Do not containerize the current static Marketer Lab website as part of this exercise. Cloudflare Pages already serves the HTML files directly. Docker would add a build and runtime layer without providing a current product benefit.

Purpose of the file

website/docker.html is a standalone lesson page. It contains its own semantic HTML structure, lesson content, metadata, and presentation rules so it can be deployed directly by the current Cloudflare Pages configuration.

Purpose of the folder

The website/ folder is the build output directory configured in Cloudflare Pages. Files placed in this folder are part of the public website after the selected production branch is deployed.

Key takeaways

Software needs both code and a compatible runtime environment.
Docker helps package an application with much of the environment it needs.
An image is a packaged template; a container is an instance created from that image.
A Dockerfile describes how to build an image.
A registry stores and distributes images, and Docker Hub is one example.
Ports expose containerized services to other systems.
Environment variables provide runtime configuration.
Volumes allow important data to survive container replacement.
Containers are useful across development, testing, deployment, and demos.
Containers share the host kernel, while virtual machines include guest operating systems.
Docker packages and runs software, but it does not replace Git, deployment systems, hosting, security practices, or application design.
Marketer Lab does not currently need Docker in its architecture.

← Back to Learning Path