Network/Roadmap/MigrateToGitlab: Difference between revisions

From NURDspace
(Created page with "= Summary = We would like to switch our gitea instance to a gitlab-ee instance, so that we can more easily use ci/cd functionality within the space = Architecture = Gitlab-ee...")
 
No edit summary
Line 1: Line 1:
= Summary =
= Summary =
We would like to switch our gitea instance to a gitlab-ee instance, so that we can more easily use ci/cd functionality within the space
We run a Gitlab Enterprise setup to provide GIT and  CI/CD services for NURDspace members.


= Architecture =
= Architecture =
Gitlab-ee should run on a VM with atleast 4 cores, 8GB ram and 100GB of storage. We want to use the enterprise edition, not the community edition.
We use a single Gitlab-ee instance running on a dedicated KVM. There are two dedicated VMs that are used for CI/CD pipelines using both a docker and a shell runner. Storage for gitlab is done on a minio instance. In total, the following 4 VMs are in use:
 
* gitlab.vm.nurd.space
* gh-runner-almalinux.vm.nurd.space
* gh-runner-debian.vm.nurd.space
* minio.vm.nurd.space
 
= Access control =
To gain access to this setup, you need to have an LDAP account, and one of the gitlab admins will need to link you to the members group. In order to do this, you need to login once. This will sync your LDAP account to gitlab.
 
There are two top-level groups. One which contains code for members (and the public), and one that contains code that is used by the BOFH group, and only accessible via membership of the BOFH group.
 
= TODO =
Currently it is only possible to work with this system if you are on the space network or connected via VPN. We want to expose gitlab on a dedicated ip address, so that both HTTP and SSH will be able to work properly.
 
Also, this setup is linked to the new FreeIPA setup. As of right now, FreeIPA is not fully rolled out, so you might run into issues while connecting to gitlab.

Revision as of 18:09, 2 September 2024

Summary

We run a Gitlab Enterprise setup to provide GIT and CI/CD services for NURDspace members.

Architecture

We use a single Gitlab-ee instance running on a dedicated KVM. There are two dedicated VMs that are used for CI/CD pipelines using both a docker and a shell runner. Storage for gitlab is done on a minio instance. In total, the following 4 VMs are in use:

  • gitlab.vm.nurd.space
  • gh-runner-almalinux.vm.nurd.space
  • gh-runner-debian.vm.nurd.space
  • minio.vm.nurd.space

Access control

To gain access to this setup, you need to have an LDAP account, and one of the gitlab admins will need to link you to the members group. In order to do this, you need to login once. This will sync your LDAP account to gitlab.

There are two top-level groups. One which contains code for members (and the public), and one that contains code that is used by the BOFH group, and only accessible via membership of the BOFH group.

TODO

Currently it is only possible to work with this system if you are on the space network or connected via VPN. We want to expose gitlab on a dedicated ip address, so that both HTTP and SSH will be able to work properly.

Also, this setup is linked to the new FreeIPA setup. As of right now, FreeIPA is not fully rolled out, so you might run into issues while connecting to gitlab.