[debops-users] New DebOps release - v0.8.1
drybjed at drybjed.net
Sat Feb 2 23:57:31 CET 2019
The next release of DebOps is here, after almost 6 months. The previous
release was done after 4 months of work, I wonder if a few months between
releases is a good trend.
Also, Groundhog Day!
New DebOps release, v0.8.1
You can find the new version of DebOps on:
You can upgrade the Python-based installation by running the command:
pip install --upgrade debops
DebOps is again oficially available on the Ansible Galaxy website, and the
multi-role repository can be downloaded using the experimental 'mazer' content
manager. You can find more details about installing DebOps in different ways
in the rewritten installation documentation:
The brief Changelog can also be found on the 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 \
The v0.8.1 release ended up with ~400 commits. Here's the list of people
involved in creating it, apart from merge commits:
244 Maciej Delmanowski
24 Rainer 'rei' Schuth
16 Markus Wigge
14 Robin Schneider
12 Thomas Danielsson
11 Jérémy Gardais
10 Mike Nowak
8 Martin Kimmerle
8 Patryk Ściborek
8 Serge Victor
4 Nicolas Quiniou-Briand
3 Norbert Summer
3 Pedro Luis López Sánchez
2 André Jucovsky Bianchi
2 Eric Renfro
2 Jan Kowalsky
2 Stuart Mumford
1 Alex Schmitz
1 Aloïs Oddon
1 Christian Fischer
1 Fabio Bonelli
1 Gaudenz Steinlin
1 Jack Hill
1 Jonathan Struebel
1 Kamila Součková
1 Konstantinos Koukopoulos
1 Korbinian Preisler
1 Mariska Hoogenboom
1 Nick Janetakis
1 Petr Gajdůšek
1 Russell T. Sherman
1 Stuart Read
Big thanks to everyone involved in this release, for finding out and fixing
bugs, and adding new features to the roles.
Goals reached since latest release
The Redis support has been redesigned - the 'debops.redis' role has been split
into 'debops.redis_server' and 'debops.redis_sentinel' roles. Both roles
support multi-instance installations.
The IP forwarding configuration was rethought, the 'debops.ifupdown' role now
uses the 'debops.sysctl' role to configure kernel parameters independently for
each network interface. Now the packet forwarding is not configured globally
any more, but independently per interface. Unfortunately some software like
'lxc-net' or 'libvirt' can still enable IP forwarding globally, I haven't
found a workaround for that yet.
The 'debops.dnsmasq' role has been rewritten and now uses the custom DebOps
filter plugins to merge configuration from different sources together. The
role can now synergize with the 'lxc-net' service managed by the 'debops.lxc'
role to allow easy use of the internal LXC containers, which can be reached by
their hostname instead of an IP address.
Unfortunately, nothing happend with the LDAP support in DebOps, but I hope to
improve it in the next release.
Supercharged LXC support
During last few months I focused on improving the LXC container support in
DebOps. The 'debops.lxc' role gained support for managing unprivileged LXC
containers, lots of configuration tweaks and a few custom scripts to support
easier container management from the command line.
The 'lxc-net' service is now configured by default to support internal LXC
containers, with their own DNS subdomain. If the 'debops.dnsmasq' role is
configured on the LXC host, containers can be reached using their hostnames
instead of IP addresses - this can be used to give unprivileged users access
to their own LXC containers without giving them access to the 'lxc-*' commands
to not let them mess with each other's containers.
The 'lxc_ssh.py' custom Ansible connection plugin has been included in DebOps.
It can be used to manage LXC containers on the remote host with direct SSH
access. You can find the details in the 'debops.lxc' role documentation.
On hosts with 'systemd', the LXC containers will be started using the
'lxc at .service' instances, with custom overrides. This helps the service
manager correctly shut down the LXC containers at reboot and avoids issues
with forcibly killing them after a timeout.
Reorganization of the bootstrap playbook
The initial configuration of the '/etc/hosts' file done by the
'debops.bootstrap' playbook has been ripped from it, redesigned, and
incorporated into the 'debops.netbase' role, which is now included in the
'bootstrap.yml' playbook. This should ensure that the '/etc/hosts'
configuration is idempotent between the bootstrap and common playbooks, and
the domain configuration is set correctly the first time. The 'debops.netbase'
role supports different domain configurations (via external DNS, directly in
'/etc/hosts') and should correclty update the host database in most cases.
The 'debops.apt' role has been added to the 'bootstrap.yml' playbook to allow
early APT configuration. This should ensure that the support for HTTPS APT
repositories, as well as release backports is present when needed by other
The last thing left in the 'debops.bootstrap' role is management of the System
Administrator accounts. I'm thinking about creating a new role for that
purpose, which would allow configuration of multiple, separate, sysadmin UNIX
accounts as well as support LDAP configuration if present. After that the
'debops.bootstrap' role will probably be removed and replaced completely by
the playbook itself.
Improvements in the DebOps repository
The Vagrant environment has been updated - Vagrant hosts now use Avahi to
discover other hosts in the same cluster and configure a custom
'*.vagrant.test' DNS domain in their '/etc/hosts' files. This drops the need
for an external DNS/DHCP server for the test environment, however the setup
requires use of a bridged network. Best results can be achieved under Linux,
with LXC or libvirt environments.
The DebOps roles and playbooks have been cleaned up and are now tested using
the 'ansible-lint' command. This results in a perfect 5/5 score on the Ansible
Galaxy, woohoo! ;-)
The 'make versions' command can be used to check currently pinned versions of
third-party software used in DebOps roles, and compare them to the upstream
versions of the released software. Since the project gains support for more
third-party applications installed via 'git' repositories, this should help
the project track the updated software better. The roles that use the software
from the Debian Archive, or third-party APT repositories, are not included in
these checks. The check has been implemented using the 'uscan' command
included in the Debian 'devscripts' APT package.
The 'debops.ansible_plugins' role now contains all of the custom Ansible
plugins used in DebOps roles (apart from the connection and callback plugins
which are not useful on the role level). This should fix issues with the
custom lookup plugins not being available when DebOps roles are used
independently from the whole DebOps project. The lookup plugins don't require
the 'debops' Python package to be installed, and will work just fine without
Plans for the next release
At the moment, Debian Testing release is beginning to freeze, with the Debian
Buster release aimed some time around August 2019. If we keep with the 6-month
release cycle, the next DebOps release could be done somewhere around the same
time. So let's aim for that and see what happens. Some of the new Debian
Buster features like AppArmor enabled by default will have to be implemented
in DebOps roles, that probably will end up as one of the main goals for the
next DebOps version.
In the next release cycle I would like to focus on the clustered environment
managed by DebOps - DNS (bind9), LDAP (slapd, sssd, some kind of LDAP
management interface like LAM, better support for LDAP in various
applications), remote storage (NFSv4, block storage provided by Minio, Docker
Registry for container storage), centralization of various services
(centralized logs via logstash, filebeat, load balancing via haproxy and/or
keepalived). I'm interested in further exploring the way storage and compute
nodes can be managed together, to allow easy reinstallation or scaling of
compute nodes as well as data replication and security on the storage nodes.
I'd like to explore the "unprivileged" side of DebOps more, as explained in my
previous e-mail. At present it seems that the roles could be designed with
usage via an admin account by default, but allow for direct unprivileged
operation in some cases. I'm not sure how the main playbook will have to
change to accomodate more unprivileged operation yet.
Once again, thanks to everyone involved in this project, and remember to have
fun with it. See you next time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 585 bytes
Desc: not available
More information about the debops-users