1
0
Fork
You've already forked scripted-configuration
0
An attempt at a much more simple and intuitive configuration system (used for most of our services)
Shell 95.5%
Caddyfile 2.2%
HTML 1.9%
CSS 0.4%
2025年08月10日 00:52:50 +02:00
base for new containers use trixie 2025年07月16日 17:35:50 +02:00
hosts reverseproxy: set headers only if they aren't already set 2025年08月10日 00:52:50 +02: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 add nano to the list of editors to be installed 2025年07月18日 15:33:19 +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.