<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with devops]]></title><description><![CDATA[A list of topics that have been tagged with devops]]></description><link>https://forum.androidiani.net/tags/devops</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 15:58:35 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/devops.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 24 May 2026 18:17:13 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Liquibase: gestione delle modifiche al database e automazione CI&#x2F;CD]]></title><description><![CDATA[La gestione delle modifiche allo schema di un database è uno degli aspetti più delicati e sottovalutati nei progetti software moderni. Script SQL sparsi, modifiche manuali non documentate, disallineamenti tra ambienti di sviluppo, staging e produzione: questi problemi sono comuni in quasi ogni team di sviluppo. Liquibase risolve questi problemi portando il controllo di versione al database, proprio come Git fa con il codice sorgente.Cos’è Liquibase e perché usarloLiquibase è uno strumento open source per il database schema change management. Permette di definire, versionare e distribuire le modifiche allo schema del database tramite file di configurazione (chiamati changelog), supportando oltre 30 database diversi: Oracle, MySQL, PostgreSQL, SQL Server, DB2 e molti altri.Il problema che Liquibase risolve è semplice ma critico: applicare modifiche al database con script SQL tradizionali è un processo manuale, error-prone e difficile da tracciare. Questi script spesso mancano di versioning, rendendo quasi impossibile sapere quale versione dello schema è in produzione rispetto allo sviluppo. Liquibase standardizza questo processo tramite file di configurazione versionati, tracciamento automatico via checksum MD5 e supporto nativo al rollback.Concetti fondamentaliPrima di entrare nell’implementazione, è essenziale comprendere i quattro pilastri architetturali di Liquibase:Changelog: è il file principale che contiene tutte le modifiche al database, organizzate in sequenza. Può essere in formato XML, YAML, JSON o SQL puro. Tipicamente si usa un file master che include sotto-changelog organizzati per release o sprint.ChangeSet: è l’unità atomica di modifica, identificata univocamente da una coppia id + author. Ogni changeset viene eseguito una sola volta e tracciato nella tabella DATABASECHANGELOG. Una regola fondamentale: non modificare mai un changeset già eseguito; crea sempre un nuovo changeset per le correzioni.Preconditions: verifiche condizionali che devono passare prima dell’esecuzione di un changeset. Permettono di rendere sicure le migrazioni anche in scenari complessi (es. verificare che una colonna non esista già prima di aggiungerla).Contexts e Labels: meccanismi di filtraggio per controllare quali changeset vengono eseguiti in quale ambiente (dev, staging, prod). Indispensabili per gestire dati di test o configurazioni ambiente-specifiche.Struttura base di un changelog YAMLEcco un esempio pratico di changelog in formato YAML per la creazione di una tabella transazioni con supporto al rollback:databaseChangeLog:
  - changeSet:
      id: create-payment-table
      author: devops.team
      changes:
        - createTable:
            tableName: payment_transaction
            columns:
              - column:
                  name: id
                  type: varchar(50)
                  constraints:
                    primaryKey: true
                    nullable: false
              - column:
                  name: amount
                  type: decimal(15,2)
                  constraints:
                    nullable: false
              - column:
                  name: currency_code
                  type: char(3)
                  constraints:
                    nullable: false
              - column:
                  name: transaction_date
                  type: timestamp
                  defaultValueComputed: CURRENT_TIMESTAMP
              - column:
                  name: status
                  type: varchar(20)
                  constraints:
                    nullable: false
      rollback:
        - dropTable:
            tableName: payment_transactionIl blocco rollback è fondamentale: definisce esplicitamente come annullare la modifica, rendendo ogni deployment reversibile in modo prevedibile.Configurazione per ambienti multipliUn file liquibase.properties separato per ogni ambiente permette di gestire connessioni e contesti in modo sicuro:# liquibase-dev.properties
