Discrepancy in results from Docker container started with Ansible docker_container versus Docker CLI commands

[MacDhughaill]

SUMMARY

When I use the following Docker CLI commands, the container successfully starts up and runs normally.

docker create --name=unifi --network=host --env RUNAS_UID0="false" --init jacobalberty/unifi:latest
docker start unifi

When I use docker_container in an Ansible playbook with the equivalent options, the playbook completes successfully, but the container immediately afterwards exits with an error code of "1".

ISSUE TYPE

• Bug Report

COMPONENT NAME

docker_container

ANSIBLE VERSION

ansible 2.7.2
  config file = /home/me/.ansible.cfg
  configured module search path = [u'/home/me/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.15 (default, Oct 15 2018, 15:24:06) [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)]

CONFIGURATION

ANSIBLE_NOCOWS(/home/me/.ansible.cfg) = True
DEFAULT_HOST_LIST(/home/me/.ansible.cfg) = [u'/home/me/Ansible/inventories/dev']
DEFAULT_LOAD_CALLBACK_PLUGINS(/home/me/.ansible.cfg) = True
DEFAULT_MANAGED_STR(/home/me/.ansible.cfg) = This file was automatically created by Ansible. Manual editing is not advised.
DEFAULT_ROLES_PATH(/home/me/.ansible.cfg) = [u'/home/me/Ansible/roles', u'/home/me/Projects/git/ansible_roles']
DEFAULT_STDOUT_CALLBACK(/home/me/.ansible.cfg) = yaml
PERSISTENT_COMMAND_TIMEOUT(/home/me/.ansible.cfg) = 300
RETRY_FILES_ENABLED(/home/me/.ansible.cfg) = False

OS / ENVIRONMENT

Ansible controller:
Fedora 28

Ansible host (aka the computer I'm trying to run the Docker container on):
CentOS 7 with a virtualenv to provide the newer docker Python library
Docker is installed from the stable repository as described in their docs

STEPS TO REPRODUCE

- hosts: none

  tasks:
    - docker_container:
        image: jacobalberty/unifi:latest
        init: true
        name: unifi
        state: started
        network_mode: host
        env:
          RUNAS_UID0: false
      become: true

EXPECTED RESULTS

I expect the container to continue running normally after it is started, in the same way as it would if I used Docker CLI commands.

ACTUAL RESULTS

The playbook completes successfully. The container is successfully started, but it immediately exits with error code "1".

[ansibot]

Files identified in the description:

• lib/ansible/modules/cloud/docker/docker_container.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibot]

cc @DBendit @akshay196 @chouseknecht @cove @danihodovic @dariko @dusdanig @felixfontein @joshuaconner @jwitko @kassiansun @softzilla @tbouvet @zfil
click here for bot help

[felixfontein]

Have you tried to run docker inspect unifi afterwards to see what the difference between the two containers are?

It might help to first just create the containers (without starting them) and see what the differences are before the containers are started (otherwise one difference will be that one of them is running and the other one not).

[DBendit]

Are you sure that this image is working at all? When I run that image with the same settings as yours, it fails just as you describe, completely outside of Ansible.

needs_info

➜  ~ docker create --name=unifi --network=host --env RUNAS_UID0="false" --init jacobalberty/unifi:latest
2a7192a1219abae76a08be4e1352d5efdf01626f47a1310b28b8745da51ad2eb
➜  ~ docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS               NAMES
2a7192a1219a        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   7 seconds ago       Created                                 unifi
➜  ~ docker start unifi
unifi
➜  ~ docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                            PORTS               NAMES
2a7192a1219a        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   18 seconds ago      Up 2 seconds (health: starting)                       unifi
➜  ~ docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                              PORTS               NAMES
2a7192a1219a        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   27 seconds ago      Exited (1) Less than a second ago                       unifi
➜  ~ docker --version
Docker version 18.09.0, build 4d60db4
➜  ~ uname -a
Linux linode 4.18.8-x86_64-linode117 #1 SMP PREEMPT Tue Sep 18 18:48:25 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[MacDhughaill]

@felixfontein I did as you suggested. Aside from the usual expected differences (timestamps, randomly generated alphanumerice sequences), there are a few curious differences, like where Docker puts [] but Ansible puts null. I have no idea however if that truly is important.

unifi_docker_cli.txt
unifi_docker_ansible.txt

@DBendit It does work. I even checked by connecting to the container from my web browser, and I got the Unifi controller setup wizard. (Don't forget to open port 8443 first on the Docker host's firewall!)

[root@Tatooine me]# docker container ls -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                        PORTS               NAMES
80476aa8094f        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   6 minutes ago       Up About a minute (healthy)                       unifi
[root@Tatooine me]# docker container ls -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                        PORTS               NAMES
80476aa8094f        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   6 minutes ago       Up About a minute (healthy)                       unifi
[root@Tatooine me]# docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                   PORTS               NAMES
80476aa8094f        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   6 minutes ago       Up 2 minutes (healthy)                       unifi
[root@Tatooine me]# docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                   PORTS               NAMES
80476aa8094f        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   8 minutes ago       Up 3 minutes (healthy)                       unifi
[root@Tatooine me]# docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                   PORTS               NAMES
80476aa8094f        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   10 minutes ago      Up 5 minutes (healthy)                       unifi
[root@Tatooine me]# docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS                   PORTS               NAMES
80476aa8094f        jacobalberty/unifi:latest   "/usr/local/bin/dock…"   12 minutes ago      Up 7 minutes (healthy)                       unifi
[root@Tatooine me]# docker --version
Docker version 18.09.0, build 4d60db4
[root@Tatooine me]# uname -a
Linux Tatooine 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Some further investigation has revealed that creating and starting it from Ansible does work...if I leave the RUNAS_UID0 environment variable to its default of "true". Unfortunately, this means the process runs as root inside the container and is not recommended by common sense or the container's creator.

[felixfontein]

Can you try RUNAS_UID0: "false" (with quotes)? This could be the important difference: if you write false, it will be interpreted as a boolean with value false (this is due to YAML being "user-friendly"), as opposed to the string "false". Now Ansible will simply convert it back to a string, but since the string for false is "False", it will end up in another case.

Besides that, the CLI version has

            "AttachStdout": true,
            "AttachStderr": true,

while the Ansible version has

            "AttachStdout": false,
            "AttachStderr": false,

The other differences look harmless.

[MacDhughaill]

Arrgh! That was the solution indeed. Of course it's something small and simple and easily overlooked. Sorry for wasting everyone's time with a PEBKAC error.

[DBendit]

@MacDhughaill Nope, this is a failing on our end. We should handle this input properly.

[MacDhughaill]

Hey! I contributed by finding an actual bug! Will this fix show up in 2.7 at all, or will it have to wait for 2.8? I just want to know so I can put a reminder comment in my playbook.

[felixfontein]

@DBendit it isn't, it's a failing on YAML's end. It is impossible to handle this correctly with YAML.

[felixfontein]

(Except by failing and telling the user to quote ambiguous values.)

[felixfontein]

@MacDhughaill when backported, it should appear in the next 2.7.x version released after the backport was merged. There will be a 2.7.x release this week (which definitely won't contain any change related to this, since the merge window for that one closed this monday).

It's definitely something you have to fix in your playbook, though, since it is impossible to know what you wrote in your playbook once you end up with a YAML boolean. It could have also been y, Y, yes, Yes, YES, True, TRUE, on, On or ON. These are all accepted as truish booleans, and there's no way to know which one it was after parsing. The only change to Ansible which makes sense from my POV is that it will fail and tell you to quote the value.