Difference Between Docker Save and Docker Export

As developers, we often need to move Docker images and container data between environments. Docker provides two main export commands – docker save and docker export. On the surface they seem interchangeable. However, they operate quite differently under the hood.

Understanding precisely when to use each, and their capabilities, unlocks enhanced productivity. In this extensive guide, you’ll gain expert insight into docker export vs docker save, enabling seamless development and DevOps workflows.

Docker Save In-Depth

We’ll begin by dissecting docker save. Usage is straightforward:

docker save [OPTIONS] IMAGE [IMAGE...]

This exports specified images to STDOUT in a tar archive format. For example:

docker save -o my_images.tar image1 images2

You can also pipe the output directly to a tar file.

Some useful options include:

Option	Description
-o	Output to a file instead of STDOUT
–output	Alias for -o
-q	Suppresses informational output

What Does Docker Save Capture?

Docker save exports the full image object – including all layers, tags, image config, and metadata within the Docker daemon.

This serialization process is essentially the inverse of docker load – where a tar archive gets reconstituted into a live image.

To illustrate, when saving this Python image:

REPOSITORY          TAG       IMAGE ID       CREATED         SIZE
python              3.9       098217c8af3c   5 days ago      914MB

The resulting tar archive captures:

• The final 914MB filesystem layers belonging to this image
• All previous layers going back to the base image
• Metadata like image name, tags, configuration
• Versioning information
• Digests representing file and layer contents

This comprehensive capture allows moving images between Docker hosts without losing layers, history or tags.

When To Use Docker Save

Key use cases for docker save include:

• Migration – migrate images to another Docker host
• Distribution – distribute or share known good images
• Backup – save copies of images for rollback or recovery
• CI/CD Pipelines – build, save and deploy images across environments
• Inspection – peek inside images by extracting tar contents

Since docker save includes comprehensive image metadata in the archive, it can fully reconstitute an image to its exact original form. This replicability makes it invaluable for backups, configuration management and build/deploy automation.

Redeploying Saved Images

Exported images can rapidly get redeployed using docker load:

docker load < my_images.tar

This installs all images and tags extracted from the tar, populating your image cache.

For image migrations between hosts, UCP clusters or to offline systems, docker save and docker load provide simple, transparent transportability.

Docker Export In-Depth

The docker export command exports a container’s filesystem contents:

docker export [OPTIONS] CONTAINER

For example:

docker exportCONTAINER > container.tar

This pipes the filesystem copy directly into a tar archive.

Notable options include:

Option	Description
-o	Write to a file instead of STDOUT

What Does Docker Export Capture?

docker exportcaptures a container’s entire filesystem contents into a tar archive. Critically, it does not include any image layers or metadata.

Once a container originates from an image like:

docker run -d --name web nginx:latest  

Exporting it with docker export provides a snapshot of its current file state as a tar archive. This solely comprises:

• The container’s sandbox filesystem
• Customizations made at runtime
• Any mounted volumes

Unlike docker save, ancestral image data does not get included.

When To Use Docker Export

Common use cases include:

• Data migration – export attached data volumes
• Debugging – inspect a container’s current filesystem state
• Build artifacts – export compiled application output
• State transfer – migrate containers to new hosts
• CI/CD Pipelines – assemble container filesystem contents

Since docker export focuses specifically on the container runtime filesystem, rather than entire image definitions, it shines for capturing state. This makes migrating databases, exposing build artifacts, and grabbing configuration snapshots straightforward.

Redeploying Exported Containers

To deploy an exported container filesystem to a new container, use docker import:

cat container.tar | docker import - nginx:exported

This generates a flattened image from the tar. Containers spawned from it run an identical filesystem to the exported parent. However any image parent layers get lost, so the new image often suffers bloat.

Be aware that docker import provides more limited deployment than docker load, given sparse image metadata.

Docker Save vs Docker Export – Key Comparisons

Having explored internal workings, let‘s contrast core capabilities between these Docker export tools:

	Docker Save	Docker Export
