1
0
Fork
You've already forked scripted-configuration
0
An attempt at a much more simple and intuitive configuration system (experimental / proof of concept)
Shell 100%
Otto 68a611fd6a Simple rate-limiting (haproxy) ( #18 )
Co-authored-by: Codeberg Admins @ kampenwand <contact@codeberg.org>
Reviewed-on: Codeberg-Infrastructure/scripted-configuration#18 
2023年01月16日 16:09:59 +00:00
base Fix path bugs 2023年01月15日 14:51:20 +01:00
config/var/jump/.ssh add secondary key for gapodo (gapodo_ed_sk_2) 2022年12月20日 20:22:38 +01:00
hosts Simple rate-limiting (haproxy) ( #18 ) 2023年01月16日 16:09:59 +00:00
.gitignore Create backup files on config installation 2022年12月01日 19:27:53 +00:00
inside.sh Various improvements 2022年11月05日 22:34:58 +00:00
LICENSE Update 'LICENSE' 2022年10月14日 17:25:44 +02:00
README.md Update 'README.md' 2022年10月12日 12:41:04 +02:00
rm-container.sh Behind every warning there is a true story. 2022年11月06日 01:39:50 +01:00
setup-container.sh add capability to run lxc as user ( #7 ) 2022年12月14日 12:18:18 +00: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.