• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Tutoriels AWS Systems Manager Patch Manager
Les didacticiels de cette section montrent comment utiliser Patch Manager un outil dans AWS Systems Manager plusieurs scénarios d'application de correctifs.
**Topics**
+ [Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutoriel : créer un référentiel de correctifs pour l’installation des Service Packs Windows à l’aide de la console](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutoriel : mettre à jour les dépendances des applications, appliquer des correctifs sur un nœud géré et effectuer une surveillance de l’état spécifique à l’application en utilisant la console](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# Tutoriel : Appliquer des correctifs à un serveur dans un environnement IPv6 uniquement
Patch Managerprend en charge l'application de correctifs aux nœuds dans les environnements qui en ont IPv6 uniquement. En mettant à jour la SSM Agent configuration, les opérations de correction peuvent être configurées pour effectuer des appels uniquement aux points de terminaison IPv6 du service.
**Pour appliquer un correctif à un serveur dans un environnement IPv6 uniquement**
1. Assurez-vous que SSM Agent la version 3.3270.0 ou ultérieure est installée sur le nœud géré.
1. Sur le nœud géré, accédez au fichier SSM Agent de configuration. Le `amazon-ssm-agent.json` fichier se trouve dans les répertoires suivants :
+ Linux : `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
S'il `amazon-ssm-agent.json` n'existe pas encore, copiez le contenu de `amazon-ssm-agent.json.template` dans le même répertoire dans`amazon-ssm-agent.json`.
1. Mettez à jour l'entrée suivante pour définir la bonne région et définissez-la `UseDualStackEndpoint` sur `true` :
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. Redémarrez le SSM Agent service à l'aide de la commande adaptée à votre système d'exploitation :
+ Linux : `sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Serverà l'aide de Snap : `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` suivi par `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` suivi par `Start-Service AmazonSSMAgent`
Pour obtenir la liste complète des commandes par système d'exploitation, consultez[Vérification du statut de l'SSM Agent et démarrage de l'agent](ssm-agent-status-and-restart.md).
1. Exécutez n'importe quelle opération de correction pour vérifier que les opérations de correction réussissent dans votre environnement réservé à votre environnement IPv6. Assurez-vous que les nœuds auxquels le correctif est appliqué sont connectés à la source du correctif. Vous pouvez vérifier le Run Command résultat de l'exécution du correctif pour vérifier la présence d'avertissements concernant des référentiels inaccessibles. Lorsque vous appliquez des correctifs à un nœud qui s'exécute dans un environnement IPv6 réservé, assurez-vous que le nœud est connecté à la source du correctif. Vous pouvez vérifier le Run Command résultat de l'exécution du correctif pour vérifier la présence d'avertissements concernant des référentiels inaccessibles. Pour les systèmes d'exploitation basés sur DNF, il est possible de configurer les référentiels indisponibles pour qu'ils soient ignorés lors de l'application des correctifs si l'`skip_if_unavailable`option est définie sur moins. `True` `/etc/dnf/dnf.conf` Les systèmes d'exploitation basés sur DNF incluent Amazon Linux 2023, les versions Red Hat Enterprise Linux 8 et ultérieures, les versions Oracle Linux 8 et ultérieures Rocky Linux AlmaLinux, et CentOS 8 et les versions ultérieures. Sur Amazon Linux 2023, l'`skip_if_unavailable`option est définie sur `True` par défaut.
**Note**
Lorsque vous utilisez les fonctionnalités Install Override List ou Baseline Override, assurez-vous que l'URL fournie est accessible depuis le nœud. Si l'option de SSM Agent configuration `UseDualStackEndpoint` est définie sur`true`, un client S3 à double pile est utilisé lorsqu'une URL S3 est fournie.
# Tutoriel : créer un référentiel de correctifs pour l’installation des Service Packs Windows à l’aide de la console
Lorsque vous créez un référentiel de correctifs personnalisée, vous pouvez spécifier que tous, certains ou un seul type de correctif pris en charge sont installés.
Dans les références de correctifs pour Windows, vous pouvez sélectionner `ServicePacks` comme seule option de **Classification** afin de limiter les mises à jour des correctifs aux Service Packs uniquement. Les Service Packs peuvent être installés automatiquement à l'aide d'un outil AWS Systems Manager, à condition que la mise à jour soit disponible dans Windows Update ou Windows Server Update Services (WSUS). Patch Manager
Vous pouvez configurer un référentiel de correctifs pour contrôler si les Service Packs pour toutes les versions de Windows sont installés, ou uniquement ceux pour des versions spécifiques, comme Windows 7 ou Windows Server 2016.
Suivez la procédure ci-dessous afin de créer un référentiel de correctifs personnalisé à utiliser exclusivement pour installer tous les Service Packs sur vos nœuds gérés Windows.
**Créer un référentiel de correctifs pour l'installation des Service Packs Windows (console)**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l'onglet **Référentiels de correctifs**, puis choisissez **Créer un référentiel de correctifs**.
1. Pour **Nom**, entrez un nom pour votre nouvelle référentiel de correctifs, par exemple : `MyWindowsServicePackPatchBaseline`.
1. (Facultatif) Pour **Description**, saisissez une description pour cette référence de correctif.
1. Pour **Système d'exploitation**, sélectionnez `Windows`.
1. Si vous souhaitez commencer à utiliser cette référence de correctif comme valeur par défaut pour Windows dès sa création, sélectionnez **Définir cette référence de correctif comme référence par défaut pour les instances Windows Server**.
**Note**
Cette option n'est disponible que si vous avez accédé à Patch Manager pour la première fois avant la publication des [politiques de correctifs](patch-manager-policies.md) le 22 décembre 2022.
Pour de plus amples informations, sur la définition d'un référentiel de correctifs existante en tant que référence par défaut, veuillez consulter [Définition d'un référentiel de correctifs existante en tant que valeur par défaut](patch-manager-default-patch-baseline.md).
1. Dans la section **Règles d'approbation pour les systèmes d'exploitation)**, utilisez les champs pour créer une ou plusieurs règles d'approbation automatique.
+ **Produits** : versions des systèmes d'exploitation auxquelles s'applique la règle d'approbation, par exemple `WindowsServer2012`. Vous pouvez choisir une, plusieurs ou toutes les versions prises en charge de Windows. La sélection par défaut est `All`.
+ **Classification** : sélectionnez `ServicePacks`.
+ **Importance** : valeur d'importance des correctifs à laquelle la règle va s'appliquer. Pour vous assurer que tous les Service Packs sont inclus dans la règle, sélectionnez `All`.
+ **Approbation automatique** : méthode de sélection des patchs pour approbation automatique.
+ **Approuver les correctifs après un nombre de jours spécifié** : pendant lesquels Patch Manager doit attendre après la publication ou la mise à jour d'un correctif avant son approbation automatique. Vous pouvez entrer tout nombre entier situé entre zéro (0) et 360. Nous vous recommandons, en règle générale, de ne pas attendre plus de 100 jours.
+ **L'approbation des correctifs publiés jusqu'à une date spécifique**: date de publication des correctifs pour laquelle Patch Manager applique automatiquement tous les correctifs publiés à cette date ou avant cette date. Par exemple, si vous spécifiez le 7 juillet 2023, aucun correctif publié ou mis à jour le 8 juillet 2023 ou après ne sera installé automatiquement.
+ (Facultatif) **Rapport de conformité** : niveau d'importance que vous voulez affecter aux Service Packs approuvés par la référence, par exemple `High`.
**Note**
Si vous spécifiez un niveau de rapport de conformité et que l'état des correctifs d'un Service Pack approuvé est indiqué `Missing`, le niveau de sévérité de conformité global indiqué pour le référentiel de correctifs est le niveau de sévérité que vous avez spécifié.
1. (Facultatif) Pour **Gérer les balises**, appliquez une ou plusieurs name/value paires de clés de balise à la ligne de base du correctif.
Les balises sont des métadonnées facultatives que vous affectez à une ressource. Les balises vous permettent de classer une ressource de différentes façons, par exemple, par objectif, par propriétaire ou par environnement. Pour ce référentiel de correctifs dédiée à la mise à jour des Service Packs, vous pouvez spécifier des paires clé-valeur telles que les suivantes :
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. Sélectionnez **Créer un référentiel de correctif**.
# Tutoriel : mettre à jour les dépendances des applications, appliquer des correctifs sur un nœud géré et effectuer une surveillance de l’état spécifique à l’application en utilisant la console
Dans bien des cas, un nœud géré doit être redémarré après l'installation de la dernière mise à jour logicielle. Toutefois, le redémarrage d'un nœud en production sans mesures de protection peut occasionner différents problèmes, comme le déclenchement d'alarmes, l'enregistrement de données métriques incorrectes et l'interruption des synchronisations de données.
Ce didacticiel illustre la façon d'éviter les problèmes de ce genre en utilisant le document AWS Systems Manager (document SSM) `AWS-RunPatchBaselineWithHooks` pour réaliser une opération complexe d'application de correctifs en plusieurs étapes qui effectue les opérations suivantes :
1. Empêcher de nouvelles connexions à l'application
1. Installer les mises à jour du système d'exploitation
1. Mettre à jour les dépendances de package de l'application
1. Redémarrer le système
1. Effectuer une surveillance de l'état spécifique à l'application
Pour cet exemple, nous avons configuré notre infrastructure de la façon suivante :
+ Les machines virtuelles ciblées sont enregistrées en tant que nœuds gérés auprès de Systems Manager.
+ `Iptables` est utilisé comme pare-feu local.
+ L'application hébergée sur les nœuds gérés s'exécute sur le port 443.
+ L'application hébergée sur les nœuds gérés est une application `nodeJS`.
+ L'application hébergée sur les nœuds gérés est gérée par le gestionnaire de processus pm2.
+ L'application dispose déjà d'un point de terminaison de surveillance de l'état spécifié.
+ Le point de terminaison de surveillance de l'état de l'application n'exige aucune authentification de l'utilisateur final. Le point de terminaison autorise une surveillance de l'état qui répond aux exigences de l'organisation en matière d'établissement de la disponibilité. (Dans vos environnements, il pourrait suffire de vérifier simplement que l'application `nodeJS` est en cours d'exécution et peut écouter les demandes. Dans d'autres cas, vous pouvez également vouloir vérifier qu'une connexion à la couche de mise en cache ou à la couche de base de données est déjà établie.)
Les exemples de ce didacticiel sont fournis à titre indicatif uniquement. Ils ne sont pas destinés à être mis en œuvre en l'état dans les environnements de production. N’oubliez pas non plus que la fonction de hooks de cycle de vie de Patch Manager, un outil de Systems Manager, avec le document `AWS-RunPatchBaselineWithHooks` peut prendre en charge de nombreux autres scénarios. Voici quelques exemples.
+ Arrêtez l'agent de génération de rapport de métriques avant d'appliquer les correctifs, et relancez-le après le redémarrage du nœud géré.
+ Détachez le nœud géré du cluster CRM ou PCS avant d'appliquer les correctifs, et attachez-le de nouveau après le redémarrage du nœud.
+ Mettez à jour les logiciels tiers (comme les applications Adobe, Java, Tomcat, etc.) sur les machines Windows Server après l'application des mises à jour du système d'exploitation, mais avant le redémarrage du nœud géré.
**Pour mettre à jour les dépendances des applications, appliquer des correctifs sur un nœud géré et effectuer une surveillance de l'état spécifique à l'application**
1. Créez un document SSM avec le contenu suivant pour votre script de préinstallation et nommez-le `NodeJSAppPrePatch`. Remplacez *your\$1application* par le nom de votre application.
Ce script bloque immédiatement les nouvelles demandes entrantes et fournit aux demandes déjà actives un délai de cinq secondes avant de commencer l'opération d'application de correctifs. Pour l'option `sleep`, spécifiez un nombre de secondes supérieur à ce qu'il faut habituellement aux requêtes entrantes pour s'effectuer.
```
# 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
```
Pour de plus amples informations sur la création de documents SSM, consultez [Création du contenu du document SSM](documents-creating-content.md).
1. Créez un autre document SSM avec le contenu suivant pour votre script postinstallation, pour mettre à jour vos dépendances d'application, et nommez-le `NodeJSAppPostPatch`. Remplacez */your/application/path* par le chemin d'accès à votre application.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. Créez un autre document SSM avec le contenu suivant pour votre script `onExit`, pour rétablir votre application et effectuer une surveillance de l'état. Nommez ce document SSM `NodeJSAppOnExitPatch`. Remplacez *your\$1application* par le nom de votre application.
```
# 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. Créez une association dans State Manager, un outil d’ AWS Systems Manager, pour émettre l’opération en procédant comme suit :
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **State Manager**, puis **Créer une association**.
1. Pour **Nom**, fournissez un nom permettant d'identifier le but de l'association.
1. Dans la liste **Document**, sélectionnez `AWS-RunPatchBaselineWithHooks`.
1. Pour **Operation (Opération)**, sélectionnez **Install (Installer)**.
1. (Facultatif) Pour **ID d'instantané**, fournissez un GUID que vous générez pour accélérer l'opération et garantir la cohérence. La valeur du GUID peut être aussi simple que `00000000-0000-0000-0000-111122223333`.
1. Pour **Nom de document du hook de préinstallation**, saisissez `NodeJSAppPrePatch`.
1. Pour **Nom de document du hook de postinstallation**, saisissez `NodeJSAppPostPatch`.
1. Pour **On ExitHook Doc Name**, entrez`NodeJSAppOnExitPatch`.
1. Dans **Targets (Cibles)**, identifiez vos nœuds gérés en spécifiant des balises, en choisissant manuellement les nœuds, en choisissant un groupe de ressources ou en choisissant tous les nœuds gérés.
1. Pour **Spécifier le calendrier**, spécifiez la fréquence d'exécution de l'association. La fréquence d'application des correctifs sur les nœuds gérés est couramment définie sur une fois par semaine.
1. Dans la section **Rate control (Contrôle du débit)**, sélectionnez les options permettant de contrôler la façon dont l'association s'exécute sur plusieurs nœuds gérés. Assurez-vous que seule une partie des nœuds gérés est mise à jour à la fois. Autrement, la totalité ou la majeure partie de votre flotte pourrait être déconnectée en même temps. Pour de plus amples informations sur l'utilisation des contrôles de débit, consultez [Comprendre les cibles et les contrôles du taux dans les associations State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. (Facultatif) Dans **Output options (Options de sortie)**, pour enregistrer la sortie de la commande dans un fichier, sélectionnez **Enable writing to an S3 bucket (Autoriser l'écriture dans un compartiment S3)** Saisissez les noms de compartiment et de préfixe (dossier) dans les zones.
**Note**
Les autorisations S3 qui donnent la possibilité d'écrire les données dans un compartiment S3 sont celles du profil d'instance attribué au nœud géré, et non celles de l'utilisateur IAM qui effectue cette tâche. Pour plus d’informations, consultez les sections [Configurer des autorisations d’instance requises pour Systems Manager](setup-instance-permissions.md) et [Créer un rôle de service IAM pour un environnement hybride](hybrid-multicloud-service-role.md). En outre, si le compartiment S3 spécifié se trouve sur un autre Compte AWS, vérifiez que le profil d'instance ou la fonction de service IAM associé au nœud géré dispose des autorisations nécessaires pour écrire dans ce compartiment.
1. Sélectionnez **Create Association (Créer une association)**.
# Tutoriel : appliquer un correctif à un environnement de serveur à l'aide du AWS CLI
La procédure suivante décrit l'application de correctifs à un environnement de serveur à l'aide d'un référentiel de correctifs personnalisée, de groupes de correctifs et d'une fenêtre de maintenance.
**Avant de commencer**
+ Installez ou mettez à jour SSM Agent sur vos nœuds gérés. Pour appliquer des correctifs à des nœuds gérés Linux, ces derniers doivent exécuter SSM Agent version 2.0.834.0 ou ultérieure. Pour de plus amples informations, veuillez consulter [Mise à jour de SSM Agent à l'aide de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Configurez les rôles et les autorisations pourMaintenance Windows, un outil dans AWS Systems Manager. Pour de plus amples informations, veuillez consulter [Configuration de Maintenance Windows](setting-up-maintenance-windows.md).
+ Installez et configurez le AWS Command Line Interface (AWS CLI), si ce n'est pas déjà fait.
Pour de plus amples informations, consultez [Installation ou mise à jour de la version la plus récente de l' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Pour configurer Patch Manager et appliquer des correctifs aux nœuds gérés (ligne de commande)**
1. Exécutez la commande suivante pour créer un référentiel de correctifs pour Windows nommée `Production-Baseline`. Ce référentiel de correctifs approuve les correctifs pour un environnement de production 7 jours après leur publication ou leur dernière mise à jour. Cela signifie que le référentiel de correctifs a été balisée pour indiquer qu'elle est destinée à un environnement de production.
**Note**
Le paramètre `OperatingSystem` et `PatchFilters` varient en fonction du système d'exploitation des nœuds gérés cibles auxquels s'applique le référentiel de correctifs. Pour plus d’informations, consultez [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) et [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"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Exécutez les commandes suivantes pour enregistrer le référentiel de correctifs « Production-Baseline » pour deux groupes de correctifs. Les groupes sont nommés « serveurs de base de données » et « serveurs 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"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"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"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Exécutez les commandes suivantes pour créer deux fenêtres de maintenance pour les serveurs de production. La première fenêtre est exécutée tous les mardis à 22:00. La seconde fenêtre est exécutée tous les samedis à 22:00. En outre, la fenêtre de maintenance a été balisée pour indiquer qu'elle est destinée à un environnement de production.
------
#### [ 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
```
------
Le système retourne des informations telles que les suivantes.
```
{
"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
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. Exécutez les commandes suivantes pour enregistrer les groupes de correctifs des serveurs `Database` et `Front-End` avec leurs fenêtres de maintenance respectives.
------
#### [ 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"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"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"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. Exécutez les commandes suivantes pour enregistrer une tâche de correctif qui installe les mises à jour manquantes sur les serveurs `Database` et `Front-End` pendant leurs fenêtres de maintenance respectives.
------
#### [ 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}}"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"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}}"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. Exécutez la commande suivante pour obtenir le résumé de haut niveau de la conformité des correctifs d'un groupe de correctifs. Le récapitulatif détaillé de conformité des correctifs comprend le nombre de nœuds gérés et présente les correctifs en indiquant leurs états respectifs.
**Note**
Ce récapitulatif doit théoriquement afficher des zéros pour le nombre de nœuds gérés jusqu'à ce que la tâche d'application des correctifs soit exécutée lors de la première fenêtre de maintenance.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. Exécutez la commande suivante pour obtenir le récapitulatif des états des correctifs par nœud géré pour un groupe de correctifs. Le récapitulatif par nœud géré présente un certain nombre de correctifs en indiquant leurs états respectifs par nœud géré pour un groupe de correctifs.
------
#### [ 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"
```
------
Le système retourne des informations telles que les suivantes.
```
{
"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
}
]
}
```
Pour des exemples d'autres AWS CLI commandes que vous pouvez utiliser pour vos tâches Patch Manager de configuration, consultez[Travailler avec des ressources Patch Manager à l’aide de l’AWS CLI](patch-manager-cli-commands.md).