VMware Aria Automation

Dallo script al catalogo in

Indice

Dallo script al catalogo in VMware Aria Automation

Creazione di una extensibility

Preparazione dell'azione

Importazione delle estensibilità actions

Richiesta ed esecuzione

Conclusione

I team infrastrutturali sviluppano spesso logiche di automazione mirate per rispondere a esigenze operative ricorrenti. Queste logiche possono essere implementate come script di estensione in Automation Assembler, ma raramente devono essere eseguite direttamente dagli amministratori. Più spesso, l’obiettivo è rendere tali operazioni disponibili a utenti di progetto o team applicativi, mantenendo controllo, tracciabilità e separazione dei ruoli. In VMware Aria Automation 8.18, questo scenario è gestito tramite l’integrazione tra Automation Assembler ed Automation Service Broker, che consente di esporre extensibility actions come elementi di catalogo consumabili, senza concedere accesso diretto ai livelli infrastrutturali della piattaforma.

Creazione di una extensibility action in Automation Assembler

Il punto di partenza del flusso è la creazione di una extensibility action in Automation Assembler. Le extensibility actions sono script leggeri, progettati per essere eseguiti in risposta a eventi o come operazioni autonome.
La documentazione descrive l’action-based extensibility come un meccanismo alternativo ai workflow di Automation Orchestrator, adatto a integrazioni e personalizzazioni più semplici.

Un’azione viene creata dalla sezione Extensibility > Library > Actions, dove l’amministratore definisce nome, descrizione e progetto di appartenenza. La piattaforma consente di creare l’azione tramite script personalizzato oppure partendo da un action template. In entrambi i casi, l’azione viene associata a un runtime supportato e salvata nel contesto del progetto selezionato.

È importante sottolineare che, per impostazione predefinita, le extensibility actions sono legate a un singolo progetto, a meno che non vengano esplicitamente configurate come condivise.

Preparazione dell’azione per l’esposizione a catalogo

Una volta creata, l’extensibility action è disponibile per l’uso interno, ad esempio tramite subscription. Tuttavia, per renderla consumabile da utenti non amministrativi, è necessario esporla tramite Automation Service Broker.

La documentazione specifica che le extensibility actions possono essere importate nel Service Broker come contenuto, diventando a tutti gli effetti elementi di catalogo. Questo passaggio consente di separare nettamente chi sviluppa e governa l’automazione da chi ne richiede l’esecuzione.

Prima dell’importazione, è necessario verificare che l’azione sia associata al progetto corretto e che gli input richiesti siano definiti in modo coerente, poiché questi input saranno presentati agli utenti in fase di richiesta.

Importazione delle extensibility actions nel Service Broker

L’importazione avviene tramite la configurazione di una content source in Automation Service Broker. Una volta aggiunta la sorgente, il Service Broker rileva le extensibility actions disponibili e le rende importabili.Dopo l’importazione, le azioni compaiono nella sezione di gestione dei contenuti, da cui possono essere condivise con uno o più progetti. La documentazione evidenzia che è possibile selezionare singole azioni o importare l’intero set disponibile da una content source, mantenendo flessibilità nella governance.

Questo passaggio rappresenta il punto di transizione tra un artefatto tecnico e un servizio consumabile. Una volta importata, l’azione deve essere condivisa con i progetti e gli utenti che ne faranno uso. Il Service Broker consente di definire con precisione quali progetti possano visualizzare e richiedere l’azione dal catalogo.

La condivisione non modifica il comportamento tecnico dell’azione, ma ne determina esclusivamente la visibilità e l’accesso. In questo modo, l’amministratore mantiene il controllo sull’esecuzione, mentre gli utenti operano all’interno di un perimetro ben definito. Questo modello è particolarmente rilevante in contesti multi-team, dove la stessa piattaforma serve ruoli con responsabilità differenti.

Richiesta ed esecuzione dal catalogo

Dopo la condivisione, l’azione diventa visibile nella sezione Catalog del Service Broker per gli utenti autorizzati. Da qui, l’utente può selezionare l’azione, inserire gli input richiesti e inviare la richiesta. L’esecuzione segue lo stesso modello delle altre richieste di catalogo: la richiesta viene tracciata, lo stato è monitorabile e il risultato è associato a un deployment. La documentazione indica che, in caso di errore, è possibile accedere ai dettagli per avviare le attività di troubleshooting.

Questo comportamento garantisce coerenza operativa tra provisioning, azioni di estensione e altri servizi esposti a catalogo.
Il passaggio dallo script al catalogo consente di standardizzare l’uso delle automazioni senza esporre la complessità sottostante. Le extensibility actions rimangono sotto il controllo degli amministratori di Automation Assembler, mentre il Service Broker funge da interfaccia di consumo.

Dal punto di vista operativo, questo modello riduce il rischio di utilizzi impropri e centralizza l’esecuzione delle operazioni tecniche in un flusso tracciato e governato.

Conclusione

In VMware Aria Automation 8.18, l’integrazione tra Automation Assembler e Automation Service Broker consente di trasformare script tecnici in servizi di catalogo controllati. Attraverso l’importazione e la condivisione delle extensibility actions, le organizzazioni possono esporre operazioni mirate a utenti di progetto, mantenendo separazione dei ruoli, tracciabilità e coerenza con il modello di automazione della piattaforma.

Questo approccio rappresenta un punto chiave per rendere l’automazione realmente fruibile in contesti enterprise complessi, senza rinunciare al controllo operativo.

A cura di Gaetano Maurizio Abbaticchio