Should this image contain the docker run time?

[james-nesbitt]

There are some cases where we need to use a docker run inside which we may run docker commands. It may be usefull to add the docker runtime cmd to this image, so that it can be used.

An example is:

• in a docker run, use a script to build an image
• in a docker run, inspect other docker containers to determine if a certain role is needed (like db server)
• in a docker run, operate on a remote docker server

There should be no security issues, as any privileged access would require permission from the docker run using this image.

[james-nesbitt]

The change required would be:

# Install docker cmd
RUN apk --update --no-cache add docker && \
         rm -rf /tmp/* && \
         rm -rf /var/cache/apk/

[aleksijohansson]

@james-nesbitt Why run docker inside docker and not just run directly?

[james-nesbitt]

@aleksijohansson There are a number of reasons to use dockerception, but the primary is to create an image from inside a container.

For example:

I would like to run composer to get the some vendor supplied, and then add some custom code to create a source image. I don't really want php run-time, nor composer to be available in that image (nor on the host) I can use a Docker run as an intermediate environment from which I can create an image. I can also handle image creation errors inside that script. There are ways around it, using sequential runs, but then you may end up with funcitonality split across scripts: 1 for inside the run, and one to coordinate the run and the build.

[aleksijohansson]

@james-nesbitt Thanks for the explanation, makes perfect sense to have docker inside docker. Please provide a pull request and I'll be happy to merge that.

[james-nesbitt]

will do

[james-nesbitt]

https://github.com/wunderkraut/image-fuzzy-alpine-devshell/issues/56 delivers this.

[aleksijohansson]

@james-nesbitt The latest release v7.0.12-3 includes this and is now ready at https://quay.io/repository/wunder/fuzzy-alpine-devshell

[james-nesbitt]

as a follow up: more situations where you want docker runtime, that don't require privbileged containers:

1. running related docker operations on other docker engines
2. checking the status of a docker container/image before running an operation