Sintassi ed esempi della politica di implementazione dell'aggiornamento - AWS Organizations

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Sintassi ed esempi della politica di implementazione dell'aggiornamento

Una politica di implementazione degli aggiornamenti definisce il modo in cui AWS i servizi applicano gli aggiornamenti automatici a tutte le risorse. La comprensione della sintassi delle politiche consente di creare politiche efficaci che soddisfino i requisiti di aggiornamento dell'organizzazione.

Considerazioni

Quando implementate le politiche di implementazione degli aggiornamenti, tenete conto di questi fattori importanti:

  • I nomi delle politiche devono essere univoci all'interno dell'organizzazione e devono essere chiari e descrittivi. Scegliete nomi che riflettano lo scopo e l'ambito della politica. Per ulteriori informazioni, consulta Ottimizza l'efficienza operativa.

  • I test sono fondamentali prima di un'implementazione su larga scala. Convalida innanzitutto le nuove politiche negli ambienti non di produzione ed espandile gradualmente per garantire il comportamento desiderato. Per ulteriori informazioni, consulta Inizia in piccolo e scala gradualmente.

  • La propagazione delle modifiche alle policy all'interno dell'organizzazione può richiedere diverse ore. Pianificate le vostre implementazioni di conseguenza e assicuratevi che sia in atto un monitoraggio adeguato. Per ulteriori informazioni, consulta Monitora e comunica le modifiche.

  • La formattazione JSON deve essere valida e rientrare nella dimensione massima della policy di 5.120 byte. Mantieni le strutture delle politiche il più semplici possibile, soddisfacendo al contempo i tuoi requisiti.

  • Le revisioni periodiche delle politiche aiutano a mantenere l'efficacia. Pianifica valutazioni periodiche delle tue politiche per assicurarti che continuino a soddisfare le tue esigenze organizzative. Per ulteriori informazioni, consulta Stabilisci processi di revisione.

  • Per le risorse senza un ordine di aggiornamento assegnato viene impostato automaticamente l'ordine «Secondo». Valuta la possibilità di impostare in modo esplicito gli ordini di aggiornamento per le risorse critiche anziché affidarti alle impostazioni predefinite. Per ulteriori informazioni, consulta Convalida le modifiche alle politiche in modo efficace.

  • Gli aggiornamenti manuali hanno la precedenza sugli ordini di aggiornamento definiti dalle politiche. Assicurati che i processi di gestione delle modifiche tengano conto degli scenari di aggiornamento sia automatici che manuali. Per ulteriori informazioni, consulta Stabilisci processi di revisione.

Nota

Quando implementate politiche di implementazione degli upgrade basate su tag dal vostro account di gestione, tenete presente che l'account di gestione non può visualizzare o accedere direttamente ai tag a livello di risorsa negli account dei membri. Ti consigliamo di stabilire un processo in cui gli account dei membri applichino tag di risorsa coerenti e quindi di creare politiche a livello di organizzazione che facciano riferimento a questi tag. Ciò garantisce il corretto coordinamento tra l'etichettatura a livello di risorsa e l'applicazione delle politiche organizzative. Puoi anche utilizzarlo Policy di tag per mantenere i tag coerenti quando le risorse vengono etichettate in tutta l'organizzazione.

Struttura politica di base

Le politiche di implementazione dell'aggiornamento utilizzano una struttura JSON che include i seguenti elementi principali:

  • Metadati delle politiche (come le informazioni sulla versione)

  • Regole di targeting delle risorse

  • Aggiorna le specifiche dell'ordine

  • Messaggi di eccezione opzionali

  • Attributi specifici del servizio

L'esempio seguente mostra una struttura di policy di implementazione degli aggiornamenti di base:

