When copying content to the local disk, by default "." is the destination used. This is intentional, but it would be more informative in the logs if the pwd was provided to the user instead of "."

See https://github.com/exdx/coreutils/blob/main/utils/src/lib.rs for an example of a color library based off the colored package. We could introduce the same crate here and then have a flag that can optionally color all output.

https://github.com/vv9k/podman-api-rs is a rust i/f to podman

By same author, perhaps the single lib https://github.com/vv9k/containers-api would allow access to both?

• Add docs on using a custom socket
• Add e2e tests on a windows VM for docker
• Add/update docs on windows support

Add a quick gif that shows the tool in action for new users.

$ dcp quay.io/operator-framework/rukpak:latest
 ERROR dcp > ❌ error 404 Not Found - manifest for quay.io/operator-framework/rukpak:latest not found: manifest unknown: manifest unknown
 DEBUG dcp > 📦 Created container with id: "b529d9210b1ec503ff8e90a0e8d83ef6cbc232161f0f59d68bceedebed919eb4"
 INFO  dcp > ✅ Copied content to . successfully
 DEBUG dcp > 📦 Cleaned up container "b529d9210b1ec503ff8e90a0e8d83ef6cbc232161f0f59d68bceedebed919eb4" successfully

dcp does successfully copy the container filesystem, but it gives a misleading error when presented with an image that is not on a remote registry (just one built locally). It should first check to see if the image is available locally before attempting to pull it.

https://github.com/containers/youki is a new container runtime written entirely in Rust. It would be cool to support a youki runtime in dcp alongside docker and podman.

Use-case:
I want to be able to see the labels on the particular container image I am interested in, to inform what I would like to copy.

A/C:
Provide a dcp describe command that can show the labels associated with a particular image.

The current method of connecting to the docker socket, via the unix:// path, does not work on windows systems. Connecting in an alternative way would enable support for windows.

Running cargo test results in a manifests directory being added to the root-level, producing a git diff. This directory should probably go into the /tmp test directory for now

https://github.com/runfinch/finch

sbom is a new docker API, see https://www.docker.com/blog/announcing-docker-sbom-a-step-towards-more-visibility-into-docker-images/ for details.

It would be interesting if dcp could optionally emit the sbom for a particular image, and save the file in the same location as the contents being copied.

This feature is for a shell that opens so one can explore the files of a container without actually running the ls command inside it.

This functionality is similar to the dive tool. Potentially the feature should just be a dive integration but that project is in Go versus Rust.

cc @tylerslaton

As a user, I would like to use dcp with a custom socket, either a remote socket or one on my host in a different location.

dcp should have a command-line flag to set a custom socket path.

Notes:

• The user would also have to supply which runtime the socket is meant for, since both docker and podman sockets are options

Instead of a custom error implementation, use the popular anyhow library to generate application errors in an idiomatic fashion.

The -w flag is currently unimplemented. Provide an implementation that writes the tar archive contents to stdout.

It would be nice to have some light instructions for how to compile dcp from source using an existing rust binary.

Since dcp has stabilized, it would make sense to release it to the wider community. As a first step, releasing it on crates.io lets Rust users install dcp via cargo install.

When copying data from the container to the local filesystem, there should be a choice whether or not to preserve the original permissions of the files in the container. I think this may be possible, based on the underlying tar unpack command.

Hi, i come across a issus with Error: failed to unpack when i unpack a image to local folder. And i understand why this happened by FAQ.
But i have a question about how it works. Does it unpack all the image files expect the ones like symlinks, or just stop unpacking when it fail to unpack a file? Thanks!

Right now, dcp only extracts one directory from the image, provided via a mandatory command-line argument. As a user, I want to extract multiple directories (for example, /manifests and /metadata) from the image in one invocation of dcp.

A/C:

• Support specifying multiple directories as command line arguments, either comma separated or space separated, and have dcp copy these multiple directories out

Right now the container is created, the files are copied, and then the program exits. The program should cleanup the container after it's done.

As a user, I would like to debug a live container running in my k8s cluster by copying files from that container's filesystem to my local filesystem.

For example,

dcp --cluster-container namespace/pod -d /tmp/data -c /data

The functions that currently check whether an image is on-disk are very imperative and a sequence of for statements. They do the job, but can be rewritten to be more functional and clear.

A/C:
Rewrite

In a recent PR we were going to introduce an FAQ section to the README. However, we decided it would be a bit more scalable if we just added a question label for issues and backfill with the frequently asked questions. From there we could just link an issue filter in the README.md for easy access.

Follow-up to #51

The logging output right now is not very clean. Using a logging library and providing structure logs should be sufficient. Also, provide a log indicating the content was copied succesfully (from where to where)

