Reconstruct a dockerfile docker-compose file from a rocker setup

[blooop]

This might be orthogonal to the aim of the project, but I was wondering if its possible to generate a dockerfile and docker-compose file from a rocker configuration.

The reason is that I use vscode with the devcontainer extension for development, and if I can pass it a docker or docker-compose file, then its possible to have a fully self contained development environment without any dependencies on external tools.

The workflow would be something like this:

1. I set up an environment with rocker.
2. Once I confirm that it has all the features I need, I export to a dockerfile.
3. Include the dockerfile in the vscode repo
4. Another user can recreate the development environment without needing to install rocker.

Thanks

[tfoote]

Yes, this is something that would be great to add support. Right now with the dry run mode you get the execution out as a command line script to copy. But it should be relatively easy to extend/adapt it to generate a docker-compose file instead.

It sounds like you're looking for fully baked images that are runtime environment, that's fine but less reusable.

I've also envisioned prebuilding and publishing images with the build time customizations which are not deployment specific to optimize and avoid potentially longer build times.

[blooop]

Thanks.

Yeah, I change environments more infrequently, but rocker still makes the setup of those environments simpler. Day to day I only use one environment so I was looking to optimise that use case with vscode.

I will take a look at the dry run mode.

[tfoote]

Yeah, I change environments more infrequently, but rocker still makes the setup of those environments simpler. Day to day I only use one environment so I was looking to optimise that use case with vscode.

That makes sense, it would be great to have a good story for vscode dev containers and use cases like yours.

The other potential for thinking about generating runtime is a kubernetes pod definition. Which would give you 3 potential execution environments, docker daemon/command line, docker-compose, or kubernetes. Thinking about generalizing to this will help avoid potentially over-fitting to docker-compose.

I will take a look at the dry run mode.

Dry-run just tells it not to execute and just leaves it at printing the command. I actually prints the command before running it, but it usually goes away quickly with the potentially large volume of console outputs making it harder to debug.

[blooop]

I have not had time to look into this yet, but came across dockge: https://github.com/louislam/dockge which has a feature for generating a docker-compose file from a docker run command.

[tfoote]

Interesting, I searched quickly for just that and there's several projects doing specifically that conversion. but one caught my eye https://github.com/composerize/composerize

With a docker wrapper too https://github.com/sharevb/composerize-docker that might be possible to automatically convert instead of requiring plugin maintainers to do both implementations.

[blooop]

I have a very early proof of concept working now using:
https://github.com/Red5d/docker-autocompose

rocker --nvidia --x11 --user --pull --git --image-name "$CONTAINER_NAME" --name "$CONTAINER_NAME" --volume "${PWD}":/workspaces/"${CONTAINER_NAME}":Z --oyr-run-arg " --detach" ubuntu:22.04 

docker pull ghcr.io/red5d/docker-autocompose:latest
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/red5d/docker-autocompose $CONTAINER_NAME > .devcontainer/docker-compose.yaml

#stop the container to stop vscode complaining that the container is already running (when using vscode to launch later)
docker stop "${CONTAINER_NAME}"

which creates a docker-compose.yaml file in the .devcontainer folder.

I also have a devcontainer.json:

{
	"name": "python_template",	
	"dockerComposeFile":"docker-compose.yaml",
	"service": "python_template",
	"workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}"	
}

Once I have run the script that uses rocker to generate the compose, I can use the vscode "Reopen in container" task.

Caveats:

• The compose file that is generated is not portable at all. You need to run the script that calls rocker on every machine so that the correct files are generated on the host machine. A lot of these files are in the /tmp folder which also seems like its asking for problems.
• This does not work with vscode tasks such as "Rebuild and Reopen in container", "Rebuild without cache and Reopen in container" This first time I tried these commands it just crashed vscode, the second time vscode attached to the container, but of was not able to rebuild because there is no docker file.
• I'm not sure I like this approach more than what I was doing before, which was using rocker to launch a container, and then attaching to it with vscode. I started looking into this because I found the caching wasn't working well with rocker so it took ages to rebuild and launch with rocker.

Question:
The dry run mode outputs more than just the dockerfile. Is there a way to access the dockerfile directly without parsing the dry run output? I tried catting location of the temporary file:

Writing dockerfile to /tmp/tmpzzhmwxvt/Dockerfile

but it seems that file is deleted by the time the rocker command ends.

Thanks

[blooop]

I have found and fixed the issues that were causing cache misses. Now that I have rocker working properly and have encountered the docker-compose caveats, I don't think this is a good avenue to go down. Creating a docker-compose was an attempt to integrate better with devcontainers, but I think its not a good solution. I'm interested to see how #270 progresses.

I'm closing this issue but I would still be interested in knowing the best way to directly access the temporary dockerfile that rocker creates.