-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add docker_compose_v2 module #739
Conversation
ba25363
to
9e5a10a
Compare
This is now ready for review! |
plugins/modules/docker_compose_v2.py
Outdated
- The Docker compose CLI plugin has no stable output format (see for example U(https://github.com/docker/compose/pull/10918)), | ||
and for the main operations also no machine friendly output format. The module tries to accomodate this with various | ||
version-dependent behavior adjustments and with testing older and newer versions of the Docker compose CLI plugin. | ||
|
||
Currently the module is tested with multiple plugin versions between 2.18.1 and 2.23.3. The exact list of plugin versions | ||
will change over time. New releases of the Docker compose CLI plugin can break this module at any time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lel-amri I've added the above note in response to #586 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly, I think this is about as good as you can get there. At least we can take heart in the fact that if Docker were to change the command's UX too drastically, it would break people's brains in addition to the Ansible code, so hopefully they keep it pretty stable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me! Nice to finally have a v2 option. Shame there's no stable/machine-friendly output from the tool.
@@ -1,2 +1,3 @@ | |||
.azure-pipelines/scripts/publish-codecov.py replace-urlopen | |||
plugins/modules/docker_compose_v2.py validate-modules:return-syntax-error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what in this module triggers a return syntax error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the type: raw
IIRC. Some older versions might also barf on choices
in return values.
Emit warnings (or things we assume are warnings), and report unparsable messages to the user so they can report them to us.
@lel-amri thanks for your work on this in #586! |
@felixfontein Many thanks for your PR. Is there still the possibility for a |
@b-reich right now no. I'm currently working on a About |
Ahh I understand. If there are things I can support, please ping me. |
Thanks!
Short answer: look at docker_image and compare its usage to the new docker_image_* modules. Long answer: it reduces the complexity, both of the code and of the user interface (the argument spec). This benefits both the user (less bugs, documentation easier to understand since the amount of options per module is small, you don't have to wonder whether option There are some cases where a combined module makes things easier to express (like for docker_image: you can build, tag, and push the tagged image in one single task!). I hope that there are no cases where separate modules make something impossible or something common very inefficient. For |
(Just look at https://docs.ansible.com/ansible/latest/collections/community/docker/docker_image_module.html#parameters and note that originally the options grouped in |
PR for docker_compose_v2_pull module: #751 |
@felixfontein separate modules for compose, pull and build are ok for me. Another option is to have basic pull and build flag options in the standard This matches the compose command, the I just need an way to update services with locally built images for regular maintenance updates. I now see, that the pull option is already implemented for the Separate Issue for the build feature: #750 |
the module currently does not have support for --diff. @felixfontein Would it be possible to display those in diff mode? or are there strict conventions for diff output? I now implemented a workaround with a second task: - name: docker compose up ({{ webserver_domain }} in {{ webserver_path }})
community.docker.docker_compose_v2:
project_src: '{{ webserver_path }}'
state: present
remove_orphans: yes
pull: "{{ webserver_docker_pull }}"
build: "{{ webserver_docker_pull }}"
register: webserver__register_compose
- name: print actions by compose
vars:
actions: "{{ webserver__register_compose.actions }}"
debug:
var: actions
when: webserver__register_compose.changed
changed_when: webserver__register_compose.changed This generates the following output. also works in check mode: TASK [teamapps.general.webserver : docker compose up (www-dev.example.com) in /container/contao)] *******
changed: [website-dev1]
TASK [teamapps.general.webserver : print actions by compose] ***********
changed: [website-dev1] =>
actions:
- id: contao-sftp-1
status: Starting
what: container |
@pgassmann I guess the question is what you expect from diff mode :) I agree that the actions are better than nothing, but it's not really what I personally would expect (I would expect it to tell me which configuration changes trigger the actions - but that's not so easy to retrieve). Let's maybe create an issue and collect ideas. |
@felixfontein what is the equivalent of the Previously I was doing like this: community.docker.docker_compose:
project_src: "{{ _ovos_installer_working_directory }}/{{ _ovos_installer_project_name }}/compose"
project_name: "{{ _project_name }}"
files: "{{ _composition_files }}"
pull: true
remove_orphans: "{{ ovos_installer_docker_compose_remove_orphans }}"
remove_images: "{{ ovos_installer_docker_compose_remove_images }}"
remove_volumes: "{{ ovos_installer_docker_compose_remove_volumes }}" |
@goldyfruit there is no equivalent at the moment. I've never used that feature nor saw it being used, so I didn't want to implement it in the first version to avoid screwing it up ;) Please create an issue (Feature Request) for it. |
Feature request created. 👍 |
If someone is interested, #776 adds support for a |
Ansible 9.2.0 was released yesterday, containing the new docker_compose_v2 modules: https://github.com/ansible-community/ansible-build-data/blob/main/9/CHANGELOG-v9.rst BTW: Is there anywhere a better readable, rendered version of this Changelog for ansible-community? |
@pgassmann not yet, I'm currently working of creating a MD version, I'll hopefully have time to get a first working version done on Friday. I'm currently running very low on spare time for any open source work, but from Friday on it will be better :) (If you're interested: ansible-community/antsibull-changelog#139) In the meantime you can complain to GitHub which screwed up the RST preview of quite many changelogs and other RST documents (https://github.com/orgs/community/discussions/86715). |
@felixfontein don't apologize for not having much time for open source work. You are the most active and helpful contributor on the issues that affect me. It's telling, that you are the one who already implemented a a solution that fixes the issue in my question. Shouldn't the changelog be part of the rendered website or a docs site like: |
The Ansible changelog traditionally always was on git only and was never part of the docsite (docs.ansible.com); I don't know the reasons for that. One possible reason might be that the docsite build takes quite some time, so it's usually only updated after the actual release happens, which can be confusing since for some time (a few hours at most) the changelog wouldn't mention the latest version. In any case, here's a markdown version of the Ansible 9 changelog: https://github.com/felixfontein/ansible-build-data/blob/markdown/9/CHANGELOG-v9.md (PR: ansible-community/ansible-build-data#364). And here's the community.docker changelog as markdown: https://github.com/felixfontein/community.docker/blob/changelog/CHANGELOG.md (PR: #788). |
I think it would be worthwhile to publish the changelog if possible. Individual collections can already do this fairly easily if they want to with a symlink and a small change, see:
But I can't speak to what this process would be for the community package as a whole, nor how delayed its publishing might be. The collection-level published changelog could be added with a small PR for anyone who's interested in doing so! |
SUMMARY
Implements a basic module wrapping the Docker CLI compose plugin.
I copied some of the output parsing code from #586. Unfortunately
docker compose
's status reporting is pretty primitive, see also docker/compose#10872.Fixes #216.
Closes #586.
Reference for changes to compose over time: https://docs.docker.com/compose/release-notes/
ISSUE TYPE
COMPONENT NAME
docker_compose_v2