Setting up/configuring GitLab using using code instead of ClickOps

Infrastructure as Code & Cloud Native
, ,
1

Problem to solve

I have deployed GitLab using the Helm chart and setup external services like the database, object storage and redis/valkey.

I am now at the stage where I would like to setup administration options, for example, disabling sign up, setting up an external OAuth provider, etc.

I have setup an external OAuth provider already as I could see those options in the Helm chart and there was documentation on it.
It doesn’t look like there are many other options in the Helm chart to configure such settings, so my question is: “how can I set all the administration options in the GitLab Admin UI pages using config/infrastructure as code principles?”.
I want to do this to make disaster recovery easier.

I would hope to be able to do something similar to Jenkins Configuration as Code.

Versions

  • Self-managed
  • GitLab.com SaaS
  • Dedicated

gitlab-rake gitlab:env:info output:

System information
System:		
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	3.2.8
Gem Version:	3.7.2
Bundler Version:2.7.2
Rake Version:	13.0.6
Redis Version:	7.0.15
Sidekiq Version:7.3.9
Go Version:	unknown

GitLab information
Version:	18.6.1-ee
Revision:	6e920e06fbf
Directory:	/srv/gitlab
DB Adapter:	PostgreSQL
DB Version:	17.4
URL:		https://gitlab.dsohub.co.uk
HTTP Clone URL:	https://gitlab.dsohub.co.uk/some-group/some-project.git
SSH Clone URL:	git@gitlab.dsohub.co.uk:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: openid_connect

GitLab Shell
Version:	14.45.3
Repository storages:
- default: 	tcp://gitlab-gitaly-0.gitlab-gitaly.gitlab.svc:8075
GitLab Shell path:		/home/git/gitlab-shell

Gitaly
- default Address: 	tcp://gitlab-gitaly-0.gitlab-gitaly.gitlab.svc:8075
- default Version: 	18.6.1
- default Git Version: 	2.50.1
2

My initial reaction - at runtime after provisioning (Helm in this case, for cloud VMs, Terraform/Opentofu), leveraging Ansible against the GitLab REST API. Application settings API | GitLab Docs There are also community.general.gitlab_* modules. For secrets, Ansible Vault. As API library, python-gitlab which plays well together with Ansible.

After reasoning with Claude a bit, it recommended the Terraform provider for GitLab, following the same GitOps principles as with Helm.

3

Thanks @dnsmichi !

I am using the GitLab terraform provider already for managing users/groups.
I use the Keycloak provider and have created a GitLab module to get around the lack of OIDC client group sync features.

Is it just this terraform resource that would be used for all settings within the admin section? Terraform Registry.
This is my guess judging by the “upstream API” link on that docs page.

4

I did not use it yet, but it looks good for administrative settings from what I can see, mapping Application settings API | GitLab Docs

5

I have decided to just use the GitLab API directly and create a Bruno collection (Bruno is open source Postman without forced cloud syncing for those that don’t know, I love it) with all the different sorts of management requests I want.

I think that the Terraform provider includes many of the resources you would want if you want to create projects/repositories in that manner, but the application_settings resource does not include all the settings that are listed on the official API docs page, and therefore it is difficult to use.

I have used the Terraform to manage users and groups as I was already using the Keycloak provider to do that with OIDC clients, and I used the GitLab Terraform provider resources to make up for the lack of OIDC client group sync features which works really nicely.

1 Like
6

Thanks for sharing your solution and feedback :slight_smile: