Docker Guides and Tutorials | Spacelift Blog

Author title

The Practitioner’s Guide to Scaling Infrastructure as Code

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Transform your IaC management to scale
securely, efficiently, and productively
into the future.

Blog

What Are Terraform Modules and How to Use Them: Tutorial

Terraform Functions, Expressions, Loops (Examples)

Managing Terraform State - Best Practices & Examples

Terraform For Loop - Expression Overview with Examples

What is Terraform? What is it Used For, How it Works

44 Ansible Best Practices to Follow [Tips & Tricks]

How to Stop and Remove Docker Containers

How to Create a CI/CD Pipeline with Docker [Tutorial]

CI/CD Pipeline : Everything You Need To Know

Kubernetes CI/CD Pipelines - 7 Best Practices and Tools

How to Deploy Infrastructure in CI/CD Using Terraform (Pipeline)

Terraform with Azure DevOps CI/CD Pipelines - Tutorial

Terragrunt Tutorial - Getting Started & Examples

Pulumi Pricing – Editions Overview 2024

73 Most Useful DevOps Tools to Use in 2024

Top 10 Terraform Enterprise Alternatives for 2024

Terraform Cloud/Enterprise Pricing - Tiers Overview 2024

16 Most Useful Infrastructure as Code (IaC) Tools for 2024

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

ebook-global-banner

ebook global banner

Meet Spacelift, The IaC Orchestration Platform

Heading to KubeCon+CloudNativeCon North America?

Why Spacelift

How it works

Integrations

Product

Solutions

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

IaC at Scale

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

By Initiative

CI/CD for Infrastructure

Drift Detection

Achieve Terraform at Scale

OpenTofu Migration

By Use Case

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

blog-2

partners

Partners

partners-2

events

Events

events-2

Insights and quick guides to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Ebooks & Cheatsheets

users

Users

users-2

Case studies

33-what-makes-spacelift-secure

What Makes Spacelift Secure

About Us

Contact Us

About

cheatsheets-2

Test

See more

Test webinar name

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

Docker

Want to level up your Kubernetes knowledge? Explore our tutorials and step-by-step guides written by Kubernetes experts. Learn Kubernetes best practices and solutions to the most difficult problems.

Kubernetes Guides and Tutorials | Spacelift Blog

Kubernetes

James Walker

<a href="https://www.docker.com" target="_blank" rel="nofollow noopener">Docker</a> and <a href="https://kubernetes.io" target="_blank" rel="nofollow noopener">Kubernetes</a> are two of the most popular container tools used for modern DevOps. Docker is primarily a platform for creating and running container images, while Kubernetes is an orchestrator that focuses on deploying, scaling, and managing containers in production environments.
Docker and Kubernetes overlap in several ways but also have unique differences that affect the situations where they&#8217;re used. You can use one tool without the other or allow them to complement each other by combining both in your workflows.
In this article, we&#8217;ll explore their similarities and differences, then discuss the advantages of using each tool.
We will cover:
<ol>
<li><a href="https://spacelift.io/blog/docker-vs-kubernetes#what-is-docker">What is Docker?</a></li>
<li><a href="https://spacelift.io/blog/docker-vs-kubernetes#what-is-kubernetes">What is Kubernetes?</a></li>
<li><a href="https://spacelift.io/blog/docker-vs-kubernetes#similarities">Similarities</a></li>
<li><a href="https://spacelift.io/blog/docker-vs-kubernetes#differences">Differences</a></li>
<li><a href="https://spacelift.io/blog/docker-vs-kubernetes#does-kubernetes-use-docker">Does Kubernetes Use Docker?</a></li>
<li><a href="https://spacelift.io/blog/docker-vs-kubernetes#which-is-better-docker-or-kubernetes">Which is better: Docker or Kubernetes?</a></li>
</ol>

<a href="https://spacelift.io/blog/docker-tutorial" target="_blank" rel="noopener">Docker</a> is a platform for building and running containers. You can use it to create new container images from <a href="https://spacelift.io/blog/dockerfile" target="_blank" rel="noopener">Dockerfiles</a>, then start containers from your images.
Docker was instrumental in establishing the container movement that&#8217;s transformed DevOps over the past decade. Most developers begin using containers with Docker. It&#8217;s available as a <a href="https://www.docker.com/products/docker-desktop/alternatives" target="_blank" rel="nofollow noopener">graphical desktop interface</a> for developer use, and a CLI and daemon for server environments.
See also: <a href="https://spacelift.io/blog/docker-alternatives" target="_blank" rel="noopener">Top 12 Docker Alternatives</a>.

<a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">Kubernetes</a> (K8s) is a system for running containers with flexible scaling and high availability. Developed at Google to simplify the use of containers in production, Kubernetes automates key administration tasks to help you reliably operate your containers.
Several Kubernetes distributions are available. Compact versions like <a href="https://minikube.sigs.k8s.io/docs/start" target="_blank" rel="nofollow noopener">Minikube</a> are ideal for local use, while managed services such as <a href="https://cloud.google.com/kubernetes-engine" target="_blank" rel="nofollow noopener">Google GKE</a> and <a href="https://aws.amazon.com/eks" target="_blank" rel="nofollow noopener">Amazon EKS</a> allow you to rapidly provision new cloud-based clusters.

Docker and Kubernetes each revolve around containers. You can use them to run containers, link them together, attach persistent storage, and provide network services.
Both Docker and Kubernetes are compatible with all <a href="https://opencontainers.org" target="_blank" rel="nofollow noopener">OCI</a> container images, runtimes, and container registries. Images created with Docker can be used in Kubernetes, for example.
The two tools include their own <a href="https://kubernetes.io/docs/concepts/cluster-administration/networking" target="_blank" rel="nofollow noopener">networking models</a> and <a href="https://docs.docker.com/storage/volumes" target="_blank" rel="nofollow noopener">storage abstractions</a>. You can also use them to replicate container instances across multiple hosts–this is fundamental in Kubernetes, whereas Docker offers it as part of its optional <a href="https://docs.docker.com/engine/swarm" target="_blank" rel="nofollow noopener">Swarm mode</a>.

