Handling server configurations
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.
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
- change the passwords of technical-users
- prepare [the server initially]
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.
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.