DevOps, CI/CD, contenidors i Kubernetes

Abast decidit per nosaltres: l'enunciat oficial no acota la matèria

Enunciat oficial. DevOps i integració/desplegament continus (CI/CD). Contenidors Docker i orquestració Kubernetes.

1. DevOps

Definició: DevOps és una filosofia, un conjunt de pràctiques culturals, organitzatives i tècniques que uneixen desenvolupament (Dev) i operacions (Ops). La seva finalitat principal és millorar la col·laboració entre els dos equips; reduir el temps de lliurament, retallar costos i pujar la qualitat en són conseqüències, no l'objectiu en si.

El problema que resol: el «mur de la confusió» entre un equip de desenvolupament incentivat pel canvi i un equip d'operacions incentivat per l'estabilitat.

DevOps no és una eina ni un producte: és una manera de treballar que després es materialitza en un flux automatitzat. Els components que sí que en formen part són el repositori de codi, la integració i les proves automàtiques i el desplegament automatitzat; tot allò que només observa el resultat —un quadre de comandament d'indicadors de producció— és útil, però no és una peça del cicle.

1.1 Els tres camins i CALMS

1. Flux: optimitzar el flux d'esquerra a dreta, de desenvolupament a producció (lots petits, visualització del treball, eliminació de colls d'ampolla).
2. Retroalimentació: crear cicles de retroalimentació ràpids de dreta a esquerra (proves automàtiques, monitoratge, alertes). Aquest camí és el que exigeix una plataforma d'observabilitat → tema 23.
3. Aprenentatge continu i experimentació: cultura d'aprenentatge, post-mortems sense culpables, injecció de fallides.

CALMS (Culture, Automation, Lean, Measurement, Sharing) és la llista de comprovació d'adopció: cultura, automatització, eliminació del malbaratament, mesura i compartició.

1.2 Les mètriques DORA

DORA (DevOps Research and Assessment) és el grup de recerca —avui a Google— que publica cada any l'informe State of DevOps. Les seves quatre mètriques clau:

La troballa central de DORA és que no hi ha compromís entre velocitat i estabilitat: els equips d'alt rendiment són millors en totes quatre.

1.3 DevSecOps, SRE i plataforma

