Pianifica il percorso di upgrade ad Ansible Automation Platform 2.6

Il rilascio di Red Hat Ansible Automation Platform 2.6 segna un traguardo fondamentale. Prima di iniziare l'upgrade, devi conoscere tre aspetti fondamentali per semplificare la transizione.

• Si tratta dell'ultima versione con un programma di installazione basato su RPM. Red Hat Ansible Automation Platform 2.6 con il metodo RPM è disponibile solo per Red Hat Enterprise Linux (RHEL) 9; il programma di installazione RPM verrà ritirato dopo questa versione. Ansible Automation Platform 2.7 supporterà solo un metodo di installazione containerizzato, l'operatore Red Hat OpenShift o i nostri servizi cloud; quindi è il momento di iniziare la transizione.
• Ansible Automation Platform 2.6 è una versione fondamentale. Ogni percorso di upgrade alle versioni future della piattaforma deve passare dalla versione 2.6. Non è possibile evitarlo.
• RHEL 8 non è più supportato. Se utilizzi ancora RHEL 8, devi eseguire la migrazione a RHEL 9 (o RHEL 10) prima di eseguire l'upgrade ad Ansible Automation Platform 2.6.

Pianifica l'upgrade

Nel programmare la transizione ad Ansible Automation Platform 2.6, dovresti tenere conto di due importanti aspetti.

Puoi fare una sola modifica alla volta. Che si tratti del sistema operativo (OS) alla base, del metodo di installazione o della versione del prodotto, il programma di installazione gestisce solo una modifica per esecuzione. Ciò significa che potrebbe essere necessario eseguirlo più volte. Consulta la documentazione ufficiale per scoprire come funziona.

Nella maggior parte dei casi, è necessaria una nuova installazione. A parte alcuni scenari specifici, come l'aggiornamento dalla versione 2.5 alla 2.6 sulla stessa architettura o alcune distribuzioni di operatori Red Hat OpenShift, dovrai distribuire una nuova istanza di Ansible Automation Platform 2.6 e migrare la configurazione su di essa.

Questo solleva una domanda fondamentale: come si può trasferire la configurazione esistente nella nuova istanza? La risposta inizia con la consapevolezza che la configurazione di Ansible Automation Platform risiede in un database PostgreSQL. La strategia di upgrade riguarda il modo in cui trasferisci i dati.

Approcci all'upgrade

Esistono due percorsi per Ansible Automation Platform 2.6: una migrazione incentrata sul database o una migrazione incentrata sulle API. La scelta giusta dipende dall'ambiente, dai requisiti e dai compromessi che intendi accettare.

Un approccio incentrato sul database considera Ansible Automation Platform un sistema stateful in cui i dati sono la sorgente di verità. Un approccio incentrato sulle API considera la piattaforma come Configuration as Code (CaC), la cui sorgente di verità risiede nei file di configurazione. Consulta la tabella seguente per valutare le considerazioni tecniche relative a ciascun approccio.

Migrazioni incentrate sul database

Le migrazioni incentrate sul database rappresentano il percorso documentato e completamente supportato che preserva e trasferisce l'intero database durante il processo di upgrade. La sfida? Molteplici passaggi. Potresti passare da RHEL 8 a RHEL 9, da RPM a una soluzione containerizzata e da Ansible Automation Platform 2.4/2.5 a 2.6: ognuno di questi passaggi è una fase separata che richiede la propria infrastruttura. 

Potrebbero esserci molti ambienti intermedi di cui eseguire il provisioning e la gestione. A seconda del punto di partenza, dell'obiettivo finale delle attività di migrazione e della scalabilità dell'ambiente (e quindi delle dimensioni del database), l'operazione potrebbe richiedere molto tempo.

Un avvertimento importante: se questa complessità ti spinge verso le offerte di servizi cloud gestiti di Ansible Automation Platform, tieni presente che il caricamento di un database nei servizi gestiti richiederà un ticket di supporto. Puoi trovare questo processo documentato qui. Per farlo autonomamente, dovrai adottare l'approccio incentrato sulle API.

Migrazione incentrata sulle API

Red Hat non supporta formalmente questo approccio, sebbene supporti i singoli componenti che consentono questa tecnica di migrazione. Detto questo, può essere molto più veloce, soprattutto per gli ambienti di grandi dimensioni. Poiché si tratta di un unico passaggio alla piattaforma di destinazione, non sono necessarie installazioni intermedie.

Con questo metodo, esporterai la configurazione di Ansible Automation Platform tramite chiamate API per archiviarla localmente, ad esempio in file di configurazione o in un database temporaneo. Potrai quindi modificare questi file in base alle esigenze e ripristinarli su un'altra piattaforma, sempre tramite l'API. Questo metodo offre anche un utile vantaggio collaterale: introduce la Configuration as Code (CaC) nel tuo flusso di lavoro, fornendo una base per gestire la piattaforma utilizzando i metodi CaC in futuro.

Quali sono i compromessi? Perderai la cronologia dei processi (problema mitigato da un aggregatore di log esterno) e dovrai gestire i segreti con attenzione (operazione facilitata da un gestore dei segreti esterno). Potresti anche dover modificare i file di configurazione esportati per formattarli correttamente per l'importazione, in particolare per Private Automation Hub e per gli oggetti Event-Driven Ansible.

Un appunto sui segreti

Le credenziali e i segreti di notifica sono archiviati nel database di configurazione e crittografati tramite la SECRET_KEY del database. Poiché sono crittografati, l'API non ne esporta affatto i valori. Pertanto, per accedere ai segreti della configurazione, è necessario l'accesso root al server del database. Poiché in questo modo i segreti verrebbero esposti in chiaro, dovrai gestirli con estrema cura, ad esempio crittografandoli nuovamente in un Ansible Vault. 