<ul>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
<li><a href="https://spacelift.io/blog/terraform-vs-kubernetes" target="_blank" rel="noopener">Terraform vs. Kubernetes Comparison</a></li>
<li><a href="https://spacelift.io/blog/kubernetes-best-practices" target="_blank" rel="noopener">15 Kubernetes Best Practices to Follow</a></li>
</ul>

Beyond their high-level support for running containers, Docker and Kubernetes each possess several differences that lend them advantages and drawbacks in specific situations.
These differences can be summarized by assessing the use cases that the tools focus on: Docker is primarily a platform for building and running containers, whereas Kubernetes is an operations-oriented orchestrator for deploying containers at scale.
Here&#8217;s how Docker and Kubernetes compare across some key characteristics:

docker-vs-kubernetes-comparison-table

docker vs kubernetes comparison table

Docker and Kubernetes are both container tools, but they focus on different areas within the overall containerization space. Docker provides functionality for building and running containers, whereas Kubernetes is focused on their deployment and operation.
Docker includes components <a href="https://docs.docker.com/build/buildkit" target="_blank" rel="nofollow noopener">such as BuildKit</a> for writing Dockerfiles and building images from them. You can also <a href="https://docs.docker.com/engine/reference/commandline/search" target="_blank" rel="nofollow noopener">search Docker Hub</a> to find images relevant to your workload, and access built-in tools for <a href="https://docs.docker.com/engine/scan" target="_blank" rel="nofollow noopener">image security scans</a> and <a href="https://docs.docker.com/engine/sbom" target="_blank" rel="nofollow noopener">SBOM generation</a>.
Kubernetes only works with existing images and provides fewer features for managing them. You can run services inside your cluster that offer functions similar to those bundled with Docker, but they&#8217;re not part of the core Kubernetes experience. The power of Kubernetes is its ability to <a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale" target="_blank" rel="nofollow noopener">scale containers across</a> multiple physical Nodes, then ensure they remain accessible after Node failures.

Docker generally works with individual containers. In practice, most applications are formed from multiple services that need to be managed as a collective stack. Docker ecosystem tools, including <a href="https://spacelift.io/blog/docker-compose" target="_blank" rel="noopener">Docker </a><a href="https://spacelift.io/blog/docker-compose" target="_blank" rel="noopener">Compose</a> and <a href="https://docs.docker.com/engine/swarm" target="_blank" rel="nofollow noopener">Swarm Mode</a>, facilitate this, but they&#8217;re relatively narrow in scope.
Kubernetes, meanwhile, is a purpose-built orchestrator for scaling containers across multiple nodes. It includes a robust set of features for <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler" target="_blank" rel="nofollow noopener">assigning containers to nodes</a>, maintaining <a href="https://kubernetes.io/docs/concepts/configuration/manage-resources-containers" target="_blank" rel="nofollow noopener">resource capacities</a>, and<a href="https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale" target="_blank" rel="nofollow noopener"> adjusting scaling configuration</a> in response to actual demand. Although the initial setup procedure is more demanding, Kubernetes is better suited to the demands of real applications in live environments.
Another benefit of Kubernetes is its declarative-first design. Deployments are usually configured as <a href="https://spacelift.io/blog/yaml" target="_blank" rel="noopener">YAML manifests</a>, which describe your desired state. When you apply a manifest, Kubernetes automatically reconciles the changes and applies any actions required to transition your cluster to the new state. 
By contrast, most users <a href="https://spacelift.io/blog/docker-commands-cheat-sheet" target="_blank" rel="noopener">interact with Docker using imperative CLI commands</a>; Compose and Swarm mode are required for declarative configuration of replicated services, but the result is still more limited than Kubernetes.

Docker is a relatively low-level tool. It directly manages containers, and you need to use other tools, such as Compose, to link them together.
Kubernetes takes a higher-level view that includes more abstraction layers. Concepts such as <a href="https://kubernetes.io/docs/concepts/workloads/pods" target="_blank" rel="nofollow noopener">Pods</a>, <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset" target="_blank" rel="nofollow noopener">ReplicaSets</a>, and <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment" target="_blank" rel="nofollow noopener">Deployments</a> present a learning curve initially but allow more accurate and powerful modeling of your application.
Kubernetes can manage your supporting infrastructure too. It can provision networking components such as <a href="https://spacelift.io/blog/kubernetes-load-balancer" target="_blank" rel="noopener">load balancers</a> and <a href="https://spacelift.io/blog/kubernetes-persistent-volumes" target="_blank" rel="noopener">storage volumes</a> for you, using the resources available from your cloud provider. Abstracting away the differences between different clouds gives you more flexibility when deploying your workloads.

Docker comes with extremely minimal ops features for overseeing your deployments. You can get basic resource utilization information from <a href="https://docs.docker.com/engine/reference/commandline/stats" target="_blank" rel="nofollow noopener">docker stats</a>, or use <a href="https://docs.docker.com/engine/reference/commandline/logs" target="_blank" rel="nofollow noopener">docker logs</a> to access a container&#8217;s log stream. Beyond these features, there are no other observability capabilities, nor are there mechanisms for controlling access to Docker itself. This simplifies local use on your own machine but is restrictive in production.
Kubernetes comes with essential operations controls built-in. It has extensive support for <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac" target="_blank" rel="nofollow noopener">Role-Based Access Control (RBAC)</a>, for example, which allows you to control the operations different users can perform. Kubernetes is also easily integrated with advanced observability solutions such as <a href="https://spacelift.io/blog/prometheus-kubernetes" target="_blank" rel="noopener">Prometheus</a>, which can run in your cluster while simultaneously scraping metrics from it.
In summary, Kubernetes is designed around the requirements of operators, as it originated from this field. Docker is positioned as a developer-oriented tool, which means it lacks robust ops-specific features.