• DevSecOps: la seguretat entra al pipeline des del primer minut (shift left), en lloc d'auditar-se al final.
• SRE (Site Reliability Engineering): la disciplina de Google que aplica pràctiques d'enginyeria de programari a operacions. DevOps diu què cal aconseguir (cultura i flux); SRE és una implementació concreta amb regles mesurables: SLI (Service Level Indicator, l'indicador mesurat), SLO (Service Level Objective, l'objectiu que se li fixa) i pressupost d'error (error budget), que és el marge de fallida que queda abans d'incomplir l'objectiu i que autoritza o congela els desplegaments nous.
• Enginyeria de plataforma: un equip intern construeix una plataforma d'autoservei perquè la resta desplegui sense demanar permís.

2. Integració contínua

Integració contínua (CI, Continuous Integration): pràctica en què els desenvolupadors integren el seu codi al repositori compartit de manera freqüent —diverses vegades al dia— i cada integració es verifica automàticament amb una compilació i una bateria de proves automatitzades.

Per què és essencial: detecta els errors d'integració i el codi conflictiu en minuts en lloc de setmanes, manté la branca principal sempre desplegable, redueix el cost de la correcció (com més tard es detecta un defecte, més car és), dona retroalimentació ràpida i objectiva, i és la base necessària per a qualsevol grau de lliurament o desplegament continus.

Pràctiques associades: control de versions únic per a tot (codi, configuració, infraestructura), compilacions automatitzades i reproduïbles —mateixa entrada, mateix artefacte—, bateria de proves ràpida, arreglar la compilació trencada com a màxima prioritat i branques de vida curta.

3. Lliurament i desplegament continus

Les dues comparteixen la sigla CD, i és la confusió que més es pregunta: el que canvia no és el grau d'automatització de les proves, sinó qui prem el botó final.

3.1 El pipeline

El pipeline és la cadena automatitzada que porta un canvi del repositori a producció. És la tècnica que implementa el lliurament continu: sense ell, «llest per desplegar en qualsevol moment» és una declaració d'intencions.

commit → build → proves unitàries → anàlisi estàtica i de seguretat →
empaquetat (imatge) → desplegament a proves → proves d'integració i
d'extrem a extrem → preproducció → aprovació → producció → verificació

Quines proves corren a quina etapa és matèria del tema de proves de programari (→ tema 49); aquí importa l'ordre: com més barata i ràpida és una prova, més aviat corre.

Qualitat i seguretat al pipeline: SAST (Static Application Security Testing, anàlisi estàtica del codi), SCA (Software Composition Analysis, dependències de tercers), DAST (Dynamic Application Security Testing, sobre l'aplicació en execució), escaneig de les imatges de contenidor, detecció de secrets i signatura d'artefactes → tema 46.

Artefactes i registre: el pipeline construeix una sola vegada l'artefacte —un fitxer empaquetat o una imatge de contenidor—, el desa en un repositori d'artefactes o registre d'imatges versionat i és aquest mateix artefacte el que puja per tots els entorns. Recompilar per a cada entorn trenca la garantia de que allò provat és allò desplegat.

Eines: Jenkins, GitLab CI/CD, GitHub Actions, Azure DevOps, Tekton, Argo CD i Flux.

3.2 Estratègies de desplegament

• Recreate: aturar i desplegar. Simple, però amb tall de servei.
• Rolling update: substitució progressiva de les instàncies, sense tall. És l'estratègia per defecte de Kubernetes.
• Blau-verd (blue-green): dos entorns idèntics i complets; es commuta el trànsit d'un a l'altre. Retorn immediat, a canvi de duplicar recursos.
• Canari (canary): s'envia un percentatge petit del trànsit a la versió nova i s'incrementa si les mètriques són bones. Limita l'abast de la fallida.
• Feature flags: el codi es desplega desactivat i s'activa per configuració. Desacobla el desplegament de l'alliberament → tema 19.

4. Infraestructura com a codi i GitOps

Infraestructura com a codi (IaC, Infrastructure as Code): gestionar servidors, xarxes i serveis mitjançant fitxers versionats en lloc de configuració manual. La forma correcta de gestionar la infraestructura en un projecte àgil és exactament aquesta: automatitzar-la amb una eina, no configurar-la a mà.

Dues famílies que no s'han de confondre:

• Aprovisionament: crea i destrueix els recursos (Terraform / OpenTofu, Pulumi, CloudFormation).
• Gestió de la configuració: deixa una màquina ja existent en l'estat desitjat —paquets, fitxers, serveis— (Ansible, Puppet, Chef). Ansible és l'exemple de codi obert de referència: sense agent (treballa per connexió remota), descriu infraestructura, aplicacions i xarxa en fitxers de text i serveix tant per a màquines virtuals com per a contenidors.

Distincions que es pregunten:

• Declaratiu vs imperatiu: el declaratiu descriu l'estat desitjat i l'eina calcula els passos; l'imperatiu descriu els passos. Terraform i Kubernetes són declaratius; un guió de consola és imperatiu.
• Idempotència: aplicar la mateixa definició una vegada o deu vegades deixa el sistema en el mateix estat. És el que permet reexecutar sense por.
• Una eina no és un format: YAML i JSON són formats de dades i Python és un llenguatge; cap dels tres és, per si sol, una eina de gestió de la configuració. I kubectl tampoc: és el client de línia d'ordres de Kubernetes, limitat a aquest orquestrador.

Infraestructura immutable: els components no es modifiquen un cop desplegats; quan cal un canvi es construeix una instància nova a partir de la imatge actualitzada i se substitueix la vella. Elimina la deriva de configuració (configuration drift), fa els desplegaments reproduïbles i simplifica el retorn. S'oposa a la infraestructura mutable, on s'apedacen els servidors existents.

GitOps: portar el model anterior fins al final. L'estat desitjat viu a Git, que és l'única font de veritat, i un agent reconciliador dins del clúster compara contínuament l'estat real amb el declarat i el corregeix (Argo CD, Flux). Desplegar és fusionar un canvi; retornar és revertir-lo.

5. Contenidors i Docker

Contenidor: unitat d'empaquetat que conté l'aplicació i totes les seves dependències —biblioteques, configuració i entorn d'execució— i que s'executa aïllada compartint el nucli del sistema operatiu amfitrió.

Avantatges, per ordre del que es pregunta:

• Lleugeresa i eficiència en l'ús dels recursos: no hi ha sistema operatiu convidat, i per tant l'arrencada és de segons i la densitat per servidor és molt més alta.
• Consistència entre entorns: l'aplicació s'executa idènticament al portàtil, a integració i a producció, perquè el paquet inclou les dependències.
• Portabilitat entre amfitrions i entre proveïdors, i encaix natural amb la integració i el lliurament continus i amb els microserveis (un servei, una imatge → tema 48).

5.1 Contenidor, màquina virtual i chroot

La conseqüència pràctica: si cal executar sistemes operatius diferents i complets sobre un mateix maquinari —programari que només funciona sobre Windows al costat d'aplicacions Linux—, la resposta és la màquina virtual, no el contenidor. Les dues tecnologies conviuen: el patró habitual és un clúster de contenidors sobre màquines virtuals.

L'antecessor és chroot, que només canvia el directori arrel que veu un procés: no aïlla processos, ni xarxa, ni usuaris, ni limita recursos, i no és una plataforma de desplegament.

Tecnologia de base a Linux: namespaces —aïllament de processos, xarxa, muntatges, usuaris, comunicació entre processos i nom d'amfitrió— i cgroups —límits de CPU (Central Processing Unit), memòria i entrada/sortida—, més capabilities, seccomp i SELinux/AppArmor.

5.2 La imatge en capes i el contenidor efímer

• Dockerfile: la recepta declarativa que construeix la imatge; cada instrucció genera una capa.
• Imatge: plantilla immutable, formada per capes de només lectura i identificada per una etiqueta i un resum criptogràfic.
• Contenidor: una instància en execució d'una imatge, amb una capa d'escriptura pròpia i efímera al damunt (copy-on-write).

D'aquí surt la regla que més cau: tot el que s'escriu dins d'un contenidor viu en aquesta capa i desapareix quan el contenidor s'elimina. Modificar a mà un fitxer de configuració dins d'un contenidor no toca la imatge: en tornar a instanciar-la reapareix la configuració original i el problema torna. Per això:

• Les dades que han de sobreviure van fora: volums gestionats pel motor, muntatges d'un directori de l'amfitrió o emmagatzematge de xarxa.
• La configuració va fora de la imatge: variables d'entorn, volums i, a Kubernetes, ConfigMap i Secret. Escriure els valors dins del Dockerfile els cou a la imatge i obliga a una imatge per entorn: és precisament l'opció que no val.
• Els registres surten per la sortida estàndard i els recull la plataforma, en lloc d'acumular-se al disc del contenidor.

5.3 Docker, OCI i els altres motors

• Registre (registry): repositori d'imatges, públic o privat (Docker Hub, Harbor, els dels proveïdors de núvol).
• Docker Compose: definició multicontenidor per a entorns de desenvolupament.
• OCI (Open Container Initiative): l'organisme, sota la Linux Foundation, que estandarditza el format d'imatge, el temps d'execució i la distribució. És el que fa que «contenidor» no vulgui dir «Docker»: qualsevol motor conforme executa la mateixa imatge.

5.4 Seguretat dels contenidors

La guia de referència és la NIST SP (Special Publication) 800-190, que ordena els riscos pels components: imatge, registre, orquestrador, contenidor i sistema operatiu amfitrió. Contramesures mínimes:

• Imatges mínimes (Alpine, distroless) i compilació multietapa: menys programari, menys superfície.
• No executar com a arrel ni amb contenidor privilegiat.
• Cap secret dins de la imatge, que és de només lectura i es distribueix.
• Etiquetes immutables —mai latest en producció— i signatura de la imatge.
• Escaneig de vulnerabilitats de la imatge i de les seves dependències, integrat al pipeline.
• Amfitrió endurit: el nucli és compartit, i una fuita del contenidor compromet tots els que hi conviuen.

6. Kubernetes

Definició: plataforma de codi obert per a l'orquestració de contenidors. Automatitza el desplegament, l'escalat, la recuperació i la gestió d'aplicacions contenidoritzades sobre un clúster de màquines. Un contenidor sol no dona alta disponibilitat; l'orquestrador sí: manté el nombre de rèpliques declarat, reprograma els contenidors d'un node caigut i retira del balanceig els que no superen les proves de vida.

6.1 Arquitectura

Model declaratiu i reconciliació: es declara l'estat desitjat i els controladors treballen contínuament perquè l'estat real hi coincideixi. És el fonament de GitOps i el que dona l'autoreparació.

6.2 Objectes de càrrega de treball

• Pod: la unitat mínima desplegable. Un o més contenidors que comparteixen xarxa —una adreça i un espai de ports— i emmagatzematge, i que sempre es programen junts al mateix node. Kubernetes no desplega contenidors solts.
• ReplicaSet: manté el nombre de rèpliques d'un pod.
• Deployment: gestiona ReplicaSets i ofereix actualització progressiva amb retorn (rollback). És l'objecte habitual per a serveis sense estat.
• StatefulSet: per a càrregues amb estat, amb identitat de xarxa i emmagatzematge estables per rèplica.
• DaemonSet: una rèplica per node (agents de registre, de mètriques, de xarxa).
• Job: executa un o diversos contenidors fins que completen amb èxit una tasca puntual —un procés per lots (batch)— i no es torna a llançar. CronJob: llança un Job a una hora programada, puntualment o recurrentment, com el cron d'Unix. Cap dels dos manté rèpliques contínues com Deployment, ni s'executa un cop per node com DaemonSet.

6.3 Xarxa, configuració i emmagatzematge

• Service: adreça i nom estables amb balanceig cap a un conjunt de pods, que van i vénen. Tipus: ClusterIP (intern, el tipus per defecte), NodePort (un port fix a cada node), LoadBalancer (balancejador extern del proveïdor) i ExternalName (àlies a un nom extern).
• Ingress i Gateway API: no són un tipus de Service. Són el punt d'entrada del trànsit web des de fora, amb encaminament per amfitrió i per ruta i acabament de xifratge, i concentren en un sol recurs allò que si no exigiria un balancejador per servei.
• ConfigMap i Secret: configuració i dades sensibles fora de la imatge, injectades com a variables d'entorn o com a fitxers.
• PersistentVolume (PV) i PersistentVolumeClaim (PVC, Persistent Volume Claim): el primer és el volum real que ofereix l'administrador o una classe d'emmagatzematge; el segon és la petició que en fa l'aplicació. Separen qui consumeix de qui proveeix.
• Namespace: separació lògica dins d'un mateix clúster, amb quotes i permisos propis.

6.4 Recursos, escalat, seguretat i ecosistema

• Peticions i límits: la petició (request) és el que el planificador reserva per decidir on cap el pod; el límit és el sostre que no pot passar. Sense petició no hi ha planificació fiable; sense límit, un pod pot ofegar el node.
• Escalat automàtic: HPA (Horizontal Pod Autoscaler, més rèpliques segons una mètrica), VPA (Vertical Pod Autoscaler, més recursos per rèplica) i autoescalat de nodes.
• Sondes: de vida (liveness), de disponibilitat (readiness) i d'arrencada (startup). Són el que converteix les rèpliques en alta disponibilitat real.
• Seguretat: RBAC (Role-Based Access Control) amb mínim privilegi, comptes de servei, NetworkPolicy per a la microsegmentació entre pods, secrets xifrats en repòs, admissió de polítiques (OPA (Open Policy Agent) o Kyverno) i actualització del clúster.
• Ecosistema: Helm (empaquetat i plantilles reutilitzables), Kustomize, operadors (lògica d'operació pròpia mitjançant recursos a mida), service mesh → tema 47, i observabilitat → tema 23. La CNCF (Cloud Native Computing Foundation) allotja i gradua aquests projectes.
• Plataformes i distribucions: OpenShift, Rancher, k3s i els serveis gestionats dels grans proveïdors de núvol. Compte amb els productes veïns que no són plataformes de contenidors: dins de la mateixa família d'un fabricant hi conviuen l'hipervisor i l'emmagatzematge definit per programari —vSAN n'és el cas típic—, que resolen un altre problema.

7. Al sector públic

• Contractació: cal preveure la propietat del codi i de les definicions d'infraestructura, la reversibilitat i la portabilitat entre proveïdors (LCSP, Llei de Contractes del Sector Públic, i Mesura de digitalització oberta).
• Kubernetes com a capa d'abstracció és una de les millors defenses contra el bloqueig de proveïdor de núvol → tema 59.
• Seguretat: l'ENS (Esquema Nacional de Seguretat) exigeix control de canvis, gestió de la configuració, gestió de vulnerabilitats i traçabilitat; el pipeline n'és l'instrument natural.
• Traçabilitat de l'actuació automatitzada (Llei 40/2015, art. 41): auditar el codi font i les versions desplegades es resol amb control de versions i signatura d'artefactes.
• Programari lliure: tot l'ecosistema descrit és de codi obert, cosa que encaixa amb la política municipal.

Claus d'examen

• La pregunta que més ha caigut és la de sempre: quina pràctica executa proves automàtiques cada cop que s'integra codi al repositori compartit. La resposta és integració contínua, no desplegament continu ni gestió de la configuració (TS-TIC 2025, p. 45; i reformulada a TS-TIC 2025, pràctica p. 7).
• El pipeline implementa el lliurament continu de programari, no els contenidors ni els microserveis, encara que hi convisquin (TS-TIC 2018, p. 7).
• El contenidor és efímer: el tribunal ho ha preguntat dues vegades, per les dues cares. Un fitxer creat dins d'un contenidor s'esborra quan aquest s'atura o s'elimina (TS-TIC 2021, p. 8), i per això editar-hi la configuració a mà no arregla res (TM-TIC 2021, pràctica p. 8).
• Quan la pregunta demana executar sistemes operatius complets i diferents sobre el mateix maquinari, la resposta és màquina virtual, mai contenidor: el contenidor comparteix el nucli (TS-TIC 2023, pràctica p. 12).
• Preguntes de tipus «quina NO»: sol colar-s'hi un producte d'una altra categoria —emmagatzematge definit per programari entre plataformes de contenidors (TS-TIC 2023, pràctica p. 13)—, o un valor cuit dins del Dockerfile entre les maneres de configurar des de fora (TM-TIC 2021, p. 15). Classifica el producte abans de respondre.
• Eina no és format: si demanen l'eina de codi obert que desplega i configura infraestructura, aplicacions i xarxa, és Ansible; YAML i JSON són formats i Python és un llenguatge (TM-TIC 2021, pràctica p. 7).

Per recordar

• Integració contínua = integrar sovint i verificar automàticament amb proves a cada integració. Lliurament continu = llest per desplegar, amb botó humà; desplegament continu = a producció sense intervenció.
• Les quatre mètriques DORA: freqüència de desplegament i temps de lliurament (velocitat), temps de recuperació i taxa de fallides dels canvis (estabilitat).
• SRE és una implementació concreta de DevOps: SLI, SLO i pressupost d'error.
• L'avantatge del contenidor és la lleugeresa i l'eficiència de recursos més la consistència entre entorns. Comparteix el nucli de l'amfitrió; la màquina virtual porta el seu propi sistema operatiu complet i és l'única que fa conviure Linux i Windows sobre el mateix maquinari.
• La imatge és immutable i per capes; el contenidor hi afegeix una capa d'escriptura efímera. Dades i configuració, sempre fora: volums, variables d'entorn, ConfigMap i Secret.
• OCI estandarditza imatge, execució i distribució: contenidor no és sinònim de Docker.
• Pod = unitat mínima desplegable; Deployment gestiona rèpliques i actualització progressiva; Service dona adreça estable —ClusterIP per defecte—; Ingress és l'entrada web i no és un tipus de Service; etcd guarda l'estat i tot passa pel servidor d'API.
• Kubernetes és declaratiu i reconciliatiu, i és l'orquestrador —no el contenidor sol— qui aporta alta disponibilitat.
• Infraestructura immutable: no es modifica en calent, es reemplaça; elimina la deriva de configuració. GitOps posa aquest estat desitjat a Git com a única font de veritat.
• Aprovisionament (Terraform) i gestió de la configuració (Ansible) no són el mateix; les dues han de ser idempotents (IaC).
• Blau-verd = commutació entre dos entorns complets; canari = increment progressiu del trànsit; feature flags desacoblen desplegament i alliberament.