view / download files from UI

[robbuckley]

It would be really handy to be able to view small text files within the UI. Also to be able to download a selected file (to the local filesystem) would be super convenient

[eine]

@robbuckley, what do you mean with 'the local filesystem' in the context of running dive in a docker container? I'd like it to be the host where the container is running, and not the container itself. However, dive should not be able to 'explore' the host (that's the main purpose of containers). I can think of three options:

• Make the content of the image available in a predefined location inside the dive container (or a volume). Expect users to use docker exec and/or docker cp.
• Bind/mount a path. dive would copy selected files to that path.
• Bind a port. dive would serve directories/files through HTTP, so any browser could be used to download the content.

Based on the last approach, it is already possible to copy all the content of any image to a dummy container and use a tool such as filebrowser to browse it. For example:

FROM filebrowser/filebrowser
COPY --from=wagoodman/dive / /tmp/dive

[robbuckley]

@1138-4eb i mean the equivalent of docker cp for a single file. For example, while exploring the container contents, select a file, hit 'save locally'. This would save a copy of the file to cwd on the host's filesystem. Or to make it even slicker, pull up a 'save as' dialog, allowing the user to specify a different path/filename to save as on the host

[eine]

@robbuckley, the point is that, when dive is started as follows:

docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest <IMAGE>

executing docker cp CONTAINER:SRC_PATH DEST_PATH internally will place files in DEST_PATH inside the container, because docker-cli is being executed in it (even though the docker daemon is on the host). Since there is no shared/mount/bind volume, the container cannot copy files to any location on the host. The best it can do is show a command on screen which you can copy and paste on a different shell running on your host.

That's why I suggested three approaches. Precisely, the third option is an alternative to provide a 'Save as' dialog, which must be handled by the host, not by dive.

[wagoodman]

Slick, I like the idea. To sum it up generically: you're looking for a way while your're browsing layer contents in the UI to export a single file onto your host to you can inspect the contents.

I'll have to think of the best way to do this. Currently dive throws away the file content, as it can take up a lot of space and currently isn't needed for the UI. Though, there are a number of requested features that would require the image file content to implement, so it sounds like there is some gaining appeal. As for how to get the file to the host, @1138-4eb you bring up some good approaches (the third option is clever, but also possibly non-obvious).

[eine]

export a single file onto your host to you can inspect the contents

In my case, I don't want to export it in order to inspect it, but to use it. For inspecting the contents, I think that dive's UI is ok. Optionally, common utilities such as less or vim can be used.

Regarding my comment above ("the container cannot copy files to any location on the host"), upon further thinking, it might be possible for dive inside the container to copy content to any location on the hots. In order to do so, dive needs to copy the desired files to a docker volume, and then start a temporal container where both the volume and a path from the host are bind.

[brightzheng100]

Do we have an easy way to select and view specific file's content through dive's UI, at least?

[fstaats]

It is a great tool which I use regularly. It would be very useful to be able to view / export individual files from specific layers within the dive GUI. It would also be very useful to compare two files between layers (for example if a config file is overridden from one layer to another). It is easy enough to inspect and extract from my own containers. But when inspecting 3rd party containers I want to know what has been modified in order to evaluate why it has been changed.

[abitrolly]

I needed this again, so I wasted a day to discover Google crane, which can do this. It still doesn't work with local images, so I tried to fix that, but failed so far.

[Rom1deTroyes]

Got an usecase for this today :

• an image does not start and exit with a Exited (139) code...
• No log from docker (just ""),
• I can't log in and see what happend (container not starting),
• I don't have the dockerfile (only the image), so I investigate with Dive, and want to review some conf files inside the image.

Thanx for the tool, it's great for other use cases :-)

[pibylick]

+1 for this feature, viewing file content from UI would be very nice

[yurenchen000]

the cli way (to get file from docker image layer):
#336 (comment)

[TheRealGramdalf]

A simpler CLI method: https://unix.stackexchange.com/questions/331645/extract-file-from-docker-image

[abitrolly]

I've fixed crane to work with image streams from stdout. See above. Now it is possible to list, view and extract files from a local container image using crane and podman itself.

To view /etc/passwd from an image in local podman registry.

export IMAGE=bb2-make-single
podman image save $IMAGE - | crane export - - | tar -Oxf - etc/passwd

Note the missing front slash etc/passwd. With slash it doesn't work.

[faelin]

@wagoodman — it would be spectacular to combine with some tools like fzf and bat to provide fuzzy-searching and an in-UI preview of files. The preview could even be a hotkey based "load-on-demand" using something such as docker run some_image cat "$file_path" > "$output_path" behind the scenes in order to load the preview. That would alleviate the need to keep the entire container contents (since you noted that dive already throws away the raw content).

Even if you don't use those two specific tools, I imagine that a hotkey-driven on-demand load should be possible without adding a lot of extra size (though I would definitely advocate for file-caching to avoid re-extracting the file repeatedly if the user is, for example, flipping back and forth between two files to compare them).