Docker Config Reference (docker context)

Docker context is a feature in Docker that allows users to manage and switch between multiple Docker environments or endpoints seamlessly from a single CLI. Introduced to enhance flexibility in multi-host or hybrid setups, a context encapsulates configuration details such as the Docker daemon endpoint (e.g., local Unix socket, remote TCP, or SSH connection), TLS settings, and optional Kubernetes integrations. This enables developers and operators to direct Docker commands to different targets without repeatedly specifying connection parameters, thereby streamlining workflows in distributed systems. For instance, the default context typically points to the local Docker daemon, while custom contexts can be created for remote servers or cloud-based instances, ensuring commands like docker ps or docker build execute in the intended environment.

In practice, Docker contexts facilitate efficient management of diverse infrastructures, such as switching between development, staging, and production clusters. Users can create, list, inspect, update, or remove contexts using commands like docker context create or docker context use, with options to export and import configurations for sharing across teams. This abstraction layer promotes security by isolating credentials and reduces errors in complex setups, making it particularly valuable for DevOps teams handling remote builds, Swarm clusters, or Kubernetes-orchestrated containers. Overall, Docker contexts enhance productivity by providing a unified interface for heterogeneous Docker deployments.

Example 1

docker context create myremote --docker host=ssh://user@remotehost:22

This command establishes a new Docker context named "myremote" configured to connect to a remote Docker daemon via SSH at the specified host and port, facilitating management of distant Docker environments from a local machine.

Example 2

docker context use myremote

This command switches the active Docker context to "myremote", redirecting subsequent Docker commands to operate within that context, which is essential for seamless transitions between local and remote operations.

Example 3

docker context ls

This command lists all available Docker contexts, displaying their names, descriptions, Docker endpoints, and active status, providing an overview for effective context management.

Example 4

docker context inspect default

This command retrieves detailed information about the "default" context in JSON format, including its configuration and endpoints, aiding in verification or troubleshooting of the local setup.

Example 5

docker context rm myremote

This command removes the context "myremote", eliminating its configuration from the system, which is appropriate for cleanup after completing remote tasks.

Example 6

docker context create cloudctx --docker host=tcp://cloud.example.com:2376 --description "Cloud production environment"

This command creates a context "cloudctx" with a TCP endpoint and a descriptive label, enabling organized access to a cloud-based Docker host for production deployments.

Example 7

docker context update myremote --docker host=ssh://newuser@newhost:2222

This command modifies the existing "myremote" context by updating its Docker host endpoint, allowing adjustments for changes in remote server credentials or addresses.

Example 8

docker context show

This command displays the name of the currently active Docker context, offering a quick confirmation of the operational environment.

Example 9

docker context export myremote - > myremote.tar

This command exports the "myremote" context to a tar file via stdout redirection, supporting backup or transfer of context configurations to other systems.

Example 10

docker context import myremote.tar

This command imports a context from the tar file "myremote.tar", restoring a previously exported configuration for replication across machines.

Example 11

docker context ls --format "{{.Name}} {{.Description}}"

This command lists contexts in a custom format, showing only names and descriptions, which is useful for scripted parsing or concise reporting.

Example 12

docker context inspect --format '{{json .DockerEndpoint}}' cloudctx

This command inspects "cloudctx" and formats the output to display only the Docker endpoint in JSON, extracting specific details for automation.

Example 13

docker context create testctx --docker host=unix:///var/run/docker.sock --description "Local test setup"

This command creates a "testctx" context pointing to the local Unix socket with a description, duplicating the default for isolated testing.

Example 14

docker context rm -f testctx

This command forcibly removes "testctx" without confirmation, expediting cleanup in non-interactive or automated processes.

Example 15

docker context use default

This command reverts to the "default" context, ensuring commands target the local Docker daemon after working with remotes.

Example 16

docker context create securectx --docker host=tcp://securehost:2376 --tls=true

This command creates "securectx" with a TCP endpoint and TLS enabled, enforcing secure communication for remote daemons.

Example 17

docker context update securectx --tls-verify=true

This command updates "securectx" to require TLS verification, enhancing security by mandating certificate checks.

