HowItWorks:Docker - Revision history

Rongzhou: /* Try it yourself */

2026-09-01T21:00:09Z

Try it yourself

← Older revision		Revision as of 21:00, 1 September 2026
Line 253:		Line 253:
	The commands below are drawn from Docker's official documentation, as read on 2026-08-31.		The commands below are drawn from Docker's official documentation, as read on 2026-08-31.

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 1. Confirm the welcome-to-docker image ~~really~~ exists on Docker Hub ~~(live check, 2026-08-31)~~		# 1. Confirm the welcome-to-docker image exists on Docker Hub and view the number of times it has been pulled
	curl -s "https://hub.docker.com/v2/repositories/docker/welcome-to-docker/" \| grep -o '"pull_count":[0-9]*'		curl -s "https://hub.docker.com/v2/repositories/docker/welcome-to-docker/" \| grep -o '"pull_count":[0-9]*'
	</~~pre~~>		</syntaxhighlight>

	Output ~~(verified live)~~:		Output:

	<pre>		<pre>
Line 264:		Line 264:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 2. Start a web server container, publishing port 8080 on the host to port 80 in the container		# 2. Start a web server container, publishing port 8080 on the host to port 80 in the container
	docker run -d -p 8080:80 docker/welcome-to-docker		docker run -d -p 8080:80 docker/welcome-to-docker
	</~~pre~~>		</syntaxhighlight>

	"The output from this command is the full container ID.~~"<ref>{{#cite:Q1408}}</ref> The container now serves a small website at~~ http://localhost:8080.		The output from this command is the full container ID. Visit http://localhost:8080 to see a small website served by this test container.

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 3. List running containers		# 3. List running containers
	docker ps		docker ps
	</~~pre~~>		</syntaxhighlight>

	~~Documented output (IDs and names vary)~~:~~<ref>{{#cite:Q1408}}</ref>~~		Output:

	<pre>		<pre>
Line 283:		Line 283:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 4. ~~Stop~~ the container		# 4. Stopping the container
	docker stop a1f7a4bb3a27		docker stop a1f7a4bb3a27
	</~~pre~~>		</syntaxhighlight>

	"Only enough of the ID to make it unique" is needed — <code>docker stop a1f</code> would do.<ref>{{#cite:Q1408}}</ref>		Only enough of the ID to make it unique is needed. For instance, <code>docker stop a1f</code> would work as long as there is not another active container with an ID beginning with "a1f".<ref>{{#cite:Q1408}}</ref>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 5. Run an interactive Ubuntu shell in a container		# 5. Run an interactive Ubuntu shell in a container
	docker run -i -t ubuntu /bin/bash		docker run -i -t ubuntu /bin/bash
	</~~pre~~>		</syntaxhighlight>

	If the image isn't local, Docker pulls it; then it creates the container, allocates its writable layer, attaches it to the default network, starts it and runs <code>/bin/bash</code> — type <code>exit</code> and the container stops but is not removed.<ref>{{#cite:Q1407}}</ref>		If the image isn't local, Docker pulls it; then it creates the container, allocates its writable layer, attaches it to the default network, starts it and runs <code>/bin/bash</code> — type <code>exit</code> and the container stops but is not removed.<ref>{{#cite:Q1407}}</ref>
Line 299:		Line 299:
	=== 6. Build your own image from a Dockerfile ===		=== 6. Build your own image from a Dockerfile ===

			<syntaxhighlight lang="bash" copy>
	<~~pre~~>
	# 6a. make a dedicated directory and move into it.		# 6a. make a dedicated directory and move into it.
	# That directory will be the build context — files in it (and only in it)		# That directory will be the build context — files in it (and only in it)
	# can be referenced by COPY / ADD instructions.		# can be referenced by COPY / ADD instructions.
	mkdir myapp && cd myapp		mkdir myapp && cd myapp
	</~~pre~~>		</syntaxhighlight>


	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 6b. Create the Dockerfile and the script to be copied into the image.		# 6b. Create the Dockerfile and the script to be copied into the image.
	cat > Dockerfile <<'EOF'		cat > Dockerfile <<'EOF'
Line 323:		Line 322:
	EOF		EOF
	chmod +x app.sh		chmod +x app.sh
	</~~pre~~>		</syntaxhighlight>

	A Dockerfile is "a text file containing instructions for building source code", read top to bottom; the instruction syntax is defined by the Dockerfile reference.<ref>{{#cite:Q1437}}</ref><ref>{{#cite:Q1410}}</ref> Each instruction becomes a layer of the image.<ref>{{#cite:Q1407}}</ref> The essential instructions:		A Dockerfile is "a text file containing instructions for building source code", read top to bottom; the instruction syntax is defined by the Dockerfile reference.<ref>{{#cite:Q1437}}</ref><ref>{{#cite:Q1410}}</ref> Each instruction becomes a layer of the image.<ref>{{#cite:Q1407}}</ref> The essential instructions:
Line 342:		Line 341:
	</blockquote>		</blockquote>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 6c. Build the image		# 6c. Build the image
	docker build -t myapp:latest .		docker build -t myapp:latest .
	</~~pre~~>		</syntaxhighlight>

	<code>-t</code> names and tags the image, the trailing dot selects the build context (the current directory).<ref>{{#cite:Q1437}}</ref> Docker reads the instructions in order; each creates a layer, and unchanged layers are reused from the build cache on the next build.<ref>{{#cite:Q1410}}</ref><ref>{{#cite:Q1407}}</ref>		<code>-t</code> names and tags the image, the trailing dot selects the build context (the current directory).<ref>{{#cite:Q1437}}</ref> Docker reads the instructions in order; each creates a layer, and unchanged layers are reused from the build cache on the next build.<ref>{{#cite:Q1410}}</ref><ref>{{#cite:Q1407}}</ref>

	Output ~~(step numbers, hashes and timings vary)~~:		Output:

	<pre>		<pre>
Line 365:		Line 364:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 6d. Run it: start a container from the image; --rm removes it on exit.		# 6d. Run it: start a container from the image; --rm removes it on exit.
	docker run --rm myapp:latest		docker run --rm myapp:latest
	</~~pre~~>		</syntaxhighlight>

	~~Documented output~~:		Output:

	<pre>		<pre>
Line 376:		Line 375:
	</pre>		</pre>

	<~~pre~~>		<syntaxhighlight lang="bash" copy>
	# 6e. Confirm the image is stored in the local image store.		# 6e. Confirm the image is stored in the local image store.
	docker image ls		docker image ls
	</~~pre~~>		</syntaxhighlight>

	~~Documented output (image ID, age and size vary)~~:~~<ref>{{#cite:Q1437}}</ref>~~		Output:

	<pre>		<pre>

Rongzhou: /* A short history */

2026-09-01T07:16:05Z

A short history

← Older revision		Revision as of 07:16, 1 September 2026
Line 9:		Line 9:
	Programmatically independent but sharing the host's kernel, a Docker container offers the full isolation provided by '''Virtual Machines (VM)''' at a fraction of the resource overhead.<ref>{{#cite:Q1408}}</ref>		Programmatically independent but sharing the host's kernel, a Docker container offers the full isolation provided by '''Virtual Machines (VM)''' at a fraction of the resource overhead.<ref>{{#cite:Q1408}}</ref>

	=== A short history ===		== A short history ==

	Docker was first pioneered by [[Person:Solomon Hykes\|Solomon Hykes]], founder of dotCloud, as an internal project to solve virtualisation bottlenecks for his company's PaaS service.		Docker was first pioneered by [[Person:Solomon Hykes\|Solomon Hykes]], founder of dotCloud, as an internal project to solve virtualisation bottlenecks for his company's PaaS service.

Rongzhou: /* Bundled software, standardized primitives */

2026-09-01T06:49:40Z

Bundled software, standardized primitives

← Older revision		Revision as of 06:49, 1 September 2026
Line 247:		Line 247:
	As can be seen in the [[HowItWorks:Docker#Components_and_interactions\|components and interactions diagram]], Docker has a layered architecture.		As can be seen in the [[HowItWorks:Docker#Components_and_interactions\|components and interactions diagram]], Docker has a layered architecture.

	An important ~~decision~~ leading to Docker's lasting success is ~~that~~ its low-level layers are built as open standards and neutral ~~projects~~:		An important factor leading to Docker's lasting success is its interoperability. Docker's low-level layers are built as open standards and neutral primitives: '''The Open Container Initiative (OCI)''' specifications for runtime, image, and distribution; '''[[FOSS:Containerd\|containerd]]''' for runtime daemon;'''[[FOSS:Runc\|runc]]''' for runtime execution; and '''[[FOSS:BuildKit\|BuildKit]]''' for builder backend. As such a Docker image can be built, distributed and run by any OCI-compliant toolchain with no additional arguments".<ref>{{#cite:Q1418}}</ref>

	* '''The Open Container Initiative (OCI)''' ~~— "a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation,~~ for the express purpose of creating open industry standards around container formats and runtimes".<ref>{{#cite:Q1418}}</ref> Launched on June 22, 2015 by Docker, CoreOS and other container industry leaders, it received Docker's container format and runtime, ~~[[FOSS:Runc\|runc]], as "the cornerstone of this new effort".<ref>{{#cite:Q1418}}</ref> The OCI maintains three specifications:<ref>{{#cite:Q1418}}</ref>~~
	** '''runtime-spec''' — how to run a "filesystem bundle" that is unpacked on disk;
	** '''image-spec''' — how to create an OCI image: "an image ~~manifest, a filesystem (layer) serialization~~, and ~~an image configuration"~~;
	** '''distribution-spec''' — the API to distribute container images, which reached v1.0 in May 2020.
	* '''[[FOSS:Containerd\|containerd]]''' ~~— the container~~ runtime daemon ~~spun out of Docker in 2016<ref>{{#cite:Q1416}}</ref> and accepted into the Cloud Native Computing Foundation (CNCF) in March 2017~~; in February 2019 it became the CNCF's fifth project to graduate, after Kubernetes, Prometheus, Envoy and CoreDNS, with "its widest usage and adoption as the layer between the Docker engine and the OCI runc executor".<ref>{{#cite:Q1439}}</ref>
	* '''[[FOSS:Runc\|runc]]''' ~~— the OCI~~ runtime ~~donated by Docker: a standalone command-line tool that spawns~~ and ~~runs containers according to the OCI specification, the reference implementation of the runtime-spec.<ref>{{#cite:Q1418}}</ref>~~
	* '''[[FOSS:BuildKit\|BuildKit]]''' ~~— "the~~ builder backend ~~used by Docker", itself an independent open-source project developed in the Moby ecosystem (github~~.~~com/moby/buildkit) rather than as~~ a ~~closed part of the engine.<ref>{{#cite:Q1412}}</ref>~~

	~~The payoff is interoperability: the primitives are not~~ Docker~~-specific. Because image formats, runtimes and registries all follow OCI standards, the same~~ image can be built, distributed and run by any OCI-compliant toolchain~~, and the workflow is defined so that it "should support the UX that users have come to expect from container engines like Docker and rkt: primarily, the ability to run an image~~ with no additional arguments".<ref>{{#cite:Q1418}}</ref>

	== Try it yourself ==		== Try it yourself ==

Rongzhou: /* Try it yourself */

2026-09-01T06:40:09Z

Try it yourself

Show changes

RonzzWikiCowriterAI: AI-assisted (RonzzWikiCowriter): expand step 6 (build your own image from a Dockerfile: where to put it, what's in it, how to build) (via update-page on MediaWiki MCP Server)

2026-08-31T17:17:51Z

AI-assisted (RonzzWikiCowriter): expand step 6 (build your own image from a Dockerfile: where to put it, what's in it, how to build) (via update-page on MediaWiki MCP Server)

@@ Line 309: / Line 309: @@
 <syntaxhighlight lang="bash" copy>
 # 6. Build your own image from a Dockerfile
-# Dockerfile:
+#    Where to put the Dockerfile, what's in it, then how to build.
 </syntaxhighlight>
-Docker reads the Dockerfile's instructions in order; each creates a layer, and unchanged layers are reused from the build cache on the next build.<ref>{{#cite:Q1410}}</ref><ref>{{#cite:Q1407}}</ref>
+'''Where to put it.''' The Dockerfile lives in the root of the directory you pass to <code>docker build</code> — that directory is the '''build context''', "the set of files that your build can access".<ref>{{#cite:Q1436}}</ref> By default the file is named <code>Dockerfile</code>, "without a file extension", so that <code>docker build</code> needs no extra flags; for differently-named files (a common convention is <code>*.Dockerfile</code>) pass the name with <code>-f</code> / <code>--file</code>.<ref>{{#cite:Q1437}}</ref>
 == References ==

RonzzWikiCowriterAI: AI-assisted (RonzzWikiCowriter): complete the "Bundled software, standardized primitives" section (OCI, containerd/CNCF, runc, BuildKit) (via update-page on MediaWiki MCP Server)

2026-08-31T17:17:40Z

AI-assisted (RonzzWikiCowriter): complete the "Bundled software, standardized primitives" section (OCI, containerd/CNCF, runc, BuildKit) (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 17:17, 31 August 2026
Line 243:		Line 243:
	In a nutshell, Docker's versioned API does not guarantee that old code would work forever, but it provides additional years of runway to migrate.<ref>{{#cite:Q1411}}</ref>		In a nutshell, Docker's versioned API does not guarantee that old code would work forever, but it provides additional years of runway to migrate.<ref>{{#cite:Q1411}}</ref>

	=== Bundled software, standardized primitives ===		=== Bundled software, standardized primitives ===

	As can be seen in the [[HowItWorks:Docker#Components_and_interactions\|components and interactions diagram]], Docker has a layered architecture.		As can be seen in the [[HowItWorks:Docker#Components_and_interactions\|components and interactions diagram]], Docker has a layered architecture.

	An important decision leading to Docker's lasting success is that its low-level layers are built as open standards and neutral projects:		An important decision leading to Docker's lasting success is that its low-level layers are built as open standards and neutral projects:

			* '''The Open Container Initiative (OCI)''' — "a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation, for the express purpose of creating open industry standards around container formats and runtimes".<ref>{{#cite:Q1418}}</ref> Launched on June 22, 2015 by Docker, CoreOS and other container industry leaders, it received Docker's container format and runtime, [[FOSS:Runc\|runc]], as "the cornerstone of this new effort".<ref>{{#cite:Q1418}}</ref> The OCI maintains three specifications:<ref>{{#cite:Q1418}}</ref>
			** '''runtime-spec''' — how to run a "filesystem bundle" that is unpacked on disk;
			** '''image-spec''' — how to create an OCI image: "an image manifest, a filesystem (layer) serialization, and an image configuration";
			** '''distribution-spec''' — the API to distribute container images, which reached v1.0 in May 2020.
			* '''[[FOSS:Containerd\|containerd]]''' — the container runtime daemon spun out of Docker in 2016<ref>{{#cite:Q1416}}</ref> and accepted into the Cloud Native Computing Foundation (CNCF) in March 2017; in February 2019 it became the CNCF's fifth project to graduate, after Kubernetes, Prometheus, Envoy and CoreDNS, with "its widest usage and adoption as the layer between the Docker engine and the OCI runc executor".<ref>{{#cite:Q1439}}</ref>
			* '''[[FOSS:Runc\|runc]]''' — the OCI runtime donated by Docker: a standalone command-line tool that spawns and runs containers according to the OCI specification, the reference implementation of the runtime-spec.<ref>{{#cite:Q1418}}</ref>
			* '''[[FOSS:BuildKit\|BuildKit]]''' — "the builder backend used by Docker", itself an independent open-source project developed in the Moby ecosystem (github.com/moby/buildkit) rather than as a closed part of the engine.<ref>{{#cite:Q1412}}</ref>

			The payoff is interoperability: the primitives are not Docker-specific. Because image formats, runtimes and registries all follow OCI standards, the same image can be built, distributed and run by any OCI-compliant toolchain, and the workflow is defined so that it "should support the UX that users have come to expect from container engines like Docker and rkt: primarily, the ability to run an image with no additional arguments".<ref>{{#cite:Q1418}}</ref>

	== Try it yourself ==		== Try it yourself ==

Rongzhou: /* Try it yourself */

2026-08-31T17:09:28Z

Try it yourself

← Older revision		Revision as of 17:09, 31 August 2026
Line 251:		Line 251:
	== Try it yourself ==		== Try it yourself ==

	The commands below ~~follow~~ Docker's official documentation, ~~verified~~ on 2026-08-31~~. No Docker daemon was available in the authoring environment, so run them on your own machine with Docker installed; the outputs shown are those documented by Docker~~.		The commands below are drawn from Docker's official documentation, as read on 2026-08-31.

	<syntaxhighlight lang="bash" copy>		<syntaxhighlight lang="bash" copy>

Rongzhou: /* Standardize the primitives, assemble the rest */

2026-08-31T17:06:58Z

Standardize the primitives, assemble the rest

← Older revision		Revision as of 17:06, 31 August 2026
Line 243:		Line 243:
	In a nutshell, Docker's versioned API does not guarantee that old code would work forever, but it provides additional years of runway to migrate.<ref>{{#cite:Q1411}}</ref>		In a nutshell, Docker's versioned API does not guarantee that old code would work forever, but it provides additional years of runway to migrate.<ref>{{#cite:Q1411}}</ref>

	=== ~~Standardize the~~ primitives~~, assemble the rest~~ ===		=== Bundled software, standardized primitives ===

	~~The most consequential decision is arguably~~ the ~~unbundling. Rather than keeping the whole stack proprietary to~~ Docker, ~~the low-level pieces became open standards and neutral projects:~~		As can be seen in the [[HowItWorks:Docker#Components_and_interactions\|components and interactions diagram]], Docker has a layered architecture.

	* '''OCI (2015)''' — runtime, image and distribution specifications, with Docker's ~~runc as the reference runtime. Any OCI-compliant engine can run OCI images;~~ that ~~is why <code>docker pull</code> images run under other runtimes.<ref>{{#cite:Q1418}}</ref>~~		An important decision leading to Docker's lasting success is that its low-level layers are built as open standards and neutral projects:
	* '''containerd (2016)''' — the core runtime spun out and donated to the CNCF, as part of "a multi-year effort to break up the Docker platform into a more modular architecture of loosely coupled components".<ref>{{#cite:Q1416}}</ref>
	* '''Moby (2017)''' — the open-~~source framework of components and assemblies on which Docker itself is~~ built~~, letting others assemble their own container systems from the same parts.<ref>{{#cite:Q1415}}</ref>~~

	~~Docker Engine is thus best understood~~ as ~~one particular assembly of standardized, swappable components — "batteries included", but with every battery standardized~~ and replaceable. Compose followed the same arc: born in 2014 as a Python tool (<code>docker-compose</code>), rewritten in Go as Compose v2 (2020) integrated into the CLI as <code>docker compose</code>, and released as Compose v5 (2025) with an official Go SDK — all defined by the rolling, version-less '''Compose Specification'''.<ref>{{#cite:~~Q1414}}</ref>~~

	== Try it yourself ==		== Try it yourself ==

Rongzhou: /* The Engine API is versioned and stable */

2026-08-31T16:57:38Z

The Engine API is versioned and stable

← Older revision		Revision as of 16:57, 31 August 2026
Line 237:		Line 237:
	=== The Engine API is versioned and stable ===		=== The Engine API is versioned and stable ===

	~~Like MediaWiki's parser stability,~~ Docker's contract with the outside world is ~~its~~ '''versioned ~~Engine API~~'''. Clients and daemons negotiate ~~the~~ API version, so a newer CLI can drive an older daemon and vice versa. Docker Engine 29 ~~keeps this discipline hard: the~~ daemon now requires API version v1.44 or later, and ~~the~~ client dropped support for negotiating versions below v1.44 ~~— old enough that tooling has years of runway~~ to ~~migrate~~.<ref>{{#cite:Q1411}}</ref> ~~Breaking changes are announced in the release notes and take effect per~~ API ~~version~~, ~~not per install~~.<ref>{{#cite:Q1411}}</ref>		As Docker's contract with the outside world, the Docker API must be stable and compatible across versions. To achieve this, Docker's Engine API is '''versioned'''. Clients and daemons negotiate a mutually compatible API version, so a newer CLI can drive an older daemon and vice versa.

			However, this unfortunately does not mean that all versions of Docker are mutually compatible. Docker Engine 29's daemon now requires API version v1.44 or later, and its client dropped support for negotiating versions below v1.44, as the changes have become genuinely hard to bridge.<ref>{{#cite:Q1411}}</ref>

			In a nutshell, Docker's versioned API does not guarantee that old code would work forever, but it provides additional years of runway to migrate.<ref>{{#cite:Q1411}}</ref>

	=== Standardize the primitives, assemble the rest ===		=== Standardize the primitives, assemble the rest ===

Rongzhou: /* A daemon-centric client-server design */

2026-08-31T16:47:28Z

A daemon-centric client-server design

← Older revision		Revision as of 16:47, 31 August 2026
Line 231:		Line 231:
	=== A daemon-centric client-server design ===		=== A daemon-centric client-server design ===

	Docker ~~chose~~ a single privileged '''daemon''' that owns all state, fronted by a deliberately thin CLI.<ref>{{#cite:Q1407}}</ref> Every <code>docker</code> command is a REST call to the Engine API; the daemon performs it and reports back.<ref>{{#cite:Q1407}}</ref> This concentrates complexity in one place, enforcing the object model and facilitating security auditing. It also makes the engine highly scriptable — CI systems, orchestrators and tools like [[FOSS:Docker Compose\|Compose]] and Docker Desktop all call the '''daemon's API'''.<ref>{{#cite:Q1407}}</ref>		Docker uses a single privileged '''daemon''' that owns all state, fronted by a deliberately thin CLI.<ref>{{#cite:Q1407}}</ref> Every <code>docker</code> command is a REST call to the Engine API; the daemon performs it and reports back.<ref>{{#cite:Q1407}}</ref> This concentrates complexity in one place, enforcing the object model and facilitating security auditing. It also makes the engine highly scriptable — CI systems, orchestrators and tools like [[FOSS:Docker Compose\|Compose]] and Docker Desktop all call the '''daemon's API'''.<ref>{{#cite:Q1407}}</ref>

	~~The cost: a single point~~ of ~~failure and~~ a long-lived process, ~~which is precisely what the containerd extraction (below) addressed —~~ the low-level container lifecycle ~~moved out~~ of ~~the daemon, so~~ the daemon can restart without killing containers.		A logical downside of this complexity concentration is a long-lived server process as a single point of failure. To mitigate the risk, the daemon behaves a bit like a manager: it does not handle low-level container lifecycle itself but instead delegates them to <code>containerd</code>. This way, in case of state corruption the daemon can restart without killing containers, a bit like how a manager can go for a short refresher while ground workers continue to function normally.

	=== The Engine API is versioned and stable ===		=== The Engine API is versioned and stable ===