0

With the upgrade of the Ansible control node to Debian trixie, the docker_compose module is gone.

However, the community.docker.docker_compose_v2 module fails to work with a Debian bullseye target node.

There is no available upgrade for Docker in Debian bullseye to make this work, and a switch to Docker-upstream-provided packages is undesirable.

As someone who merely has to occasionally run the playbooks and needs to make them continue to work until the box can be upgraded to bookworm and then trixie, what are my options?

Can I just download/clone the community.docker collection at release 3.9.0 (the last one before the removal) and put it as old.docker (i.e. rename the directory), or are the collection names also hardcoded in the collections themselves and relevant for execution? If so, can I just s/community\.docker/old.docker/g over all files?

Improve this question

1 Answer 1

Reset to default
0

Freeze community.docker at a version before 4, the last one upstream is 3.13.10. Do not rename it, internally there are metadata and code imports of that name, and you might need to update playbooks. That is more work to maintain.

If you were using someone else's packages for ansible collections, for example the community ansible package, those keep getting updated. A more selective way to install individual collections would make sense.

Consider project specific collections path. Paths in an ansible.cfg are relative to that config file, so playbooks and collections are all in a tree.

Or some other path. Or a different Ansible install in a different python venv. Whatever makes sense to contain collections.

[defaults] # Installs collections into [current dir]/ansible_collections/namespace/collection_name collections_paths = ./

In requirements.yml specify the version for use with ansible-galaxy collection install --requirements-file

--- collections: - name: community.docker version: 3.13.10

This version should have a docker_compose_v2, that was the purpose of a transition period.

If these plays are to exist for let's say another year, change them to not use the old module, then allow community.docker to be upgraded. Old module code can run for quite a long time, but its not tested on old ansible so eventually technical debt will catch up to you.

Improve this answer
3
  • We use the Debian installation of Ansible, so no further updates, but that’s that. We also need the new module, for the newer nodes. So basically what I should be looking for is to take an older community.docker clone and throw it into a project-specific path? Commented Nov 21 at 23:50
  • Maintain an old collections path and a new collections path. Up to you whether you do this with different ansible configs, separate ansible installs in venvs or containers. Or maybe make version 3 of that collection work somehow. Unlikely the Debian packaging will suit your needs. Commented Nov 22 at 1:17
  • That was precisely my question… Commented Nov 25 at 18:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.