• La AWS Systems Manager CloudWatch dashboard non sarà più disponibile dopo il 30 aprile 2026. I clienti possono continuare a utilizzare la CloudWatch console Amazon per visualizzare, creare e gestire le proprie CloudWatch dashboard Amazon, proprio come fanno oggi. Per ulteriori informazioni, consulta la [documentazione di Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
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à.
# tutorial AWS Systems Manager Patch Manager
I tutorial di questa sezione mostrano come utilizzare Patch Manager uno strumento in AWS Systems Manager diversi scenari di applicazione delle patch.
**Topics**
+ [Tutorial: applicazione di patch a un server in un IPv6 unico ambiente](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutorial: creare una baseline delle patch per l'installazione di Windows Service Pack tramite la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: aggiorna le dipendenze dell'applicazione, applica patch a un nodo gestito ed esegui un controllo dell'integrità specifico dell'applicazione tramite la console](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# Tutorial: applicazione di patch a un server in un IPv6 unico ambiente
Patch Managersupporta l'applicazione di patch ai nodi in ambienti che dispongono solo di. IPv6 Aggiornando la SSM Agent configurazione, le operazioni di patching possono essere configurate in modo da effettuare solo chiamate agli endpoint IPv6 del servizio.
**Per applicare patch a un server in un unico ambiente IPv6**
1. Assicurati che SSM Agent la versione 3.3270.0 o successiva sia installata sul nodo gestito.
1. Sul nodo gestito, accedi al file di configurazione. SSM Agent Puoi trovare il `amazon-ssm-agent.json` file nelle seguenti directory:
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
Se `amazon-ssm-agent.json` non esiste ancora, copia il contenuto della `amazon-ssm-agent.json.template` stessa directory in`amazon-ssm-agent.json`.
1. Aggiorna la voce seguente per impostare la regione corretta e impostala `UseDualStackEndpoint` su`true`:
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. Riavviate il SSM Agent servizio utilizzando il comando appropriato per il vostro sistema operativo:
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Serverusando Snap: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` seguito da `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` seguito da `Start-Service AmazonSSMAgent`
Per l'elenco completo dei comandi per sistema operativo, vedere[Verifica dello stato di SSM Agent e avvio dell'agente](ssm-agent-status-and-restart.md).
1. Eseguite qualsiasi operazione di patching per verificare che le operazioni di patching abbiano successo solo nel vostro ambiente IPv6. Assicurati che i nodi a cui applicare le patch siano connessi alla fonte della patch. È possibile controllare l'Run Commandoutput dell'esecuzione della patch per verificare la presenza di avvisi relativi a repository inaccessibili. Quando applichi una patch a un nodo in esecuzione in un IPv6 unico ambiente, assicurati che il nodo sia connesso alla fonte della patch. È possibile controllare l'Run Commandoutput dell'esecuzione della patch per verificare la presenza di avvisi relativi a repository inaccessibili. Per i sistemi operativi basati su DNF, è possibile configurare i repository non disponibili da ignorare durante l'applicazione delle patch se l'opzione è impostata su under. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` I sistemi operativi basati su DNF includono Amazon Linux 2023, Red Hat Enterprise Linux 8 e versioni successive, Oracle Linux 8 e versioni successive e CentOS 8 e versioni successive. Rocky Linux AlmaLinux Su Amazon Linux 2023, l'`skip_if_unavailable`opzione è impostata come `True` predefinita.
**Nota**
Quando utilizzi le funzionalità Install Override List o Baseline Override, assicurati che l'URL fornito sia raggiungibile dal nodo. Se l'opzione di SSM Agent configurazione `UseDualStackEndpoint` è impostata su`true`, viene utilizzato un client S3 dualstack quando viene fornito un URL S3.
# Tutorial: creare una baseline delle patch per l'installazione di Windows Service Pack tramite la console
Quando crei una baseline delle patch personalizzata, è possibile specificare che siano installati tutti, alcuni o solo un tipo di patch supportata.
Nelle baseline delle patch per Windows, è possibile selezionare `ServicePacks` come unica opzione di **Classificazione** per limitare gli aggiornamenti delle patch solo ai Service Pack. I service pack possono essere installati automaticamente da Patch Manager uno strumento in AWS Systems Manager, a condizione che l'aggiornamento sia disponibile in Windows Update o Windows Server Update Services (WSUS).
È possibile configurare una baseline delle patch per controllare se sono installati i Service Pack per tutte le versioni di Windows o solo quelli per versioni specifiche, ad esempio Windows 7 o Windows Server 2016.
Completa la procedura seguente per creare una baseline delle patch personalizzata da utilizzare esclusivamente per l'installazione di tutti i Service Pack nei nodi gestiti di Windows.
**Per creare una baseline delle patch per l'installazione di Windows Service Pack (console)**
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegli **Patch Manager**.
1. Scegli la scheda **Baseline delle patch** e quindi **Crea baseline delle patch**.
1. Nel campo **Nome** inserisci il nome della baseline delle patch, ad esempio `MyWindowsServicePackPatchBaseline`.
1. (Facoltativo) Per **Descrizione**, inserisci una descrizione per questa baseline delle patch.
1. Per **Sistema operativo**, seleziona `Windows`.
1. Se desideri iniziare a utilizzare subito questa baseline delle patch appena creata come impostazione predefinita per Windows, seleziona **Rendi predefinita questa baseline delle patch per le istanze di Windows Server**.
**Nota**
Questa opzione è disponibile solo se hai effettuato l'accesso per la prima volta a Patch Manager prima del rilascio delle [policy di patch](patch-manager-policies.md) del 22 dicembre 2022.
Per informazioni sull'impostazione di una baseline delle patch esistente come predefinita, consulta [Impostare una baseline delle patch esistente come predefinita](patch-manager-default-patch-baseline.md).
1. Nella sezione **Regole di approvazione per i sistemi operativi**, utilizza i campi per creare una o più regole di approvazione automatica.
+ **Prodotto**: le versioni del sistema operativo alle quali si applica la regola di approvazione, ad esempio `WindowsServer2012`. È possibile scegliere una, più di una o tutte le versioni supportate di Windows. L'opzione predefinita è `All`.
+ **Classificazione**: scegli `ServicePacks`.
+ **Gravità**: il valore di gravità delle patch a cui si applica la regola. Per assicurarti che tutti i Service Pack siano inclusi nella regola, scegli `All`.
+ **Approvazione automatico**: il metodo per selezionare le patch per l'approvazione automatica.
+ **Approva le patch dopo un determinato numero di giorni**: il numero di giorni in cui Patch Manager Patch Manager deve attendere dopo il rilascio o l'aggiornamento di una patch prima che una patch venga approvata automaticamente. È possibile inserire qualsiasi numero intero da zero (0) a 360. Per la maggior parte degli scenari, consigliamo di attendere non più di 100 giorni.
+ **Approva le patch rilasciate fino a una data specifica**: la data di rilascio delle patch per la quale Patch Manager applica automaticamente tutte le patch rilasciate o aggiornate prima di tale data (inclusa). Ad esempio, se si specifica il 7 luglio 2023, nessuna patch rilasciata o aggiornata a partire dall'8 luglio 2023 verrà installata automaticamente.
+ (Facoltativo) **Report di conformità**: il livello di gravità da assegnare ai Service Pack approvati dalla baseline, ad esempio `High`.
**Nota**
Se si specifica un livello di report di conformità e lo stato delle patch di un Service Pack approvato viene riportato come `Missing`, la gravità di conformità complessiva riportata dalla baseline delle patch corrisponde al livello di gravità specificato.
1. (Facoltativo) Per **Gestisci tag**, applica una o più name/value coppie di chiavi di tag alla linea di base della patch.
I tag sono metadati facoltativi assegnati a una risorsa. Consentono di categorizzare una risorsa in diversi modi, ad esempio in base allo scopo, al proprietario o all'ambiente. Per questa baseline delle patch dedicata all'aggiornamento dei Service Pack, è possibile specificare coppie chiave-valore come le seguenti:
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. Scegli **Crea una baseline delle patch**.
# Tutorial: aggiorna le dipendenze dell'applicazione, applica patch a un nodo gestito ed esegui un controllo dell'integrità specifico dell'applicazione tramite la console
In molti casi, un nodo gestito deve essere riavviato dopo che è stata applicata la patch con l'aggiornamento software più recente. Tuttavia, il riavvio di nodo in produzione senza misure di protezione può causare diversi problemi, ad esempio richiamare allarmi, registrare dati metrici errati e interrompere le sincronizzazioni dei dati.
Questo tutorial illustra come evitare problemi come questi utilizzando il documento (documento SSM) AWS Systems Manager `AWS-RunPatchBaselineWithHooks` per ottenere una complessa operazione di applicazione di patch in più fasi che consente di eseguire le operazioni seguenti:
1. Impedire nuove connessioni all'applicazione
1. Installare gli aggiornamenti nel sistema operativo
1. Aggiornare le dipendenze del pacchetto dell'applicazione
1. Riavviare il sistema
1. Esegui un controllo dell'integrità specifico dell'applicazione
Per questo esempio, abbiamo impostato la nostra infrastruttura in questo modo:
+ Le macchine virtuali di destinazione vengono registrate come nodi gestiti con Systems Manager.
+ `Iptables` viene utilizzato come firewall locale.
+ L'applicazione ospitata sui nodi gestiti è in esecuzione sulla porta 443.
+ L'applicazione ospitata sui nodi gestiti è un'applicazione di `nodeJS`.
+ L'applicazione ospitata sui nodi gestiti è gestita dal gestore di processi pm2.
+ L'applicazione dispone già di un endpoint di controllo dell'integrità specificato.
+ L'endpoint di controllo dell'integrità dell'applicazione non richiede l'autenticazione dell'utente finale. L'endpoint consente un controllo dell'integrità che soddisfi i requisiti dell'organizzazione per stabilire la disponibilità. Nei tuoi ambienti, potrebbe essere sufficiente accertare semplicemente che l'applicazione `nodeJS` sia in esecuzione e in grado di ascoltare le richieste. In altri casi, è possibile verificare anche che sia già stata stabilita una connessione al livello di memorizzazione nella cache o al livello di database.
Gli esempi riportati in questo tutorial sono esclusivamente a scopo dimostrativo e non devono essere implementati così come sono negli ambienti di produzione. Inoltre, tenere presente che la funzionalità hook del ciclo di vita di Patch Manager, una funzionalità di Systems Manager, con il documento `AWS-RunPatchBaselineWithHooks` può supportare numerosi altri scenari. Di seguito sono riportati vari esempi.
+ Arresta un agente di reporting dei parametri di riferimento prima di applicare patch e riavviarlo dopo il riavvio dei nodi gestiti.
+ Staccare il nodo gestito da un cluster CRM o PCS prima di applicare patch e ricollegarsi dopo il riavvio del nodo.
+ Aggiornare software di terze parti (ad esempio, Java, Tomcat, applicazioni Adobe e così via) su macchine Windows Server dopo l'applicazione degli aggiornamenti del sistema operativo (OS), ma prima del riavvio del nodo gestito.
**Per aggiornare le dipendenze dell'applicazione, applicare patch a un nodo gestito ed eseguire un controllo dell'integrità specifico dell'applicazione**
1. Creare un documento SSM per lo script di preinstallazione con i seguenti contenuti e denominarlo `NodeJSAppPrePatch`. Sostituisci *your\$1application* con il nome della tua applicazione.
Questo script blocca immediatamente le nuove richieste in arrivo e fornisce cinque secondi per le richieste già attive da completare prima di iniziare l'operazione di applicazione delle patch. Per l'opzione `sleep`, specifica un numero di secondi maggiore del necessario per il completamento delle richieste in arrivo.
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
Per informazioni sulla creazione di un documento SSM, consulta [Creazione del contenuto del documento SSM](documents-creating-content.md).
1. Crea un altro documento SSM con il seguente contenuto per lo script post-installazione per aggiornare le dipendenze dell'applicazione e denominarlo `NodeJSAppPostPatch`. Sostituisci */your/application/path* con il percorso dell'applicazione.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. Crea un altro documento SSM con il seguente contenuto per il tuo script `onExit` per eseguire il backup dell'applicazione ed eseguire un controllo dell'integrità. Denomina questo documento SSM `NodeJSAppOnExitPatch`. Sostituisci *your\$1application* con il nome della tua applicazione.
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. Crea un'associazione in State Manager, uno strumento di AWS Systems Manager, per eseguire l'operazione eseguendo i passaggi seguenti:
1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Nel pannello di navigazione, scegliere **State Manager**, quindi **Create association (Crea associazione)**.
1. Per **Nome**, fornire un nome per identificare lo scopo dell'associazione.
1. Nell'elenco **Document (Documento)** scegliere `AWS-RunPatchBaselineWithHooks`.
1. Per **Operation (Operazione)**, selezionare **Install (Installa)**.
1. (Facoltativo) Per **ID snapshot**, fornire un GUID generato per velocizzare l'operazione e garantire la coerenza. Il valore GUID può essere semplice come `00000000-0000-0000-0000-111122223333`.
1. Per **Nome documento Hook pre-installazione**, immettere`NodeJSAppPrePatch`.
1. Per **Post Install Hook Doc Name** (Nome documento Hook post-installazione), immetti `NodeJSAppPostPatch`.
1. Per **On ExitHook Doc Name**, inserisci`NodeJSAppOnExitPatch`.
1. Per **Targets**, identificare i nodi gestiti specificando i tag, scegliendo i nodi manualmente, scegliendo un gruppo di risorse o scegliendo tutti i nodi gestiti.
1. Per **Specificare la pianificazione**, specificare la frequenza di esecuzione dell'associazione. Ad esempio, per l'applicazione di patch su nodi gestiti, una volta alla settimana è una cadenza comune.
1. Nella sezione **Rate control (Controllo della velocità)** scegli le opzioni per controllare l'esecuzione dell'associazione su più nodi gestiti. Assicurarsi che solo una parte dei nodi gestiti venga aggiornata alla volta. In caso contrario, tutto o la maggior parte del parco potrebbe essere disconnesso in una sola volta. Per informazioni sull'utilizzo dei controlli di velocità, consultare [Comprensioni su destinazioni e controlli di velocità nelle associazioni di State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. (Facoltativo) In **Opzioni di output**, per salvare l'output del comando in un file, seleziona la casella **Abilita scrittura in S3**. Digita i nomi del bucket e del prefisso (cartella) nelle caselle.
**Nota**
Le autorizzazioni S3 che consentono di scrivere dati in un bucket S3 sono quelle del profilo dell'istanza assegnate al nodo gestito e non quelle dell'utente IAM che esegue questo processo. Per ulteriori informazioni, consulta le pagine [Configurazione delle autorizzazioni dell'istanza richieste per Systems Manager](setup-instance-permissions.md) oppure [Creazione di un ruolo di servizio IAM per un ambiente ibrido](hybrid-multicloud-service-role.md). Inoltre, se il bucket S3 specificato si trova in un Account AWS diverso, assicurarsi che il profilo dell'istanza o il ruolo di servizio IAM associato all'istanza disponga delle autorizzazioni necessarie per scrivere su quel bucket.
1. Scegli **Crea associazione**.
# Tutorial: applicare una patch a un ambiente server utilizzando il AWS CLI
La procedura seguente mostra in che modo un utente potrebbe applicare patch a un ambiente server utilizzando una baseline delle patch personalizzata, gruppi di patch e una finestra di manutenzione.
**Prima di iniziare**
+ Installazione o aggiornamento dell'SSM Agent sui tuoi nodi gestiti. Per applicare patch ai nodi gestiti Linux, i nodi devono essere in esecuzione la versione 2.0.834.0 SSM Agent o successive. Per ulteriori informazioni, consulta [Aggiornamento di SSM Agent utilizzando Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Configura ruoli e autorizzazioni perMaintenance Windows, uno strumento in AWS Systems Manager. Per ulteriori informazioni, consulta [Configurazione di Maintenance Windows](setting-up-maintenance-windows.md).
+ Installa e configura AWS Command Line Interface (AWS CLI), se non l'hai già fatto.
Per informazioni, consulta la pagina [Installazione o aggiornamento della versione più recente di AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Per configurare Patch Manager e applicare patch ai nodi gestiti (riga di comando).**
1. Eseguire il comando seguente per creare una baseline delle patch per Windows denominata `Production-Baseline`. Questa baseline delle patch approva le patch per un ambiente di produzione 7 giorni dopo il rilascio o l'ultimo aggiornamento. In questo modo, la baseline delle patch è stata contrassegnata per indicare che è destinata a un ambiente di produzione.
**Nota**
Il parametro `OperatingSystem` e `PatchFilters` variano a seconda del sistema operativo dei nodi gestiti di destinazione a cui si applica la baseline delle patch. Per ulteriori informazioni, consultare [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) e [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Eseguire i comandi seguenti per registrare la baseline delle patch "Production-Baseline" per due gruppi di patch. I gruppi sono denominati «Server database» e «Server front-end».
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Eseguire i seguenti comandi per creare due finestre di manutenzione per il server di produzione. La prima finestra viene eseguita ogni martedì alle 22:00. La seconda finestra viene eseguita ogni sabato alle 22:00. Inoltre, la finestra di manutenzione è stata contrassegnata per indicare che è destinata a un ambiente di produzione.
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. Eseguire i comandi seguenti per registrare i gruppi di patch server `Database` e `Front-End` con le rispettive finestre di manutenzione.
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. Eseguire i comandi seguenti per registrare un'attività di patch che installa aggiornamenti mancanti nei server `Database` e `Front-End` durante le rispettive finestre di manutenzione.
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. Eseguire il seguente comando per ottenere il riepilogo di conformità delle patch di alto livello per un gruppo di patch. Il riepilogo della conformità patch di alto livello include il numero di nodi gestiti con patch nei rispettivi stati di patch.
**Nota**
Si prevede di visualizzare gli zeri per il numero di nodi gestiti nel riepilogo fino a quando l'attività di patch viene eseguita durante la prima finestra di manutenzione.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. Eseguire il seguente comando per ottenere il riepilogo dello stato di un nodo gestito per le patch di un gruppo. Il riepilogo per nodo gestito include un numero di patch nei rispettivi stati di patch per nodo gestito per un gruppo di patch.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
Il sistema restituisce informazioni simili alle seguenti.
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Per esempi di altri AWS CLI comandi che puoi usare per le tue attività Patch Manager di configurazione, vedi[Lavorare con le risorse di Patch Manager utilizzando AWS CLI](patch-manager-cli-commands.md).