{ "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } }

Componenti della policy

Una politica di implementazione degli aggiornamenti è costituita da due componenti chiave che interagiscono per controllare il modo in cui gli aggiornamenti vengono applicati alle risorse. Questi componenti includono opzioni di configurazione sia per i comportamenti predefiniti che per le sostituzioni basate su tag. Comprendere come interagiscono questi componenti consente di creare politiche efficaci che soddisfino le esigenze organizzative.

Configurazione predefinita dell'ordine delle patch

Quando si crea una politica di implementazione degli aggiornamenti senza specificare alcuna modifica specifica per ogni risorsa, per impostazione predefinita tutte le risorse seguono un ordine di aggiornamento di base. È possibile impostare questa impostazione predefinita utilizzando il campo «predefinito» nella politica. Le risorse senza l'assegnazione esplicita dell'ordine di aggiornamento tramite tag seguiranno questo ordine predefinito.

Nota

L'esperienza odierna della console richiede la specificazione di un ordine predefinito.

L'esempio seguente mostra come impostare tutte le risorse in modo che ricevano gli aggiornamenti per ultimi per impostazione predefinita, a meno che non vengano sovrascritte dai tag. Questo approccio è utile quando si desidera garantire che la maggior parte delle risorse venga aggiornata più avanti nel ciclo di aggiornamento:

"upgrade_rollout": { "default": { "patch_order": "last" } }

Sovrascrittura del livello di risorsa tramite tag

È possibile sovrascrivere l'ordine di aggiornamento predefinito per risorse specifiche utilizzando i tag. Ciò consente di creare un controllo granulare su quali risorse ricevono gli aggiornamenti in quale ordine. Ad esempio, è possibile assegnare diversi ordini di aggiornamento in base ai tipi di ambiente, alle fasi di sviluppo o alla criticità del carico di lavoro.

L'esempio seguente mostra come configurare le risorse di sviluppo in modo che ricevano gli aggiornamenti per prime e le risorse di produzione per riceverli per ultime. Questa configurazione garantisce che gli ambienti di sviluppo possano convalidare gli aggiornamenti prima che raggiungano la produzione:

"upgrade_rollout": { "tags": { "environment": { "tag_values": { "development": { "patch_order": "first" }, "production": { "patch_order": "last" } } } } }

Esempi di politiche di implementazione degli aggiornamenti

Di seguito sono riportati gli scenari più comuni relativi alle politiche di implementazione degli aggiornamenti:

Esempio 1: innanzitutto l'ambiente di sviluppo

Questo esempio mostra come configurare le risorse nell'ambiente di sviluppo in modo che ricevano prima gli aggiornamenti. Indirizzando le risorse con il tag «development» environment, ti assicuri che i tuoi ambienti di sviluppo siano i primi a ricevere e convalidare nuovi aggiornamenti. Questo modello aiuta a identificare potenziali problemi prima che gli aggiornamenti raggiungano ambienti più critici:

{ "tags": { "environment": { "tag_values": { "development": { "upgrade_order": "first" } } } } }

Esempio 2: ultimo ambiente di produzione

Questo esempio dimostra come garantire che gli ambienti di produzione ricevano gli aggiornamenti per ultimi. Impostando in modo esplicito le risorse con tag di produzione sull'ultimo ordine di aggiornamento, è possibile mantenere la stabilità dell'ambiente di produzione e consentire al contempo test adeguati negli ambienti di preproduzione. Questo approccio è particolarmente utile per le organizzazioni con requisiti rigorosi di gestione delle modifiche:

{ "tags": { "environment": { "tag_values": { "production": { "upgrade_order": "last" } } } } }

Esempio 3: ordini di upgrade multipli che utilizzano tag

L'esempio seguente mostra come utilizzare una singola chiave di tag con valori diversi per specificare tutti e tre gli ordini di aggiornamento. Questo approccio è utile quando si desidera gestire gli ordini di upgrade tramite un unico schema di tagging:

{ "upgrade_rollout":{ "default":{ "patch_order":{ "@@assign":"last" } }, "tags":{ "devtag":{ "tag_values":{ "tag1":{ "patch_order":{ "@@assign":"first" } }, "tag2":{ "patch_order":{ "@@assign":"second" } }, "tag3":{ "patch_order":{ "@@assign":"last" } } } } } } }