DebOps in practice: roles, inventory, and a Dockerfile that disagrees with the quick start

Roles are shared, inventory holds the differences

The project supplies general-purpose Ansible roles for Debian and Ubuntu hosts, plus a default set of playbooks that applies those roles in a controlled way through Ansible inventory groups. The customization story is the part worth understanding before anything else: options are set in inventory rather than in the role code, so the same roles and playbooks can be shared between environments that need different configuration. A service can be managed on one host or spread across many. The stated coverage includes SQL and NoSQL databases, web servers, programming languages, and specialized applications useful in a data center or a cluster. Virtualization is part of the same offer, with KVM/libvirt, Docker and LXC named as the technologies it can deploy. The recorded primary language for the repository is Jinja, which follows from roles being templates rather than scripts.

The quick start names Buster while the Dockerfile builds on trixie

The quick start tells you to start a container acting as an Ansible Controller with DebOps support, described as based on Debian Buster. The Dockerfile in the repository says something different, in two stages from the same slim base:

FROM debian:trixie-slim AS builder

A builder stage installs the packaging toolchain, Sphinx, pandoc and make, then runs `make man wheel-quiet` and copies `lib/docker/docker-entrypoint` into place. A second, identical-base stage installs the runtime set, including iproute2, iputils-ping, vim, openssh-client, procps, sudo, tree, sshpass, make, git and man-db, followed by a pip install step. Buster and trixie are far apart in Debian's lifecycle, so anyone sizing Python and Ansible versions from the quick start text is sizing them from the wrong release. The container is also only one of three routes in.

Three install routes, two artifact formats

The container route and the Vagrant route both clone the source and run from the `src/controller` subdirectory, and both end with the same command:

docker run -it --rm debops/debops
cd src/controller ; debops run common --diff

Vagrant does the same work on a local VM after `vagrant up && vagrant ssh`. The other two routes install artifacts instead of cloning. The Python package carries the roles and playbooks plus helper scripts, and the documented install is:

pipx install --user debops[ansible]

The Ansible Galaxy route installs a collection instead:

ansible-galaxy collection install debops.debops

Those two produce different layouts on disk, and the `debops project init` and `debops run` helpers that the quick start assumes come from the Python package rather than from a bare collection.

Password authentication is disabled and the image installs sshpass

Ansible reaches hosts over SSH, and DebOps enforces SSH security by disabling password authentication, which is why SSH keys are strongly recommended. The behavior is not hardcoded into a role you cannot touch: it is described as changeable through inventory variables, consistent with the project's inventory-driven design. The second warning is operational. During initial deployments you may find that the firewall created by DebOps has blocked you from the hosts, so out-of-band console access is advisable for login and troubleshooting. The runtime image carries `sshpass` in its package list, which sits oddly beside a policy of disabled password logins: the tool is there for hosts that still require one, and the project is candid that securing the server is part of your side of the arrangement.

make check refuses to run on a dirty working tree

The Makefile is a thin dispatcher over the test suite, and two of its entries change how you work. The sanity target declares a dependency before it does anything:

SPHINXFLAGS ?= -n -W

check: fail-if-git-dirty

So `make check` is gated on a clean tree rather than on passing tests, and the documentation build runs Sphinx in nitpicky mode with warnings promoted to errors. Every other name is an alias with a comment, which makes the file readable as an index: spdx for copyright and license checks, versions for upstream versions, docker for an image build, spell, docs, man, links, pep8, shell, syntax for playbook syntax, and collection for building with ansible-galaxy. The clean-git target is worth reading before running, since it calls `git clean -X -d -f` and removes every ignored file in the tree.

The package version is manufactured at build time by git describe

setup.py does not carry a version string. It shells out during the build, retrieves the project version from `git describe`, and writes it into `__version__.py` and a VERSION file, which the file comments say is needed for correct installation of the Python package. It also reads the long description from disk with a plain `README = open('README.md').read()`, and keeps a small compatibility shim that defines a `unicode` class when the name is missing on Python 3. A separate helper walks directories for package data, and its docstring records a real packaging failure: a glob pattern matching a directory can make setuptools try to install that directory as a file. Meanwhile pyproject.toml holds no build table at all, only codespell configuration.

SPDX headers disagree about or-later, and the license field is empty

Each file declares its own license, and the declarations do not match. pyproject.toml carries `SPDX-License-Identifier: GPL-3.0-only`, while setup.py, the Dockerfile and the Makefile carry `SPDX-License-Identifier: GPL-3.0-or-later`. The repository also has a LICENSES/ directory and a REUSE status badge wired into the overview, so the project takes the question seriously enough to have tooling for it. The license recorded for the repository itself is empty, and the overview links to GPL v2 by URL rather than naming a license for the project. Three files therefore give three answers, and picking one is a decision for the maintainers, not something a reader should infer. If compliance depends on the exact scope, that question is worth asking before the roles touch a production host.

Three tags in one afternoon, plus two CI systems

Three releases went out on the same day: v3.3.2, v3.2.8 and v3.1.9, all on 2026-09-28, which is the shape of parallel maintenance branches rather than a single line. The last push was 2026-10-01, the default branch is master, and the repository is not archived. It shows 1,426 stars and 426 open issues. Both CI systems are wired in, with a GitHub Actions badge for a Continuous Integration workflow and a GitLab CI pipeline badge pointing at gitlab.com/debops/debops, and the overview carries a CII Best Practices badge as well. Packaging extends past pip and Galaxy: PKGBUILD at the root brings Arch Linux into scope, and the top level also holds MANIFEST.in, setup.cfg, requirements.yml, requirements-integration.txt, a CODEOWNERS file and .pre-commit-config.yaml.

Editorial conclusion

DebOps earns its place for teams that already live in Ansible and want opinionated, inventory-driven roles for databases, web servers and virtualization on Debian-family hosts. The parts to verify before adopting it are all in its build files rather than its prose. Check which base image you actually get, since the quick start text and the Dockerfile name different Debian releases. Check the SPDX scope, because the recorded license field is empty and the headers disagree on or-later. Check how your version is produced, because the package version comes out of git describe at build time. And keep out-of-band console access, because the first deployment can lock you out with its own firewall. The distribution model itself is unfussy: a fork, a pull request, and a preference for signed commits.

Frequently asked questions

Official sources

1. debops/debops on GitHub
2. Issues
3. Project website
4. README
5. Releases