Handling server configurations

Intro

During my work as a programmer I often encountered that configuration and infrastructure files only lived on the servers they belog to. If they had a copy in git, the states would always divert over time. One reason for this diverting is that you actively have to put the changed files in git, after you finished your work. It’s simply a thing you can forget.

What do I mean by “infrastructure files”? For me infrastructure files are files, that you need to configure the server itself, e.g. nginx-config, docker-compose.yml, … .

A few years ago every program was installed on the server directly with all the consequences. Nowadays, I prefer to use a docker-based server setup. It has the clear benefit that I can move my infrastructure easily to another server and have less stress with server upgrades [because fewer applications on the server itself means fewer conflicts while upgrading].

My current setup

Currently, my whole server setup is based on docker, docker-compose, bash-files and git. I store all configurations in git - except for the secrets, of course. In this configuration the git-state is the one and only truth. When I push a commit to the master branch of the configuration-repository, a chain of events will update the server according to the git state. You can follow the triggered events in the following figure.

As you can see the server follows the git state. If someone ever changes something on the server directly and forgets to push the changes into git, the next CI-job will fail and therefor bring attention to that problem.

The runcontrol.sh script plays a big role in the automated process. It knows how to get the server to the desired state. In a simple setup it would just execute git pull and docker-compose up -d --build, but in a more advanced setup runcontrol.sh can do much more than that. My implementation of runcontrol.sh can:

• update
• backup
• restore
• change the passwords of technical-users
• prepare [the server initially]
• start
• stop

Future

I’m currently thinking about replacing runcontrol.sh with a program. It has gotten quite complex over time. There is the need for shared functionality like backing up / restoring a folder, backing up / restoring a specific database and so on. A real programming language supports all these features more intuitively than bash - at least for me as a programmer.

Conclusion

This concept comes with many benefits and is what I currently use for all my setups. As usual there are some things to improve like I mentioned in Future. It’s a good start and as many concepts it will evolve to something even better.

If you have any ideas to improve this concept feel free to comment below.