changeLogFile=db/changelog.yaml
url=jdbc:postgresql://localhost:5432/devdb
username=dev_user
password=${DB_PASSWORD}
contexts=dev,test
defaultSchemaName=DEV_SCHEMA
logLevel=DEBUGNota importante: le credenziali non devono mai essere committate nel repository. Usa variabili d’ambiente, HashiCorp Vault, AWS Secrets Manager o Kubernetes Secrets per la gestione dei segreti.Precondizioni per deployment sicuriLe precondizioni rendono Liquibase robusto in ambienti dove lo schema potrebbe trovarsi in stati intermedi. Questo esempio in SQL nativo verifica che una colonna non esista prima di aggiungerla:--liquibase formatted sql

--changeset devops.team:add-merchant-id
--preconditions onFail:MARK_RAN onError:HALT
--precondition-sql-check expectedResult:0 SELECT COUNT(*) FROM information_schema.columns WHERE table_name = 'payment_transaction' AND column_name = 'merchant_id'

ALTER TABLE payment_transaction 
ADD COLUMN merchant_id VARCHAR(50);

--rollback ALTER TABLE payment_transaction DROP COLUMN merchant_id;Il comportamento onFail:MARK_RAN istruisce Liquibase a segnare il changeset come già eseguito (senza eseguirlo) se la precondizione fallisce — comportamento ideale quando la colonna esiste già per altri motivi.Integrazione in pipeline CI/CDLa vera potenza di Liquibase emerge quando viene integrato in una pipeline di deployment automatizzato. Ecco un esempio completo con Jenkins:pipeline {
    agent any
    
    stages {
        stage('Validate') {
            steps {
                sh 'liquibase validate'
            }
        }
        
        stage('Deploy Staging') {
            steps {
                sh 'liquibase --contexts=staging update'
            }
        }
        
        stage('Deploy Production') {
            when { 
                branch 'main' 
            }
            steps {
                input 'Deploy to Production?'
                sh 'liquibase --contexts=prod update'
            }
        }
    }
    
    post {
        failure {
            sh 'liquibase rollbackCount 1'
        }
    }
}Il blocco post { failure } garantisce il rollback automatico dell’ultimo changeset in caso di errore — un salvagente fondamentale in produzione.Pattern Kubernetes: Init ContainerPer architetture cloud-native, il pattern degli init container è ideale: Liquibase viene eseguito come container di inizializzazione prima dell’avvio dell’applicazione, garantendo che lo schema sia sempre aggiornato prima che il servizio inizi a ricevere traffico:apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    spec:
      initContainers:
      - name: liquibase-migration
        image: liquibase/liquibase:4.25.0
        command:
        - liquibase
        - --url=jdbc:postgresql://$(DB_HOST):5432/$(DB_NAME)
        - --username=$(DB_USER)
        - --password=$(DB_PASSWORD)
        - update
        env:
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: host
      containers:
      - name: payment-service
        image: payment-service:latest
        ports:
        - containerPort: 8080Best practice per ambienti enterpriseAlcune regole fondamentali per adottare Liquibase in contesti di produzione:Principio del minimo privilegio: l’utente Liquibase deve avere solo i permessi DDL necessari, mai privilegi DBA completi.Revisione obbligatoria: ogni modifica al changelog deve passare per una Pull Request con review da un secondo sviluppatore prima del merge.Test su dati realistici: prima del deployment in produzione, eseguire le migrazioni in un ambiente staging con volumi di dati simili a quelli di produzione per individuare problemi di performance.Mai modificare changeset già eseguiti: il checksum MD5 rileverei la modifica e bloccherebbe il deployment. Crea sempre un nuovo changeset per le correzioni.Crea indici dopo i bulk insert: creare indici prima di caricare grandi quantità di dati aumenta enormemente il tempo di migrazione senza benefici pratici.Monitoraggio con Prometheus e GrafanaPer ambienti enterprise, integrare le metriche Liquibase in un sistema di osservabilità permette di rilevare problemi prima che impattino la produzione. Le metriche chiave da tracciare includono:Durata per changeset: identifica migrazioni lente che potrebbero causare downtimeLock contention: conflitti sulla tabella DATABASECHANGELOGLOCK in ambienti multi-istanzaChecksum failures: modifica non autorizzata a changeset già eseguitiRollback rate: indicatore di qualità del processo di testing prima del deployment# Esempio metriche Prometheus esportate da Liquibase
