Categoria: Desenvolupament
Gitea gestionat: Git lleuger i CI propi en el vostre servidor
Repositoris, revisions de codi i pipelines en una sola aplicació que cap en un servidor xicotet, amb còpies que restaurem de veritat i actualitzacions sense ensurts.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- Open source, MIT
En resum
Gitea és una forja de codi lleugera escrita en Go que reuneix repositoris Git, incidències, pull requests, paquets i CI en un sol binari. L'instal·lem al vostre compte o en el vostre servidor, el connectem amb el vostre inici de sessió, muntem els runners de Gitea Actions, fem còpies completes que restaurem en proves i el mantenim actualitzat.
De què ens encarreguem?
Gitea arranca en un minut i per això moltes vegades es queda tal com està: un contenidor amb SQLite, sense còpies i amb el runner en la mateixa màquina. Mentre l’equip és de tres persones no passa res. Quan el codi de l’empresa viu ací, cada peça necessita algú al darrere:
Repositoris
Emmagatzematge en disc dimensionat, amb recollida de fem de Git i avisos abans que s’òmpliga.
Base de dades
PostgreSQL per a usuaris, incidències i pull requests, amb còpies independents de les dels repositoris.
Runners d'Actions
act_runner en màquines separades, amb contenidors aïllats per treball i neteja d’imatges.
Accés
SSH, HTTPS, tokens i claus de desplegament, amb inici de sessió únic i doble factor.
Paquets
Registre de contenidors, npm, Maven i altres formats, amb polítiques per a no guardar cada versió per sempre.
Vigilància
Disc, certificats, cua de tasques internes i runners que deixen de respondre.
Quina arquitectura recomanem?
Gitea no necessita una plataforma gran. La separació que sí que val la pena és entre la forja i el que executa codi aliè:
Proxy invers
Acaba l’HTTPS, limita la mida de les pujades i deixa passar l’SSH de Git pel seu port.
Gitea
Un sol procés que serveix la web, l’API i Git. Els repositoris van en un volum propi, no en el disc del sistema.
PostgreSQL
Gestionada pel proveïdor o muntada per nosaltres, amb còpies a part. SQLite només per a proves.
Runners
act_runner en una altra màquina: un pipeline que es descontrola no ha de tombar la forja ni llegir-ne les dades.
Els adjunts, els artefactes d’Actions i els paquets els enviem a emmagatzematge d’objectes compatible amb S3 quan creixen, perquè el disc del servidor només guarde els repositoris.
Quins problemes trobem en un Gitea self-hosted?
- SQLite amb tot l’equip damunt: bloquejos d’escriptura quan diverses persones comenten i fusionen alhora.
- Runner en el mateix servidor: un treball que omple el disc amb imatges deixa sense espai els repositoris.
- Registre de paquets sense neteja: cada compilació puja una imatge nova i ningú no esborra les velles.
- Port SSH en conflicte: l’SSH del sistema i el de Gitea competeixen i els
git pushfallen sense un missatge clar. - Versions saltades: es passa d’una versió molt antiga a l’última de colp i la migració de la base de dades es queda a mitges.
- Usuaris locals que ningú no dona de baixa: sense connexió amb el directori, qui se’n va conserva l’accés al codi.
Com fem les còpies i les actualitzacions?
Gitea porta gitea dump, que empaqueta repositoris, base de dades, configuració i adjunts. El fem servir en instàncies xicotetes; en les grans copiem per separat la base de dades amb la seua eina nativa i els repositoris amb una còpia incremental, perquè un bolcat complet diari de diversos centenars de gigues no té sentit. En tots dos casos la còpia ix del servidor i, cada cert temps, alcem una instància a part a partir d’ella, clonem un repositori i obrim una pull request per a comprovar que tot encaixa.
Gitea publica versions menors amb correccions sovint i una de major cada pocs mesos. Llegim les notes, actualitzem primer una còpia de la vostra instància, comprovem que els runners continuen connectant i després actualitzem producció en una finestra avisada. Si aneu diverses versions per darrere, avancem de major en major, sense dreceres.
Com protegim la instància?
Desactivem el registre obert, fem obligatori el doble factor o el deleguem en el vostre Keycloak per OpenID Connect i revisem quins repositoris són públics. Els runners executen cada treball en un contenidor d’un sol ús, sense accés a la xarxa interna llevat del que és imprescindible, i els secrets d’Actions es guarden per repositori o organització, mai en el codi. Si Gitea no s’ha de veure des d’internet, el deixem darrere de la VPN.
Com migrem des de GitLab o GitHub?
Gitea té un assistent de migració que porta cada repositori amb el seu historial i, si l’origen ho permet, les seues incidències, pull requests, etiquetes i versions. Abans preparem la llista d’organitzacions, equips i permisos, perquè aquesta estructura no es trasllada sola. Els pipelines de GitLab CI cal reescriure’ls com a workflows d’Actions; els de GitHub Actions solen funcionar amb pocs canvis. Mantenim l’origen en només lectura uns dies fins que ningú no el troba a faltar.
Si el que necessiteu és la plataforma completa, amb desplegaments inclosos, és a plataforma interna i PaaS. Si encara dubteu entre les dues forges, la pàgina de GitLab self-hosted gestionat us ajuda a comparar.
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 | Un servidor cloud per a Gitea i PostgreSQL, i un altre per als runners. Repositoris en un volum i còpies a Object Storage de Hetzner, compatible amb S3. | Gitea consumeix poc: un servidor modest dona per a un equip sencer. El que més creix és el disc dels repositoris. |
| AWS | Gitea en EC2 amb volum EBS, RDS for PostgreSQL i S3 per a adjunts, paquets i còpies. | Els runners poden anar en instàncies spot si els treballs aguanten una interrupció. |
| Google Cloud | Compute Engine amb disc persistent, Cloud SQL per a PostgreSQL i Cloud Storage per a adjunts i còpies. | Encaixa si la resta de la vostra plataforma ja viu a Google Cloud. |
| Azure | Màquina virtual amb disc administrat, Azure Database for PostgreSQL i Blob Storage per a les còpies. | L'inici de sessió es connecta amb Microsoft Entra ID per OpenID Connect. |
| DigitalOcean | Droplet amb Gitea, base de dades PostgreSQL gestionada i Spaces per a adjunts i còpies. | |
| OVH | Instància de Public Cloud, base de dades gestionada d'OVHcloud i Object Storage per a les còpies. | |
| Servidor propi | Gitea i PostgreSQL en contenidors en el vostre servidor o en una màquina virtual, al costat del vostre directori. | Si l'accés és només intern, el deixem darrere de la VPN i publiquem, com a molt, els webhooks que ho necessiten. |
Què inclou
- Gitea al vostre compte del núvol o en el vostre servidor, a nom de la vostra empresa, amb la configuració (app.ini) al vostre repositori.
- PostgreSQL com a base de dades en lloc de SQLite quan l'equip ja treballa cada dia amb la instància.
- Runners de Gitea Actions (act_runner) en màquines separades, amb etiquetes per tipus de treball.
- Accés per SSH i HTTPS darrere d'un proxy invers, amb inici de sessió per OpenID Connect o LDAP.
- Registre de paquets i contenidors activat si el feu servir, amb neteja de versions antigues.
- Còpies diàries de repositoris, base de dades i adjunts, amb restauració de prova periòdica.
- Actualitzacions seguint les notes de cada versió, provades abans en una còpia.
- Migració de repositoris, incidències i pull requests des de GitLab, GitHub o una altra forja.
Preguntes freqüents
Gitea és una bona alternativa lleugera a GitLab?
Per a molts equips, sí. Ofereix repositoris, revisions, incidències, paquets i CI amb molts menys recursos i menys peces per mantindre. Es queda curt si necessiteu planificació de cartera, anàlisi de seguretat integrada o permisos molt fins entre centenars de grups; ací GitLab té més recorregut.
Serveixen els nostres workflows de GitHub Actions en Gitea Actions?
En bona part, perquè la sintaxi és compatible i moltes accions públiques funcionen tal com estan. Hi ha diferències: algunes accions depenen de l'API de GitHub i no totes les opcions estan implementades. Revisem els vostres workflows un a un i adaptem els que fallen.
Gitea o Forgejo?
Forgejo és una bifurcació comunitària de Gitea que hui segueix el seu propi camí, amb el seu propi calendari de versions i el seu propi govern. Per a l'ús diari s'assemblen molt. Mantenim qualsevol dels dos; si ja en teniu un, el normal és continuar-hi, i si comenceu de zero en parlem segons què us pese més.
Podem portar els repositoris des de GitLab o GitHub sense perdre l'historial?
Sí. La migració de Gitea copia l'historial complet de Git i, segons l'origen, també incidències, pull requests, etiquetes, fites i versions publicades. El que no viatja sol són els pipelines, les variables secretes i els webhooks, que preparem a part.
Qui gestiona els usuaris i els permisos?
La persona administradora de la vostra empresa, des de Gitea o des del vostre directori si està connectat per LDAP o OpenID Connect. Nosaltres ens ocupem del servidor, els runners, les còpies i les actualitzacions.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
Revisat el