docker login credentials not made available to non-root provisioned user about azure-docker-extension

[ahmetb]

@s093294 I think this is happening because registry credentials are saved in root's $HOME (/root/.docker) simply because the extension runs as root. Your user's (pksorensen) $HOME is different (/home/pksorensen/.docker).

If you pull the ascend/tiling image via Azure Docker Extension, it should work. If you want to run docker commands as your user, you should probably login again using docker login or switch to root (sudo -i).

[ahmetb]

In other words, this is by design for now. If you think you could work around this easily, then we may keep it as it is. If you have a good use case for it, then we might perhaps find a way to pass the credentials to the non-root user as well.

[pksorensen]

Ye, its okay for now. I am also in design phase and could consider to run everything under sudo -i.

One usecase where it would be nice that the credentials was also populated to the active user is for the swarm cluster setup. (which is the one I am using atm). When each slave node is logged in using docker extension.

When sshing into one of the masters - I wonder if doing sudo run on the master with DOCKER_HOST configure for the manager, if swarm will also be using sudo on the slave nodes for running (I would assume not).

In my arm template, i do have the adminusername, so if its a simple matter of copying the content of /root/.docker to /home/adminusername/.docker I could do this is a custom script extension.

[ahmetb]

@s093294 I suggest establishing an SSH tunnel to the swarm manager from your development machine instead of actually SSHing and setting DOCKER_HOST etc. to manage the swarm cluster. The docker-swarm ARM template we have has output commands (such as "sshTunnelCmd") that allows you to easily establish a tunnel to the cluster.

If you create a swarm cluster with the extension (what docker-swarm ARM template does), the slave nodes should be picking up the credentials. This is the case because the docker engine is started as root and it'll pick up the credentials supplied and swarm manager will directly talk to docker engine. (It doesn't matter if you do sudo docker run targeting swarm manager; manager does not store any registry credentials).

Right now, setting environment variables etc on the master manages seem like a bit out of scope for the Azure Docker Extension (as it is more general purpose than the docker-swarm ARM template and has no notion of Swarm) and it certainly increases the surprise factor for any user of the extension (not to mention it will probably break existing users' environments).

We can continue discussing whether we should populate the environment/credentials for the swarm template on email if you like. I believe it will better to stick with the recommended method (SSH tunnels) to manage swarm clusters.

[pksorensen]

I agree that the docker extension should not add environment variables.

I added a CustomScriptForLinux extension to all master nodes with the following command:
"commandToExecute": "/bin/bash -c 'echo \"DOCKER_HOST=:2375\" >> /etc/environment'"

Then it defaults for me to the swarm manager when sshing in or when i use sshClient from c#

 using (var client = new SshClient(host, 2200, "pksorensen", new PrivateKeyFile(File.OpenRead(@"C:\dev\pksorensen.oss"))))
            {
                client.Connect();

now docker info gives the cluster info.

var infohost = client.RunCommand("docker info");

now running a command that rely on a image in the private hub.

  var commandb = string.Format("docker run --rm -i -m 1536M {0} ascend/tiling  /bin/bash -c \"cd /;mkdir /dataout;AscendTiling /data1/{1} /dataout {3} {4} {5};tar -zcvf {2} -C /dataout .;mv /{2} /data1/{2}\"",
                                string.Join(" ", CreateVolume(tileAShareOut, "data1")), tileName, zipName, xstart / 256, ystart / 256, maxZoom - 6/*// 16384 is 6 zoom lvlz */);

                                var infob = RunCommand(commandb, client);

it fails with

Error response from daemon: Error: image ascend/tiling:latest not found

which is the same experience if one sshed into the node and ran the command as the current user. So root has been signed in but not the "adminusername". I then conclude that when running docker run on the swarm manager, the run commands on the slave nodes are not run under the root account as you indicate.

If I ssh in and do docker login as "adminusername" on all 3 slaves, then the above commands work as expected.

Let me know if you dont get same experience, other wise I will just debug a bit more in the end of the week.

[ahmetb]

@s093294 You are indeed correct. docker login credentials are not persisted into the docker-engine, they are just read from $HOME/.docker/config.json when the caller does a docker push.

For now, the private images used in "compose" section of the extension configuration JSON would work fine as docker-compose is invoked as root. This is the automation part of the story.

However it looks like your use case is more manual and it involves SSHing into the VM, doing docker pull for private repositories in there. Is that right? I am just trying to understand the use case, I see no problem in implementing the feature as long as it makes sense and does not pose security risks.

[pksorensen]

My goal is to use a docker swarm cluster to execute our GIS heavy algorithms as it simplifies the process of moving what our engineers are working with into production as we can distribute it as docker containers.

These docker containers are hosted in a private registry.

I then want to incorporate the management part of scheduling/running the algorithms into our services such our C#/.NET backend with open a SSH connection and execute the docker run commands which then is distributed using docker swarm manager behind the scenes.

But as I see it right now, I do not require any changes to the docker extension. I can simply add a custom linux extension that copies over the root/.docker/ to adminusername/.docker/ ect. I could also just do a docker login when signed in the first time.

I do however see that it would make sense that there was two scopes in the docker extension, that allowed both being able to do docker login for the root for private images in the compose step, but also to execute a docker login for the adminusername.

Something like

"protectedSettings": {
          "login": [{ //For docker compose setup
            "username": "pksorensen",
            "password": "***",
            "email": "***"
          },
          { //For when signed in as user.
            "user":[parameters('adminUsername')], 
            "username": "pksorensen",
            "password": "***",
            "email": "***"
          }],       
        },

The motivation for having it being part of the template is that then its my responsibility when setting up the infrastructure and i do not have to share credentials with developers that work on the services ontop of the docker swarm.

Hope the information helps

[pksorensen]

I copyed over the credentials to the current user and when on a swarm-node, i can do the docker pull and it fetches the images from the private registry.

But when doing a docker pull from the manager I still run into the issue:

pksorensen@swarm-master-1:~$ docker pull ascend/tiling
Using default tag: latest
swarm-node-2: Pulling ascend/tiling:latest... : Error: image ascend/tiling:lates                                                swarm-node-0: Pulling ascend/tiling:latest... : Error: image ascend/tiling:lates                                                Error: image ascend/tiling:latest not found

I am guessing this is not directly related to the azure docker extension and wonder if I should try to create issues on docker instead.

Its unclear to me if its not supported to pull images from a private registry from swarm manager.

[pksorensen]

Now that I know what to google for I found all the answeres I needed.

docker-archive/classicswarm#374 has the backlog discussion and docker-archive/classicswarm#1384 seem to have the solution that is part of 1.0.1

[ahmetb]

@s093294 great to hear it is getting resolved.

Another point to watch out for is if you just copy from /root/.docker/config.json, the file probably will have root:root and 0600/-rw------- permissions. When you run the docker client as azureuser, it may fail to read, so you may need to chown it.

[pksorensen]

Thanks @ahmetalpbalkan for the note, i did do that too.

For reference my scripts are here: https://gist.github.com/s093294/0f1b72d497dc2c84233a

[boumenot]

The Docker extension has been deprecated.