Tuttavia, se utilizzi un gestore dei segreti esterno come HashiCorp Vault, questo non sarà un problema perché tali segreti non risiedono in Ansible Automation Platform. In alternativa, se devi gestire solo pochi segreti, potrebbe essere altrettanto semplice inserirli direttamente nella nuova piattaforma.

Considerazioni per entrambi i metodi

Indipendentemente dal percorso scelto, tieni presente quanto segue. Le integrazioni esterne e i token API richiederanno plausibilmente attenzione. 

Ansible Automation Platform 2.5 ha introdotto Automation Gateway, un front end unificato che connette Automation Controller, Ansible Automation Hub e Event-Driven Ansible Controller in un'unica interfaccia. Questa operazione ha spostato molti endpoint API su nuovi percorsi. Sebbene sia stata mantenuta la retrocompatibilità per questi endpoint di integrazione per la versione 2.6, dovrai aggiornarli per le versioni future. Inoltre, dovrai rigenerare e ridistribuire la maggior parte dei token emessi dalla piattaforma; potrebbe essere necessario eseguire il provisioning di server aggiuntivi e aggiornare i bilanciatori del carico al nuovo servizio gateway.

Database gestiti esternamente

Se utilizzi database gestiti esternamente, devi tenere conto di ulteriori considerazioni.  Innanzitutto, Red Hat Ansible Automation Platform 2.4 utilizza Postgres 13. Il database viene aggiornato a Postgres 15 per la versione 2.5 e a PostgreSQL 15 per la 2.6. In Red Hat Ansible Automation Platform 2.6 è disponibile anche il supporto per i database PostgreSQL 16 e 17 forniti dai clienti. Questa procedura di upgrade del database è un aspetto fondamentale della migrazione e dell'aggiornamento; per questo motivo non puoi riutilizzare il database esistente senza completare questo processo.  Nello specifico, per Red Hat Ansible Automation Platform 2.5 e versioni successive, devi abilitare i componenti International Components for Unicode (ICU) nei database forniti dal cliente: questa opzione è disponibile, ma non abilitata per impostazione predefinita, presso i principali provider come EDB, Amazon Web Services Relational Database Service (AWS RDS) e Azure SQL Database. Questa compatibilità del database è il motivo per cui non è possibile limitarsi ad aggiornare lo schema in un database esistente.

Compatibilità con i playbook

Quando esegui l'upgrade di Red Hat Ansible Automation Platform, si aggiorna anche la versione di ansible-core inclusa nell'ambiente di esecuzione predefinito. La buona notizia è che puoi sempre eseguire ambienti di esecuzione meno recenti sulle versioni più recenti della piattaforma, mantenendo la compatibilità con le versioni precedenti; tuttavia, ti consigliamo vivamente l'upgrade per sfruttare le nuove funzionalità e le correzioni di sicurezza.

Se esegui l'upgrade degli ambienti di esecuzione, passi a una nuova versione di Ansible core, che può apportare alcune modifiche.  Ecco cosa puoi aspettarti.

Passaggio da Red Hat Ansible Automation Platform 2.4 alla versione 2.6 (da ansible-core 2.15 a 2.16)

Si tratta di un upgrade secondario. La differenza più significativa è che ora il sistema tratta come errori alcuni avvisi nelle istruzioni condizionali. Oltre a questo, l'impatto è minimo.

Passaggio ad ansible-core 2.18 (ambiente di esecuzione facoltativo in Red Hat Ansible Automation Platform 2.6) Questo upgrade, disponibile come ambiente di esecuzione supportato facoltativo per Red Hat Ansible Automation Platform 2.6, introduce cambiamenti significativamente maggiori. Nello specifico:

• Le versioni Python 2.7 e 3.6 sui nodi di destinazione non sono più supportate. Questo significa che non puoi più gestire host RHEL 6 con questo ambiente di esecuzione. Per l'automazione con Red Hat Ansible Automation Platform, gli host RHEL 7 necessitano di Python 3.8 (disponibile tramite Red Hat Software Collections).
• Python 3.11 è ora la versione di Python inclusa nell'ambiente di esecuzione. Devi aggiornare le librerie Python personalizzate e di terze parti a versioni compatibili con la 3.11.
• È in corso la pulizia dei moduli obsoleti di Python. PEP 594 rimuoverà le librerie non gestite, non sicure e obsolete dalla libreria standard nel corso delle prossime versioni di Python. Gli avvisi di rimozione iniziano con Python 3.11; la versione 3.12 rimuove alcune librerie, mentre la rimozione di massa avverrà nella versione 3.13.

Per la stragrande maggioranza dei clienti, questo non è un problema immediato, ma ti consigliamo di prestare attenzione agli avvisi di rimozione fin da ora per prepararti.

Per i dettagli completi sulle versioni supportate di ansible-core, consulta la politica di supporto ufficiale di Red Hat.

La transizione ad Ansible Automation Platform 2.6 è molto più di un semplice aggiornamento di versione: è una mossa strategica che prepara il terreno per la prossima generazione dell'automazione. Scegliendo il percorso di migrazione più adatto alla tua infrastruttura attuale, puoi mantenere l'automazione resiliente, incentrata sulla sicurezza e pronta per le sfide future.

Risorse aggiuntive

• Articolo: Automazione degli upgrade di Ansible Automation Platform 2.6 con Python, AsyncIO e operazioni collettive
• Note sulla versione e documentazione di Ansible Automation Platform.
• Novità di Ansible Automation Platform