Images you build with Docker can be deployed to a Kubernetes cluster. The two tools operate independently, however: Kubernetes does not directly depend on Docker. You don’t need Docker installed to use Kubernetes, and vice versa.
Both Docker and Kubernetes are compliant with the <a href="https://opencontainers.org" target="_blank" rel="nofollow noopener">Open Container Initiative (OCI)</a> specifications. This project defines standards for interoperability between different container runtimes and image formats. Docker outputs OCI-compatible images, which can be run by any OCI runtime. The default runtime used by Docker and Kubernetes is <a href="https://containerd.io" target="_blank" rel="nofollow noopener">containerd</a>, but alternatives such as <a href="https://github.com/cri-o/cri-o" target="_blank" rel="nofollow noopener">CRI-O</a> are available.
It&#8217;s worth noting that Kubernetes <a href="https://kubernetes.io/blog/2020/12/02/dockershim-faq" target="_blank" rel="nofollow noopener">did historically use</a> Docker to run the containers in your cluster. A component called Dockershim provided an interface between Docker and Kubernetes. Dockershim was removed in Kubernetes v1.24; an OCI-compatible runtime must now be used instead.

There&#8217;s no definitive answer to this question. It depends on the container features you require and how they will be used. Nowadays, it&#8217;s common for development teams to deploy both technologies as part of their container workflows, allowing them to complement each other.
<h3>Using Docker and Kubernetes</h3>
Docker&#8217;s typically used to build images and run containers on developer workstations, while the enhanced operational abilities of Kubernetes are chosen for production deployments.
Docker&#8217;s simplicity means it&#8217;s often the most convenient option during development. It&#8217;s ideal for smaller applications with few components. Docker also has the advantage of familiarity and a low learning curve: most developers quickly become proficient at building images and starting containers.
Kubernetes is more complex, but it&#8217;s also much more flexible and better suited to the requirements of operators running containers in production. Its support for scalability, high availability, container lifecycle management, and observability can&#8217;t be replicated by Docker. 
Additionally, the ability to quickly provision new Kubernetes clusters using managed cloud services can significantly accelerate your route to production.
See also: <a href="https://spacelift.io/blog/docker-compose-vs-kubernetes" target="_blank" rel="noopener">Docker Compose vs Kubernetes comparison</a>.

Both Docker and Kubernetes are great tools for working with containers in DevOps situations. They&#8217;re both capable of running containers, but they&#8217;re typically used in different parts of the development workflow.
Docker is focused on application components. It&#8217;s useful for building your container images and running them locally as you work. However, Docker lacks the operations features essential to the use of containers in production. 
Kubernetes accommodates this use case by providing a platform for automating container deployments and lifecycle management. It helps you operate containers by providing features for dynamic scaling and robust fault tolerance.
Kubernetes is also easy to integrate with IaC and CI/CD solutions. You can use <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> to <a href="https://spacelift.io/blog/provision-kubernetes-cluster-terraform-spacelift" target="_blank" rel="noopener">provision Kubernetes clusters with Terraform</a>, for example, allowing you to automate infrastructure configuration. You can use Kubernetes to run all your container workloads across production, development, and CI/CD jobs, but might still want to choose Docker for quick testing on your laptop.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

15 Common Kubernetes Pitfalls & Challenges

What is Container Security? 10 Best Practices & Solutions

Docker Swarm vs. Kubernetes - Key Differences Explained

Both Docker and Kubernetes are container tools. See their similarities and differences, and the advantages of using each tool.

207-docker-vs-kubernetes

docker vs kubernetes

Docker vs. Kubernetes: Tools Comparison

<a href="https://spacelift.io/blog/docker-tutorial" target="_blank" rel="noopener">Docker</a> is a containerization platform that uses OS-level virtualization to package software applications and their dependencies into reusable units called containers. Docker containers can be run on any host with Docker or an equivalent container runtime installed, whether locally on your laptop or in a remote cloud.
Docker includes a networking system for managing communications between containers, your Docker host, and the outside world. Several different network types are supported, facilitating a variety of common use cases. 
In this article, we&#8217;ll explain how Docker networks function, then cover the basics of using them with your container deployments.
We will cover:
<ol>
<li><a href="https://spacelift.io/blog/docker-networking#docker-network-types">Docker Network Types</a></li>
<li><a href="https://spacelift.io/blog/docker-networking#how-docker-networking-works">How Docker Networking Works</a></li>
<li><a href="https://spacelift.io/blog/docker-networking#using-docker-networks">Using Docker Networks</a></li>
</ol>

