[debops-users] New DebOps release: v0.8.0
by Maciej Delmanowski
It's time for a new release of DebOps. This time there are two new package
dependencies ('future' and 'dnspython' Python modules) therefore I decided to
do a minor version bump. The project is still some time from a stable release
though, so we stay in the v0.x.y series.
New DebOps release, v0.8.0
You can find the new version of DebOps on:
You can also install the new scripts by running the command:
pip install --upgrade debops
The 'pip' package manager should install the new Python package dependencies if
they are not present.
You can find the brief Changelog in the DebOps documentation page:
Complete, detailed changelog can be viewed using the 'git log' command.
The DebOps documentation has a separate page which details important changes
from previous release in the Ansible inventory or on the remote hosts which
you might need to perform manually:
The Python packages available on PyPI, as well as the tarballs available on
GitHub are signed with my GPG key. You can get it from the OpenPGP keyserver
network using the command:
gpg --keyserver hkp://pool.sks-keyservers.net \
This release has again a rather small number of commits, 239. List of commit
authors, without merge commits:
133 Maciej Delmanowski
37 Robin Schneider
16 Jérémy Gardais
6 Stefan G. Weichinger
5 Alban Browaeys
4 Alin Alexandru
4 Markus Wigge
3 Alexander Mette
3 Gaudenz Steinlin
3 Pedro Luis López Sánchez
2 Carl Alexander
2 Fabio Bonelli
2 Martin Kimmerle
2 Matt Callaghan
2 Stuart Mumford
2 Tomoyuki Harada
1 Aloïs Oddon
1 Andreas Zilian
1 Artur Martins
1 Christian Fischer
1 Hanno - Felix Wagner
1 Jonathan Struebel
1 Julien Peeters
1 Mathieu MD
1 Patryk Ściborek
1 Thiago Talma
1 Tomasz bla Fortuna
Thanks to everyone involved for finding bugs and providing pull requests!
Introduction of DebOps Enhancement Proposals (DEPs)
This is a mechanism inspired by Python Enhancement Proposals which is intended
for more community-driven approach for DebOps development. In short, community
members can propose project-wide changes to the project via the mailing list
which can then be discussed and implemented if the change is accepted. Over
time, most of the documentation related to project-wide architecture and best
practices will be reimplemented as DEPs which then can be used as reference
for automated testing suites. You can read more about how this system works in
DEP 1: https://docs.debops.org/en/master/dep/dep-0001.html
Some time after implementing this I learned about Debian Enhancement Proposals
(https://dep-team.pages.debian.net/), thats an unfortunate name collision...
New Python package dependencies
THe 'debops' Python package now depends on the 'dnspython' and 'future' Python
packages. The 'dnspython' package allows usage of the 'dig' Ansible lookup
plugin for better integration with the DNS database, for example to resolve
service addresses via DNS SRV records. The 'future' Python package is used as
a compatibility layer between Python 2.7 and Python 3.x environments - DebOps
is usable in either of these, and usage of the 'future' package should allow
writing of cleaner code in the scripts and custom Ansible plugins.
Icinga 2 support
The DebOps v0.8.0 release brings Icinga 2 support in the form of 3 Ansible
roles: for an Icinga 2 Agent service, database support and fully-fledged
Icinga 2 Web service with Icinga 2 Director. With this arrangement, you can
use just the Icinga 2 Agent role to set up the configuration "manually" from
scratch, or use Icinga 2 Director to manage the configuration via the web
interface. Read the documentation of the new roles for more details about
deployment and configuration options.
Changes in Ansible roles in DebOps
Parts of the current 'debops.console' and 'debops.auth' roles have been moved
to their own separate roles - 'debops.netbase', 'debops.sudo',
debops.system_groups', 'debops.python'. This change allows to better integrate
the bootstrap and main playbooks; any configuration applied at bootstrap time
should be done by the same roles at normal playbook runs.
The 'debops.python' role is designed to support both Python 2.7 and Python 3.x
environments independently, either one of them can be disabled to allow
installation of, for example, Python 3.x environment only. In the long term,
DebOps roles that install Python packages will be modified to use
'debops.python' as a dependency instead of installing these packages directly.
This should allow for DebOps to manage Py3-only hosts in the future.
The LXC support in DebOps has been redesigned. 'debops.lxc' role is focused on
the container host configuration and does not allow for the container
management itself. Due to issues with unprivileged container implementation,
the custom 'lxc-debops' container template has been dropped, new LXC containers
should be now bootstrapped as other hosts/VMs instead. Unprivileged LXC
container support is not ready yet due to issues with configuration of the
'/etc/subuid' and '/etc/subgid' databases.
Quality of Life changes
The 'debops' script has been touched up a bit and will now check all command
line arguments for possible playbooks instead of just the first one. You can
now specify multiple playbooks at a time which will be chained together.
Unfortunately I wasn't able to implement the changes related for IP forwarding
that would move the configuration from 'debops.ferm' to 'debops.ifupdown' and
make it a per-interface option instead of a global setting. Perhaps this will
be possible in the next release.
The new Ansible 2.6 version has reimplemented interation over multiple items
via the 'loop' task keyword. With the 'subelement' filter plugin this allows
for easier access to the nested configuration in YAML dictionaries which is
a common practice in DebOps. Some roles will greatly benefit from these
changes, when Ansible 2.6 will be more widely available - currently the
'stretch-backports' repository has Ansible 2.5.x packages, I hope that the new
version will be backported eventually.
For the next DebOps release I would like to focus a bit on various directory
services - DNS via 'debops.dnsmasq' and probably a BIND9 role, LDAP via
'debops.slapd' role with properly implemented data replication for high
availability. This hopefully can lead to better support for clustered
environments and single, centralized authentication database in different
applications managed by DebOps.
Redis 4.x series is available in the 'stretch-backports' repository, the new
major version supports management of multiple Redis instances on a single host.
The configuration of Redis in DebOps is a little bit tricky due to the software
dynamically modifying the configuration files, but that can be worked around
- I'll probably split the Redis Server and Sentinel management to their own
separate roles in the process.
These were just some of the major changes in the project, you can read more
details in the changelog. Until next time.
4 years, 7 months