Example 18

docker context ls -q

This command lists only the names of all contexts in quiet mode, suitable for piping into other commands.

Example 19

docker context inspect myremote securectx

This command inspects multiple contexts "myremote" and "securectx", outputting combined JSON for comparative analysis.

Example 20

docker context create k8sctx --kubernetes config-file=/path/to/kubeconfig --description "Kubernetes integration"

This command creates "k8sctx" with a Kubernetes endpoint from a config file, enabling Docker commands in Kubernetes environments.

Example 21

docker context update k8sctx --kubernetes namespace=default

This command updates "k8sctx" to target the "default" Kubernetes namespace, refining scope for container operations.

Example 22

docker context export default > local.tar

This command exports the "default" context to "local.tar", preserving local configurations for archival.

Example 23

docker context import local.tar

This command imports from "local.tar", restoring the default or other contexts on a new system.

Example 24

docker context ls --format "table {{.Name}}\t{{.DockerEndpoint}}"

This command lists contexts in table format with names and endpoints, for structured viewing.

Example 25

docker context create hybridctx --docker host=ssh://hybridhost --kubernetes config-file=/hybrid/kube

This command creates "hybridctx" with both Docker and Kubernetes endpoints, supporting hybrid orchestration.

Example 26

docker context rm hybridctx k8sctx

This command removes multiple contexts "hybridctx" and "k8sctx", for batch deletion.

Example 27

docker context update testctx --description "Updated test description"

This command modifies the description of "testctx", improving documentation without altering endpoints.

Example 28

docker context show --format '{{.Name}}'

This command formats the active context output to show only the name, for precise scripting.

Example 29

docker context create tlscactx --docker host=tcp://tlshost:2376 --tls-ca-cert=/path/to/ca.pem

This command creates "tlscactx" with a custom CA certificate for TLS, ensuring trusted connections.

Example 30

docker context inspect --pretty tlscactx

This command inspects "tlscactx" in a pretty-printed format, displaying readable details for verification.

5 Real World Examples of Using docker context!

Real-World Example 1: Switching to a Remote Development Server

docker context use dev-remote

In a DevOps workflow where developers need to test applications on a remote development server without leaving their local machine, this command switches the active context to "dev-remote" (previously created with an SSH or TCP endpoint). It allows seamless execution of Docker commands like docker ps or docker run on the remote host, streamlining collaboration and reducing the need for direct SSH logins.

Real-World Example 2: Managing Multiple Swarm Clusters

docker context create prod-swarm --docker host=tcp://swarm-manager.prod.example.com:2376

For organizations running multiple Docker Swarm clusters (e.g., one for production and one for staging), this command creates a context "prod-swarm" connected to the production Swarm manager via TCP. It enables administrators to manage orchestration tasks, such as deploying services or scaling replicas, across clusters from a single local CLI, improving efficiency in large-scale deployments.

Real-World Example 3: Integrating with Kubernetes for Hybrid Environments

docker context create k8s-staging --kubernetes config-file=~/.kube/staging-config

In hybrid cloud environments where teams use both Docker and Kubernetes, this command sets up a context "k8s-staging" linked to a Kubernetes config file for a staging cluster. Developers can then use Docker commands to build and push images directly to the Kubernetes context, facilitating CI/CD pipelines that bridge containerization with orchestration.

Real-World Example 4: Remote Building on a Powerful Server from a Local Machine

docker context create build-server --docker host=ssh://builder@highperf-server:22

For resource-constrained local machines (e.g., a laptop), this command creates a context "build-server" connected via SSH to a high-performance remote build server. Users can then run docker build commands that offload intensive compilation or image building to the remote server, speeding up development cycles for complex applications like machine learning models.

Real-World Example 5: Exporting and Importing Contexts for Team Onboarding

docker context export shared-context > shared-context.tar

In team-based projects, this command exports the "shared-context" (e.g., configured for a shared testing environment) to a tar file. New team members can import it on their machines to instantly access the same remote Docker setup, ensuring consistency in collaborative workflows and reducing setup time during onboarding.