Docker networks configure communications between neighboring containers and external services. Containers must be connected to a Docker network to receive any network connectivity. The communication routes available to the container depend on the network connections it has.
Docker comes with five <a href="https://docs.docker.com/network" target="_blank" rel="nofollow noopener">built-in network drivers</a> that implement core networking functionality:
<ol>
<li>bridge</li>
<li>host</li>
<li>overlay</li>
<li>IPvLAN</li>
<li>macvlan</li>
</ol>
<h3>1. <code>bridge</code></h3>
<a href="https://docs.docker.com/network/bridge" target="_blank" rel="nofollow noopener">Bridge networks</a> create a software-based bridge between your host and the container. Containers connected to the network can communicate with each other, but they&#8217;re isolated from those outside the network.
Each container in the network is assigned its own IP address. Because the network&#8217;s bridged to your host, containers are also able to communicate on your LAN and the internet. They will not appear as physical devices on your LAN, however.
<h3>2. <code>host</code></h3>
Containers that use the <a href="https://docs.docker.com/network/host" target="_blank" rel="nofollow noopener"><code>host</code> network mode</a> share your host&#8217;s network stack without any isolation. They aren&#8217;t allocated their own IP addresses, and port binds will be published directly to your host&#8217;s network interface. This means a container process that listens on port 80 will bind to <code>&lt;your_host_ip&gt;:80</code>.
<h3>3. <code>overlay</code></h3>
<a href="https://docs.docker.com/network/overlay" target="_blank" rel="nofollow noopener">Overlay networks</a> are distributed networks that span multiple Docker hosts. The network allows all the containers running on any of the hosts to communicate with each other without requiring OS-level routing support.
Overlay networks implement the networking for <a href="https://docs.docker.com/engine/swarm" target="_blank" rel="nofollow noopener">Docker Swarm clusters</a>, but you can also use them when you&#8217;re running two separate instances of Docker Engine with containers that must directly contact each other. This allows you to build your own Swarm-like environments.
<h3>4. <code>ipvlan</code></h3>
<a href="https://docs.docker.com/network/ipvlan" target="_blank" rel="nofollow noopener">IPvLAN</a> is an advanced driver that offers precise control over the IPv4 and IPv6 addresses assigned to your containers, as well as layer 2 and 3 VLAN tagging and routing.
This driver is useful when you&#8217;re integrating containerized services with an existing physical network. IPvLAN networks are assigned their own interfaces, which offers performance benefits over bridge-based networking.
<h3>5. <code>macvlan</code></h3>
<a href="https://docs.docker.com/network/macvlan/" target="_blank" rel="nofollow noopener"><code>macvlan</code></a> is another advanced option that allows containers to appear as physical devices on your network. It works by assigning each container in the network a unique MAC address.
This network type requires you to dedicate one of your host&#8217;s physical interfaces to the virtual network. The wider network must also be appropriately configured to support the potentially large number of MAC addresses that could be created by an active Docker host running many containers.
<h3>Which Network Type Should I Use?</h3>
Bridge networks are the most suitable option for the majority of scenarios you&#8217;ll encounter. Containers in the network can communicate with each other using their own IP addresses and DNS names. They also have access to your host&#8217;s network, so they can reach the internet and your LAN.
Host networks are best when you want to bind ports directly to your host&#8217;s interfaces and aren&#8217;t concerned about network isolation. They allow containerized apps to function similarly to network services running directly on your host.
Overlay networks are required when containers on different Docker hosts need to communicate directly with each other. These networks let you set up your own distributed environments for high availability.
Macvlan networks are useful in situations where containers must appear as a physical device on your host&#8217;s network, such as when they run an application that monitors network traffic. IPvLAN networks are an advanced option for when you have specific requirements around container IP addresses, tags, and routing.
Docker also supports <a href="https://docs.docker.com/engine/extend/plugins_services" target="_blank" rel="nofollow noopener">third-party network plugins</a>, which expand the networking system with additional operating modes. These include <a href="https://github.com/openstack/kuryr" target="_blank" rel="nofollow noopener">Kuryr</a>, which implements networking using <a href="https://docs.openstack.org/neutron/latest/" target="_blank" rel="nofollow noopener">OpenStack Neutron</a>, and <a href="https://www.weave.works/docs/net/latest/introducing-weave" target="_blank" rel="nofollow noopener">Weave</a>, an overlay network with an emphasis on service discovery, security, and fault tolerance.
Finally, Docker networking is always optional at the container level: setting a container&#8217;s network to <code>none</code> will completely disable its networking stack. The container will be unable to reach its neighbors, your host&#8217;s services, or the internet. This helps improve security by sandboxing applications that aren&#8217;t expected to require connectivity.

Docker uses your host&#8217;s network stack to implement its networking system. It works by <a href="https://docs.docker.com/network/iptables" target="_blank" rel="nofollow noopener">manipulating <code>iptables</code> rules</a> to route traffic to your containers. This also provides isolation between Docker networks and your host.
<a href="https://linux.die.net/man/8/iptables" target="_blank" rel="nofollow noopener"><code>iptables</code></a> is the standard Linux packet filtering tool. Rules added to <code>iptables</code> define how traffic is routed as it passes through your host&#8217;s network stack. Docker networks add filtering rules which direct matching traffic to your container&#8217;s application. The rules are automatically configured, so you don&#8217;t need to manually interact with <code>iptables</code>.
Docker containers are assigned their own <a href="https://man7.org/linux/man-pages/man7/network_namespaces.7.html" target="_blank" rel="nofollow noopener">network namespace</a>, a Linux kernel feature that provides isolated virtual network environments. Containers also create virtual network interfaces on your host that allow them to communicate outside their namespace using your host&#8217;s network.
The details of how Docker networking is implemented are relatively complex and low-level. Docker abstracts them away from end users, providing a seamless container networking experience that&#8217;s predictable and effective. However, more information is available <a href="https://docs.docker.com/network/iptables" target="_blank" rel="nofollow noopener">in Docker&#8217;s documentation</a>.
Check out also &#8211; <a href="https://spacelift.io/blog/kubernetes-networking" target="_blank" rel="noopener">Kubernetes Networking Explained</a>.
<h3>Docker Networking vs. VM Networking</h3>
Docker&#8217;s networking model provides isolated virtualized environments to containers. These networks satisfy common use cases but have some key differences compared to the virtual networks created by traditional VMs.
Whereas Docker achieves network isolation using namespaces and <code>iptables</code> rules, VMs typically run a separate networking stack for each virtual machine. There are also differences in terminology that can cause confusion: what Docker calls a &#8220;bridge&#8221; network is similar to a <a href="https://en.wikipedia.org/wiki/Network_address_translation" target="_blank" rel="nofollow noopener">NAT-based</a> network in most VM solutions.
Generally, VMs can support a broader range of network topologies than Docker natively permits. However, Docker includes all the tools to create the network solution you require, whether by using <code>macvlan</code> to assign containers addresses on your physical network or by using a third-party plugin to implement missing network models.

<ul>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
</ul>

Ready to explore Docker networking? Here&#8217;s how to use networks to manage container communications. To follow along with this tutorial, you&#8217;ll need to open three terminal windows.
<h3>Creating Networks</h3>
To create a new network, use the <a href="https://docs.docker.com/engine/reference/commandline/network_create" target="_blank" rel="nofollow noopener"><code>docker network create</code> command</a>. You can specify the driver to use, such as <code>bridge</code> or <code>host</code>, by setting the <code>-d</code> flag. A <code>bridge</code> network will be created if you omit the flag.
Run the following in your first terminal window:

The ID of the created network is emitted to your terminal. The new network&#8217;s useless at the moment because no containers have been connected.
<h3>Connecting Containers to Networks</h3>
You can attach new containers to a network by setting the <code>--network</code> flag with your <code>docker run</code> command. Run this command in your second terminal window:

Next, open your third terminal window and start another Ubuntu container, this time without the <code>--network</code> flag:

Now try communicating between the two containers, using their names:

The containers aren&#8217;t in the same network yet, so they can&#8217;t directly communicate with each other.
Use your first terminal window to join <code>container2</code> to the network:

The containers now share a network, which allows them to discover each other:

<h3>Using Host Networking</h3>
Bridge networks are what you&#8217;ll most commonly use to connect your containers. Let&#8217;s also explore the capabilities of host networks, where containers attach directly to your host&#8217;s interfaces. You can enable host networking for a container by connecting it to the built-in <code>host</code> network:

