Sei interessato?
Day 2 Operations
API as
Indice
Day 2 Operations as API
Introduzione
Concetto e identificazione
Esecuzione, tracciamento e limiti
Modello operativo Enterprise
Conclusione
Introduzione alle Day 2 Operations e stato del deployment
In molti ambienti enterprise, il provisioning iniziale di una macchina virtuale rappresenta solo il primo passo del suo ciclo di vita. Requisiti applicativi, carichi di lavoro variabili o cambiamenti infrastrutturali rendono necessario intervenire sulle risorse anche dopo che il deployment è stato completato. In VMware Aria Automation 8.18, questo scenario è gestito attraverso il modello delle Day 2 operations, che consente di applicare modifiche a deployment già esistenti senza ricreare le risorse.
Una volta che una richiesta dal catalogo è stata eseguita con successo, il deployment risultante è visibile nella sezione Resources > Deployments. In questo stato, le risorse associate al deployment sono considerate “complete” dal punto di vista del provisioning iniziale.
A differenza delle personalizzazioni applicabili durante il provisioning tramite extensibility topics, le modifiche successive richiedono un’azione esplicita sul deployment o sulle singole risorse che lo compongono. La documentazione distingue chiaramente tra la modifica delle proprietà durante il ciclo di provisioning e le operazioni Day 2, che vengono attivate su risorse già create e operative.
Concetto e identificazione delle Day 2 Operations
Le Day 2 operations rappresentano azioni eseguite su un deployment o su una sua risorsa dopo il completamento del provisioning. In VMware Aria Automation 8.x, queste operazioni possono essere attivate tramite API, utilizzando richieste esplicite verso i servizi di deployment.
Il modello operativo prevede che l’azione venga inviata a una risorsa specifica appartenente a un deployment identificato. L’azione viene quindi eseguita come una richiesta di modifica, tracciata e gestita dal sistema, in modo coerente con il lifecycle del deployment.
Il primo passaggio operativo consiste nell’identificare correttamente il deployment e la risorsa su cui intervenire. Ogni deployment è identificato da un deployment ID, mentre ogni risorsa al suo interno possiede un resource ID.
Il primo passaggio operativo consiste nell’identificare correttamente il deployment e la risorsa su cui intervenire. Ogni deployment è identificato da un deployment ID, mentre ogni risorsa al suo interno possiede un resource ID.
Questi identificativi sono utilizzati come parametri nelle chiamate API e rappresentano il riferimento univoco per l’esecuzione delle Day 2 operations. La documentazione fornisce esempi di utilizzo delle API partendo proprio da questi identificativi, evidenziando che l’operazione viene sempre indirizzata a una risorsa specifica all’interno di un deployment.
Esecuzione, tracciamento e limiti delle modifiche tramite API
Per applicare una modifica post-deployment, VMware Aria Automation 8.18 utilizza una richiesta di tipo POST verso l’endpoint dedicato alle richieste sulle risorse di un deployment. L’azione da eseguire è identificata tramite un actionId, che rappresenta il tipo di operazione Day 2 supportata per quella risorsa.
Un esempio documentato riguarda la modifica di CPU e memoria di una macchina virtuale. In questo caso, la richiesta include come input i nuovi valori di CPU e memoria da applicare. L’operazione non crea una nuova risorsa, ma aggiorna quella esistente secondo i parametri forniti. È importante notare che la documentazione specifica l’uso di un’azione dedicata al resize della macchina, confermando che tali modifiche rientrano esplicitamente tra le operazioni supportate.
Un esempio documentato riguarda la modifica di CPU e memoria di una macchina virtuale. In questo caso, la richiesta include come input i nuovi valori di CPU e memoria da applicare. L’operazione non crea una nuova risorsa, ma aggiorna quella esistente secondo i parametri forniti. È importante notare che la documentazione specifica l’uso di un’azione dedicata al resize della macchina, confermando che tali modifiche rientrano esplicitamente tra le operazioni supportate.
Una volta inviata la richiesta di Day 2 operation, VMware Aria Automation gestisce l’operazione come una richiesta a sé stante. Il sistema consente di monitorarne l’esecuzione, verificando se l’azione è stata completata con successo o se sono stati riscontrati errori. Questo comportamento è coerente con il modello di gestione delle richieste già utilizzato per il provisioning iniziale: ogni operazione viene tracciata e associata allo stato del deployment, mantenendo visibilità e controllo sul ciclo di vita della risorsa.
La documentazione chiarisce che non tutte le proprietà di una risorsa possono essere modificate post-deployment e che le operazioni disponibili dipendono dal tipo di risorsa e dall’azione supportata. Le API consentono di eseguire solo le operazioni esplicitamente documentate, e non sostituiscono i meccanismi di personalizzazione previsti durante il provisioning tramite extensibility topics. Dal punto di vista operativo, questo implica che la progettazione del cloud template e delle extensibility subscription rimane fondamentale per definire il comportamento iniziale delle risorse, mentre le Day 2 operations rappresentano uno strumento complementare per la gestione evolutiva.
Modello operativo enterprise
In ambienti enterprise, il valore delle Day 2 operations risiede nella possibilità di adattare le risorse nel tempo senza interrompere il modello di governance. L’utilizzo delle API consente integrazioni con strumenti esterni o workflow automatizzati, mantenendo VMware Aria Automation come punto di controllo centrale. Questo approccio permette di gestire modifiche incrementali, mantenendo allineamento con il deployment originale e senza introdurre derive non tracciate nel ciclo di vita della risorsa.
Conclusione
In VMware Aria Automation 8.18, le Day 2 operations rappresentano un’estensione naturale del provisioning iniziale. Attraverso l’uso delle API documentate, è possibile intervenire su deployment già completati, applicando modifiche controllate e tracciabili alle risorse esistenti. Questo modello consente di affrontare scenari reali di gestione infrastrutturale, dove il ciclo di vita di una macchina virtuale evolve nel tempo, senza rinunciare alla coerenza e al controllo offerti dalla piattaforma di automazione.
A cura di Gaetano Maurizio Abbaticchio
