varie

2026-09-20 19:26:05 +02:00
parent 48f3f1ff22
commit 63649a642a
11 changed files with 578 additions and 45 deletions
@@ -0,0 +1,21 @@
+# Dockerfile di esempio — containerizza un flow esportato da Langflow
+# come Python app standalone, da usare nel percorso BYO (Esempio B).
+
+FROM python:3.11-slim
+
+WORKDIR /app
+
+# requirements.txt generato/estratto insieme all'export del flow
+# (langflow, langgraph-checkpointer-kagent, e le dipendenze del tuo flow)
+COPY requirements.txt .
+RUN pip install --no-cache-dir -r requirements.txt
+
+# Codice esportato dal builder low-code + eventuali customizzazioni
+# del developer (es. integrazione kagentCheckpointer se usi LangGraph)
+COPY . .
+
+# L'agente deve esporre un endpoint compatibile A2A sulla porta
+# dichiarata in byo.deployment.port dell'Agent CR
+EXPOSE 8080
+
+CMD ["python", "agent_server.py"]
@@ -0,0 +1,7 @@
+# crea secret con langflow-secrets-setup.sh
+
+
+# Poi installa con i valori personalizzati
+helm install langflow-ide langflow/langflow-ide \
+  -f langflow-values.yaml \
+  -n langflow-team-alpha --create-namespace
@@ -0,0 +1,61 @@
+# HTTPRoute (Gateway API) per Langflow IDE
+# Presuppone un Gateway nginx già esistente nel cluster (nginx Gateway
+# Fabric), referenziato come parentRef qui sotto.
+
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: langflow-team-alpha
+  namespace: langflow-team-alpha
+spec:
+  parentRefs:
+    - name: nginx-gateway          # nome del Gateway condiviso — verifica con:
+      namespace: nginx-gateway     # kubectl get gateway -A
+      sectionName: https           # nome del listener HTTPS sul Gateway
+
+  hostnames:
+    - "langflow-team-alpha.pigreco66.it"
+
+  rules:
+    # UI/editor visuale (frontend) — porta 8080 come da doc Langflow
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /
+      backendRefs:
+        - name: langflow-ide-frontend   # verifica nome esatto: kubectl get svc -n langflow-team-alpha
+          port: 8080
+
+    # API backend, se vuoi esporla separatamente (es. per invocazione
+    # programmatica di un flow senza passare dall'editor) — porta 7860
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /api
+      backendRefs:
+        - name: langflow-ide-backend    # verifica nome esatto: kubectl get svc -n langflow-team-alpha
+          port: 7860
+---
+# TLS: con Gateway API il certificato si referenzia sul Gateway stesso
+# (non sull'HTTPRoute). Se il Gateway condiviso non ha già un listener
+# per questo hostname, serve aggiungerlo lì, es.:
+#
+# apiVersion: gateway.networking.k8s.io/v1
+# kind: Gateway
+# metadata:
+#   name: nginx-gateway
+#   namespace: nginx-gateway
+# spec:
+#   gatewayClassName: nginx
+#   listeners:
+#     - name: https
+#       protocol: HTTPS
+#       port: 443
+#       hostname: "*.pigreco66.it"
+#       tls:
+#         mode: Terminate
+#         certificateRefs:
+#           - name: wildcard-pigreco66-it-tls
+#       allowedRoutes:
+#         namespaces:
+#           from: All
@@ -0,0 +1,35 @@
+# Creazione dei Secret richiesti da langflow-values.yaml
+# Namespace di esempio: langflow-team-alpha (adatta al tuo tenant)
+
+# 1. Secret connessione database Postgres
+kubectl create secret generic langflow-db-secret \
+  -n langflow-team-alpha \
+  --from-literal=connection-string="postgresql://user:pass@host:5432/langflow"
+
+# 2. Secret credenziali admin (superuser Langflow)
+kubectl create secret generic langflow-admin-secret \
+  -n langflow-team-alpha \
+  --from-literal=username="admin" \
+  --from-literal=password="<password-sicura>"
+
+# 3. Secret credenziali LLM — STESSO Secret già usato per kagent nel
+#    golden path di onboarding-team: se lo hai già creato per kagent
+#    in questo namespace, questo passaggio è già fatto, verifica solo
+#    che contenga le chiavi coi nomi attesi (vedi sotto).
+#
+#    Se non esiste ancora, crealo così (aggiungi/rimuovi provider a
+#    seconda di cosa serve al team):
+kubectl create secret generic llm-credentials \
+  -n langflow-team-alpha \
+  --from-literal=openai-api-key="sk-..." \
+  --from-literal=anthropic-api-key="sk-ant-..."
+
+# Se il Secret esiste già (es. creato per kagent) e vuoi solo
+# aggiungere/aggiornare una chiave senza ricrearlo da zero:
+kubectl patch secret llm-credentials -n langflow-team-alpha \
+  --type=json \
+  -p='[{"op":"add","path":"/data/openai-api-key","value":"'$(echo -n "sk-..." | base64)'"}]'
+
+# 4. Verifica che tutti i Secret siano presenti prima di installare/
+#    aggiornare la release Helm
+kubectl get secrets -n langflow-team-alpha
@@ -0,0 +1,87 @@
+# values.yaml — Langflow IDE, personalizzato per un namespace-tenant
+# Uso: helm install langflow-ide langflow/langflow-ide -f values.yaml -n <namespace>
+
+langflow:
+  backend:
+    image:
+      repository: langflowai/langflow
+      tag: "1.10.0"          # fissa una versione esplicita, evita 'latest' in produzione
+
+    resources:
+      requests:
+        cpu: 250m
+        memory: 512Mi
+      limits:
+        cpu: "1"
+        memory: 2Gi
+
+    # Variabili LLM/DB — usa Secret, mai valori in chiaro qui
+    env:
+      - name: LANGFLOW_DATABASE_URL
+        valueFrom:
+          secretKeyRef:
+            name: langflow-db-secret
+            key: connection-string
+      - name: LANGFLOW_SUPERUSER
+        valueFrom:
+          secretKeyRef:
+            name: langflow-admin-secret
+            key: username
+      - name: LANGFLOW_SUPERUSER_PASSWORD
+        valueFrom:
+          secretKeyRef:
+            name: langflow-admin-secret
+            key: password
+      # Rimuove automaticamente eventuali API key salvate nei flow prima
+      # di persisterli a DB — best practice di sicurezza, seconda linea
+      # di difesa oltre alle Global Variable qui sotto
+      - name: LANGFLOW_REMOVE_API_KEYS
+        value: "true"
+
+      # --- Pre-caricamento credenziali LLM come Global Variable ---
+      # Riusa lo stesso Secret 'llm-credentials' già previsto per kagent
+      # in fase di onboarding del team (vedi golden path Backstage).
+      # I developer trovano le chiavi già pronte nel dropdown Global
+      # Variable, senza mai vederne il valore reale.
+      - name: LANGFLOW_STORE_ENVIRONMENT_VARIABLES
+        value: "true"
+      - name: LANGFLOW_VARIABLES_TO_GET_FROM_ENVIRONMENT
+        value: "OPENAI_API_KEY,ANTHROPIC_API_KEY"
+      - name: OPENAI_API_KEY
+        valueFrom:
+          secretKeyRef:
+            name: llm-credentials
+            key: openai-api-key
+            optional: true      # non tutti i team useranno tutti i provider
+      - name: ANTHROPIC_API_KEY
+        valueFrom:
+          secretKeyRef:
+            name: llm-credentials
+            key: anthropic-api-key
+            optional: true
+
+  frontend:
+    image:
+      repository: langflowai/langflow
+      tag: "1.10.0"
+    resources:
+      requests:
+        cpu: 100m
+        memory: 256Mi
+      limits:
+        cpu: 500m
+        memory: 512Mi
+
+# Ingress classico DISABILITATO — l'esposizione avviene via Gateway API
+# (nginx Gateway Fabric), vedi manifest separato langflow-httproute.yaml
+ingress:
+  enabled: false
+
+# Il Service del frontend resta ClusterIP (default del chart), sarà
+# l'HTTPRoute a instradare il traffico dal Gateway verso questo Service
+
+# Persistenza dei flow salvati (altrimenti persi al riavvio del pod)
+persistence:
+  enabled: true
+  size: 5Gi
+  storageClassName: standard   # adatta alla tua StorageClass
@@ -0,0 +1,166 @@
+# =====================================================================
+# ESEMPIO A — Agent dichiarativo nativo (kagent esegue direttamente)
+# Caso d'uso: flow Langflow/Flowise semplice — un LLM + un paio di tool,
+# nessuna logica custom complessa. Tradotto 1:1 in prompt + tool MCP.
+# =====================================================================
+apiVersion: kagent.dev/v1alpha2
+kind: Agent
+metadata:
+  name: k8s-troubleshooter
+  namespace: team-alpha
+spec:
+  description: Agente di troubleshooting Kubernetes
+  type: Declarative
+  declarative:
+    modelConfig: gpt4o-config
+    systemMessage: |
+      Sei un agente di troubleshooting per Kubernetes...
+    a2aConfig:
+      skills:
+        - id: diagnose-pod-issue
+          name: Diagnose Pod Issue
+          description: Investiga problemi su pod/servizi Kubernetes
+          inputModes: ["text"]
+          outputModes: ["text"]
+          tags: ["kubernetes"]
+    tools:
+      - type: McpServer
+        mcpServer:
+          name: kagent-tool-server
+          kind: RemoteMCPServer
+          toolNames:
+            - k8s_get_pods
+            - k8s_describe_pod
+            - k8s_get_logs
+---
+apiVersion: kagent.dev/v1alpha1
+kind: ModelConfig
+metadata:
+  name: gpt4o-config
+  namespace: team-alpha
+spec:
+  provider: OpenAI
+  model: gpt-4o
+  apiKeySecretRef:
+    name: llm-credentials
+    key: openai-api-key
+
+
+
+
+# invocazione
+Le 4 modalità di invocazione
+1. Dashboard kagent (per gli utenti umani, uso interattivo)
+bash
+kagent dashboard
+
+Apre una UI web dove cerchi k8s-troubleshooter nella lista e chatti direttamente — il modo più immediato per un developer che vuole testare l'agente senza altri strumenti.
+
+2. CLI kagent (per script, pipeline, debug da terminale)
+bash
+kagent invoke --agent k8s-troubleshooter -n team-alpha \
+  --task "Il pod payment-service-7d9f in default sta crashando, investiga"
+3. Chiamata diretta via A2A REST (per integrazione da altri sistemi/servizi)
+
+Ogni Agent espone un endpoint A2A standard, con un "agent card" che ne descrive le capability:
+
+bash
+kubectl port-forward -n kagent svc/kagent-service 8083:8083
+
+# scopri le capability dell'agente
+curl localhost:8083/api/a2a/team-alpha/k8s-troubleshooter/.well-known/agent.json
+
+# invocalo
+curl -X POST localhost:8083/api/a2a/team-alpha/k8s-troubleshooter/ \
+  -H "Content-Type: application/json" \
+  -d '{"task": "Perché il pod payment-service sta in CrashLoopBackOff?"}'
+
+Questa è la via che useresti se, ad esempio, un tuo servizio interno (o un'automazione CI/CD) deve invocare l'agente programmaticamente.
+
+4. Canali chat (Slack/Teams/Discord/Telegram) — via AgentHarness CRD
+
+Se vuoi che i developer interroghino l'agente direttamente da Slack invece che aprire la dashboard, kagent ha una CRD dedicata (AgentHarness) che fa da ponte:
+
+yaml
+apiVersion: kagent.dev/v1alpha2
+kind: AgentHarness
+metadata:
+  name: k8s-troubleshooter-slack
+  namespace: kagent
+spec:
+  backend: hermes
+  modelConfigRef: default-model-config
+  channels:
+    - name: platform
+      type: slack
+      slack:
+        botToken:
+          valueFrom: {type: Secret, name: slack-tokens, key: bot-token}
+        appToken:
+          valueFrom: {type: Secret, name: slack-tokens, key: app-token}
+
+Poi in Slack: /mykagent perché il pod X sta crashando? — il bot inoltra la richiesta all'agente via A2A e posta la risposta nel canale. Interessante per un'IDP perché è il canale più naturale per i developer, senza dover imparare dashboard o CLI dedicate.
+
+# =====================================================================
+# ESEMPIO B — Agent BYO (Bring Your Own), container esportato da
+# Langflow/Flowise dopo containerizzazione custom.
+# Caso d'uso: flow complesso con logica di stato/loop che il developer
+# ha personalizzato oltre quello che il builder low-code esporta,
+# quindi ha bisogno di pieno controllo del codice.
+# =====================================================================
+apiVersion: kagent.dev/v1alpha1
+kind: Agent
+metadata:
+  name: currency-exchange-agent
+  namespace: team-alpha
+spec:
+  type: BYO
+  byo:
+    deployment:
+      image: ghcr.io/team-alpha/langflow-currency-agent:latest
+      workingDir: /app
+      env:
+        - name: GOOGLE_API_KEY
+          valueFrom:
+            secretKeyRef:
+              name: llm-credentials
+              key: gemini-api-key
+      port: 8080          # porta su cui l'agente espone l'endpoint A2A
+
+  # Nota: kagent invoca questo agente via protocollo A2A, trattandolo
+  # come black box — nessuna decomposizione in prompt/tool separati,
+  # perché la logica vive interamente dentro l'immagine.
+
+
+## Esempio Agent di Orchestrazione
+apiVersion: kagent.dev/v1alpha2
+kind: Agent
+metadata:
+  name: incident-commander
+  namespace: team-alpha
+spec:
+  type: Declarative
+  declarative:
+    systemMessage: |
+      Sei il coordinatore per la gestione incidenti. Quando ricevi una
+      segnalazione, decidi quali specialisti coinvolgere: se riguarda
+      pod/servizi K8s, delega al k8s-troubleshooter; se servono i log,
+      delega al log-analyzer. Puoi chiamare entrambi in sequenza se
+      il problema lo richiede.
+    modelConfig: gpt4o-config
+    tools:
+      - type: McpServer
+        mcpServer:
+          name: kagent-tool-server
+          toolNames: ["k8s_get_events"]
+
+      # Sotto-agenti esposti come "tool" — la scelta di chiamarli
+      # è dell'LLM di incident-commander, non di kagent
+      - type: Agent
+        agent:
+          name: k8s-troubleshooter
+          namespace: team-alpha
+      - type: Agent
+        agent:
+          name: log-analyzer
+          namespace: team-alpha
@@ -619,6 +619,11 @@ spec:
 EOF
 ```

+
+
+
+
+
 COMANDO - applica alert
 ```bash
 kubectl apply -f blackbox-http-alerts.yaml
@@ -631,8 +636,119 @@ kubectl describe prometheusrule blackbox-http-alerts -n monitoring
 ```


-10. TEST MANUALE BLACKBOX EXPORTER
-=================================
+10. CONFIGURA ALERTMANAGER - INVIO EMAIL SU FAIL DI UN SERVIZIO
+================================================================
+
+Obiettivo:
+- inviare una email a un indirizzo specifico quando la probe di un
+  servizio specifico (serviceX) fallisce (alert BlackboxHttpProbeFailed).
+
+FILE - blackbox-email-alert.yaml
+
+Descrizione:
+- crea un receiver email dedicato al servizio da monitorare;
+- instrada verso quel receiver solo gli alert che riguardano il
+  target specifico, identificato tramite il label instance.
+
+NOTA - credenziali SMTP
+Se il server SMTP richiede autenticazione, crea prima un Secret con
+la password:
+
+COMANDO - crea secret con password SMTP
+```bash
+kubectl create secret generic alertmanager-smtp \
+  -n monitoring --from-literal=password='<SMTP_PASSWORD>'
+```
+
+COMANDO - crea blackbox-email-alert.yaml
+```bash
+cat > blackbox-email-alert.yaml <<'EOF'
+apiVersion: monitoring.coreos.com/v1alpha1
+kind: AlertmanagerConfig
+metadata:
+  name: blackbox-email-routing
+  namespace: monitoring
+  labels:
+    release: kube-prometheus-stack
+spec:
+  route:
+    groupBy: ["alertname", "instance"]
+    groupWait: 30s
+    groupInterval: 5m
+    repeatInterval: 1h
+    receiver: "email-default"
+    routes:
+      - matchers:
+          - name: alertname
+            value: BlackboxHttpProbeFailed
+            matchType: "="
+          - name: instance
+            value: "<SERVIZIO_X_URL_O_HOST>"
+            matchType: "="
+        receiver: "email-servizioX"
+
+  receivers:
+    - name: "email-default"
+      emailConfigs: []
+
+    - name: "email-servizioX"
+      emailConfigs:
+        - to: "<INDIRIZZO_X>"
+          from: "<SMTP_FROM>"
+          smarthost: "<SMTP_HOST>:<SMTP_PORT>"
+          authUsername: "<SMTP_USER>"
+          authPassword:
+            name: alertmanager-smtp
+            key: password
+          requireTLS: true
+          sendResolved: true
+          headers:
+            subject: "[ALERT] Servizio X non raggiungibile"
+          html: |
+            <p>Il servizio <b>{{ "{{" }} .CommonLabels.instance {{ "}}" }}</b> non risponde.</p>
+            <p>{{ "{{" }} .CommonAnnotations.description {{ "}}" }}</p>
+EOF
+```
+
+Da personalizzare:
+- <SERVIZIO_X_URL_O_HOST>: valore del label instance della probe da
+  monitorare (es. http://my-service.my-namespace.svc.cluster.local:8080/health);
+- <INDIRIZZO_X>: indirizzo email destinatario;
+- <SMTP_HOST>, <SMTP_PORT>: server SMTP (es. smtp.gmail.com:587);
+- <SMTP_FROM>: mittente email;
+- <SMTP_USER>: utente SMTP, se richiesta autenticazione.
+
+COMANDO - applica la configurazione
+```bash
+kubectl apply -f blackbox-email-alert.yaml
+```
+
+COMANDO - verifica AlertmanagerConfig
+```bash
+kubectl get alertmanagerconfig -n monitoring
+kubectl describe alertmanagerconfig blackbox-email-routing -n monitoring
+```
+
+NOTA - matcher su instance vs job
+Se vuoi far scattare l'email per TUTTI i target di una Probe (job)
+invece che per un singolo servizio, sostituisci il matcher su
+`instance` con:
+```yaml
+- name: job
+  value: "http-services-probe"
+  matchType: "="
+```
+
+COMANDO - verifica alert in Alertmanager
+```bash
+kubectl port-forward -n monitoring svc/kube-prometheus-stack-alertmanager 9093
+# -> http://localhost:9093, controlla che l'alert BlackboxHttpProbeFailed
+#    per il servizio X sia instradato sul receiver email-servizioX
+```
+
+
+11. TEST MANUALE BLACKBOX EXPORTER
+==================================

 COMANDO - port-forward blackbox-exporter
 ```bash
@@ -651,7 +767,7 @@ probe_http_status_code 200
 ```


-11. TROUBLESHOOTING
+12. TROUBLESHOOTING
 ===================

 CASO - Prometheus non vede la Probe
@@ -700,7 +816,7 @@ Azioni consigliate:
 - aggiungere un modulo dedicato in blackbox-values.yaml se serve una configurazione HTTP specifica.


-12. ORDINE DI ESECUZIONE CONSIGLIATO
+13. ORDINE DI ESECUZIONE CONSIGLIATO
 ====================================

 COMANDO - sequenza completa
@@ -727,7 +843,7 @@ blackbox-http-alerts.yaml
 ```


-13. NOTE PER DEV, QA E PROD
+14. NOTE PER DEV, QA E PROD
 ===========================

 Per separare gli ambienti e semplificare dashboard e alert, usa Probe distinte:
@@ -0,0 +1,75 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Aggiunge un hostname a spec.template.spec.hostAliases del Deployment blackbox.
+#
+# Uso:
+#   ./add-hostalias.sh <hostname> <deployment_name> <deployment_namespace>
+#
+# Esempio:
+#   ./add-hostalias.sh idcidcp.pigreco66.it cert-manager cert-manager
+#  
+
+DEPLOYMENT_NAME="${2:-}"
+DEPLOYMENT_NS="${3:-}"
+TARGET_IP="10.43.37.118"
+HOSTNAME_VAL="${1:-}"
+
+if [[ -z "$HOSTNAME_VAL" ]]; then
+  echo "Uso: $0 <hostname>" >&2
+  exit 1
+fi
+
+if ! command -v kubectl >/dev/null 2>&1; then
+  echo "Errore: kubectl non trovato nel PATH" >&2
+  exit 1
+fi
+
+if ! command -v jq >/dev/null 2>&1; then
+  echo "Errore: jq non trovato nel PATH" >&2
+  echo "Installa jq e riprova." >&2
+  exit 1
+fi
+
+# Idempotenza: controlla solo il blocco hostAliases associato a TARGET_IP.
+EXISTING_HOSTNAMES="$(kubectl get deployment "$DEPLOYMENT_NAME" -n "$DEPLOYMENT_NS" -o jsonpath="{.spec.template.spec.hostAliases[?(@.ip=='${TARGET_IP}')].hostnames[*]}" 2>/dev/null || true)"
+if echo " $EXISTING_HOSTNAMES " | grep -Fq " $HOSTNAME_VAL "; then
+  echo "Hostname '$HOSTNAME_VAL' gia presente per IP ${TARGET_IP} in ${DEPLOYMENT_NS}/${DEPLOYMENT_NAME}. Nessuna modifica."
+  exit 0
+fi
+
+DEPLOY_JSON="$(kubectl get deployment "$DEPLOYMENT_NAME" -n "$DEPLOYMENT_NS" -o json)"
+
+UPDATED_HOST_ALIASES="$({
+  echo "$DEPLOY_JSON" | jq -c --arg ip "$TARGET_IP" --arg hostname "$HOSTNAME_VAL" '
+    (.spec.template.spec.hostAliases //= [])
+    | if any(.spec.template.spec.hostAliases[]?; .ip == $ip) then
+        .spec.template.spec.hostAliases |= map(
+          if .ip == $ip then
+            if ((.hostnames // []) | index($hostname)) then
+              .
+            else
+              .hostnames = ((.hostnames // []) + [$hostname])
+            end
+          else
+            .
+          end
+        )
+      else
+        .spec.template.spec.hostAliases += [{"ip": $ip, "hostnames": [$hostname]}]
+      end
+    | .spec.template.spec.hostAliases
+  '
+} )"
+
+PATCH_PAYLOAD="$(jq -cn --argjson hostAliases "$UPDATED_HOST_ALIASES" '{spec:{template:{spec:{hostAliases:$hostAliases}}}}')"
+
+kubectl patch deployment "$DEPLOYMENT_NAME" \
+  -n "$DEPLOYMENT_NS" \
+  --type=merge \
+  -p "$PATCH_PAYLOAD" >/dev/null
+
+echo "Hostname aggiunto con successo."
+echo "  Deployment: ${DEPLOYMENT_NS}/${DEPLOYMENT_NAME}"
+echo "  IP       : ${TARGET_IP}"
+echo "  Hostname : ${HOSTNAME_VAL}"
@@ -45,11 +45,13 @@ fi

 # Se l'hostname non e nel dominio *.italiadatacenter.com, aggiungilo anche a cert-manager hostAliases.
 if [[ "$host_no_port" != *.italiadatacenter.com ]]; then
-  HOSTALIAS_SCRIPT="/root/work/pipeline/add-cert-manager-hostalias.sh"
+  HOSTALIAS_SCRIPT="/root/work/pipeline/add-hostalias.sh"
  if [[ -x "$HOSTALIAS_SCRIPT" ]]; then
-    "$HOSTALIAS_SCRIPT" "$host_no_port"
+    "$HOSTALIAS_SCRIPT" "$host_no_port" "cert-manager" "cert-manager"
+    "$HOSTALIAS_SCRIPT" "$host_no_port" "blackbox-exporter" "monitoring"
  elif [[ -f "$HOSTALIAS_SCRIPT" ]]; then
-    bash "$HOSTALIAS_SCRIPT" "$host_no_port"
+    bash "$HOSTALIAS_SCRIPT" "$host_no_port" "cert-manager" "cert-manager"
+    bash "$HOSTALIAS_SCRIPT" "$host_no_port" "blackbox-exporter" "monitoring"
  else
    echo "Errore: script non trovato: $HOSTALIAS_SCRIPT" >&2
    exit 1
@@ -7,44 +7,7 @@ ENVIRONMENT="${1:-dev}"

 YAML_DIR="kubernetes"

-# ---------------------------------------------------------------------------
-# Cerca risorse postgresql.cnpg.io/v1 nei manifest e deploya una ConfigMap
-# ---------------------------------------------------------------------------
-CNPG_FILE=$(grep -rl "postgresql.cnpg.io/v1" "$YAML_DIR" 2>/dev/null | head -1 || true)

-if [ -n "$CNPG_FILE" ]; then
-  echo "Trovata risorsa postgresql.cnpg.io/v1 in: $CNPG_FILE"
-
-  # Estrae metadata.name dal manifest CNPG preferendo yq, altrimenti awk
-  if command -v yq >/dev/null 2>&1; then
-    PG_NAME=$(yq eval 'select(.apiVersion == "postgresql.cnpg.io/v1") | .metadata.name' "$CNPG_FILE")
-  else
-    PG_NAME=$(awk '/postgresql\.cnpg\.io\/v1/{found=1} found && /^metadata:/{meta=1} meta && /^\s+name:/{print $2; exit}' "$CNPG_FILE")
-  fi
-
-  # Ricava il namespace dal Role namespace-deployer presente nel cluster
-  PG_NS=$(kubectl --kubeconfig=./kubeconfig get role namespace-deployer \
-     --no-headers \
-    -o custom-columns='NS:.metadata.namespace' 2>/dev/null | head -1 || true)
-  #PG_NS="${PG_NS:-default}"
-
-  if [ -z "$PG_NAME" ]; then
-    echo "⚠️  Impossibile estrarre metadata.name dal cluster CNPG, skip ConfigMap." >&2
-  else
-    echo "  → cluster: $PG_NAME  namespace: $PG_NS"
-    kubectl --kubeconfig=./kubeconfig apply -f - <<EOF
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: service-config
-  namespace: ${PG_NS}
-data:
-  tipodb: "postgres"
-  urldb: "${PG_NAME}.${PG_NS}.svc.cluster.local"
-EOF
-    echo "ConfigMap db-config deployata in namespace ${PG_NS}."
-  fi
-fi

 # ---------------------------------------------------------------------------
 # Deploy di tutti i manifest Kubernetes