NGINX listens on port 80 by default. Because the container&#8217;s using a host network, you can access your NGINX server on your host’s <code>localhost:80</code> outside the container, even though no ports have been explicitly <a href="https://docs.docker.com/config/containers/container-networking" target="_blank" rel="nofollow noopener">bound</a>:

<h3>Disabling Networking</h3>
When a container&#8217;s networking is disabled, it will have no connectivity available – either to other containers, or your wider network. Disable networking by attaching your container to the <code>none</code> network:

This lets you easily sandbox unknown services.
<h3>Removing Containers from Networks</h3>
Docker lets you freely manage network connections without restarting your containers. In the previous section, you saw how to connect a container after its creation; it&#8217;s also possible to remove containers from networks they no longer need to participate in:

Any changes you make will apply immediately.
<h3>Managing Networks</h3>
You can list all your Docker networks with the <code>network ls</code> command:

The output includes the built-in networks, <code>bridge</code>, <code>host</code>, and <code>none</code>, as well as the networks you&#8217;ve created.
To delete a network, <a href="https://spacelift.io/blog/docker-stop-container" target="_blank" rel="noopener">disconnect or stop all the Docker containers</a> that use it, then pass the network&#8217;s ID or name to <code>network rm</code>:

You can automatically delete all unused networks using the <code>network prune</code> command:

<h3>Using Networks With Docker Compose</h3>
You can use networks with Docker Compose services too. It&#8217;s often possible to avoid manual networking configuration when you’re using Compose, because the services in your stack are automatically added to a shared bridge network:

Use Compose to deploy the stack:

As shown by the following output, Compose has created a network for your stack that includes both the containers:

This means your application container can communicate directly with the neighboring mysql database container:

Adding Extra Networks
You can define additional networks inside your Compose file. Name the network in the top-level <code>networks</code> field, then connect your services by referencing the network in the service-level <code>networks</code> field:

This example overrides the behavior of the default stack-level network. Now, only the app service can communicate with <code>mysql</code>. <code>helper</code> is unable to reach the database because the two services don&#8217;t share a network.
Learn more with our <a href="https://spacelift.io/blog/docker-compose" target="_blank" rel="noopener">Docker Compose tutorial</a>.

Docker&#8217;s networking system provides flexible options for managing communication between containers, their neighbors, and your Docker host. Containers within a network are able to reach each other by name or IP address.
Networking is implemented by a set of pluggable drivers that accommodate the most common use cases. Networks rely on your host&#8217;s networking stack, but are isolated using namespaces. The separation is weaker than the virtual networking model used by VMs, although containers can still appear as physical network devices when you attach them to a macvlan network.
Looking for more Docker guides and tutorials? Check out our other articles <a href="https://spacelift.io/blog">on the Spacelift blog</a>. 
Check out also how <a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift" target="_blank" rel="noopener">integrating with third party tools</a> is easily done at Spacelift. You have the possibility of installing and configuring them <a href="https://docs.spacelift.io/concepts/stack/stack-settings#customizing-workflow" target="_blank" rel="noopener">before and after runner phases</a> or you can simply bring your own <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">Docker image</a> and leverage them directly.

Docker Volumes - Guide with Examples

Using Terraform to Set Up and Deploy Docker Containers

With this Docker networking introduction, you'll learn how Docker networks function and the basics of using them with your container deployments.

203-docker-networking-2

docker networking

Docker Networking - Basics, Network Types & Examples

Customize your workflow by bringing your own Docker image and using it as a runner to accelerate deployments that leverage third-party tools.

Docker is a platform for building and running containerized applications. Containers package your source code, dependencies, and runtime environment into reusable units, which can be deployed anywhere a container runtime is available. This could be a Docker installation on your laptop or a <a href="https://spacelift.io/blog/kubernetes-tutorial" target="_blank" rel="noopener">Kubernetes cluster</a> that provides your production infrastructure.
Wherever you launch your containers, you need a container image to run. Images define the initial state of container filesystems. They&#8217;re created using a <a href="https://docs.docker.com/engine/reference/builder" target="_blank" rel="nofollow noopener">Dockerfile</a> – a list of instructions that Docker processes to assemble your image.
In this article, we&#8217;ll walk through what Dockerfiles are, how to create one, and some best practices you should follow.

Dockerfiles are text files that list instructions for the Docker daemon to follow when building a container image. When you execute the <a href="https://docs.docker.com/engine/reference/commandline/build" target="_blank" rel="nofollow noopener"><code>docker build</code> command</a>, the lines in your Dockerfile are processed sequentially to assemble your image.
The basic Dockerfile syntax looks as follows:

Instructions are keywords that apply a specific action to your image, such as copying a file from your working directory, or executing a command within the image.
By convention, instructions are usually written in uppercase. This <a href="https://docs.docker.com/engine/reference/builder" target="_blank" rel="nofollow noopener">is not a requirement</a> of the Dockerfile parser, but it makes it easier to see which lines contain a new instruction. You can spread arguments across multiple lines with the backslash operator:

Lines starting with a <code>#</code> character are interpreted as comments. They&#8217;ll be ignored by the parser, so you can use them to document your Dockerfile.
<h3>Key Dockerfile Instructions</h3>
Docker supports over <a href="https://docs.docker.com/engine/reference/builder" target="_blank" rel="nofollow noopener">15 different Dockerfile instructions</a> for adding content to your image and setting configuration parameters. Here are some of the most common ones you&#8217;ll use.
<h4>1. <code>FROM</code></h4>

<code>FROM</code> is usually the first line in your Dockerfile. It refers to an existing image which becomes the base for your build. All subsequent instructions apply on top of the referenced image&#8217;s filesystem.
<h4>2. <code>COPY</code></h4>

<code>COPY</code> adds files and folders to your image&#8217;s filesystem. It copies between your Docker host and the work-in-progress image. Containers using the image will include all the files you&#8217;ve copied in.
The instruction&#8217;s first argument references the source path on your host. The second argument sets the destination path inside the image. It&#8217;s possible to directly copy from another Docker image using the <code>--from</code> flag:

