i am preparing a gitlab rollout and caring about backup and migration strategies.
My idea is to have a production instance and on the same machine a test instance which i use to test gitlab updates before updating the production instance itself. I want to create a backup of the production instance, transfer it to the test instance and then perform the upgrade there. This steps works basically thanks to the great documentation of gitlab.
I have defined two docker-compose files (both with different container_name: gitlab and gitlab_test and of course different Ports). And now comes the problem: when is start the test instance, the production instance goes down after showing the log message “received signal 15” […].
Any ideas what i am doing wrong? Maybe something i basically missunderstood with gitlab running from docker image?
Hi, irrespective of whether you use omnibus or docker version, you will have port conflicts. Most simplest method is to make two VM’s or have two servers, one server for production, one server for test. As you have found out, trying to do it on the same machine is pretty much impossible, even more for omnibus since there can only be one /etc/gitlab, /opt/gitlab, /var/opt/gitlab, and so on. For docker, the biggest problem are the port conflicts to overcome.
I frequently use two servers, one for production, and one for testing recovery of my server and I generally do that once every six months. However, mine is omnibus install, so without docker.
My understanding of docker was that using different volumes and different ports two instances may run independently. I was wondering how gitlab-prod can receive a SIGTERM when docker raises the gitlab-test instance…
The option to use a VM for test is still there and for now i think this is the way to go.
Yep, I think generally storage and ports are the biggest, but there seems to be something else causing a conflict. I don’t use docker so cannot say what that would be. I tend to prefer standard VM’s at least I know where I stand with them, and easier to recover in the event of problems. Although I realise containers is a way forward, and I won’t escape it forever
That said, I generally prefer to keep things simple, hence separation of environments to ensure one doesn’t have an effect on the other. Especially if someone starts to overload the test environment when the base system is running both production and test/dev containers. I wouldn’t generally have a problem with test/dev on the same system, but production ideally should be segregated from these.
We don’t have that heavy usage but a lot of data so i dont think it would disturb daily operation. But i am with you, i will pull the daily backup to the test machine for migration tests.
