In qualità di amministratore, è possibile aggiungere vincoli di governance o proprietà personalizzate a livello di progetto quando i requisiti del progetto sono diversi da quelli dei modelli cloud di Automation Assembler. Oltre ai tag di vincolo, è possibile aggiungere tag di risorse che vengono aggiunti alle risorse distribuite durante il processo di provisioning, in modo da poter gestire le risorse.

Che cosa sono i tag di risorse del progetto

Un tag di risorse del progetto funziona come un tag di identificazione standardizzato che è possibile utilizzare per gestire le risorse di elaborazione distribuite e garantire la conformità.

I tag di risorse definiti in un progetto vengono aggiunti a tutte le risorse macchina distribuite che fanno parte di tale progetto insieme a tutti i tag specifici della macchina. È quindi possibile utilizzare l'assegnazione di tag standard per gestire le risorse utilizzando altre applicazioni, ad esempio, per monitorare i costi utilizzando CloudHealth e, cosa importante, per garantire la conformità. I tag delle risorse del progetto non vengono aggiunti ad altre risorse come la rete o lo storage.

Ad esempio, in qualità di amministratore del cloud, si desidera utilizzare un'applicazione come CloudHealth per gestire i costi. È possibile aggiungere il tag costCenter:eu-cc-1234 a un progetto dedicato allo sviluppo di uno strumento di risorse umane dell'Unione europea. Quando il team del progetto esegue la distribuzione da questo progetto, il tag viene aggiunto alle risorse della macchina distribuite. È quindi possibile configurare lo strumento dei costi per identificare e gestire le risorse che includono questo tag. Altri progetti con altri centri di costo avranno valori alternativi da passare con la chiave.

Che cosa sono i tag di vincolo del progetto

Un vincolo di progetto funziona come definizione di governance. Si tratta di un tag di key:value che definisce le risorse che la richiesta di distribuzione utilizza o evita nelle zone cloud del progetto.

Il processo di distribuzione cerca i tag delle reti e dello storage che corrispondono ai vincoli del progetto ed esegue la distribuzione in base ai tag corrispondenti.

Il vincolo di estendibilità viene utilizzato per specificare l'istanza integrata di VMware Aria Automation Orchestrator da utilizzare per i workflow di estendibilità.

Quando si configurano i vincoli di progetto, tenere in considerazione i seguenti formati.

  • key:value e key:value:hard. Utilizzare questo tag in uno dei formati quando il modello cloud deve essere sottoposto a provisioning sulle risorse con il tag di funzionalità corrispondente. Il processo di distribuzione non riesce quando non viene trovato alcun tag corrispondente. Ad esempio, è necessario effettuare il provisioning di un modello cloud distribuito dai membri di un progetto su una rete conforme a PCI. Si utilizza security:pci. Se non viene trovata nessuna rete nelle zone cloud del progetto, la distribuzione non riesce e garantisce che non avvengano distribuzioni non sicure.
  • key:value:soft. Utilizzare questo tag quando si preferisce una risorsa corrispondente, ma si desidera che il processo di distribuzione proceda senza errori e possa accettare risorse in cui il tag non corrisponde. Ad esempio, si preferisce che i membri del progetto distribuiscano i propri modelli cloud in uno storage meno costoso, ma si desidera che la disponibilità dello storage non interferisca con la loro capacità di distribuzione. Si utilizza tier:silver:soft. Se non è disponibile alcuno storage con tag tier:silver nelle zone cloud del progetto, il modello cloud viene comunque distribuito in altre risorse di storage.
  • !key:value. Utilizzare questo tag, con applicazione permanente o temporanea, quando si desidera evitare la distribuzione alle risorse con un tag corrispondente.
È importante sottolineare che i tag di vincolo del progetto hanno una priorità più alta rispetto ai tag di vincolo del modello cloud e li sovrascrivono al momento della distribuzione. Se si dispone di un modello cloud in cui questa operazione non deve mai verificarsi, è possibile utilizzare failOnConstraintMergeConflict:true nel modello. Ad esempio, se il progetto ha un vincolo di rete loc:london, ma il modello cloud è loc:mumbai; tuttavia, per evitare che la posizione del progetto abbia la precedenza, si desidera che la distribuzione non riesca con un messaggio di conflitto di vincoli, aggiungendo una proprietà simile al seguente esempio. 
constraints:
	- tag: 'loc:mumbai'
failOnConstraintMergeConflict:true

Come utilizzare le proprietà personalizzate del progetto

È possibile utilizzare una proprietà personalizzata del progetto per la creazione di report, per attivare e popolare le azioni di estendibilità e il workflow e per sovrascrivere le proprietà a livello del modello cloud.

L'aggiunta di una proprietà personalizzata a una distribuzione consente di utilizzare il valore nell'interfaccia utente o di recuperarla utilizzando l'API in modo da poter generare report.

L'estendibilità può inoltre utilizzare una proprietà personalizzata per una sottoscrizione di estendibilità. Per ulteriori informazioni sull'estendibilità, vedere Estensione e automazione dei cicli di vita delle applicazioni con l'estendibilità.

Un modello cloud potrebbe avere un particolare valore di proprietà che si desidera modificare per un progetto. È possibile fornire un nome e un valore alternativi come proprietà personalizzata.

È inoltre possibile crittografare il valore della proprietà in modo che né l'utente corrente né gli altri utenti possano vedere il valore incluso nella distribuzione. È possibile ad esempio crittografare una password utilizzata da tutti gli utenti nel progetto, ma che si desidera non sia visibile. Dopo aver crittografato il valore e salvato il progetto, non sarà possibile rimuovere la maschera o sostituire il valore. Se si deseleziona la casella di controllo Crittografato, il valore verrà rimosso. Sarà necessario immettere nuovamente un valore.