liquibase_deployment_success_total{environment="prod"} 145
liquibase_changeset_duration_seconds_bucket{id="1",database="prod",le="0.5"} 120
liquibase_rollback_total{environment="prod"} 3
liquibase_deployment_failure_total{environment="prod",reason="validation_error"} 2ConclusioneLiquibase trasforma la gestione del database da processo manuale e rischioso a pratica ingegneristica controllata e auditabile. L’integrazione con i sistemi CI/CD permette di applicare agli schemi database gli stessi standard di qualità già applicati al codice applicativo: versionamento, review, test automatizzati e rollback prevedibile.Per team che adottano DevOps o pratiche di continuous delivery, Liquibase non è un’opzione ma una necessità: è il tassello mancante tra il deployment del codice e quello del database.Fonte: Liquibase: Database Change Management and Automated Deployments — DZone]]></description><link>https://forum.androidiani.net/topic/fb8ba74e-e81d-4b8b-8854-3d5d82b35c5a/liquibase-gestione-delle-modifiche-al-database-e-automazione-ci-cd</link><guid isPermaLink="true">https://forum.androidiani.net/topic/fb8ba74e-e81d-4b8b-8854-3d5d82b35c5a/liquibase-gestione-delle-modifiche-al-database-e-automazione-ci-cd</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Sun, 24 May 2026 18:17:13 GMT</pubDate></item><item><title><![CDATA[Fine del supporto NGINX Ingress su AKS: guida alla migrazione verso Gateway API]]></title><description><![CDATA[Se gestisci workload su Azure Kubernetes Service (AKS), nelle ultime settimane potresti aver ricevuto un’email da Microsoft che annuncia la fine del supporto per NGINX Ingress su AKS entro novembre 2026. Non si tratta di una comunicazione da ignorare: la migrazione è inevitabile e conviene pianificarla per tempo. In questo articolo vediamo cosa sta succedendo, perché è successo e cosa fare concretamente.Il contesto: perché Ingress è diventato obsoletoLa risorsa Ingress di Kubernetes nasce con una specifica intenzionalmente minimale: regole di host e path, niente di più. Ma i load balancer cloud (AWS, Azure, GCP e altri) sono in grado di fare molto di più — timeout configurabili, retry policy, routing per header, circuit breaker — e gli utenti hanno cercato di esprimere queste funzionalità tramite annotation proprietarie sulle risorse Ingress. Il risultato è stato un’esplosione di annotation non standardizzate, specifiche per ogni controller, che rendono ogni configurazione di Ingress portabile solo sulla carta.Gateway API è la risposta della community a questo problema. Sostituisce Ingress con risorse strutturate e tipizzate — HTTPRoute, Gateway, GatewayClass — capaci di esprimere comportamenti di routing avanzati in modo nativo e standardizzato, con una separazione netta tra il ruolo del platform team (che gestisce i Gateway) e il ruolo del team applicativo (che gestisce le HTTPRoute). Gateway API è stabile dalla versione 1.28 di Kubernetes ed è la direzione verso cui si sta muovendo l’intero ecosistema.La fine di ingress-nginx e le conseguenze su AKSIl progetto upstream ingress-nginx — il controller Ingress più diffuso nell’ecosistema Kubernetes — è stato formalmente ritirato a marzo 2026. Il progetto era mantenuto da un esiguo gruppo di volontari, aveva accumulato debito tecnico significativo e presentava vulnerabilità di sicurezza note rimaste senza patch. Con il ritiro, qualsiasi nuova vulnerabilità scoperta rimarrà indefinitamente senza correzione.Microsoft ha fissato la propria data di fine supporto al novembre 2026, concedendo agli utenti AKS un margine aggiuntivo. Fino ad allora, le vulnerabilità critiche continueranno a essere corrette, ma non ci sarà sviluppo di nuove funzionalità.Chi è impattato e con quale urgenzaInstallazione self-managed via HelmSe hai installato ingress-nginx manualmente tramite Helm, sei esposto direttamente al ritiro upstream avvenuto a marzo 2026. Da quel momento, qualsiasi vulnerabilità nel controller resta senza patch: mantenerlo in produzione è un rischio di sicurezza crescente nel tempo.AKS Application Routing add-onSe usi l’add-on gestito di AKS abilitato con --enable-app-routing, hai tempo fino a novembre 2026. Microsoft garantisce patch per le vulnerabilità critiche fino a quella data. È un margine utile, ma non è una soluzione permanente.Altro controller Ingress (Traefik, Istio, HAProxy…)Se non usi NGINX Ingress, questo annuncio non ti impatta direttamente. Vale però la pena iniziare a familiarizzare con Gateway API, che è la direzione dell’intero ecosistema Kubernetes.Gateway API: il nuovo modello di risorseLa migrazione da Ingress a Gateway API cambia il modello di risorse con cui si lavora. Ecco un confronto diretto tra i due approcci.Una configurazione Ingress tipica con annotation NGINX:apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-api
            port:
              number: 80La configurazione equivalente con Gateway API:# Definito dal platform team (una volta sola)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: gateway-system
