mhutter / ansible-docker-systemd-service Goto Github PK

Context

This Ansible module uses its own parameters to support various docker run command line arguments.
Out of those, multiple types are used:

• Single strings
• Lists

Examples for single strings:

• container_network maps to --network
• container_user maps to --user
• container_hostname maps to --hostname

Examples for lists:

• container_volumes maps to --volume
• container_ports maps to --publish
• container_hosts maps to --add-host

This is great and marks explicitly how to use this module.
The big downside on this: You need to add additional support for each docker run command line argument into this module. And the docker run reference is looooong.

One proposal would be to make this Ansible more flexible and avoid the burden of implementing every single docker run command line argument by offering ways to add arbitrarily

• key -> value pairs (for single string values that are only allowed once in a docker run cmd, like --user)
• key -> list[value] pairs (for docker run cmd arguments that are allowed multiple times like --volume)

How a possible Ansible usage can look like in the future / Usage of the module:

- name: Start image
  include_role:
    name: mhutter.docker-systemd-service
  vars:
    container_name: "hello-world"
    container_image: "hello:v1"
    container_docker_pull_force_source: false

    container_single_args:
      network: my-network
      user: nonroot
      hostname: world
      [...]

    container_multi_args:
      publish:
        - '127.0.0.1:3030:3000'
        - '127.0.0.1:1234:5678'
      volume:
        - '/opt/foo:/var/lib/bar:rw'
      [...]

    [...]

The top-level keys under container_single_args and container_multi_args are not validated They can be defined to whatever you want.

A few keys, like container_image might be good to keep separate, primarily when those are used in a different context (e.g., to craft the systems unit name).

The same can be done for boolean flags via a list like container_boolean_args for keys like --rm or --tty:

container_boolean_args:
  - 'rm'
  - 'tty'

Open decisions