3. <code>ADD</code>

<code>ADD</code> works similarly to <code>COPY</code> but additionally supports remote file URLs and automatic archive extraction. Archives will be extracted into the destination path in your container. Decompression of <code>gzip</code>, <code>bzip2</code>, and <code>xz</code> formats is supported.
Although <code>ADD</code> can simplify some image authorship tasks, its use <a href="https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#add-or-copy" target="_blank" rel="nofollow noopener">is discouraged</a> because its behavior masks important details. Accidentally using <code>ADD</code> instead of <code>COPY</code> can be confusing because archive files will be extracted into your container instead of being copied as-is.
4. <code>RUN</code>

<code>RUN</code> runs a command inside the image you&#8217;re building. It creates a new <a href="https://docs.docker.com/storage/storagedriver/#images-and-layers" target="_blank" rel="nofollow noopener">image layer</a> on top of the previous one; this layer will contain the filesystem changes that the command applies. <code>RUN</code> instructions are most commonly used to install and configure packages that your image requires.
<h4>5. <code>ENV</code></h4>

The <code>ENV</code> instruction is used to set environment variables that will be available within your containers. Its argument looks similar to a variable assignment in your shell: specify the name of the variable and the value to assign, separated by an equals character.

Ready to create a Docker image for your application? Here&#8217;s how to get started with a simple Dockerfile.
First, create a new directory for your project. Copy the following code and save it as <code>main.js</code>:

Use npm to add the <code>uuid</code> package to your project:

Next, copy the following set of Docker instructions, then save them to <code>Dockerfile</code> in your working directory:

Let&#8217;s unpack this Dockerfile line-by-line:
<ul>
<li><code>FROM node:16</code> &#8211; <a href="https://hub.docker.com/_/node" target="_blank" rel="nofollow noopener">The official Node.js image</a> is selected as the base image. All the other statements apply on top of <code>node:16</code>.</li>
<li><code>WORKDIR /app</code> – The working directory is changed to <code>/app</code>. Subsequent statements which use relative paths, such as the <code>COPY</code> instructions immediately afterwards, will be resolved to <code>/app</code> inside the container.</li>
<li><code>COPY package.json</code> – The next two lines copy in your <code>package.json</code> and <code>package-lock.json</code> files from your host&#8217;s working directory. The destination path is <code>.</code>, meaning they&#8217;re deposited into the in-container working directory with their original names.</li>
<li><code>RUN npm install</code> – This instruction executes <code>npm install</code> inside the container&#8217;s filesystem, fetching your project&#8217;s dependencies.</li>
<li><code>COPY main.js .</code> – Your app&#8217;s source code is added to the container. It happens after the <code>RUN</code> instruction because your code will usually change more frequently than your dependencies. This order of operations allows more <a href="https://docs.docker.com/build/cache" target="_blank" rel="nofollow noopener">optimal usage</a> of Docker&#8217;s build cache.</li>
<li><code>ENTRYPOINT ["node"]</code> – The image&#8217;s <a href="https://docs.docker.com/engine/reference/builder/#entrypoint" target="_blank" rel="nofollow noopener">entrypoint</a> is set so the <code>node</code> binary is launched automatically when you create new containers with your image.</li>
<li><code>CMD ["main.js"]</code> – This instruction supplies arguments for the image&#8217;s entrypoint. In this example, it results in Node.js running your application’s code.</li>
</ul>

<h3>Building your Dockerfile</h3>
Now you can use <code>docker build</code> to build an image from your Dockerfile. Run the following command in your terminal:

Wait while Docker builds your image. The sequence of instructions will be displayed in your terminal.
<h3>Docker Build Options</h3>
The <code>docker build</code> command takes the path to the build context as an argument. The build context defines which paths you can reference within your Dockerfile. Paths outside the build context will be invisible to Dockerfile instructions such as <code>COPY</code>. It&#8217;s most common to set the build context to <code>.</code>, as in this example, to refer to your working directory.
Docker automatically looks for instructions in your working directory&#8217;s <code>Dockerfile</code>, but you can reference a different Dockerfile with the <code>-f</code> flag:

The <code>-t</code> flag sets the tag which will be assigned to your image after the build completes. You can repeat the flag if you need to add multiple tags.
<h3>Using Your Image</h3>
With your image built, start a container to see your code execute:

The image&#8217;s filesystem has been populated with the Node.js runtime, your npm dependencies, and your source code, based on the instructions in your Dockerfile.

<ul>
<li style="text-align: left;"><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li style="text-align: left;"><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
<li style="text-align: left;"><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
</ul>

Writing a Dockerfile for your application is usually a relatively simple task, but there are some common gotchas to watch out for. Here are 10 best practices you should follow to maximize usability, performance and security.
<h3>1. Don&#8217;t use <code>latest</code> for your base images</h3>
Using an image such as <code>node:latest</code> in your <code>FROM</code> instructions is risky <a href="https://spacelift.io/blog/docker-tutorial" target="_blank" rel="noopener">because it can expose you to</a> unexpected breaking changes. Most image authors immediately switch latest to new major versions as soon as they&#8217;re released. Rebuilding your image could silently select a different version, causing a broken build or malfunctioning container software.
Selecting a specific tag such as <code>node:16</code> is safer because it’s more predictable. Only use <code>latest</code> when there&#8217;s no alternative available.
<h3>2. Only use trusted base images</h3>
Similarly, it&#8217;s important to choose trusted base images to protect yourself from backdoors and security issues. The content of the image referenced by your <code>FROM</code> instruction is included in your image; compromised base images could contain malware that runs inside your containers. Where possible, try to use Docker Hub images that are marked as <a href="https://hub.docker.com/search?q=&amp;image_filter=official%2Cstore" target="_blank" rel="nofollow noopener">official or submitted by a verified publisher</a>.
<h3>3. Use <code>HEALTHCHECK</code> to enable container health checks</h3>
Health checks tell Docker and administrators when your containers enter a failed state. Orchestrators such as Docker Swarm and Kubernetes can use this information to automatically restart problematic containers.
Enable health checks for your containers by adding a <a href="https://docs.docker.com/engine/reference/builder/#healthcheck" target="_blank" rel="nofollow noopener"><code>HEALTHCHECK</code> instruction</a> to your Dockerfile. It sets a command Docker will run inside the container to check whether it&#8217;s still healthy:

