Sei interessato?
VMware Aria Automation
Centralizzare risorse esistenti in
Indice
Centralizzare risorse esistenti in VMware Aria Automation
Raccolta delle risorse
Onboarding Plan
Associazione a Cloud Template
Mapping delle risorse
Deployment onboardato
Conclusione
In VMware Aria Automation 8.18, Automation Assembler consente non solo il provisioning di nuove risorse, ma anche la gestione di macchine virtuali già esistenti all’interno degli ambienti target. Questo scenario è comune in contesti enterprise in cui una parte significativa dell’infrastruttura è stata distribuita al di fuori di Automation Assembler, ad esempio tramite strumenti nativi di vCenter o soluzioni di terze parti.
Per colmare questa distanza operativa, VMware Aria Automation 8.18 introduce un modello strutturato di onboarding che permette di importare tali risorse e gestirle come deployment nativi, mantenendo coerenza con il modello dichiarativo basato su cloud template.
L’onboarding non è un semplice inventario delle risorse, ma un processo controllato che consente di associare le macchine esistenti a un cloud template, abilitando le operazioni Day 2 supportate dalla piattaforma.
Raccolta delle risorse tramite Cloud Account
Il prerequisito fondamentale per l’onboarding è la configurazione di un cloud account in Automation Assembler. Quando un cloud account viene creato, VMware Aria Automation avvia automaticamente il processo di data collection, rendendo visibili tutte le macchine associate nella sezione Resources > Virtual Machines.
Questo comportamento si applica anche alle macchine che non sono state originariamente distribuite tramite Automation Assembler. In questo stato iniziale, tuttavia, tali risorse risultano solamente “discoverable” e non gestite come deployment.
La distinzione è rilevante: senza onboarding, Automation Assembler non applica il modello di lifecycle management alle macchine esistenti, limitando le possibilità di gestione operativa.
Onboarding Plan: struttura e finalità
Per trasformare risorse esistenti in deployment gestiti, Automation Assembler utilizza gli onboarding plan. Un onboarding plan definisce come e in quale contesto le macchine scoperte debbano essere importate.
Il piano include informazioni quali il cloud account di origine, il progetto di destinazione e le modalità con cui le risorse devono essere trattate durante il processo. La creazione di un onboarding plan avviene dalla sezione Infrastructure > Onboarding. Una volta creato, il piano funge da contenitore logico per uno o più deployment di onboarding, consentendo di organizzare il processo in modo ripetibile e controllato.
Associazione a Cloud Template esistenti
Uno degli aspetti centrali dell’onboarding in VMware Aria Automation 8.18 è la possibilità di associare le macchine scoperte a un cloud template esistente. Questa associazione consente di allineare le risorse già presenti al modello dichiarativo utilizzato dalla piattaforma.
Durante la creazione di un deployment di onboarding, è possibile selezionare l’opzione With Cloud Template, scegliendo un template già definito in Automation Assembler. In questa fase, il sistema richiede che il numero e il tipo di risorse nel template siano compatibili con le macchine che si intende onboardare.
La documentazione specifica che, durante l’onboarding, non è consentito avere risorse nel template che non vengano mappate a una macchina reale.
Mapping delle risorse: vincoli e comportamento
Il mapping rappresenta la fase in cui le macchine scoperte vengono associate alle singole risorse definite nel cloud template. Questo passaggio è essenziale per garantire che Automation Assembler possa gestire correttamente il deployment risultante.
Un vincolo documentato è che il mapping è supportato solo per onboarding plan basati su account vSphere. Altri tipi di cloud account non supportano questa modalità di associazione.
Durante il mapping, l’operatore assegna manualmente una macchina scoperta a ciascuna risorsa del template. Automation Assembler fornisce una vista del template per facilitare questa operazione, consentendo di verificare la corrispondenza tra risorsa dichiarata e macchina reale.
Una volta completato il mapping e avviato il piano, le macchine vengono onboardate come un singolo deployment, con un cloud template associato.
Deployment onboardato e gestione Day 2
Al termine dell’esecuzione dell’onboarding plan, le risorse risultano visibili nella sezione Resources > Deployments come deployment a tutti gli effetti. Questo passaggio è cruciale perché abilita l’utilizzo delle operazioni Day 2 documentate.
La documentazione indica che, dopo l’onboarding, l’esecuzione dell’azione Update sul deployment consente di applicare le modifiche definite nel cloud template alle risorse esistenti. In questo modo, Automation Assembler estende il proprio modello di gestione anche a infrastrutture preesistenti, mantenendo coerenza con il ciclo di vita standard.
È importante sottolineare che il comportamento delle operazioni Day 2 dipende esclusivamente dalle funzionalità documentate e supportate per il tipo di risorsa e di cloud account associato. L’onboarding non altera retroattivamente il modo in cui le macchine sono state create, ma ne modifica il contesto di gestione all’interno di VMware Aria Automation. La qualità del cloud template utilizzato per il mapping è quindi determinante: un template progettato in modo coerente facilita l’allineamento e riduce la necessità di interventi successivi.
Dal punto di vista architetturale, l’onboarding rappresenta un punto di convergenza tra infrastruttura esistente e modello dichiarativo. In ambienti complessi, questo approccio consente di standardizzare gradualmente la gestione senza richiedere una ricostruzione completa delle risorse.
Conclusione
In VMware Aria Automation 8.18, l’onboarding delle risorse esistenti tramite Automation Assembler è un processo strutturato che va oltre la semplice scoperta delle macchine. Attraverso onboarding plan, mapping ai cloud template e gestione come deployment, la piattaforma consente di estendere il proprio modello di lifecycle management anche a infrastrutture preesistenti. Questo approccio permette agli architetti e ai system engineer di integrare ambienti legacy in un framework operativo coerente, mantenendo controllo, visibilità e allineamento con le pratiche dichiarative supportate dalla piattaforma.
A cura di Gaetano Maurizio Abbaticchio