• Define which keys need to stay separate and used in different contexts
• Align on a naming for single arguments, boolean arguments, multi list arguments
• Align on how to do it (strict breaking change + removing the keys or "smooth" migration via deprecating
• Implementation: Align on several small pull requests or one big one (to keep the default branch working)

Additional notes

• This would indicate a breaking change to the module and a v1.x might be needed for a release
• It might be good to deprecate or directly remove the previous parameters that are replaced by the new capability. Removing directly would free up the code base directly.
• Changelog + Migration guide would be required

Have some kind of automated testing to avoid things like #20

Ideas

• use BATS

Latest release on galaxy is 2.0. There are tags fo 2.1.0 and 2.2.0 on github.
Would you mind releasing these versions to galaxy as well?

Hi,

i'm getting the error {"changed": false, "msg": "state is present but all of the following are missing: source"} and i'm assume, thats fixed in the 2.4.0 release, but ansible galaxy lists only 2.2.0

Basically I'm proposing to add a flag that changes the unit file to contain

TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill image
ExecStartPre=-/usr/bin/docker rm image
ExecStartPre=/usr/bin/docker pull user/image

as opposed to the current

ExecStartPre=-{{ docker_path }} rm -f {{ container_name }}

I'm going to implement this for my own use, so let me know if you'd like me to submit a pull request.

Hello, I have found there is an open issue against ansible for handlers not working when using include_role - See ansible/ansible#20493
It was documented as a Note in the documentation until it is addressed: ansible/ansible#72744

In my case I am getting the following error that the handler does not exist

TASK [mhutter.docker-systemd-service : Create unit myapp-instance1_container.service] ****************************************************************************************************************************************************************************
ERROR! The requested handler 'restart container myapp-instance1' was not found in either the main handlers list nor in the listening handlers list

Has anyone else faced this problem?

Recently templates/unit.j2 has been updated with if condition around container_cmd

{{ container_image }} {% if container_cmd is string %}{{ container_cmd | trim }}{% else %}{{ container_cmd | join(' ') | trim }}{% endif %}

It seems jinja trim line ending by "if" condition and we end up with systems config like

ExecStart=/usr/bin/docker run \
  --name vault \
  --rm \
  --env-file /etc/default/vault \
  --volume /opt/cycloid/vault/config:/vault/config --volume /opt/cycloid/vault/file:/vault/file \
  --publish 8200:8200 \
   \
  \
  \
  \
  \
  \
  --cap-add IPC_LOCK \
  vault:1.5.4 vault server -config /vault/config/local.jsonExecStop=/usr/bin/docker stop vault
ExecStartPost=-/opt/cycloid/vault/unseal.sh

As you can see the newline before ExecStop is not respected.
Should we force a new line before ExecStop ?

Version
ansible 2.9.27
jinja2 2.10-2

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

If the ansible_ssh_user is different from root (but still a sudoer), the created systemd service fails to start with this error
docker: open /etc/default/<container name>: permission denied.

My current workaround is to change permissions right after the included mhutter.docker-systemd-service role

    - name: Fix https://github.com/mhutter/ansible-docker-systemd-service/issues/45
      ansible.builtin.file:
        path: /etc/default/<container name>
        owner: '{{ ansible_user }}'
        mode: '0644'

Hi,

I'm currently facing the task of generating a few containers through service templates. Is service templates supported in this project? If yes, how exactly do I have to do this? If no, this can be considered as a feature request. :-)

The example defines myapp but the commentary uses the name mysql. Commentary should also use the name myapp.

• Run yamllint
• Do an Ansible syntax check
• Ping Ansible Galaxy on new tags
• Bonus: Generate Changelog from Pull Requests on Github using something like mikepenz/release-changelog-builder-action

See old travis.yml:

https://github.com/mhutter/ansible-docker-systemd-service/blob/3b8da4bbc840c542ef0d46815890ad58a5e17cc8/.travis.yml

https://keepachangelog.com/en/1.0.0/

I have an Ansible role in which I include your role a number of times to have long running containers on a dedicated machine. I developed everything against Vagrant + the Ansible provisioner. Everything works like a charm.

Then came the time I had to roll it out on the AWS EC2 production machine. Bam, it broke on setting up the first docker systemd service with this error (when running Ansible with -vvv):

fatal: [10.130.20.211]: FAILED! => {
    "changed": false,
    "invocation": {
        "module_args": {
            "daemon_reload": true,
            "enabled": true,
            "masked": false,
            "name": "elasticsearch_container.service",
            "no_block": false,
            "state": "{'code': 16, 'name': 'running'}",
            "user": false
        }
    },
    "msg": "value of state must be one of: reloaded, restarted, started, stopped, got: {'code': 16, 'name': 'running'}"
}

So the given state became {'code': 16, 'name': 'running'}. Googling this type of message structure always directs me to the boto Python AWS SDK library. While not really knowing how Ansible internals work, my assumption is that something of the boto usage leaks down in the namespace of the Ansible role variables. The value given above could easily be the state of the VM being checked first.

To test this, I renamed the default variable state in this role to service_state and updated the usages in install.yml. Executed my playbook again and with good results.

As I don't know Ansible well enough, I first created this ticket here. It might be the case that this is a valid case of Variable Precedence, but it might be that this collision is a core Ansible bug. In this case, I hope we can work together in the investigation before we file a bug in the Ansible core project.

See https://github.com/mhutter/ansible-docker-systemd-service/blob/master/templates/unit.j2#L48
I don't think this is intended and leads to me not able to connect to additional docker networks 😢.

If this is an actual bug, I am more then happy to create PR for it.

When using the module, a deprecation warning is thrown during execution:

[DEPRECATION WARNING]: "include" is deprecated, use include_tasks/import_tasks instead. This feature will be removed in version 2.16. Deprecation warnings can be disabled by setting deprecation_warnings=False in
ansible.cfg.

Environment

ansible [core 2.13.4]
  config file = None
  configured module search path = ['/path/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/homebrew/Cellar/ansible/6.4.0/libexec/lib/python3.10/site-packages/ansible
  ansible collection location = /Users/andy.grunwald/.ansible/collections:/usr/share/ansible/collections
  executable location = /opt/homebrew/bin/ansible
  python version = 3.10.6 (main, Aug 30 2022, 04:58:14) [Clang 13.1.6 (clang-1316.0.21.2.5)]
  jinja version = 3.1.2
  libyaml = True

It looks like commit 22495f0 had an invalid refactor of the variable names in install.yml

I think the container_enabled, container_masked, container_state should all be renamed to service_*

I'm using this role to have systemd start docker containers, and some of these containers need a Samba share to be mounted locally. These mounts are described in /etc/fstab, causing systemd to automatically create associated .mount unit configurations. I'd like systemd to only start the container after the mount unit.

To do this, we'd need to be able to support an additional after parameter, empty by default, that would allow us to supercharge the unit after clause.

WDYT? I'm ready to provide the patch if you think this is a good idea. Thanks!

The --add-host argument for docker run can be used to access the docker host from inside a container. See https://docs.docker.com/engine/reference/commandline/run/#add-host

With lines like --add-host=host.docker.internal:host-gateway.

Support for the --add-host command in docker run would be awesome.

The container_args are rendered as

ExecStart=/usr/bin/docker run --name foo --rm --env-file /etc/default/foo  ['--add-host idadwh.db:10.0.1.3'] nginx:latest

There have been a few useful changes since the 2.1.0 release currently on Galaxy. Could you make a new release to Galaxy so we can update to a stable version via our requirements.yml ? Thanks.