The healthiness of your containers is displayed when you run the docker ps command to list them:

<h3>4. Set your <code>ENTRYPOINT</code> and <code>CMD</code> correctly</h3>
<code>ENTRYPOINT</code> and <code>CMD</code> are <a href="https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact" target="_blank" rel="nofollow noopener">closely related instructions</a>. <code>ENTRYPOINT</code> sets the process to run when a container starts, while <code>CMD</code> provides default arguments for that process. You can easily override <code>CMD</code> by setting a custom argument when you start containers with <code>docker run</code>.
In the example Dockerfile created above, <code>ENTRYPOINT ["node"]</code> and <code>CMD ["main.js"]</code> result in <code>node main.js</code> executing when the container is started with <code>docker run demo-image:latest</code>.
If you ran <code>docker run demo-image:latest app.js</code>, then Docker would call <code>node app.js</code> instead.
Read more about <a href="https://spacelift.io/blog/docker-entrypoint-vs-cmd" target="_blank" rel="noopener">the differences between Docker ENTRYPOINT and CMD</a>.
<h3>5. Don&#8217;t hardcode secrets into images</h3>
Dockerfiles shouldn&#8217;t contain any <a href="https://spacelift.io/blog/docker-secrets" target="_blank" rel="noopener">hardcoded secrets</a> such as passwords and API keys. Values set in your Dockerfile apply to all containers using the image. Anyone with access to the image can inspect your secrets.
Set environment variables <a href="https://docs.docker.com/engine/reference/commandline/run/#env" target="_blank" rel="nofollow noopener">when individual containers start</a> instead of providing defaults in your Dockerfile. This prevents accidental security breaches.
<h3>6. Label your images for better organization</h3>
Teams with many different images often struggle to organize them all. You can set arbitrary metadata on your images using the Dockerfile <code>LABEL</code> instruction. This provides a convenient way to attach relevant information that&#8217;s specific to your project or application. By convention, labels are commonly set using reverse DNS syntax:

Container management tools usually display image labels and let you filter to different values.
<h3>7. Set a non-root user for your images</h3>
Docker defaults to running container processes as <code>root</code>. This is problematic because <code>root</code> in the container is the same as <code>root</code> on your host. A malicious process which escapes the container&#8217;s isolation could run arbitrary commands on your Docker host.
You can mitigate this risk by including the <code>USER</code> instruction in your Dockerfile. This sets the user and group which your container will run as. It&#8217;s good practice to assign a non-root user in all of your Dockerfiles:

<h3>8. Use <code>.dockerignore</code> to prevent long build times</h3>
The <a href="https://docs.docker.com/build/building/context" target="_blank" rel="nofollow noopener">build context</a> is the set of paths that the <code>docker build</code> command has access to. Images are often built using your working directory as the build context via docker build ., but this can cause redundant files and directories to be included.
Paths which aren&#8217;t used by your Dockerfile, or which will be recreated inside the container by other instructions, should be removed from the build context to improve performance. This will save time when Docker copies the build context at the start of the build process.
Add a <code>.dockerignore</code> file to your working directory to exclude specific files and directories. The syntax is similar to <a href="https://git-scm.com/docs/gitignore" target="_blank" rel="nofollow noopener"><code>.gitignore</code></a>:

<h3>9. Keep your images small</h3>
Docker images can become excessively large. This slows down build times and increases transfer costs when you move your images between registries.
Try to reduce the sizes of your images by only installing the minimum set of packages required for your software to function. It also helps to use compact base images when possible, such as <a href="https://hub.docker.com/_/alpine" target="_blank" rel="nofollow noopener">Alpine Linux</a> (5 MB), instead of larger distributions like Ubuntu (28 MB).
<h3>10. Lint your Dockerfile and scan images for vulnerabilities</h3>
Dockerfiles can contain errors that break your build, cause unexpected behavior, or violate best practices. Use a linter such as <a href="https://github.com/hadolint/hadolint" target="_blank" rel="nofollow noopener">Hadolint</a> to check your Dockerfile for problems before you build.
Hadolint is easily run using its own Docker image:

The results will be displayed in your terminal.
You should also scan built images for vulnerabilities. Container scanners such as <a href="https://github.com/aquasecurity/trivy" target="_blank" rel="nofollow noopener">Trivy</a> can detect outdated packages and known CVEs inside your image&#8217;s filesystem. Running a scan before you deploy helps prevent exploitable containers from reaching production environments.
Check out also <a href="https://spacelift.io/blog/docker-security" target="_blank" rel="noopener">Docker security best practices</a>.

Docker is <a href="https://www.docker.com/blog/key-insights-from-stack-overflows-2022-developer-survey" target="_blank" rel="nofollow noopener">one of the most popular</a> developer technologies. It simplifies modern software delivery tasks by packaging code and dependencies into containers that function identically across multiple environments.
To use Docker, you must first write a Dockerfile for your application. This contains instructions that Docker uses to create your container image. Dockerfiles can copy files from your local build context, run commands within your image&#8217;s filesystem, and set metadata such as labels that help to organize different images.
The Dockerfiles you write aren&#8217;t limited to Docker. The Dockerfile filename is commonly used by convention, but more generic alternatives, such as<a href="https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users" target="_blank" rel="nofollow noopener"> Podman&#8217;s favored Containerfile</a> are gaining momentum. Dockerfile instructions are defined by the <a href="https://opencontainers.org" target="_blank" rel="nofollow noopener">Open Container Initiative (OCI)</a> image specification and produce images that will work with any OCI-compatible container runtime.
Packaging software as a container makes it more portable, allowing you to eliminate discrepancies between environments. You can use the container on your laptop, in production, and within your CI/CD infrastructure. Take a look at how <a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> uses Docker containers to run CI jobs. You have the possibility of bringing your own Docker image and <a href="https://docs.spacelift.io/integrations/docker" target="_blank" rel="noopener">using it as a runner</a> to speed up the deployments that leverage third party tools. Spacelift’s official runner image can be found <a href="https://github.com/spacelift-io/runner-terraform" target="_blank" rel="nofollow noopener">here</a>.

