• El panel de AWS Systems Manager CloudWatch dejará de estar disponible después del 30 de abril de 2026. Los clientes pueden seguir utilizando la consola de Amazon CloudWatch para ver, crear y administrar sus paneles de Amazon CloudWatch, tal y como lo hacen actualmente. Para obtener más información, consulte la [documentación del panel de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). # Tutoriales de AWS Systems Manager Patch Manager Los tutoriales de esta sección muestran cómo utilizar Patch Manager, una herramienta de AWS Systems Manager, en diversos casos de aplicación de revisiones. **Topics** + [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) + [Tutorial: creación de una línea de base de revisiones para instalar Service Packs de Windows mediante la consola](patch-manager-windows-service-pack-patch-baseline-tutorial.md) + [Tutorial: actualización de las dependencias de la aplicación, implementación de una revisión a un nodo administrado y realización de una comprobación de estado específica de la aplicación mediante la consola](aws-runpatchbaselinewithhooks-tutorial.md) + [Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md) # Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6 Patch Manager admite la aplicación de revisiones en nodos en entornos que solo tienen IPv6. Al actualizar la configuración de SSM Agent, las operaciones de aplicación de revisiones se pueden configurar para que solo realicen llamadas a los puntos de conexión del servicio IPv6. **Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6** 1. Asegúrese de la versión 3.3270.0 de SSM Agent o una versión posterior esté instalada en el nodo administrado. 1. En el nodo administrado, navegue hasta el archivo de configuración de SSM Agent. Encontrará el archivo `amazon-ssm-agent.json` en los siguientes directorios: + Linux: `/etc/amazon/ssm/` + macOS: `/opt/aws/ssm/` + Windows Server: `C:\Program Files\Amazon\SSM` Si `amazon-ssm-agent.json` aún no existe, copie el contenido de `amazon-ssm-agent.json.template` del mismo directorio en `amazon-ssm-agent.json`. 1. Actualice la siguiente entrada para establecer la región correcta y establezca `UseDualStackEndpoint` en `true`: ``` { -------- "Agent": { "Region": "region", "UseDualStackEndpoint": true }, -------- } ``` 1. Reinicie el servicio de SSM Agent con el comando correspondiente de su sistema operativo: + Linux: `sudo systemctl restart amazon-ssm-agent` + Ubuntu Server mediante el uso de Snap: `sudo snap restart amazon-ssm-agent` + macOS: `sudo launchctl stop com.amazon.aws.ssm` seguido de `sudo launchctl start com.amazon.aws.ssm` + Windows Server: `Stop-Service AmazonSSMAgent` seguido de `Start-Service AmazonSSMAgent` Para ver la lista completa de comandos de cada sistema operativo, consulte [Verificación del estado de SSM Agent e inicio del agente](ssm-agent-status-and-restart.md). 1. Ejecute cualquier operación de aplicación de revisiones para comprobar que las operaciones de aplicación de revisiones se realicen correctamente en su entorno exclusivo para IPv6. Asegúrese de que los nodos a los que se va a aplicar la revisión estén conectados a la fuente de la revisión. Puede comprobar el resultado Run Command de la ejecución de la revisión para comprobar si hay advertencias sobre repositorios inaccesibles. Cuando aplique revisiones a un nodo que se ejecuta en un entorno exclusivo de IPv6, asegúrese de que el nodo tenga conectividad con la fuente de la revisión. Puede comprobar el resultado Run Command de la ejecución de la revisión para comprobar si hay advertencias sobre repositorios inaccesibles. En el caso de los sistemas operativos basados en DNF, es posible configurar los repositorios no disponibles para que se omitan durante la aplicación de revisiones si la opción `skip_if_unavailable` está establecida en `True` en `/etc/dnf/dnf.conf`. Los sistemas operativos basados en DNF incluyen Amazon Linux 2023, Red Hat Enterprise Linux 8 y versiones posteriores, Oracle Linux 8 y versiones posteriores, Rocky Linux, AlmaLinux y CentOS 8 y versiones posteriores. En Amazon Linux 2023, la opción `skip_if_unavailable` está establecida en `True` de forma predeterminada. **nota** Cuando utilice las características Install Override List o Baseline Override, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. # Tutorial: creación de una línea de base de revisiones para instalar Service Packs de Windows mediante la consola Al crear una línea de base de revisiones personalizada, puede especificar que se instalen todos, parte o solo un tipo de parche compatible. En las líneas de base de revisiones para Windows, puede seleccionar `ServicePacks` como única opción de **clasificación** para limitar las actualizaciones de revisiones solo a Service Packs. Patch Manager, una herramienta de AWS Systems Manager, puede instalar automáticamente Service Packs siempre que la actualización esté disponible en Windows Update o Windows Server Update Services (WSUS). Puede configurar una línea de base de revisiones para controlar si se instalan los Service Packs para todas las versiones de Windows o solo los de versiones específicas, como Windows 7 o Windows Server 2016. Utilice el procedimiento siguiente para crear una base de referencia de revisiones personalizada que se utilizará exclusivamente para instalar todos los Service Packs en los nodos administrados de Windows. **Para crear una línea de base de revisiones para instalar Service Packs de Windows (consola)** 1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. En el panel de navegación, elija **Patch Manager**. 1. Seleccione la pestaña **Bases de referencia de parches**, y luego **Crear una base de referencia de parches**. 1. En **Nombre**, escriba un nombre para la nueva línea de base de revisiones; por ejemplo, `MyWindowsServicePackPatchBaseline`. 1. (Opcional) En **Description (Descripción)**, escriba una descripción para esta línea de base de revisiones. 1. En **Operating system (Sistema operativo)**, elija `Windows`. 1. Si desea comenzar a utilizar esta línea de base de revisiones de forma predeterminada para Windows tan pronto como la cree, seleccione **Set this patch baseline as the default patch baseline for Windows Server instances (Establecer esta línea de base de revisiones como la línea de base de revisiones predeterminada para las instancias de Windows Server)**. **nota** Esta opción solo está disponible si accedió a Patch Manager por primera vez antes de las [políticas de parches](patch-manager-policies.md) publicadas el 22 de diciembre de 2022. Para obtener información sobre la configuración de una línea de base de revisiones existente como la opción predeterminada, consulte [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md). 1. En la sección **Approval Rules for operating systems (Reglas de aprobación para sistemas operativos)**, use los campos para crear una o varias reglas de aprobación automática. + **Productos**: versiones de los sistemas operativos a las que se aplica la regla de aprobación; por ejemplo, `WindowsServer2012`. Puede elegir una, más de una o todas las versiones compatibles de Windows. La selección predeterminada es `All`. + **Clasificación**: elija `ServicePacks`. + **Gravedad**: el valor de gravedad de las revisiones a los que se aplica la regla. Para asegurarse de que todos los Service Packs están incluidos en la regla, elija `All`. + **Auto-approval (Aprobación automática)**: método para seleccionar revisiones para su aprobación automática. + **Approve patches after a specified number of days** (Aprobar las revisiones después de una cantidad determinada de días): la cantidad de días que Patch Manager debe esperar después de que se lance o actualice una revisión y antes de que se apruebe automáticamente. Puede ingresar cualquier número entero entre cero (0) y 360. En la mayoría de los casos, se recomienda no esperar más de 100 días. + **Approve patches released up to a specific date** (Aprobar las revisiones publicadas hasta una fecha específica): la fecha de lanzamiento de la revisión para la que Patch Manager aplica automáticamente todas las revisiones publicadas o actualizadas en esa fecha o con anterioridad a ella. Por ejemplo, si especifica el 7 de julio de 2023, no se instalarán automáticamente las revisiones publicadas o actualizadas a partir del 8 de julio de 2023. + (Opcional). **Informes de conformidad**: el nivel de gravedad que desea asignar a los Service Packs aprobados por la base de referencia; como `High`. **nota** Si especifica un nivel de notificación de conformidad y se informa el estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que especificó. 1. (Opcional) En **Manage tags (Administrar etiquetas)**, aplique uno o varios pares de claves nombre/valor al a la línea de base de revisiones. Las etiquetas son metadatos opcionales que usted asigna a un recurso. Las etiquetas permiten clasificar los recursos de diversas maneras, por ejemplo, según la finalidad, el propietario o el entorno. Para esta línea de base de revisiones dedicada a la actualización de Service Packs, puede especificar pares clave-valor como los siguientes: + `Key=OS,Value=Windows` + `Key=Classification,Value=ServicePacks` 1. Elija **Create patch baseline** (Crear base de referencia de revisiones). # Tutorial: actualización de las dependencias de la aplicación, implementación de una revisión a un nodo administrado y realización de una comprobación de estado específica de la aplicación mediante la consola En muchos casos, un nodo administrado debe reiniciarse una vez que se haya aplicado la revisión correspondiente a la última actualización de software. No obstante, el reinicio de un nodo en producción sin contar con las debidas medidas de protección puede ocasionar varios problemas, como la invocación de alarmas, el registro de datos de métrica incorrectos y la interrupción de las sincronizaciones de datos. En este tutorial se demuestra cómo evitar este tipo de problemas a través del uso del documento de AWS Systems Manager (documento de SSM) `AWS-RunPatchBaselineWithHooks` para realizar una operación de implementación de una revisión compleja y de varios pasos que permita lograr lo siguiente: 1. impedir nuevas conexiones a la aplicación 1. instalar las actualizaciones del sistema operativo. 1. actualizar las dependencias del paquete de la aplicación 1. reiniciar el sistema 1. realizar una comprobación de estado específica de la aplicación Para este ejemplo, se ha configurado la infraestructura de la siguiente manera: + Las máquinas virtuales de destino se registran como nodos administrados con Systems Manager. + `Iptables` se utiliza como un firewall local. + La aplicación alojada en los nodos administrados se ejecuta en el puerto 443. + La aplicación alojada en los nodos administrados es una aplicación de `nodeJS`. + El administrador de procesos pm2 es el encargado de administrar la aplicación alojada en los nodos administrados. + La aplicación ya cuenta con un punto de enlace de comprobación de estado especificado. + El punto de enlace de comprobación de estado de la aplicación no requiere autenticación del usuario final. El punto de enlace permite una comprobación de estado conforme a los requisitos de la organización a la hora de establecer la disponibilidad. (En sus entornos, es posible que sea suficiente con solo comprobar que la aplicación de `nodeJS` se está ejecutando y es capaz de atender las solicitudes. No obstante, en otros casos, es posible que se desee verificar también que se ha establecido una conexión con el nivel de almacenamiento en caché o el nivel de base de datos). Los ejemplos expuestos en este tutorial son únicamente para fines ilustrativos y no se pretende su implementación como tales en entornos de producción. Asimismo, tenga en cuenta que la característica de los enlaces de ciclo de vida de Patch Manager, una herramienta de Systems Manager, con el documento `AWS-RunPatchBaselineWithHooks` puede admitir muchos otros casos. A continuación, se presentan varios ejemplos. + Detenga un agente de informes de métricas antes de aplicar una revisión y reiniciarlo después de que el nodo administrado se reinicie. + Desconecte el nodo administrado de un clúster de CRM o PCS antes de aplicar las revisiones y vuelva a adjuntarlo después de reiniciar el nodo. + Actualice el software de terceros (por ejemplo, Java, Tomcat, aplicaciones de Adobe, etc.) en las máquinas de Windows Server luego de aplicar las actualizaciones del sistema operativo (SO), pero antes de que el nodo administrado se reinicie. **Para actualizar las dependencias de la aplicación, aplicar una revisión a un nodo administrado y realizar una comprobación de estado específica de la aplicación** 1. Cree un documento de SSM para su script de preinstalación con el siguiente contenido y asígnele el nombre `NodeJSAppPrePatch`. Sustituya *your\$1application* por el nombre de la aplicación. Este script bloquea inmediatamente las nuevas solicitudes entrantes y proporciona cinco segundos para que las ya activas se completen antes de comenzar la operación de aplicación de parches. Para la opción `sleep`, especifique una cantidad de segundos mayor que la que suele tardar en completarse las solicitudes entrantes. ``` # 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 ``` Para obtener más información acerca de la creación de documentos de SSM, consulte [Crear contenido en el documento de SSM](documents-creating-content.md). 1. Cree otro documento SSM con el siguiente contenido para su script de posinstalación para actualizar las dependencias de su aplicación y asígnele el nombre `NodeJSAppPostPatch`. Sustituya */your/application/path* por la ruta de acceso a su aplicación. ``` cd /your/application/path npm update # you can use npm-check-updates if you want to upgrade major versions ``` 1. Cree otro documento de SSM con el siguiente contenido para que su script de `onExit` recupere su aplicación y realice una comprobación de estado. Asigne un nombre a este documento de SSM `NodeJSAppOnExitPatch`. Sustituya *your\$1application* por el nombre de la aplicación. ``` # 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. Cree una asociación en State Manager, una herramienta de AWS Systems Manager para ejecutar la operación mediante los siguientes pasos: 1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. En el panel de navegación, elija **State Manager** y, a continuación, elija **Create association (Crear asociación)**. 1. En **Name** (Nombre) proporcione un nombre que ayude a identificar la finalidad de la asociación. 1. En la lista **Document** (Documento), elija `AWS-RunPatchBaselineWithHooks`. 1. En **Operation** (Operación), elija **Install** (Instalar). 1. (Opcional) En **Snapshot Id**, (ID de instantánea), proporcione un valor GUID que genere de modo que le permita agilizar la operación y garantizar la consistencia. El valor GUID puede ser tan sencillo como `00000000-0000-0000-0000-111122223333`. 1. En **Pre Install Hook Doc Name** (Nombre del documento del enlace de preinstalación), ingrese `NodeJSAppPrePatch`. 1. En **Post Install Hook Doc Name** (Nombre del documento del enlace de posinstalación), ingrese `NodeJSAppPostPatch`. 1. En **On ExitHook Doc Name** (Nombre del documento del enlace de salida), ingrese `NodeJSAppOnExitPatch`. 1. En el caso de **Targets** (Destinos), especifique etiquetas, elija nodos manualmente, elija un grupo de recursos o elija todos los nodos administrados para identificar sus nodos administrados. 1. En **Specify schedule** (Especificar programación), especifique con qué frecuencia se ejecutará la asociación. En el caso de la aplicación de revisiones en el nodo administrado, la cadencia habitual suele ser una vez a la semana. 1. En la sección **Rate control** (Control de velocidad), elija las opciones para controlar cómo se ejecuta la asociación en varios nodos administrados. Asegúrese de que solo se actualiza una parte de los nodos administrados a la vez. De lo contrario, toda su flota o la mayor parte de ella podría quedar sin conexión a la vez. Para obtener más información sobre el uso de controles de velocidad, consulte [Cómo comprender los controles de frecuencia y destinos en las asociaciones de State Manager](systems-manager-state-manager-targets-and-rate-controls.md). 1. (Opcional) En **Output options (Opciones de salida)**, para guardar la salida del comando en un archivo, seleccione el cuadro **Enable writing output to S3 (Permitir la escritura de salida en S3)**. Ingrese los nombres del bucket y del prefijo (carpeta) en los cuadros. **nota** Los permisos de S3 que conceden la capacidad de escribir datos en un bucket de S3 son los del perfil de instancias asignado al nodo administrado, no los del usuario de IAM que realiza esta tarea. Para obtener más información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md) o [Creación de un rol de servicio de IAM para un entorno híbrido](hybrid-multicloud-service-role.md). Además, si el bucket de S3 especificado se encuentra en una Cuenta de AWS diferente, verifique que el perfil de instancias o el rol de servicio de IAM asociado al nodo administrado tenga los permisos necesarios para escribir en ese bucket. 1. Elija **Crear asociación**. # Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI En el siguiente tutorial se describe cómo aplicar parches a un entorno de servidor mediante una base de referencia de parches predeterminada, grupos de parches y un periodo de mantenimiento. **Antes de empezar** + Instalar o actualizar SSM Agent en los nodos administrados. Para aplicar revisiones a los nodos administrados de Linux, los nodos deben ejecutar la versión de SSM Agent 2.0.834.0 o posterior. Para obtener más información, consulte [Actualización de SSM Agent mediante Run Command](run-command-tutorial-update-software.md#rc-console-agentexample). + Configure roles y permisos para Maintenance Windows, una herramienta de AWS Systems Manager. Para obtener más información, consulte [Configuración de Maintenance Windows](setting-up-maintenance-windows.md). + Si aún no lo ha hecho, instale y configure la AWS Command Line Interface (AWS CLI). Para obtener más información, consulte [Instalación o actualización de la última versión de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Para configurar Patch Manager y aplicar revisiones a los nodos administrados (línea de comandos)** 1. Ejecute el siguiente comando para crear una base de referencia de revisiones para Windows denominada `Production-Baseline`. Esta línea de base de revisiones aprueba las revisiones para un entorno de producción siete días después de su lanzamiento. Es decir, se ha etiquetado la base de referencia de parches para indicar que es para un entorno de producción. **nota** El parámetro `OperatingSystem` y `PatchFilters` varían en función del sistema operativo de los nodos administrados de destino a los que se aplica la base de referencia de revisiones. Para obtener más información, consulte [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) y [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" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. Ejecute los siguientes comandos para registrar la base de referencia de parches "Production-Baseline" para dos grupos de parches. Los grupos se denominan "Database Servers" (Servidores de base de datos) y "Front-End Servers" (Servidores 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" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "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" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "PatchGroup":"Front-End Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. Ejecute los siguientes comandos para crear dos períodos de mantenimiento para los servidores de producción. El primer periodo se ejecuta cada martes a las 22:00 h. El segundo período se ejecuta cada sábado a las 22:00. Además, el periodo de mantenimiento está etiquetado para indicar que es para un entorno de producción. ------ #### [ 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 ``` ------ El sistema devuelve información similar a la siguiente. ``` { "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 ``` ------ El sistema devuelve información similar a la siguiente. ``` { "WindowId":"mw-9a8b7c6d5eEXAMPLE" } ``` 1. Ejecute los siguientes comandos para registrar los grupos de parches de servidores `Database` y `Front-End` con sus respectivos periodos de mantenimiento. ------ #### [ 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" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "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" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE" } ``` 1. Ejecute los siguientes comandos para registrar una tarea de aplicación de parches que instale las actualizaciones que faltan en los servidores `Database` y `Front-End` durante sus respectivos periodos de mantenimiento. ------ #### [ 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}}" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "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}}" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE" } ``` 1. Ejecute el siguiente comando para obtener el resumen de conformidad de parches de alto nivel de un grupo de parches. El resumen de conformidad de revisiones de alto nivel incluye el número de nodos administrados con revisiones en los respectivos estados de revisiones. **nota** Lo normal es que vea ceros para el número de nodos administrados en el resumen hasta que se ejecute la tarea de revisiones durante el primer periodo de mantenimiento. ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-group-state \ --patch-group "Database Servers" ``` ------ #### [ Windows Server ] ``` aws ssm describe-patch-group-state ^ --patch-group "Database Servers" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "Instances": number, "InstancesWithFailedPatches": number, "InstancesWithInstalledOtherPatches": number, "InstancesWithInstalledPatches": number, "InstancesWithInstalledPendingRebootPatches": number, "InstancesWithInstalledRejectedPatches": number, "InstancesWithMissingPatches": number, "InstancesWithNotApplicablePatches": number, "InstancesWithUnreportedNotApplicablePatches": number } ``` 1. Ejecute el siguiente comando para obtener los estados del resumen de revisiones por nodo administrado para un grupo de revisiones. El resumen por nodo administrado incluye un número de revisiones en los respectivos estados de revisiones por nodo administrado para un grupo de revisiones. ------ #### [ 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" ``` ------ El sistema devuelve información similar a la siguiente. ``` { "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 } ] } ``` Para ver un ejemplo de otros comandos de la AWS CLI que podría utilizar para sus tareas de configuración de Patch Manager, consulte [Trabajar con recursos Patch Manager mediante la AWS CLI](patch-manager-cli-commands.md).