Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Introduce either format or save option to Compose v2 to save images in a compose project as tar balls #9471

Open
shantanoo-desai opened this issue May 17, 2022 · 6 comments

Comments

@shantanoo-desai
Copy link
Contributor

Description
Currently Docker Compose v2.5.0 provides a command call docker compose images which will list the images / containers within dedicated docker-compose.yml file.

There is currently no way to use these --format option alongside with e.g. docker compose images --format="{{.Repository}}:{{.Tag}}" in order to save the images as tarball.

A common usage pattern with Docker CLI would be:

docker save -o myStack.tar $(docker images --format "{{.Repository}}:{{.Tag}}")

The above however requires to have a host with only the dedicated container images. In most if not all cases, host machine have many container images which may not be required in the compose project.

A potential introduction of either docker compose images --format would be useful to pack the images into a tarball without having to remove other containers outside a dedicated project or provide docker compose save to achieve the same.

Steps to reproduce the issue:
Current method of creation of tar balls is:

docker save -o myStack.tar $(docker compose images -q)

This is a bit problematic, since -q only lists the Image IDs of the container. In situations where the tarball is loaded onto an offline machine with the dedicated docker-compose.yml file, upon triggering

$ docker load -i myStack.tar # will load the images but won't have names and version in them
$ docker compose up # will try to pull the images from hub because compose files have `name:version` in them

docker compose will try to pull images from the Hub, because as standard usage each image in a compose file is always mapped with a name:version as opposed to Image Hashes

Describe the results you expected:

by using docker compose save -o <tarballname>.tar one would be able to save the images

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose v2.5.0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.2)
  compose: Docker Compose (Docker Inc., v2.5.0)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 15
  Running: 6
  Paused: 0
  Stopped: 9
 Images: 8
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.16.3-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 24.78GiB
 Name: docker-desktop
 ID: AM3A:EIDA:J3BS:FMN2:MZMR:3CBY:YHXN:US7Q:BIKM:7POA:WAGC:MRWX
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false
@ndeloof
Copy link
Contributor

ndeloof commented May 17, 2022

👍 it would be interesting to evaluate if we can offer the equivalent for docker save / docker load as compose commands for all service images

@shantanoo-desai
Copy link
Contributor Author

I am of the opinion that a --format should be sufficient. Since compose now is part of the docker CLI using a combination of

$ docker save -o myStack.tar $(docker compose images --format="{{.Repository}}:{{.Tag}}")

should be sufficient. This gives the end user more usage benefits of filtering. Providing docker compose save and docker compose load would make sense if docker itself provided some isolation environment (think like python's virtualenv). Just an opinion though

@shantanoo-desai
Copy link
Contributor Author

@ndeloof any plans, updates or Roadmap for this feature request, if you want I can try my hands on it, given it complies with the team.

@yywing
Copy link

yywing commented Sep 22, 2022

export

docker save -o test.tar $(docker compose convert --images)

....

load:

docker load  < test.tar
docker compose up -d

@0x0elliot
Copy link

hey, i would like to take up this issue if you won't mind. @ndeloof can i proceed? any kind guidance from your side :)?

@mactijn
Copy link

mactijn commented Feb 21, 2023

I for one would love to see docker compose save / load commands. Or rather, something akin to docker compose install.

I believe my use-case is somewhat similar to the functionality as the now-defunct Docker App, in that I use Docker to deploy a rather large software stack on 3rd party machines.

A related feature would be to auto-run a container after loading. This container, with some sensible bind mounts, would be responsible for stack configuration (rendering templates to configuration files etc.). However, I reckon this is potentially somewhat out of scope for this feature request

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants