How to run Docker commands as non-root user in Doc

Question

I have the following Dockerfile:

FROM docker

RUN addgroup docker && \
    adduser -DH demo && \
    addgroup demo docker

CMD /bin/sh

In this image, I'm creating a user called demo, which is then added to a group called docker. This is pretty much how full fledged environments are set up so that non-root/non-sudo users can issue docker commands. However, it doesn't work for me. What am I missing? I tried mapping the user and groups (via user, and group id's) to the user on the host system, but it still didn't work. I'm running this in Docker for Mac Beta (1.12.0-rc3-beta18).

Answer 1

This is an extension to the problem's comment.

So OP's use-case is about investigating a continuous integration environment through using the docker within docker architecture, or approach if you like.

From docker's official blog posting for nested containers, yes this can be done however, as explained further by jpetazzo, a pioneer contributor to the nested container concept; to get the architecture to work properly a significant amount of hackie effort might be needed as the nesting architecture is not perfect mainly due to the following disadvantages;

Example:

1 - Security profile

When starting a container, the “inner Docker” might try to apply security profiles that will conflict or confuse the “outer Docker.”

2 - Storage

The second issue is linked to storage drivers. When you run Docker in Docker, the outer Docker runs on top of a normal filesystem (EXT4, BTRFS, what have you) but the inner Docker runs on top of a copy-on-write system (AUFS, BTRFS, Device Mapper, etc., depending on what the outer Docker is setup to use). There are many combinations that won’t work. 2 3 - Difficult to reuse images in child containers

And what about the build cache? That one can get pretty tricky too. People often ask me, “I’m running Docker-in-Docker; how can I use the images located on my host, rather than pulling everything again in my inner Docker?”

Q) Possible solution to this problem?

A: I guess the reason why OP was experimenting with a nested container architecture was so that he can use a container, as some form of root, then orchestrate its child containers through docker commands?

If that is the idea then this is still achievable through the standard non-nested way. That is, instead of sending docker commands down the stream, you send it back to the host instance and let the host instance do the command for you the root container instead. Example; use docker REST api to send docker commands from a container.