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 alle tue risorse. La comprensione della sintassi delle policy consente di creare policy efficaci che soddisfino i requisiti di aggiornamento dell'organizzazione.
Argomenti
Considerazioni
Quando implementate le politiche di implementazione degli aggiornamenti, considerate questi fattori importanti:
-
I nomi delle policy devono essere univoci all'interno dell'organizzazione e devono essere chiari e descrittivi. Scegli 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'ampia diffusione. Convalida innanzitutto le nuove politiche in ambienti non di produzione ed espanderle gradualmente per garantire il comportamento desiderato. Per ulteriori informazioni, consulta Inizia in piccolo e scala gradualmente.
-
Le modifiche alle policy possono richiedere diverse ore per propagarsi all'interno dell'organizzazione. Pianifica le tue implementazioni di conseguenza e assicurati che sia attivo un monitoraggio adeguato. Per ulteriori informazioni, consulta Monitora e comunica le modifiche.
-
La formattazione JSON deve essere valida e rimanere entro la dimensione massima delle policy di 5.120 byte. Mantieni le strutture delle policy 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 a cui non è assegnato un ordine di upgrade assegnato viene impostato di default il «Secondo» ordine. Valuta la possibilità di impostare in modo esplicito gli ordini di aggiornamento per le risorse critiche anziché affidarti ai valori predefiniti. Per ulteriori informazioni, consulta Convalida le modifiche alle politiche in modo efficace.
-
Gli aggiornamenti manuali hanno la precedenza sugli ordini di aggiornamento definiti da policy. Assicurati che i tuoi processi di gestione delle modifiche tengano conto degli scenari di aggiornamento automatici e manuali. Per ulteriori informazioni, consulta Stabilisci processi di revisione.
Nota
Quando implementi politiche di implementazione degli aggiornamenti basate su tag dal tuo account di gestione, tieni presente che l'account di gestione non può visualizzare o accedere direttamente ai tag a livello di risorsa negli account membri. Consigliamo di stabilire un processo in cui gli account dei membri applichino tag di risorse coerenti e quindi di creare politiche a livello di organizzazione che facciano riferimento a tali 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 aiutare a mantenere i tag coerenti quando le risorse vengono etichettate in tutta l'organizzazione.
Struttura delle politiche di base
Le politiche di implementazione degli aggiornamenti utilizzano una struttura JSON che include i seguenti elementi principali:
-
Metadati delle policy (ad esempio informazioni sulla versione)
-
Regole di targeting delle risorse
-
Specifiche degli ordini di aggiornamento
-
Messaggi di eccezione opzionali
-
Service-specific attributi
L'esempio seguente mostra una struttura di base delle politiche di implementazione degli aggiornamenti:
{ "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 ti aiuta a creare policy efficaci che soddisfino le tue esigenze organizzative.
Configurazione predefinita dell'ordine delle patch
Quando si crea una politica di implementazione degli aggiornamenti senza specificare sostituzioni specifiche per le risorse, per impostazione predefinita tutte le risorse utilizzano un ordine di aggiornamento di base. Puoi impostare questa impostazione predefinita utilizzando il campo «predefinito» nella tua policy. Le risorse senza un'assegnazione esplicita degli ordini di upgrade tramite tag seguiranno questo ordine predefinito.
Nota
L'esperienza della console odierna richiede la specificazione di un ordine predefinito.
L'esempio seguente mostra come impostare per impostazione predefinita tutte le risorse in modo che ricevano gli aggiornamenti per ultime, a meno che non vengano sovrascritti 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" } }
Sostituzione 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 e 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 per prime gli aggiornamenti 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
Ecco alcuni scenari comuni delle politiche di implementazione degli aggiornamenti:
Esempio 1: innanzitutto l'ambiente di sviluppo
Questo esempio mostra come configurare le risorse nell'ambiente di sviluppo per ricevere prima gli aggiornamenti. Scegliendo come target le risorse con il tag «development» environment, ti assicuri che i tuoi ambienti di sviluppo siano i primi a ricevere e convalidare i nuovi aggiornamenti. Questo modello aiuta a identificare potenziali problemi prima che gli aggiornamenti raggiungano ambienti più critici:
{ "tags": { "environment": { "tag_values": { "development": { "patch_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, si mantiene la stabilità nell'ambiente di produzione consentendo al contempo test adeguati negli ambienti di pre-produzione. Questo approccio è particolarmente utile per le organizzazioni con severi requisiti di gestione delle modifiche:
{ "tags": { "environment": { "tag_values": { "production": { "patch_order": "last" } } } } }
Esempio 3: ordini di upgrade multipli che utilizzano tag
L'esempio seguente dimostra come utilizzare una singola chiave di tag con valori diversi per specificare tutti e tre gli ordini di upgrade. Questo approccio è utile quando si desidera gestire gli ordini di upgrade tramite un unico schema di etichettatura:
{ "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" } } } } } } }