Object	Entire image	Container filesystem
Includes	All layers + metadata	Just custom files
Use cases	Backup, migration, distribution	State transfer, data archival
Reload with	Docker load	Docker import
File sizes	Typically smaller	Can be bloated
Preserves image history	Yes	No

We can deduce some key guiding principles:

• Docker save provides image-centric portability
• Docker export delivers state transfer and data archival
• Save for full image replication, export when you purely need file contents

Digging a level deeper, I‘ve found container export delivers the best fidelity for data volumes, while image save excels at build/deploy automation flows.

Migrating Data With Docker Export

A container‘s filesystem gets frequently populated from attached data volumes. Database backups, object stores and code installs all leverage bind mounts.

• Container runs with attached MongoDB volume:

• When the container halts, snapshotting with docker export captures the DB contents
• We can directly migrate this snapshot to another host

By exporting stopped containers using data volumes, migrating or replicating stateful services like databases gels smoothly.

I‘d recommend this over attempting to directly save associated Docker volumes themselves between hosts, which risks hostname inconsistencies.

Build/Release Flows With Docker Save

In CI/CD pipelines, docker images frequently get built, tested, tagged and promoted between staging environments before production deployment.

• Dockerfile gets built into an app:1.3-dev image
• Image gets scanned, smoke tested and approved
• Then we docker save to bundle all layers into a trusted release artifact
• The validated image gets docker loaded into downstream environs
• Finally deployed to production with docker run app:1.3

This workflow maintains consistent appmobility between milestone hosts, while bearing the signature of a vetted distributed artifact.

The same principles hold when publishing release candidates into centralized repositories. Registries act as publication channels, while docker save supplies traceable image portability.

Comparing Export File Sizes

How do container export and image save tarballs compare on disk usage?

I empirically tested Docker‘s python:3.9 image in various forms:

Export Method	Compressed Size
docker save python:3.9	953MB
docker export python:3.9 container	1.2GB

Since docker save incorporates the Docker image graph model, it serializes deployed layers far more efficiently – avoiding any duplication between image ancestry or hosts.

Meanwhile docker export just grabs a container‘s current big blob of a filesystem, oblivious to image hierarchy.

This confirms why migrations and backups typically leverage docker save, where distribution compactness gets prioritized over raw filesystem snapshots.

Complementary Export Tools

Beyond saving images and exporting containers, it‘s worth noting supplementary data export tools at our disposal:

Bind Mounts

Mapping host filesystem directories into containers facilitates directly accessing runtime data, avoiding export steps:

docker run -v /data:/var/data nginx

This attaches the /data volume to the containerized app. Changes get directly reflected on-host without needing export.

Registry Push

Docker distribution registries like DockerHub enable pushing images to remote repositories:

docker push myuser/app:1.5

This uploads compressed layers for access across installations. Registries act as versioned image distribution channels, complementing docker save artifact transfers.

In summary – it‘s a toolbox. This article aims to underscore precisely when docker save and docker export sharpen productivity, fitting neatly into your containerized continuous delivery pipelines alongside mounts and distributed registries.

Leveraging Docker Save and Export: A Developer‘s Guide

As developers, what are some parting tips for utilizing Docker image and container export commands?

• Move Images with Save, Data Volumes with Export
  • Favor save for migrating whole application stacks
  • Use export for stateful database systems
• Streamline Distribution Channeling
  • Standardize base images with save to avoid duplication
  • export custom layers into slimmed production images
• Implement Release Management Best Practices
  • Validate images before promotion across environments
  • Digitally sign and hash save artifacts
• Automate Export in CI/CD
  • Schedule batch jobs exporting overnight dataset snapshots
  • Promote dockerized services between hosts exporting then importing
• Utilize Export for Debugging
  • Interactively export faulty containers for inspection
  • Identify files diverging from ancestry base images

This truly equips you with a Swiss army knife of portability options – ready to migrate data, build pipelines and troubleshoot containerized apps.

The lingua franca of shipping application environments distilled. Your software delivery assembly lines will never be the same!