spec:
  gatewayClassName: azure-application-lb
  listeners:
  - name: http
    port: 80
    protocol: HTTP
---
# Definito dal team applicativo
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: gateway-system
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-api
      port: 80Il vantaggio principale non è solo sintattico: la separazione tra Gateway e HTTPRoute permette al platform team di gestire centralmente le policy di sicurezza, TLS e throttling, mentre i team applicativi possono modificare le route senza toccare l’infrastruttura condivisa.Piano di migrazione consigliatoMicrosoft sta investendo nel supporto nativo di Gateway API nell’add-on Application Routing di AKS, con Azure Application Gateway for Containers (AGC) come backend raccomandato. I passi pratici per avviare la migrazione sono:Inventario: esegui kubectl get ingress -A -o yaml per elencare tutte le risorse Ingress e mappare le annotation nginx in uso nel cluster.Assessment delle annotation: identifica quali annotation hanno un equivalente nativo in Gateway API (la maggior parte) e quali richiedono configurazioni alternative (timeout avanzati, snippet custom).Ambiente di test: crea un cluster AKS di test con Gateway API abilitato e migra prima i workload meno critici per acquisire familiarità con il nuovo modello.Migrazione progressiva: usa la funzionalità di traffic splitting di HTTPRoute per spostare gradualmente il traffico dai vecchi Ingress alle nuove route, validando il comportamento prima di dismettere il vecchio controller.Cleanup: rimuovi le risorse Ingress e disabilita o disinstalla ingress-nginx una volta completata la validazione su tutti gli ambienti.ConclusioneLa fine di NGINX Ingress su AKS era prevedibile da quando il progetto upstream ha iniziato a mostrare segni di abbandono. La buona notizia è che Gateway API è tecnicamente superiore: più espressiva, più portabile, con una governance delle responsabilità più chiara tra platform team e team applicativi. Chi pianifica la migrazione adesso, con il margine di tempo concesso da Microsoft fino a novembre 2026, può affrontarla con calma. Chi aspetta l’ultimo momento si troverà a gestire una migrazione d’emergenza in un contesto di sicurezza degradante.La documentazione ufficiale di Gateway API è disponibile su gateway-api.sigs.k8s.io. La roadmap di AKS per Gateway API è tracciabile nelle release note del servizio Azure.Fonte: The End of NGINX Ingress on AKS: What You Need to Know – Trailhead Technology]]></description><link>https://forum.androidiani.net/topic/2edb772b-cd53-4a9f-97bd-82284bbbd1cf/fine-del-supporto-nginx-ingress-su-aks-guida-alla-migrazione-verso-gateway-api</link><guid isPermaLink="true">https://forum.androidiani.net/topic/2edb772b-cd53-4a9f-97bd-82284bbbd1cf/fine-del-supporto-nginx-ingress-su-aks-guida-alla-migrazione-verso-gateway-api</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Tue, 05 May 2026 08:48:42 GMT</pubDate></item></channel></rss>