Slavi Pantaleev

You can take inspiration from the `matrix-dendrite` role and from #818. Updating `group_vars/matrix_servers` in a few places for Conduit would also be necessary.

That's right.. Unfortunately, we are not really supervising the actual containers, but just the Docker client. Still, having systemd "supervise" is useful because: - all output generated by each container...

I see your point. It does make sense to use Docker and have support for those other (non-systemd) distros as well. Especially given that the name of the playbook is...

None of our containers run with a `root` user inside. As far as I understand (which may be wrong), the benefit of "rootless containers" is that **preparing and triggering container...

Wow, you've spent a lot of time on this! Happy to hear you're finding an alternative way to make use of this playbook! Hopefully others will find it useful as...

I also think that adjusting the existing systemd setup in a way that's part of the playbook would probably be better (and won't need any maintenance, once done). When going...

You can work on adding openrc service scripts to the playbook. They could work similarly to how our systemd `.services` work (invoking `docker run ..`).

Podman with the `dnsname` plugin may be becoming a viable alternative to Docker. Someone in our Matrix room said they'd be experimenting with that soon, so the playbook may be...

Thanks for the writeup! We try not to contaminate the system too much. We have variables that can be toggled to prevent the playbook from installing Docker (`matrix_docker_installation_enabled: false`). We...

> Docker manages and keeps track of the services. Problems during startup are no longer existing. How so? We still need to use `depends_on`, etc., for defining service order, just...