Categoria: Desenvolupament
GitLab self-hosted gestionat
El vostre GitLab en la vostra infraestructura, actualitzat sense ensurts, amb runners que no s'encallen i còpies que sabem que es restauren perquè ho comprovem.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
En resum
Un GitLab self-hosted gestionat és una instància de GitLab instal·lada en la vostra infraestructura de la qual es fa responsable un tercer. Ens encarreguem de la instància, els runners, el registry de contenidors, l'emmagatzematge d'objectes, l'inici de sessió únic, les còpies amb restauració provada, les actualitzacions de versió majors i el monitoratge. El vostre equip només l'ha de fer servir.
De què ens encarreguem?
Un GitLab autoallotjat no és només la web on hi ha el codi. És una base de dades, un emmagatzematge d’arxius, un registry d’imatges, uns runners que executen cada pipeline i un bon grapat de secrets. Si una d’aquestes peces falla, l’equip deixa de poder desplegar. Això és el que vigilem i mantenim:
Instància
Serveis de GitLab, PostgreSQL, Redis i Gitaly, amb la seua configuració en codi.
Runners
Memòria cau compartida, límits de recursos, etiquetes per tipus de treball i escalat automàtic.
Registry
Imatges de contenidor amb polítiques de neteja perquè el disc no s’òmpliga.
Emmagatzematge d'objectes
Artefactes, paquets, LFS i còpies fora del disc del servidor.
Inici de sessió únic
Accés amb el vostre proveïdor d’identitat i baixes que s’apliquen a l’instant.
Monitoratge
Salut de la instància, cues de treballs, disc i certificats, amb alertes.
Quina arquitectura recomanem?
No cal l’arquitectura de referència per a milers d’usuaris si sou quinze. Triem el mètode d’instal·lació segons la mida de l’equip i el que ja tingueu muntat:
| Mida de l’equip | Instal·lació | Runners | Emmagatzematge |
|---|---|---|---|
| Fins a unes 50 persones | Omnibus en una màquina, amb PostgreSQL i Redis inclosos | En una o dues màquines a part, amb escalat si hi ha pics | Emmagatzematge d’objectes per a artefactes, registry i còpies |
| Equips mitjans | Omnibus amb PostgreSQL gestionat del proveïdor | Escalat automàtic en màquines o en Kubernetes | Emmagatzematge d’objectes per a tot el que ho admet |
| Ja teniu Kubernetes | Chart oficial de Helm, amb base de dades i Redis fora del clúster | Runner de Kubernetes amb límits per espai de noms | Emmagatzematge d’objectes obligatori |
En els tres casos, els runners van separats de la instància: un pipeline que es menja la memòria no ha de tombar el GitLab de tot l’equip.
Quins problemes trobem més sovint?
Quan ens fem càrrec d’un GitLab que ja existeix, quasi sempre apareix algun d’aquests:
- El disc s’omple: artefactes i imatges del registry que ningú no neteja des de fa anys.
- La còpia no serveix: es copia la base de dades, però no els secrets de la instància, i sense ells la restauració no arranca.
- Versió molt endarrerida: tantes versions per darrere que cal encadenar diversos salts, un darrere l’altre.
- Runners compartits sense límits: un treball pesat deixa la resta de l’equip esperant.
- Usuaris que ja no hi són: comptes actius de persones que se’n van anar, perquè no hi ha inici de sessió únic.
- Certificats caducats: el registry deixa d’acceptar imatges un dilluns de matí.
Com tractem les còpies i les actualitzacions?
La còpia de GitLab té dues parts: les dades (repositoris, base de dades, arxius pujats) i els secrets de la instància. Copiem totes dues, fora del servidor, i cada mes restaurem la instància en una màquina de prova per a comprovar que arranca i que els repositoris estan complets. El temps que costa queda en l’informe.
Les versions majors de GitLab arriben una vegada l’any i canvien coses. Les planifiquem seguint la ruta d’actualització oficial, amb una còpia abans de cada salt, una prova prèvia si la instància és gran i una finestra avisada. Les versions de seguretat s’apliquen tan bon punt ixen.
En quin compte i amb quins accessos?
En el vostre. La màquina, l’emmagatzematge, la base de dades gestionada i la llicència, si n’hi ha, estan a nom de la vostra empresa en el vostre proveïdor: AWS, Google Cloud, Azure, Hetzner, OVH o un servidor propi. Hi entrem amb un usuari nominal i permisos d’administració només on calen, i la configuració queda al vostre repositori, perquè una altra persona puga continuar si un dia ho deixem.
Si voleu muntar alguna cosa més que GitLab, com la plataforma completa de desplegament, és a plataforma interna i PaaS. Si el que voleu és que algú responga de tota la plataforma cada mes, encaixa amb l’SRE com a servei.
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Servidor cloud amb Omnibus i PostgreSQL dins de la mateixa instal·lació, perquè Hetzner no ofereix base de dades gestionada. Object Storage de Hetzner, compatible amb S3, per a artefactes, registry i còpies. | Els runners van en servidors a part que es creen i es destrueixen segons la càrrega. |
| AWS | EC2 amb Omnibus, RDS for PostgreSQL i S3. Si ja teniu EKS, chart oficial de Helm amb la base de dades en RDS. | Vigilem la transferència d'eixida: els registry amb moltes descàrregues la disparen. |
| Google Cloud | Compute Engine amb Omnibus, Cloud SQL per a PostgreSQL i Cloud Storage. En GKE, chart de Helm. | Cloud SQL simplifica les còpies i els pegats de la base de dades. |
| Azure | Màquina virtual amb Omnibus, Azure Database for PostgreSQL i Blob Storage, que GitLab admet com a emmagatzematge d'objectes. En AKS, chart de Helm. | Encaixa si l'inici de sessió ja va amb Microsoft Entra ID. |
| DigitalOcean | Droplet amb Omnibus, PostgreSQL gestionat de DigitalOcean i Spaces, compatible amb S3. | |
| OVH | Instància de Public Cloud amb Omnibus, base de dades gestionada d'OVHcloud per a PostgreSQL i Object Storage compatible amb S3. | |
| Servidor propi | Omnibus en el vostre servidor o en una màquina virtual de Proxmox, amb PostgreSQL inclòs. | La còpia ix fora de l'edifici, a un emmagatzematge S3 en el núvol. |
Què inclou
- Instància de GitLab CE o EE instal·lada amb el mètode oficial adequat a la vostra mida: Omnibus, contenidors o Helm.
- Runners amb memòria cau, límits i escalat automàtic, en màquines o en Kubernetes.
- Registry de contenidors amb neteja automàtica d'imatges antigues.
- Emmagatzematge d'objectes (S3 o compatible) per a artefactes, paquets, LFS i còpies.
- Inici de sessió únic amb el vostre proveïdor d'identitat (SAML o OpenID Connect).
- Còpies diàries fora del servidor, amb els secrets de la instància inclosos, i restauració de prova.
- Actualitzacions de versió majors planificades, seguint la ruta d'actualització oficial.
- Monitoratge de la instància, els runners i l'espai en disc, amb alertes.
Preguntes freqüents
Quina edició de GitLab gestioneu?
Totes dues: Community Edition, gratuïta, i Enterprise Edition amb llicència o sense. Si teniu llicència de pagament, continua sent vostra i a nom vostre; nosaltres només l'apliquem en la instància.
Quant tarda una actualització major?
Depén de quantes versions calga saltar i de la mida de la base de dades. Planifiquem la ruta oficial d'actualització, fem una còpia abans de cada salt i us avisem de la finestra. En instàncies xicotetes sol ser qüestió de minuts de tall per salt.
Podem migrar de GitLab.com al nostre servidor, o a l'inrevés?
Sí. Es migren grups, projectes, incidències i merge requests amb les eines de migració de GitLab. Els runners i les variables de CI es revisen a part, perquè no sempre viatgen sols.
Gestioneu també GitHub o Gitea?
Gitea sí, també autoallotjat. Amb GitHub no hi ha instància per mantindre, però sí que podem ocupar-nos dels runners propis i dels pipelines.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Revisat el