dcp-demo: ./dcp quay.io/tflannag/bundles:resolveset-v0.0.2
PullStatus { status: "Pulling from tflannag/bundles", id: Some("resolveset-v0.0.2"), progress: None, progress_detail: None }
PullStatus { status: "Pulling fs layer", id: Some("8d646b05728d"), progress: None, progress_detail: Some(ProgressDetail { current: None, total: None }) }
PullStatus { status: "Downloading", id: Some("8d646b05728d"), progress: Some("[==================================================>]     411B/411B"), progress_detail: Some(ProgressDetail { current: Some(411), total: Some(411) }) }
PullStatus { status: "Verifying Checksum", id: Some("8d646b05728d"), progress: None, progress_detail: Some(ProgressDetail { current: None, total: None }) }
PullStatus { status: "Download complete", id: Some("8d646b05728d"), progress: None, progress_detail: Some(ProgressDetail { current: None, total: None }) }
PullStatus { status: "Extracting", id: Some("8d646b05728d"), progress: Some("[==================================================>]     411B/411B"), progress_detail: Some(ProgressDetail { current: Some(411), total: Some(411) }) }
PullStatus { status: "Extracting", id: Some("8d646b05728d"), progress: Some("[==================================================>]     411B/411B"), progress_detail: Some(ProgressDetail { current: Some(411), total: Some(411) }) }
PullStatus { status: "Pull complete", id: Some("8d646b05728d"), progress: None, progress_detail: Some(ProgressDetail { current: None, total: None }) }
PullStatus { status: "Digest: sha256:145ccb5e7e73d4ae914160c066e49f35bc2be2bb86e4ab0002a802aa436599bf", id: None, progress: None, progress_detail: None }
PullStatus { status: "Status: Downloaded newer image for quay.io/tflannag/bundles:resolveset-v0.0.2", id: None, progress: None, progress_detail: None }
"1fbb062dd17ccfd444843b29a5f99a886ef11b4c8ef03c522f1c17fbd224b5d7"

Use-case:
I want to extract a particular file from a container, but am not sure where it is located ahead of time.

A/C:
Provide an dcp ls command that can list the files on the container filesystem and write the list to stdout. The user then can use the -c flag to extract just the particular file they are interested in.

The input image reference currently requires a tag and does not accept a digest.

Example error with version 0.3.1 on linux:

dcp icr.io/cpopen/ibm-iam-operator-bundle@sha256:c63fdfbbeb3314d3ee889bee86139aa0bf6dd4a69f7e63139b6608abae0b3e5 -c manifests
 DEBUG dcp::image > 📦 Searching for image icr.io/cpopen/ibm-iam-operator-bundle@sha256:c63fdfbbeb3314d3ee889bee86139aa0bf6dd4a69f7e63139b6608abae0b3e5 locally
Error: ❌ error pulling image: error 400 Bad Request - invalid reference format

As a user, I would like dcp to be able to create a directory (a subdirectory of the current working directory, for example) when unpacking contents, so I don't need to create the directory manually before hand.

One option is to introduce a new flag, -o, that when set creates a directory on the local filesystem.

Another option is to use the existing -d flag to create a directory if one does not exist already.

Running dcp registry.ci.openshift.org/ci/determinize-ci-operator:latest I encountered the following error:

 DEBUG dcp > 📦 Created container with id: "263a233eb2dda832375e57d078bbce5d407ec42239a6b924f2d251b7b2758147"
Error: Custom { kind: Other, error: TarError { desc: "failed to unpack `/Users/dsover/code/src/ci-operator-config/usr/bin/perl5.26.3`", io: Custom { kind: Other, error: TarError { desc: "trying to unpack outside of destination path: /Users/dsover/code/src/ci-operator-config", io: Custom { kind: Other, error: "Invalid argument" } } } } }

I believe this error is coming from the tar library. It suggests that a file in the container filesystem is outside of the destination filepath, and tar doesn't allow this for security reasons. This may be a symlink file. I'm not sure how to recover from this error, since fundamentally unpacking outside the destination path is insecure.

Summary

We should go ahead and add some simple E2E tests that establish how we create them moving forward. As a first pass, it likely makes sense to make a few tests that guarantee the flags being passed are working as intended.

copy files into docker

I tried running dcp on an OLM registry+v1 bundle image but that failed with the following error:

$ dcp --content-path output registry.redhat.io/openshift-update-service/cincinnati-operator-bundle@sha256:3feccb95e912f2d710958e701a1b52acf16a676fde9a8219491ad9381e6284ea
error 400 Bad Request - invalid reference format
"d8f1b22b1239673912ad2555e16e3e790c994d9d87f599f044c808160b246b56"
Error: Error(Fault { code: 404, message: "Could not find the file output in container d8f1b22b1239673912ad2555e16e3e790c994d9d87f599f044c808160b246b56" })

And that image is pullable via docker:

$ docker pull registry.redhat.io/openshift-update-service/cincinnati-operator-bundle@sha256:3feccb95e912f2d710958e701a1b52acf16a676fde9a8219491ad9381e6284ea
registry.redhat.io/openshift-update-service/cincinnati-operator-bundle@sha256:3feccb95e912f2d710958e701a1b52acf16a676fde9a8219491ad9381e6284ea: Pulling from openshift-update-service/cincinnati-operator-bundle
d83fa9b96fa1: Pull complete 
Digest: sha256:3feccb95e912f2d710958e701a1b52acf16a676fde9a8219491ad9381e6284ea
Status: Downloaded newer image for registry.redhat.io/openshift-update-service/cincinnati-operator-bundle@sha256:3feccb95e912f2d710958e701a1b52acf16a676fde9a8219491ad9381e6284ea

Add user/password flags and provide those flags to the pull command