Module docker_service seems to create variables at runtime

[marioprudhomme]

ISSUE TYPE

• Bug Report

COMPONENT NAME

docker_service

ANSIBLE VERSION

ansible 2.4.2.0
  config file = /etc/ansible/env/dev/ansible.cfg
  configured module search path = [u'/root/.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.13 (default, Apr 20 2017, 12:13:37) [GCC 6.3.0]

CONFIGURATION

DEFAULT_HOST_LIST(/etc/ansible/env/dev/ansible.cfg) = [u'/etc/ansible/env/dev/inventory.yml']

OS / ENVIRONMENT

N/A

SUMMARY

Not sure if this is an intended feature by the owner or a bug.

When using the docker_service module with state: present, a new variable is created in the ansible runtime for each services defined in the docker-compose.yml file, containing the output of docker-compose up. This potentially overwrites variables already defined in ansible.

This also means that if i edit the docker-compose.yml file (oblivious of ansible), it can potentially break the ansible build when there are name conflicts between ansible variables and the name of services present in the docker-compose.yml file.

STEPS TO REPRODUCE

- name: Up formio container
  docker_service:
      project_src: /srv/formio
      state: present

EXPECTED RESULTS

No variables created by the module

ACTUAL RESULTS

A new formio variable gets created and overwrites the current formio variable, becausee the docker-compose.yml file has a service named formio.

version: '2.1'

volumes:
    mongodb_data:
        driver: local

    formio_data:
        driver: local

services:
    mongodb:
        image: mongo:3.4.3
        volumes:
            - mongodb_data:/data/db
        healthcheck:
            test: ['CMD-SHELL', 'echo "db.stats().ok" | mongo localhost/formioapp --quiet']
            interval: 5s
            timeout: 1s
            retries: 10

    *formio*:
        build: .
        depends_on:
            mongodb:
                condition: service_healthy
                ...

[ansibot]

Files identified in the description:

• lib/ansible/modules/cloud/docker/docker_service.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 @chouseknecht
click here for bot help

[sivel]

Ref:

ansible/lib/ansible/modules/cloud/docker/docker_service.py

Line 768 in 4c0889e

for service in self.project.services:

[marioprudhomme]

Potential fix:

Keep the current behavior for backward compatibility. Introduce a new optional attribute to allow the user to register a new fact name instead of assuming the compose service names.

- name: Up formio container
  docker_service:
      project_src: /srv/formio
      state: present
      fact: results

results would contain:

{
    "mongodb": {  as usual... },
    "formio": { as usual... }
}

[oryband]

can confirm this exact problem happens to me as well. broke my deployment.

[ansibot]

cc @felixfontein
click here for bot help

[ansibot]

cc @akshay196 @danihodovic @dariko @jwitko @kassiansun @tbouvet
click here for bot help

[ansibot]

cc @DBendit
click here for bot help

[ansibot]

Files identified in the description:

• lib/ansible/modules/cloud/docker/_docker_service.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

[felixfontein]

Please note that the docker_service module will be renamed to docker_compose in Ansible 2.8. You will be able to still use the old name, but you will receive a warning when doing so.

!component =lib/ansible/modules/cloud/docker/docker_compose.py

Also, please note that currently, nobody is actively maintaining the Ansible docker_service/docker_compose modules. If you are interested in working on this issue, please feel free to create a PR :) If you need any help, feel free to ping me or any other of the current docker_* module maintainers.

[ansibot]

cc @WojciechowskiPiotr
click here for bot help

[felixfontein]

Please note that the returned ansible_facts are deprecated for Ansible 2.8, and will be removed in Ansible 2.12. Also, maybe this helps. No idea whether this can be set on task level, though.

[ansibot]

Files identified in the description:
None

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

[felixfontein]

CC @sluther

[ansibot]

Files identified in the description:

• lib/ansible/modules/cloud/docker/docker_compose.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

[sluther]

If I'm following this correctly, formio is used to refer to the service up until the point when docker-compose up is run, at which point formio is then replaced with the result of the call to docker-compose up. This will cause issues later on when referencing the formio variable. The expected behavior is the result of docker-compose up being stored in a different variable so it doesn't overwrite the service definition. Do I have that right? If so, this seems like a critical bug.

[felixfontein]

It's not replaced, but a ansible_facts with name formio is returned by the module, which will take precedence over other variables called formio in the playbook from that point on. That's a known (mis-)behavior of the module and I've deprecated it, see here.

Use another variable name for now, or tell Ansible to handle ansible_facts differently (forgot how that option is named).

[ansibot]

Thank you very much for your interest in Ansible. Ansible has migrated much of the content into separate repositories to allow for more rapid, independent development. We are closing this issue/PR because this content has been moved to one or more collection repositories.

• lib/ansible/modules/cloud/docker/docker_compose.py -> https://galaxy.ansible.com/community/general

For further information, please see:
https://github.com/ansible/ansibullbot/blob/master/docs/collection_migration.md