An attempt at a much more simple and intuitive configuration system (used for most of our services)
Find a file
2025-12-21 12:47:39 +01:00
base *: Always pass command to apt 2025-12-01 15:05:05 +01:00
hosts caddy: Add processes.codeberg.org and data.codeberg.org to point to ev container 2025-12-21 12:47:39 +01:00
.gitattributes reverseproxy: add Forgejo 2025-04-18 14:42:54 +02:00
.gitignore Forgejo Ci configuration 2023-01-17 14:55:49 +01:00
.woodpecker.yml Forgejo Ci configuration 2023-01-17 14:55:49 +01:00
inside.sh *: install foot-terminfo 2025-10-12 01:17:02 +02:00
LICENSE Update 'LICENSE' 2022-10-14 17:25:44 +02:00
README.md describe lxc in readme 2024-06-06 23:19:54 +02:00
rm-container.sh add achtermann galera node 2024-12-21 01:44:24 +01:00
schedule-maintenance.sh Add timestamp to maintenance page 2024-10-05 02:15:43 +02:00
setup-container.sh Allow to create KVM machines 2023-07-30 16:56:29 +02:00
upgrade-self.sh We do not need debian 11 to 12 updates anymore, we are fully migrated. 2024-11-11 20:51:31 +01:00

scripted-configuration

An attempt at a much more simple and intuitive configuration system (experimental / proof of concept)

The problem:

We're using Ansible for our configuration, but our experience was anything but smooth. The repo is often in an undeployable state, there is not much you can do to test, the workflow is very unflexible.

The result is that stuff is done alongside Ansible and checked in later, often it is not. We have several black boxes, and this is a problem.

A solution attempt:

So I aim for a much simpler workflow, which is

  • easy to debug (bash / shell scripts in the end)
  • flexible to use (config can be changed from within the container by updating the scripts inside)
  • easy to getting started (in order to setup a new machine, you don't need to learn about Ansible, all you need to do is to run an interactive shell script)
  • independent and not blocking your goal (you can use functions from within this repo, or tell the shell script to do something completely different)
  • always ready to be run (no broken / out-of-sync state by making it easier to work with the tools on the system)

Looking for help:

We're looking for input at the approach, as we're mainly testing the idea.

Feel free to get in touch to discuss other alternatives to Ansible, approaches to system configuration, or potentially improving this toolset to be more flexible, useful and joy to use.

LXC

LXC containers can be provisioned with the following OS:

  • Debian (default)
  • AlmaLinux

If you want to use a different OS, set LXCTEMPLATE in host.sh as for example done for the ci-staging host. In principle, all OS available at images.linuxcontainers.org can be used.