More secure deployments via ssh

If we deploy an application automatically we have to grant the CI (Continuous Integration) access to the server. Common practice is to do that via a GitLab Runner or an ssh account on the server.

Personally I would not recommend using a GitLab Runner for deployments, because you have to maintain it. Another potential issue is, that you normally register runners for your whole GitLab instance or groups. That results in a scenario in which everyone can use that runner and accidentally (or not) destroy, for example, your production server. To avoid that you have to register the GitLab Runner in the Project it belongs to only. But even then your production server can be misused as a build worker and therefore create performance issues.

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, … .