Plataforma interna: GitLab, Kubernetes, Coolify o Dokploy
La base sobre la qual el vostre equip construeix i desplega, muntada al vostre compte, en codi i amb un procediment perquè qualsevol publique un servei nou.
Eines habituals
- Coolify
- Dokploy
- Gitea
- GitLab
- Kafka
- Keycloak
- Kubernetes
- Hetzner
En resum
Una plataforma interna és el conjunt d'eines amb què el vostre equip guarda el codi, el construeix i el desplega sense demanar ajuda. Muntem GitLab autoallotjat amb runners i registry, un clúster de Kubernetes o k3s, o un PaaS autoallotjat com Coolify o Dokploy quan Kubernetes és massa. Tot queda al vostre compte, en codi i documentat.
- Idiomes
- Castellà, català o anglés
- Resposta
- El següent dia feiner, en horari laboral
- Mètode
- Al vostre compte i al vostre repositori, en codi i documentat
Què inclou
- Arquitectura triada per escrit, amb el motiu i les alternatives descartades.
- GitLab autoallotjat amb runners, registry de contenidors i emmagatzematge d'objectes, si encaixa.
- Clúster de Kubernetes o k3s, o PaaS amb Coolify o Dokploy, desplegat amb codi.
- Plantilla per a publicar un servei nou: pipeline, desplegament, domini i certificat.
- Còpies de la plataforma amb restauració provada.
- Monitoratge bàsic de la mateixa plataforma.
- Accés de l'equip tècnic per VPN WireGuard, amb una clau per persona.
- Documentació i sessió de traspàs amb l'equip.
Quan cal una plataforma interna?
Quan desplegar depén d’una persona o d’un document desactualitzat. Aquests són els senyals més habituals:
- Cada projecte es desplega d’una manera diferent i només una persona sap com.
- El GitLab o el Gitea de casa fa anys que no s’actualitza i ningú no el vol tocar.
- Els minuts de CI al núvol o les llicències per usuari s’han convertit en una partida important.
- Voleu deixar de dependre d’un PaaS comercial i tindre els serveis al vostre compte.
- Cada client de l’agència té el seu servidor muntat a mà.
Kubernetes, k3s o un PaaS autoallotjat?
No hi ha una resposta única: depén de quants serveis teniu, de quants entorns necessiteu i de qui l’ha de mantindre. Aquesta és la comparació que solem fer amb cada equip:
| Opció | Encaixa quan | El que demana a canvi | El que no fa bé |
|---|---|---|---|
| Kubernetes gestionat (EKS, GKE, AKS) | Molts serveis, diversos entorns i alta disponibilitat | Coneixement de Kubernetes i vigilància del cost | Equips de dues persones amb tres aplicacions |
| k3s als vostres servidors | Kubernetes a Hetzner o un altre proveïdor sense servei gestionat | Mantindre vosaltres el pla de control i les actualitzacions | Escalar a desenes de nodes sense més disseny |
| Coolify o Dokploy | Poques aplicacions, un o dos servidors, equip petit | Acceptar-ne els límits de xarxa i d’alta disponibilitat | Polítiques de seguretat fines i multiclúster |
| Docker Compose amb CI | Una o dues aplicacions estables | Disciplina en el pipeline i en les còpies | Desplegaments sense tall i escalat automàtic |
La recomanació queda per escrit, amb el motiu. Si Kubernetes és massa per al vostre equip, us ho diem.
Què muntem amb GitLab?
Quan la plataforma gira al voltant de GitLab autoallotjat, ens ocupem de les peces que solen donar problemes: els runners amb memòria cau i escalat, el registry de contenidors amb neteja automàtica d’imatges, l’emmagatzematge d’objectes per a artefactes i paquets, l’inici de sessió únic amb el vostre proveïdor d’identitat i les còpies amb restauració provada. Ho detallem a la pàgina de GitLab self-hosted gestionat.
L’accés de l’equip tècnic als panells, les bases de dades i els servidors interns va per una VPN WireGuard, amb una clau per persona que es revoca al moment, sense ports d’administració oberts a internet.
Com es treballa el projecte?
És un projecte tancat, amb lliurables per escrit abans de començar:
Inventari
Quines aplicacions hi ha, com es despleguen avui, quins entorns necessiteu i quines restriccions teniu de dades o de proveïdor.
Disseny
Arquitectura triada, alternatives descartades i cost aproximat de la infraestructura al vostre proveïdor.
Muntatge en codi
Terraform o Ansible per a la infraestructura, Helm o els manifests del PaaS per als serveis, tot al vostre repositori.
Primer servei
Migrem una aplicació real de punta a punta i la fem servir de plantilla per a les altres.
Traspàs
Documentació, sessió amb l’equip i, si voleu, manteniment amb la quota d’SRE.
Quina experiència tenim amb plataformes?
Des de la direcció tècnica hem muntat i mantingut la plataforma de diverses startups, amb desplegaments en contenidors i una disponibilitat del 99,9 %. Com a DevOps en un SaaS B2B hem treballat amb entorns multinúvol descrits en codi i pipelines de CI/CD que desplegaven diverses vegades al dia. El que hem aprés: una plataforma només funciona si l’equip l’entén i la fa servir sense demanar permís.
Preguntes freqüents
Per què autoallotjar GitLab en lloc de fer servir el del núvol?
Sol compensar quan el codi no pot eixir de la vostra infraestructura, quan els minuts de CI al núvol es disparen o quan necessiteu runners amb maquinari propi. Si no es dona cap d'aquestes raons, us recomanarem el servei al núvol.
Coolify o Dokploy serveixen per a producció?
Sí, per a equips petits amb poques aplicacions i un parell de servidors. A partir de molts serveis, diversos entorns o requisits d'alta disponibilitat, Kubernetes o k3s solen ser una opció millor. Us expliquem on és el límit en el vostre cas.
Qui manté la plataforma després?
El vostre equip, amb la documentació que deixem, o nosaltres amb la quota d'SRE com a servei. La plataforma no depén de nosaltres: és al vostre compte i al vostre repositori.
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