• O AWS Systems Manager CloudWatch Dashboard não estará mais disponível a partir de 30 de abril de 2026. Os clientes podem continuar usando o console do Amazon CloudWatch para visualizar, criar e gerenciar os painéis do Amazon CloudWatch exatamente como fazem hoje. Para obter mais informações, consulte a [documentação do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). # Tutoriais do AWS Systems Manager Patch Manager Os tutoriais desta seção demonstram como usar o Patch Manager, uma ferramenta do AWS Systems Manager, para vários cenários de aplicação de patches. **Topics** + [Tutorial: corrigindo um servidor em um ambiente somente IPv6](patch-manager-server-patching-iPv6-tutorial.md) + [Tutorial: Criar uma lista de referência de patches para instalar o Windows Service Packs usando o console](patch-manager-windows-service-pack-patch-baseline-tutorial.md) + [Tutorial: Atualizar dependências de aplicações, corrigir um nó gerenciado e executar uma verificação de integridade específica da aplicação usando o console](aws-runpatchbaselinewithhooks-tutorial.md) + [Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md) # Tutorial: corrigindo um servidor em um ambiente somente IPv6 O Patch Manager suporta a correção de nós em ambientes somente IPv6. Ao atualizar a configuração do SSM Agent, as operações de correção podem ser configuradas para fazer chamadas somente para endpoints de serviço IPv6. **Corrigir um servidor em um ambiente somente IPv6** 1. Certifique-se de que o SSM Agent versão 3.3270.0 ou posterior esteja instalado em seu nó gerenciado. 1. No nó gerenciado, navegue até o arquivo de configuração do SSM Agent. É possível encontrar o arquivo `amazon-ssm-agent.json` nos seguintes diretórios: + Linux: `/etc/amazon/ssm/` + macOS: `/opt/aws/ssm/` + Windows Server: `C:\Program Files\Amazon\SSM` Se `amazon-ssm-agent.json` ainda não existir, copie o conteúdo de `amazon-ssm-agent.json.template` no mesmo diretório para `amazon-ssm-agent.json`. 1. Atualize a entrada a seguir para definir a região correta e definir `UseDualStackEndpoint` como`true`: ``` { -------- "Agent": { "Region": "region", "UseDualStackEndpoint": true }, -------- } ``` 1. Reinicie o serviço do SSM Agent usando o comando apropriado para seu sistema operacional: + Linux: `sudo systemctl restart amazon-ssm-agent` + Ubuntu Server usando Snap: `sudo snap restart amazon-ssm-agent` + macOS: `sudo launchctl stop com.amazon.aws.ssm` seguido por `sudo launchctl start com.amazon.aws.ssm` + Windows Server: `Stop-Service AmazonSSMAgent` seguido por `Start-Service AmazonSSMAgent` Para obter a lista completa de comandos de cada sistema operacional, consulte [Verificar o status do SSM Agent e iniciar o agente](ssm-agent-status-and-restart.md). 1. Execute qualquer operação de correção para verificar se as operações de correção são bem-sucedidas em seu ambiente somente IPv6. Certifique-se de que os nós que estão sendo corrigidos tenham conectividade com a fonte do patch. Você pode verificar a saída Run Command da execução do patch para verificar se há avisos sobre repositórios inacessíveis. Ao corrigir um nó que está sendo executado em um ambiente somente IPv6, certifique-se de que o nó tenha conectividade com a origem do patch. Você pode verificar a saída Run Command da execução do patch para verificar se há avisos sobre repositórios inacessíveis. Para sistemas operacionais baseados em DNF, é possível configurar para que repositórios indisponíveis sejam ignorados durante a aplicação de patches se a opção `skip_if_unavailable` estiver definida como `True` em `/etc/dnf/dnf.conf`. Os sistemas operacionais baseados em DNF incluem Amazon Linux 2023, Red Hat Enterprise Linux 8 e versões posteriores, Oracle Linux 8 e versões posteriores, Rocky Linux, AlmaLinux e CentOS 8 e versões posteriores. No Amazon Linux 2023, a opção `skip_if_unavailable` é definida como `True` por padrão. **nota** Ao usar os atributos Install Override List ou Baseline Override, certifique-se de que o URL fornecido esteja acessível a partir do nó. Se a opção de configuração `UseDualStackEndpoint` do SSM Agent estiver definida como `true`, um cliente S3 de dualstack será usado quando uma URL S3 for fornecida. # Tutorial: Criar uma lista de referência de patches para instalar o Windows Service Packs usando o console Ao criar uma lista de referência de patches personalizada, é possível especificar que todos, alguns ou apenas um tipo de patch compatível está instalado. Nas listas de referência de patches do Windows, é possível selecionar `ServicePacks` como a única opção **Classificação** para limitar atualizações de patch somente para Service Packs. Os Service Packs podem ser instalados automaticamente pelo Patch Manager, uma ferramenta do AWS Systems Manager, desde que a atualização esteja disponível no Windows Update ou no Windows Server Update Services (WSUS). É possível configurar uma lista de referência de patches para controlar se os Service Packs de todas as versões do Windows estão instalados ou apenas aqueles de versões específicas, como o Windows 7 ou Windows Server 2016. Use o procedimento a seguir para criar uma lista de referência de patches personalizada a ser usada exclusivamente para instalar todos os Service Packs em seus nós gerenciados do Windows. **Para criar uma lista de referência de patches para instalar o Windows Service Packs (console)** 1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. No painel de navegação, escolha **Patch Manager**. 1. Escolha a guia **Listas de referência de patches** e, em seguida, escolha **Criar lista de referência de patches**. 1. Em **Nome**, insira um nome para a nova lista de referência de patches, como `MyWindowsServicePackPatchBaseline`. 1. (Opcional) Em **Description (Descrição)**, insira uma descrição para essa linha de base de patch. 1. Em **Operating system (Sistema operacional)**, escolha `Windows`. 1. Se você deseja começar a usar essa linha de base de patch como o padrão para o Windows assim que a criar, selecione **Set this patch baseline as the default patch baseline for Windows Server instances (Definir essa linha de base de patch como a linha de base de patch padrão para instâncias do Windows Server)**. **nota** Essa opção está disponível somente se você acessou pela primeira vez Patch Manager antes do lançamento [das políticas de patch](patch-manager-policies.md) em 22 de dezembro de 2022. Para obter informações sobre como definir uma linha de base de patch existente como padrão, consulte [Definir uma linha de base de patches existente como padrão](patch-manager-default-patch-baseline.md). 1. Na seção **Approval rules for operating systems (Regras de aprovação para sistemas operacionais)**, use os campos para criar uma ou mais regras de aprovação automática. + **Produtos**: as versões do sistema operacional às quais a regra de aprovação se aplica, como `WindowsServer2012`. É possível escolher uma, mais de uma ou todas as versões compatíveis do Windows. A seleção padrão é `All`. + **Classificação**: escolha `ServicePacks`. + **Gravidade**: o valor da gravidade dos patches aos quais a regra se aplica. Para garantir que todos os Service Packs estejam incluídos pela regra, escolha `All`. + **Auto-approval (Aprovação automática)**: o método para selecionar patches para aprovação automática. + **Approve patches after a specified number of days** (Aprovar patches após um número específico de dias): o número de dias que o Patch Manager deve aguardar para aprovar automaticamente um patch após o lançamento ou atualização de um patch. Insira qualquer número inteiro de zero (0) a 360. Para a maioria dos casos, recomendamos que não aguarde mais de 100 dias. + **Approve patches released up to a specific date** (Aprovar patches lançados até uma data específica): a data de lançamento do patch para a qual o Patch Manager aplica automaticamente todos os patches lançados ou com a última atualização nessa data ou antes dela. Por exemplo, se você especificar 7 de julho de 2023, nenhum patch lançado ou com última atualização em ou após 8 de julho de 2023 será instalado automaticamente. + (Opcional) **Relatórios de conformidade**: o nível de gravidade que você deseja atribuir aos Service Packs aprovados pela lista de referência, como `High`. **nota** Se você especificar um nível de relatório de conformidade e o estado do patch de qualquer pacote de serviço aprovado for relatado como `Missing`, a gravidade geral da conformidade relatada pela lista de referência de patches será o nível de gravidade especificado. 1. (Opcional) Em **Manage tags (Gerenciar tags)**, aplique um ou mais pares de nome/valor de chave de tag à linha de base de patch. Tags são metadados opcionais que você atribui a um recurso. As tags permitem categorizar um recurso de diferentes formas, como por finalidade, proprietário ou ambiente. Para esta lista de referência de patches dedicada à atualização de Service Packs, é possível especificar pares de chave/valor como o seguinte: + `Key=OS,Value=Windows` + `Key=Classification,Value=ServicePacks` 1. Escolha **Create patch baseline**. # Tutorial: Atualizar dependências de aplicações, corrigir um nó gerenciado e executar uma verificação de integridade específica da aplicação usando o console Em muitos casos, um nó gerenciado deve ser reinicializado depois de ter sido corrigido com a atualização de software mais recente. No entanto, a reinicialização de um nó gerenciado em produção sem proteções implementadas pode causar vários problemas, como invocação de alarmes, registro incorreto de dados de métrica e interrupção de sincronizações de dados. Esse tutorial demonstra como evitar problemas como esses usando o documento do AWS Systems Manager (documento do SSM) `AWS-RunPatchBaselineWithHooks` para obter uma operação de aplicação de patches complexa e de várias etapas que realize o seguinte: 1. Impedir novas conexões com a aplicação 1. Instale as atualizações para o sistema operacional. 1. Atualizar as dependências do pacote da aplicação 1. Reinicie o daemon (). 1. Executar uma verificação de integridade específica da aplicação Para este exemplo, configuramos nossa infraestrutura desta forma: + As máquinas virtuais de destino são registradas como nós gerenciados com o Systems Manager. + `Iptables` é usado como um firewall local. + A aplicação hospedada em seus nós gerenciados está sendo executada na porta 443. + A aplicação hospedada em seus nós gerenciados é uma aplicação `nodeJS`. + A aplicação hospedada em seus nós gerenciados pelo gerenciador de processos pm2. + A aplicação já possui um endpoint de verificação de integridade especificado. + O endpoint da verificação de integridade da aplicação não requer autenticação do usuário final. O endpoint permite uma verificação de integridade que atenda aos requisitos da organização para estabelecer a disponibilidade. (Em seus ambientes, pode ser suficiente simplesmente verificar se a aplicação `nodeJS` está em execução e é capaz de receber solicitações. Em outros casos, também é possível verificar se uma conexão com a camada de armazenamento em cache ou com a camada de banco de dados já foi estabelecida.) Os exemplos deste tutorial são apenas para fins de demonstração e não devem ser implementados inalterados em ambientes de produção. Além disso, tenha em mente que o recurso de ganchos de ciclo de vida do Patch Manager, uma ferramenta do Systems Manager, com o documento `AWS-RunPatchBaselineWithHooks` pode oferecer suporte a vários outros cenários. Aqui estão alguns exemplos: + Interrompa um agente de relatório de métricas antes de aplicar patches e reiniciá-lo após a reinicialização do nó gerenciado. + Desconecte o nó gerenciado de um cluster CRM ou PCS antes de aplicar patches e reconecte após a reinicialização do nó. + Atualize software de terceiros (por exemplo, aplicações Java, Tomcat, Adobe e outras) em máquinas do Windows Server depois que as atualizações do sistema operacional (SO) forem aplicadas, mas antes da reinicialização do nó gerenciado. **Para atualizar dependências de aplicações, corrigir um nó gerenciado e executar uma verificação de integridade específica da aplicação** 1. Crie um documento do SSM para o script de pré-instalação com o conteúdo a seguir e nomeie-o como `NodeJSAppPrePatch`. Substituir *your\$1application* pelo nome da sua aplicação. Este script bloqueia imediatamente novas solicitações de entrada e fornece cinco segundos para que as já ativas sejam concluídas antes de iniciar a operação de patch. Para a opção `sleep`, especifique um número de segundos maior do que normalmente leva para que as solicitações recebidas sejam concluídas. ``` # 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 obter informações sobre como criar um documento do SSM, consulte [Criar conteúdo de documento do SSM](documents-creating-content.md). 1. Crie outro documento SSM com o conteúdo a seguir para o script após a instalação, para atualizar as dependências da aplicação e dê a ele o nome `NodeJSAppPostPatch`. Substituir */your/application/path* pelo caminho para a sua aplicação. ``` cd /your/application/path npm update # you can use npm-check-updates if you want to upgrade major versions ``` 1. Crie outro documento SSM com o seguinte conteúdo para o scipt do `onExit` para fazer backup da aplicação e executar uma verificação de integridade. Nomeie este documento do SSM `NodeJSAppOnExitPatch`. Substituir *your\$1application* pelo nome da sua aplicação. ``` # 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. Criar uma associação no State Manager, uma ferramenta do AWS Systems Manager para emitir a operação executando as seguintes etapas: 1. Abra o console AWS Systems Manager em [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. No painel de navegação, escolha **State Manager** e selecione **Create association**. 1. Para **Name** (Nome), forneça um nome para ajudar a identificar a finalidade da associação. 1. Na lista **Document (Documento)**, escolha `AWS-RunPatchBaselineWithHooks`. 1. Em **Action** (Ação), selecione **Install** (Instalar). 1. (Opcional) Em **Snapshot Id** (ID do snapshot), forneça um GUID que você gera para ajudar a acelerar a operação e garantir a consistência. O valor GUID pode ser tão simples quanto `00000000-0000-0000-0000-111122223333`. 1. Para **Pre Install Hook Doc Name** (Nome do Doc do Hook antes da instalação), insira `NodeJSAppPrePatch`. 1. Para **Post Install Hook Doc Name** (Nome do Doc do Hook após instalação), insira `NodeJSAppPostPatch`. 1. Para **On ExitHook Doc Name** (No nome do documento ExitHook), insira `NodeJSAppOnExitPatch`. 1. Para **Targets** (Destinos), identifique os nós gerenciados especificando etiquetas, escolhendo os nós manualmente, escolhendo um grupo de recursos ou escolhendo todos os nós gerenciados. 1. Para **Specify schedule** (Especificar programação), especifique a frequência com que a associação deve ser executada. Por exemplo, a aplicação de patches em nós gerenciados uma vez por semana é uma cadência comum. 1. Na seção **Rate control** (Controle de taxa), escolha opções para controlar como a associação é executada em vários nós gerenciados. Verifique se apenas uma parte dos nós gerenciados é atualizada de cada vez. Caso contrário, toda ou a maior parte da sua frota poderá ficar offline de uma só vez. Para obter mais informações sobre como usar controles de taxa, consulte [Sobre destinos e controles de taxa em associações do State Manager](systems-manager-state-manager-targets-and-rate-controls.md). 1. (Opcional) Em **Opções de saída**, para salvar a saída de comando em um arquivo, selecione a caixa **Habilitar a gravação da saída no S3**. Digite os nomes de bucket e prefixo (pastas) nas caixas de texto. **nota** As permissões do S3 que concedem a possibilidade de gravar os dados em um bucket do S3 são as do perfil da instância atribuído ao nó gerenciado, e não as do usuário do IAM que realiza essa tarefa. Para obter mais informações, consulte [Configurar permissões de instância obrigatórias para o Systems Manager](setup-instance-permissions.md) ou [Criar um perfil de serviço do IAM para um ambiente híbrido](hybrid-multicloud-service-role.md). Além disso, se o bucket do S3 especificado estiver em uma conta da Conta da AWS diferente, verifique se o perfil da instância ou a função de serviço IAM associada ao nó gerenciado tenha as permissões necessárias para gravar nesse bucket. 1. Escolha **Create Association (Criar associação)**. # Tutorial: Aplicar patches a um ambiente de servidor usando a AWS CLI O procedimento a seguir descreve como aplicar patch a um ambiente de servidor usando uma linha de base de patch personalizada, grupos de patches e uma janela de manutenção. **Antes de começar** + Instale ou atualize o SSM Agent em seus nós gerenciados. Para aplicar patches a nós gerenciados do Linux, os nós devem estar em execução no SSM Agent versão 2.0.834.0 ou posterior. Para obter mais informações, consulte [Atualização do SSM Agent por meio de Run Command](run-command-tutorial-update-software.md#rc-console-agentexample). + Configure as funções e permissões para a Maintenance Windows, uma ferramenta do AWS Systems Manager. Para obter mais informações, consulte [Configurar o Maintenance Windows](setting-up-maintenance-windows.md). + Instale e configure a AWS Command Line Interface (AWS CLI), caso ainda não o tenha feito. Para obter informações, consulte [Instalar ou atualizar a versão mais recente da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **Para configurar o Patch Manager e aplicar patches aos nós gerenciados (linha de comando)** 1. Execute o comando a seguir para criar uma lista de referência de patches para o Windows chamada `Production-Baseline`. Essa lista de referência de patches aprova patches para um ambiente de produção sete dias após o lançamento ou última atualização. Ou seja, marcamos a lista de referência de patches para indicar que é para um ambiente de produção. **nota** O parâmetro `OperatingSystem` e `PatchFilters` varia dependendo do sistema operacional dos nós gerenciados aos quais a lista de referência de patches se aplica. Para obter mais informações, consulte [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" ``` ------ O sistema retorna informações como estas. ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. Execute os comandos a seguir para registrar a linha de base de patch "Production-Baseline" para dois grupos de patches. Os grupos são chamados de "Database Servers" (Servidores de banco de dados) e "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" ``` ------ O sistema retorna informações como estas. ``` { "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" ``` ------ O sistema retorna informações como estas. ``` { "PatchGroup":"Front-End Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. Execute os comandos a seguir para criar duas janelas de manutenção para os servidores de produção. A primeira janela é executada todas as terças-feiras às 22 horas. A segunda janela é executada todos os sábados às 22 horas. Além disso, a janela de manutenção é marcada para indicar que é para um ambiente de produção. ------ #### [ 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 ``` ------ O sistema retorna informações como estas. ``` { "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 ``` ------ O sistema retorna informações como estas. ``` { "WindowId":"mw-9a8b7c6d5eEXAMPLE" } ``` 1. Execute os comandos a seguir para registrar os grupos de patches de servidores `Database` e `Front-End` com suas respectivas janelas de manutenção. ------ #### [ 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" ``` ------ O sistema retorna informações como estas. ``` { "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" ``` ------ O sistema retorna informações como estas. ``` { "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE" } ``` 1. Execute os comandos a seguir para registrar uma tarefa de patch que instala atualizações ausentes nos servidores `Database` e `Front-End` durante suas respectivas janelas de manutenção. ------ #### [ 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}}" ``` ------ O sistema retorna informações como estas. ``` { "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}}" ``` ------ O sistema retorna informações como estas. ``` { "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE" } ``` 1. Execute o seguinte comando para obter o resumo de conformidade de patch de alto nível para um grupo de patches. O resumo de conformidade de patches de alto nível inclui o número de nós gerenciados com patches nos respectivos estados do patch. **nota** Durante a primeira janela de manutenção é normal que zeros apareçam como o número de nós gerenciados no resumo, até que a tarefa de aplicação do patch seja executada. ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-group-state \ --patch-group "Database Servers" ``` ------ #### [ Windows Server ] ``` aws ssm describe-patch-group-state ^ --patch-group "Database Servers" ``` ------ O sistema retorna informações como estas. ``` { "Instances": number, "InstancesWithFailedPatches": number, "InstancesWithInstalledOtherPatches": number, "InstancesWithInstalledPatches": number, "InstancesWithInstalledPendingRebootPatches": number, "InstancesWithInstalledRejectedPatches": number, "InstancesWithMissingPatches": number, "InstancesWithNotApplicablePatches": number, "InstancesWithUnreportedNotApplicablePatches": number } ``` 1. Execute o seguinte comando para obter os estados de resumo de patches por nó gerenciado para um grupo de patches. O resumo por nó gerenciado inclui vários patches nos respectivos estados de patch por instância para um grupo de patches. ------ #### [ 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" ``` ------ O sistema retorna informações como estas. ``` { "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 obter exemplos de outros comandos da AWS CLI que você pode usar nas tarefas de configuração do Patch Manager, consulte [Trabalhar com recursos do Patch Manager usando a AWS CLI](patch-manager-cli-commands.md).