italiadatacenter/pipeline/DEV_build_deploy.md

Pipeline Gitea: DEV_build_deploy.yaml

Scopo

Questa pipeline esegue build, publish immagini Docker e deploy Kubernetes dell'ambiente dev.

Flusso alto livello:

1. Checkout del repository.
2. Login al registry Harbor.
3. Build e push delle immagini per ogni servizio in containers/*.
4. Creazione del file kubeconfig da secret.
5. Sostituzione variabili nei manifest Kubernetes.
6. Deploy dei manifest e configurazione listener HTTPS sul Gateway.

Trigger e runner

• Trigger: push su branch main.
• Job: docker.
• Runner richiesto: POC-Master0.

Definizione pipeline

File: pipeline/DEV_build_deploy.yaml

Step principali:

• actions/checkout@v4
• docker/login-action@v3
• /root/work/pipeline/build_container.sh ${{ github.event.repository.name }} ${{ vars.REGISTRY }}
• creazione ./kubeconfig da ${{ secrets.KUBECONFIG_DEV }}
• /root/work/pipeline/customize.sh dev
• /root/work/pipeline/deploy.sh

Script eseguiti dalla pipeline

1) build_container.sh

Responsabilità:

• Itera tutte le directory containers/*/.
• Copia i sorgenti da src/<container>/ dentro containers/<container>/.
• Rileva il Dockerfile (dockerfile oppure Dockerfile).
• Costruisce due tag immagine:
  • ${REGISTRY_URL}/${REPO_NAME}/${CONTAINER_NAME}:${COMMIT_SHA}
  • ${REGISTRY_URL}/${REPO_NAME}/${CONTAINER_NAME}:latest
• Esegue push su registry.
• Scrive su file ./imglist una riga per container:
  • IMAGE_TAG_<container>=<image-tag-con-sha>

Supporto multi-arch:

• Se presente containers/<container>/platform.conf con chiave platform=..., usa docker buildx build --platform ... --push.
• In assenza di platform.conf usa docker build + docker push classico.

Input (argomenti):

• $1: REPO_NAME (passato dalla pipeline con ${{ github.event.repository.name }}).
• $2: REGISTRY_URL (passato da ${{ vars.REGISTRY }}).

Prerequisiti runtime:

• Docker daemon disponibile nel runner.
• Permessi push su registry.
• Struttura cartelle coerente tra containers/ e src/.

2) customize.sh

Responsabilità funzionale attesa:

• Carica variabili da:
  • env/<ENV>/values.env
  • properties.env
  • file temporaneo con:
    • TAG=<commit_sha>
    • contenuto di imglist (generato da build_container.sh)
• Cerca tutti i manifest kubernetes/**/*.yaml.
• Esegue sostituzione placeholder nel formato <CHIAVE> con i valori trovati.

Input (argomenti):

• $1: ambiente (dev|qa|prod).
  • In pipeline attuale viene usato dev.

Placeholder parametrizzabili nei manifest:

• Tutte le chiavi presenti in env/<ENV>/values.env.
• Tutte le chiavi presenti in properties.env.
• TAG.
• IMAGE_TAG_<container> (una per ciascun container buildato).

Output:

• Manifest Kubernetes in-place con valori sostituiti.

3) deploy.sh

Responsabilità:

• Cerca manifest CNPG (apiVersion: postgresql.cnpg.io/v1).
• Se trovato:
  • Estrae metadata.name del cluster PostgreSQL.
  • Ricava namespace dal role namespace-deployer nel cluster.
  • Crea/aggiorna ConfigMap service-config con:
    • tipodb=postgres
    • urldb=<pg_name>.<namespace>.svc.cluster.local
• Applica tutti i manifest YAML trovati in kubernetes/ (directory per directory).
• Invoca /root/work/pipeline/addlistener.sh per configurare listener HTTPS sul Gateway.

Prerequisiti runtime:

• kubectl disponibile nel runner.
• ./kubeconfig presente e valido.
• Opzionale yq (se assente, usa fallback con awk per estrazione nome CNPG).

4) addlistener.sh

Responsabilità:

• Legge la chiave endpoint da properties.env.
• Calcola token host-based dal dominio.
• Invoca /root/work/pipeline/add-listener.sh passando:
  • <endpoint>
  • https-<token>
  • <token>-secret

Input (argomenti):

• $1 opzionale: path file properties (default properties.env).

Comportamento:

• Se file non esiste o endpoint non valorizzato: termina senza errore bloccante (exit 0).

5) add-listener.sh

Responsabilità:

• Effettua patch JSON sulla risorsa Gateway Kubernetes:
  • Gateway: main-gateway
  • Namespace: nginx-gateway
• Aggiunge un listener HTTPS con certificato TLS da Secret.
• Verifica idempotenza per name e hostname già presenti.

Input (argomenti):

• $1: hostname
• $2: name
• $3: secret-name

Parametrizzazione complessiva

Variabili Gitea Actions

• vars.REGISTRY: URL registry target.

Secret Gitea Actions

• secrets.HARBOR_USERNAME
• secrets.HARBOR_PASSWORD
• secrets.KUBECONFIG_DEV

File di configurazione repository

• env/dev/values.env (o qa, prod se si cambia argomento di customize.sh)
• properties.env
• containers/<service>/platform.conf (opzionale)

Parametri indiretti derivati

• Nome repository da ${{ github.event.repository.name }}.
• SHA commit da git rev-parse HEAD.
• Tag immagine per servizio in imglist.

Note operative importanti

1. Il file imglist viene creato/appeso da build_container.sh e poi letto da customize.sh; il job deve mantenere lo stesso workspace tra step.
2. I manifest Kubernetes vengono modificati in-place da sed -i.
3. La parte Gateway dipende da:
   • presenza di endpoint in properties.env
   • esistenza della risorsa Gateway/nginx-gateway/main-gateway
   • esistenza del Secret TLS con nome <token>-secret