Building a Scalable Infrastructure: Strategies & Best Practices

Learn what Dockerfile is, an example of how to create and use one, and some best practices you should follow.

184-dockerfile

What Is a Dockerfile?

What Is a Dockerfile And How To Build It - Best Practices

<a href="https://spacelift.io/blog/docker-tutorial" target="_blank" rel="noopener">Docker containers</a> are easiest to use with stateless applications because their filesystems are ephemeral in nature. Changes made to a container’s environment are lost when the container stops, crashes, or gets replaced.
You can Dockerize stateful applications such as databases and file servers by attaching <a href="https://docs.docker.com/storage/volumes" target="_blank" rel="nofollow noopener">volumes</a> to your containers. Volumes provide persistent storage that’s independent of individual containers. You can reattach volumes to a different container after a failure or use them to share data between several containers simultaneously.
In this article, you’ll learn what volumes are and the use cases they enable. We’ll also cover some practical examples of using volumes with Docker and Docker Compose.

Volumes are a mechanism for storing data outside containers. All volumes are managed by Docker and stored in a dedicated directory on your host, usually <code>/var/lib/docker/volumes</code> for Linux systems.
Volumes are mounted to filesystem paths in your containers. When containers write to a path beneath a volume mount point, the changes will be applied to the volume instead of the container’s <a href="https://docs.docker.com/storage/storagedriver/#container-and-layers" target="_blank" rel="nofollow noopener">writable image layer</a>. The written data will still be available if the container stops – as the volume’s stored separately on your host, it can be remounted to another container or accessed directly using manual tools.
Volumes work with both Linux and Windows containers. Several different <a href="https://docs.docker.com/storage/volumes/#use-a-volume-driver" target="_blank" rel="nofollow noopener">drivers</a> are available to store volume data in different services. Local storage on your Docker host is the default, but NFS volumes, CIFS/Samba shares, and device-level block storage adapters are available as alternatives. Third-party plugins can add extra storage options too.
<h3>Bind Mounts vs. Docker Volumes</h3>
<a href="https://docs.docker.com/storage/bind-mounts" target="_blank" rel="nofollow noopener">Bind mounts</a> are another way to give containers access to files and folders on your host. They directly mount a host directory into your container. Any changes made to the directory will be reflected on both sides of the mount, whether the modification originates from the host or within the container.
Bind mounts are best used for ad-hoc storage on a short-term basis. They’re convenient in development workflows. For example: bind mounting your working directory into a container automatically synchronizes your source code files, allowing you to immediately test changes without rebuilding your Docker image.
Volumes are a better solution when you’re providing permanent storage to operational containers. Because they’re managed by Docker, you don’t need to manually maintain directories on your host. There’s less chance of data being accidentally modified and no dependency on a particular folder structure. Volume drivers also offer increased performance and the possibility of writing changes directly to remote locations.
<h3>When to Use Docker Volumes?</h3>
Volumes are designed to support the deployment of stateful Docker containers. You’ll need to use a volume when a container requires persistent storage to permanently save new and modified files.
Typical volume use cases include the following:
<ul>
<li style="font-weight: 400;" aria-level="1">Database storage – You should mount a volume to the storage directories used by databases such as MySQL, Postgres, and Mongo. This will ensure your data persists after the container stops.</li>
<li style="font-weight: 400;" aria-level="1">Application data – Data generated by your application, such as file uploads, documents, and profile photos, should be stored in a volume.</li>
<li style="font-weight: 400;" aria-level="1">Essential caches – Consider using a volume to persist the contents of any caches, which would take significant time to rebuild.</li>
<li style="font-weight: 400;" aria-level="1">Convenient data backups – Docker’s centralized volume storage makes it easy to backup container data by mirroring /var/lib/docker/volumes to another location. Community <a href="https://github.com/offen/docker-volume-backup" target="_blank" rel="nofollow noopener">tools</a> and <a href="https://www.docker.com/blog/back-up-and-share-docker-volumes-with-this-extension" target="_blank" rel="nofollow noopener">Docker Desktop extensions</a> can automate the process, providing a much simpler experience than manually copying individual bind-mounted directories.</li>
<li style="font-weight: 400;" aria-level="1">Share data between containers – Docker volumes can be mounted to multiple containers simultaneously. Containers have real-time access to the changes made by their neighbors.</li>
<li style="font-weight: 400;" aria-level="1">Write to remote filesystems – You’ll need to use a volume when you want containers to write to remote filesystems and <a href="https://docs.docker.com/storage/volumes/#create-a-service-which-creates-an-nfs-volume" target="_blank" rel="nofollow noopener">network shares</a>. This can facilitate simpler workflows for applications that interact with your LAN resources.</li>
</ul>
You don’t need to mount a volume to containers that don’t have writable filesystem paths or that only store disposable content. As a general rule, create a volume when your container’s writing data which will cause disruption if it’s lost.

Let’s see how volumes work. You can start a container with a volume by setting the <code>-v</code> flag when you call <code>docker run</code>.
The following command starts a new Ubuntu 22.04 container and attaches your terminal to it (<code>-it</code>), ready to run demonstration commands in the following steps. A volume called <code>demo_volume</code> is mounted to <code>/data</code> inside the container. Run the command now:

List the contents of your container’s <code>/data</code> directory:

The path exists, indicating the volume has mounted successfully, but no files have been created yet.
Add a test file with some arbitrary content:

Next, detach from your container by pressing Ctrl+C or running <code>exit</code>:

The container will immediately stop because there’s no other process running within it.
Now, start a new container that attaches the same volume:

The <code>demo_volume</code> volume already exists so Docker will reuse it instead of creating a new one. This time, the volume is mounted to a different path inside the container, but when you list the path’s content, you’ll see the file that the first container created:

Learn what Docker Volumes are and the use cases they enable with some practical examples of using volumes with Docker and Docker Compose.

Docker vs. Kubernetes: Tools Comparison

Get the newsletter

Recent posts

Docker Networking – Basics, Network Types & Examples

What Is a Dockerfile And How To Build It – Best Practices

Docker Volumes – Guide with Examples

Docker Tutorial for Beginners – Introduction & Getting Started

Share your data and download the guide