Crie jobs de patch

Você pode usar o Patch para aplicar patches do sistema operacional em um grupo de instâncias de máquina virtual (VM).

Para aplicar patches às VMs, siga estas etapas:

  1. Configure a VM.
  2. Execute um job de patch.

Antes de começar

  • Revise as cotas de configuração do SO.
  • Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud. Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine selecionando uma das seguintes opções:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.

Limitações

  • É possível implantar e executar jobs de patch apenas para VMs em um único projeto do Google Cloud. Não é possível executar jobs de patch em projetos do Google Cloud, se as VMs estiverem em uma VPC compartilhada. No entanto, é possível conferir a conformidade do patch dados entre projetos.
  • Por padrão, o VM Manager não aplica patches em VMs que fazem parte de um grupo gerenciado de instâncias (MIG). O patch dessas VMs é informado como falhas no job de patch. É possível substituir esse comportamento padrão ao criar o job de patch. As limitações a seguir se aplicam ao patch de VMs que fazem parte de um MIG:
    • Quando um MIG corrige uma VM, ele a recria com base no modelo da instância. Isso pode reverter a VM para um estado sem patch.
    • A aplicação de patches em VMs pode causar resultados inesperados em um MIG com o escalonamento automático ativado. O escalonador automático exclui VMs com patches quando o carregamento diminui e cria novas VMs, sem nenhum patch, usando o modelo de instância do MIG quando a carga aumenta. Por exemplo, se a utilização média da CPU for menor que a de destino especificada para escalonamento automático, o MIG pode remover algumas das VMs com patch durante o escalonamento.

Sistemas operacionais compatíveis

Para ver a lista completa de sistemas operacionais e versões compatíveis com patches, consulte Detalhes do sistema operacional.

Configure a VM.

Para usar o recurso Patch, siga estas etapas:

  1. Para todas as VMs, configure o VM Manager.
  2. Para VMs do Windows, o Google recomenda desativar as atualizações automáticas nelas. Isso reduz os conflitos entre as atualizações automáticas do Windows e o serviço Patch.

Permissões

Os proprietários de um projeto do Cloud têm acesso total para executar e gerenciar jobs de patch. Para todos os outros usuários, você precisa conceder permissões. É possível conceder um dos seguintes papéis granulares:

  • roles/osconfig.patchJobExecutor contém permissões para executar, cancelar, receber e listar jobs de patch. Ele também contém permissões para visualizar detalhes da instância de um job de patch.
  • roles/osconfig.patchJobViewer contém permissões para acesso somente leitura para receber e listar jobs de patch. Ele também contém permissões para visualizar detalhes da instância de um job de patch.

Por exemplo, para conceder acesso ao usuário para executar jobs de patch, use o seguinte comando:

gcloud projects add-iam-policy-binding project-id \
    --member user:user-id@gmail.com \
    --role roles/osconfig.patchJobExecutor

Substitua:

  • project-id: o ID do projeto.
  • user-id: o nome de usuário do Google Workspace.

Executar jobs de patch

É possível executar um job de patch usando o console do Google Cloud, a CLI do Google Cloud ou a REST.

Quando você executar um job de patch, a aplicação de patches das VMs será iniciada simultaneamente em todas as instâncias especificadas pelo filtro de instância.

Depois de iniciar um job de patch, é possível monitorar seus patches usando o painel de patches. Depois que um job de patch é iniciado, leva cerca de 30 minutos para que os dados sejam preenchidos no painel.

Console

  1. No console do Google Cloud, acesse a página Compute Engine > VM Manager > Patch.

    Acesse a página "Patch"

  2. Clique em Nova implantação de patch.

  3. Na seção VMs de destino, selecione a zona que contém as VMs que você quer corrigir. Se preferir, selecione todas as zonas.

    Depois de fazer a seleção, é possível filtrar ainda mais as VMs dentro das zonas escolhidas.

    Por exemplo, para corrigir VMs específicas nas zonas selecionadas, insira os filtros de nome e rótulo semelhantes aos seguintes:

    • Prefixo de nome: test-
    • Rótulos: env=dev e app=web

  4. Na seção Configuração do patch, configure o patch.

    1. Especifique um Nome para seu patch.
    2. Selecione as atualizações necessárias para o sistema operacional. Para mais informações, consulte Configuração de patch.

  5. Na seção Programação, faça isto:

  6. Na seção Opções de lançamento, configure as opções de lançamento do patch:

    • Selecione se quer corrigir uma zona por vez ou várias zonas simultaneamente.
    • Defina um orçamento de interrupção. Um orçamento de interrupção é o número ou a porcentagem de VMs em uma zona que você quer que seja interrompida de uma só vez pelo processo de aplicação de patches.

  7. Opcional: na seção Opções avançadas, é possível concluir as seguintes tarefas:

  8. Clique em Implantar.

gcloud

Use o comando os-config patch-jobs execute para executar um job de patch. Substitua instance-filter pelo filtro de instância que você quer. Para mais informações sobre filtros de instância, consulte filtros de instância.

gcloud compute os-config patch-jobs execute instance-filter

Para mais informações sobre quais atualizações são aplicadas, consulte o que está incluído em um job de patch do SO. Para personalizar suas atualizações, use as sinalizações opcionais.

Exemplos

Exemplo 1: executar um job de patch com as seguintes configurações:

  • Nome da instância: instance-1
  • Zona: us-east1-b

  • Descrição: patch for instance-1

    Você executaria o seguinte comando:

gcloud compute os-config patch-jobs execute \
    --instance-filter-names="zones/us-east1-b/instances/instance-1" \
    --description "patch for instance-1"

Exemplo 2: suponha que você queira executar um job de patch de forma assíncrona com as seguintes configurações:

  • O patch precisa ser executado em todas as instâncias do projeto.
  • O job de patch precisa atingir o tempo limite e parar após 1 hora e 30 minutos.
  • As máquinas precisam ser reinicializadas com base nas configurações do sistema após a instalação das atualizações.
  • Em VMs que executam o Apt, a aplicação de patch é feita usando apt dist-upgrade.
  • Em VMs que executam o Windows, aplique somente os patches para a atualização KB4339284.
  • Em VMs que executam o Yum, a aplicação de patch é feita com o utilitário yum update-minimal --security.

Você executaria o seguinte comando:

gcloud compute os-config patch-jobs execute \
    --instance-filter-all \
    --duration="1h30m" --reboot-config="DEFAULT" \
    --apt-dist --windows-exclusive-patches=4339284 \
    --yum-minimal --yum-security \
    --async

REST

Na API, crie uma solicitação POST para executar um novo job de patch. Você precisa definir explicitamente todos os campos de configuração obrigatórios, conforme descrito na documentação da API patchJobs.execute.

Para mais informações sobre quais atualizações são aplicadas, consulte o que está incluído em um job de patch do SO. Para personalizar suas atualizações, use os parâmetros PatchConfig.

Por exemplo, um job de patch com apenas os campos obrigatórios tem a seguinte aparência:

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter": instance-filter
}

Substitua:

  • project-id: o ID do projeto
  • instance-filter: os parâmetros de filtro que você quer Para mais informações sobre filtros de instância, consulte filtros de instância.

Exemplos

Exemplo 1: suponha que você queira executar um job de patch em uma instância chamada instance1 localizada em us-east1-b. Neste exemplo, uma descrição foi adicionada e foi especificado que o job é executado por 1 hora e 30 minutos. Substitua project-id pelo ID do projeto.

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "description":"patch instance1 in us-east1-b",
  "duration":"5400s",
  "instanceFilter":{
    "instances":[
      "zones/us-east1-b/instances/instance1"
    ]
  }
}

Exemplo 2: o job de patch a seguir seleciona VMs com as seguintes configurações:

  • Ter os rótulos env=dev e app=web.
  • Estar em asia-east1-b ou asia-east1-c.
  • Ter o prefixo test-.

No seguinte comando, substitua project-id pelo ID do projeto:

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter":{
    "groupLabels":[
      {
        "labels":{
          "env":"dev",
          "app":"web"
        }
      }
    ],
    "instanceNamePrefixes":[
      "test-"
    ],
    "zones":[
      "asia-east1-b",
      "asia-east1-c"
    ]
  }
}

Exemplo 3:

Suponha que você queira executar um job de patch com as seguintes configurações:

  • O patch precisa ser executado em todas as instâncias do projeto.
  • O job de patch precisa atingir o tempo limite e parar após 1 hora e 30 minutos. A API exige que o tempo seja expresso em segundos, portanto, defina como 5.400 segundos.
  • As máquinas precisam ser reinicializadas com base nas configurações do sistema após a instalação das atualizações.
  • Em VMs que executam o Apt, a aplicação de patch é feita usando apt dist-upgrade.
  • Em VMs que executam o Windows, aplique somente os patches para a atualização KB4339284.
  • Em VMs que executam o Yum, a aplicação de patch é feita com o utilitário yum update-minimal --security.

Você criaria a seguinte solicitação:

No seguinte comando, substitua project-id pelo ID do projeto:

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
 "duration":"5400s",
 "instanceFilter":{
   "all":true
 },
 "patchConfig":{
   "rebootConfig":"DEFAULT",
   "apt":{
     "type":"DIST"
   },
   "yum":{
     "security":true,
     "minimal":true
   },
   "windowsUpdate":{
     "exclusivePatches":"4339284"
   }
 }
}

Filtros de instância

É possível especificar as instâncias a serem incluídas em um job de patch usando filtros. Os seguintes filtros são compatíveis com jobs de patch:

  • Filtrar por nome: limita o job de patch a instâncias com nomes específicos. Os nomes das instâncias precisam ser especificados usando o URI completo. Os formatos de URI compatíveis incluem os seguintes:

    • zones/zone/instances/instance-name
    • projects/project-id/zones/zone/instances/instance-name
    • https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/instance-name

  • Filtrar por prefixo de nome: limita o job de patch a instâncias com um prefixo específico no nome.

  • Filtrar por zona: limita o job de patch a instâncias em uma zona específica.

  • Filtrar por rótulo: limita o job de patch a instâncias com rótulos específicos.

Também é possível executar jobs de patch em todas as instâncias em um projeto do Cloud definindo o campo all em instanceFilter como true. Para mais informações, consulte exemplos de filtros de instância.

Exemplos de filtros de instância

Cenário Filtro gcloud Filtro API
Todas as instâncias em um projeto do Google Cloud 
--instance-filter-all

{
  "instanceFilter":{
    "all":"true"
  }
}
Uma instância com o nome instance1 localizada na zona us-east1-b. 
--instance-filter-names="zones/us-east1-b/instances/instance1"

{
  "instanceFilter":{
    "instances":[
      "zones/us-east1-b/instances/instance1"
    ]
  }
}
Instâncias com o prefixo app- 
--instance-filter-name-prefixes="app-"
 
{
  "instanceFilter":{
    "instanceNamePrefixes":[
      "app-"
    ]
  }
}
Instâncias nas zonas us-east1-b ou us-east1-c 
--instance-filter-zones="us-east1-b","us-east1-c"
 
{
  "instanceFilter":{
    "zones":[
      "us-east1-b",
      "us-east1-c"
    ]
  }
}
Instâncias com o rótulo de combinação de env=dev e app=web, bem como instâncias com env=dev e app=worker. 
--instance-filter-group-labels="env=dev,app=web"
--instance-filter-group-labels="env=dev,app=worker"

{
  "instanceFilter":{
    "groupLabels":[
      {
        "labels":{
          "env":"dev",
          "app":"web"
        }
      },
      {
        "labels":{
          "env":"dev",
          "app":"worker"
        }
      }
    ]
  }
}

Como combinar de filtros de instância

Os filtros de instância também podem ser combinados. Por exemplo, para executar um job de patch para instâncias que tenham o prefixo test-, localizadas na zona us-east1-c e que tenham os rótulos env=dev e app=web, execute o seguinte comando:

gcloud compute os-config patch-jobs execute \
    --instance-filter-name-prefixes="test-" \
    --instance-filter-zones="us-east1-c" \
    --instance-filter-group-labels="env=prod,app=web"

Configuração de patch

Ao executar um job de patch, é possível especificar parâmetros para controlar os patches aplicados à VM. Os parâmetros de configuração do patch dependem da plataforma e geralmente são transmitidos para as ferramentas de atualização do sistema subjacentes. Os patches reais são provenientes dos repositórios de pacotes (Linux) ou do servidor Windows Update (Windows) configurado na VM.

É possível especificar as seguintes configurações de patch para suas VMs:

  • No Windows, especifique a classificação dos patches a serem aplicados (por exemplo, Security e Critical) ou segmentar KBs específicos a serem excluídos. Para mais informações sobre a classificação de patches, consulte a documentação de suporte da Microsoft.

  • Para o RHEL, o Rocky Linux e o CentOS, o sistema subjacente é yum.

    • Para patches que segmentam VMs do RHEL e do Rocky Linux, é possível especificar os pacotes security e minimal.
    • Para as VMs do CentOS, não há metadados security no repositório yum do CentOS. Portanto, não é necessário especificar a opção security ao atualizar os pacotes de segurança. Se você não especificar qualquer pacote, o job de patch atualiza todos os pacotes, incluindo aqueles com atualizações de segurança.
    • Também é possível excluir pacotes específicos. Para mais informações, consulte as páginas do manual yum.

  • Para o Debian e o Ubuntu, o sistema subjacente é apt. Para patches que visam essas VMs, é possível especificar dist-upgrade ou um upgrade padrão. Também é possível excluir pacotes específicos. Para mais informações, consulte as páginas do manual do Debian ou as páginas do manual do Ubuntu.

  • Para o SuSE, o sistema subjacente é zypper, especificamente usando patches zypper. Para patches que visam essas VMs, é possível especificar opções como:

    • with update: atualizar todos os pacotes não cobertos por patches
    • with optional: patches opcionais são tratados conforme necessário
    • As categorias ou gravidades dos patches a serem aplicadas

    Também é possível excluir patches específicos.

Opcionalmente, para todos os sistemas operacionais compatíveis, é possível optar por instalar patches aprovados apenas especificando essas atualizações. Isso permite que você insira uma lista de pacotes ou patches aprovados. Quando você seleciona esses patches aprovados, apenas os pacotes ou patches aprovados são instalados. Todos os outros parâmetros de configuração de patch são ignorados durante a atualização.

Exemplos

Console

  1. Siga as etapas descritas na guia do console para criar um job de patch ou uma implantação de patch.
  2. Na seção Configuração do patch, selecione os parâmetros do job de patch.
  3. Faça as configurações adicionais necessárias para o job ou a implantação do patch.
  4. Clique em Implantar.

gcloud

Por exemplo, para executar um job de patch em todas as instâncias na zona northamerica-northeast1-a com configurações de patch específicas para diferentes sistemas operacionais, execute o comando gcloud compute os-config patch-jobs execute:

gcloud compute os-config patch-jobs execute \
    --instance-filter-zones="northamerica-northeast1-a" \
    --apt-dist \
    --yum-security \
    --yum-minimal \
    --zypper-categories=security \
    --windows-classifications=critical,security \
    --reboot-config=default

Para saber mais sobre as opções compatíveis, execute o seguinte comando:

gcloud compute os-config patch-jobs execute --help

REST

Por exemplo, para executar um job de patch em todas as instâncias na zona northamerica-northeast1-a com configurações de patch específicas para diferentes sistemas operacionais, execute o seguinte comando:

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute
{
    "instanceFilter":{
        "zones":[
            "northamerica-northeast1-a"
        ]
    },
    "patchConfig":{
        "apt": {
            "type": "dist-upgrade"
        },
        "yum": {
            "security": true,
            "minimal": true
        },
        "zypper": {
            "categories": ["security"]
        },
        "windowsUpdate": {
            "classifications": ["CRITICAL", "SECURITY"]
        },
        "rebootConfig": "DEFAULT"
    }
}

Para saber mais sobre os parâmetros compatíveis, analise a documentação do PatchConfig API.

Janela de manutenção

Uma janela de manutenção consiste no tempo total de execução permitido de um job de patch. Os jobs de patch vão atingir o tempo limite se não forem concluídos dentro da janela de manutenção especificada.

Por exemplo, se você definir uma janela de manutenção de 60 minutes, nenhum novo job de patch será iniciado nos 60 minutos após o horário de início. Alguns processos, como download de um arquivo ou reinicialização, podem ocorrer fora dessa janela de manutenção. No entanto, nenhum novo job de patch será iniciado.

Opções de reinicialização

Ao executar um job de patch, é possível especificar as opções de reinicialização do patch. As seguintes opções estão disponíveis:

  • Padrão: o agente decide se uma reinicialização é necessária verificando sinais conhecidos em cada SO. Várias reinicializações podem ocorrer durante o patch e podem ocorrer antes da instalação dos patches.
  • Sempre: a máquina é reinicializada após a conclusão da atualização.
  • Nunca: a máquina não reinicia após a conclusão da atualização. Em alguns casos, isso pode significar que nem todos os patches são totalmente aplicados.

Scripts pré-patch e pós-patch

Ao executar um job de patch, é possível especificar scripts a serem executados como parte do processo de patch. Esses scripts são úteis para desempenhar tarefas como encerrar um aplicativo e realizar verificações de integridade.

  • Scripts pré-patch são executados antes de começar o patch. Caso seja necessário reinicializar o sistema antes de iniciar a aplicação do patch, o script pré-patch é executado antes da reinicialização.
  • Scripts pós-patch são executados depois da aplicação do patch. Caso seja necessário reinicializar o sistema como parte da aplicação do patch, o script pós-patch é executado depois da reinicialização.

Um job de patch é compatível com um script pré-patch e um pós-patch para Linux e para Windows. Os scripts do Linux e do Windows precisam ser fornecidos usando flags, parâmetros ou seções apropriadas, quando especificados pela CLI do Google Cloud, REST ou pelo console do Google Cloud, respectivamente. Os scripts do Linux são executados apenas nas VMs do Linux, e os scripts do Windows são executados somente nas VMs do Windows.

Esses arquivos de script podem ser armazenados na VM ou em um bucket do Cloud Storage com controle de versões. Se o objeto do Cloud Storage não for legível publicamente, verifique se a conta de serviço padrão do Compute Engine do projeto do Cloud tem as permissões do IAM necessárias para ler objetos do Cloud Storage. Para garantir que você tenha as permissões corretas, verifique as configurações de permissão no objeto do Cloud Storage.

Se você quiser usar um bucket do Cloud Storage para armazenar seus scripts, crie um bucket do Cloud Storage e faça upload dos scripts para o bucket.

Exemplos

Console

  1. Siga as etapas descritas na guia do console para criar um job de patch ou uma implantação de patch.
  2. Na seção Opções avançadas, para as seções de pré-patch e pós-patch, clique em Procurar. Uma página de objeto do Cloud Storage é exibida.
  3. Na página do objeto do Cloud Storage, selecione o bucket do Cloud Storage que contém o script e selecione o objeto ou arquivo do Cloud Storage.
  4. Faça as configurações adicionais necessárias para o job ou a implantação do patch.
  5. Clique em Implantar.

gcloud

Por exemplo, para executar um job de patch em todas as instâncias na zona northamerica-northeast1-a com script pré-patch e pós-patch para instâncias do Linux e do Windows, execute o seguinte comando:

gcloud compute os-config patch-jobs execute \
    --instance-filter-zones="northamerica-northeast1-a" \
    --async \
    --pre-patch-linux-executable="/tmp/pre_patch_script.sh" \
    --post-patch-linux-executable="gs://my-patch-scripts/linux/post_patch_script#1523477886880" \
    --pre-patch-windows-executable="C:\\Users\\user\\pre-patch-script.cmd" \
    --post-patch-windows-executable="gs://my-patch-scripts/windows/post_patch_script.ps1#135920493447"

Para mais informações sobre formatos de arquivo aceitáveis, execute o seguinte comando:

gcloud compute os-config patch-jobs execute --help

REST

Por exemplo, para executar um job de patch em todas as instâncias na zona northamerica-northeast1-a com script pré-patch e pós-patch para instâncias do Linux e do Windows, execute o seguinte comando:

POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter":{
    "zones":[
      "northamerica-northeast1-a"
    ]
  },
  "patchConfig":{
    "preStep":{
      "linuxExecStepConfig":{
        "localPath":"/tmp/pre_patch_script.sh"
      },
      "windowsExecStepConfig":{
        "interpreter":"SHELL",
        "localPath":"C:\\Users\\user\\pre-patch-script.cmd"
      }
    },
    "postStep":{
      "linuxExecStepConfig":{
        "gcsObject":{
          "bucket":"my-patch-scripts",
          "generationNumber":"1523477886880",
          "object":"linux/post_patch_script"
        }
      },
      "windowsExecStepConfig":{
        "gcsObject":{
          "bucket":"my-patch-scripts",
          "generationNumber":"135920493447",
          "object":"windows/post_patch_script.ps1"
        },
        "interpreter":"POWERSHELL"
      }
    }
  }
}

Para mais informações sobre formatos de arquivo aceitáveis, consulte a seção ExecStepConfig da documentação da API PatchConfig.

Opções de lançamento do patch

É possível escolher entre corrigir as VMs uma zona por vez (zona por zona) e corrigir todas as zonas de uma vez (zonas simultâneas).

Além de escolher o lançamento da zona, também é possível especificar um orçamento de interrupção de zona para as VMs.

Orçamento de interrupção da zona

Um orçamento de interrupção é o número máximo (ou porcentagem) de VMs por zona a ser interrompida em um determinado momento.

Quando uma VM é considerada interrompida?

Durante a aplicação de patches, uma VM é considerada interrompida a partir do momento em que o agente de configuração do SO é notificado para dar início ao processo até que as correções sejam concluídas. Esse tempo de interrupção inclui o tempo para concluir a reinicialização e todas as etapas pós-patch.

Uma VM também será contada como parte do orçamento de interrupção se atender a alguma das seguintes condições:

  • a operação de aplicação de patches falha durante o processo;
  • a operação de aplicação de patches falha ao executar etapas pré ou pós-patch;
  • a operação de aplicação de patches não responde com uma notificação de operação bem-sucedida antes do tempo limite.

Como funcionam os orçamentos de interrupção

Em relação aos lançamentos de zona por zona, se o orçamento de interrupção em uma zona for excedido, o job de patch será interrompido. Isso acontece porque seguir para a próxima zona exige a conclusão do processo de aplicações de patches na zona anterior.

Por exemplo, se o orçamento de interrupção tiver um valor de 10, e 8 VMs falharem nas correções na zona atual, o job de patch continuará a corrigir 2 VMs por vez até que o processo na zona seja concluído. Quando essa operação for bem-sucedida, a aplicação de patches começará com 10 VMs por vez na próxima zona. Se o processo falhar em 10 VMs na próxima zona, o job de patch será interrompido.

Exemplos

Console

  1. Siga as etapas descritas na guia do console para criar um job de patch ou uma implantação de patch.
  2. Na seção Opções de lançamento, configure as opções do lançamento:
    • Selecione se quer corrigir uma zona por vez ou todas as zonas simultaneamente.
    • Defina o orçamento de interrupção. Um orçamento de interrupção é o número ou a porcentagem de VMs em uma zona que você quer que seja interrompida de uma só vez pelo processo de aplicação de patches.
  3. Faça as configurações adicionais necessárias para o job ou a implantação do patch.
  4. Clique em Implantar.

gcloud

Exemplo 1

Este exemplo mostra o comando os-config patch-jobs execute para executar um job de patch com as seguintes especificações:

  • Correção de todas as VMs no projeto
  • Correção de VMs zona por zona
  • Garantia de que, no máximo, 10 VMs na mesma zona serão interrompidas em um determinado momento
gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=zone-by-zone \
   --rollout-disruption-budget=10

Exemplo 2

Este exemplo mostra o comando os-config patch-jobs execute para executar um job de patch com as seguintes especificações:

  • Correção de todas as VMs no projeto
  • Correção de zonas simultaneamente
  • Garantia de que, no máximo, 50% das VMs na mesma zona serão interrompidas em um determinado momento
gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=concurrent-zones \
   --rollout-disruption-budget-percent=50

REST

Este exemplo mostra o método patchJobs.execute para executar um job de patch com as seguintes especificações:

  • Correção de todas as VMs nas zonas us-central1-a, us-central1-c e us-central1-f
  • Correção de zonas simultaneamente
  • Garantia de que, no máximo, 25% das instâncias na mesma zona serão interrompidas em um determinado momento
POST https://osconfig.googleapis.com/v1/projects/project-id/patchJobs:execute

{
  "instanceFilter":{
    "zones":[
      "us-central1-a",
      "us-central1-c",
      "us-central1-f"
    ]
  },
  "rollout": {
    "disruptionBudget": {
      "percent": 25
    },
    "mode": "CONCURRENT_ZONES"
  }
}

Para saber mais sobre o lançamento de patches, consulte a documentação da API PatchRollout.

Ativar a aplicação de patches de softwares da Microsoft em VMs do Windows

Por padrão, quando você executa um job de patch em VMs do Windows, o patch aplica somente os patches do sistema operacional Windows.

É possível aplicar atualizações para softwares da Microsoft, como o Microsoft SQL Server, o SharePoint Server ou o framework .NET, executados nas VMs do Windows ao executar um job de patch. Por padrão, a aplicação de patches para esses aplicativos está desativada a fim de evitar a interrupção do serviço e a fim de separar as atualizações planejadas para o software. Para ativar a aplicação automática de patches de softwares da Microsoft, use a IU do Windows ou o PowerShell.

IU do Windows

  1. No menu Iniciar do Windows, selecione Configurações > Atualização e segurança > Atualização do Windows.
  2. Na seção Opções avançadas, ative a opção Receber atualizações para outros produtos da Microsoft ao atualizar o Windows.

PowerShell 

 $service_manager = New-Object -ComObject 'Microsoft.Update.ServiceManager'
 $service_manager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"")

Depurar um job de patch

Se o patch falhar, é possível usar as etapas a seguir para ajudar a encontrar e resolver os problemas.

  1. Analise os detalhes da instância para o job de patch afetado. Isso ajuda a identificar quais instâncias falharam ou em que estado elas estão travadas. A lista de detalhes da instância também contém uma breve mensagem de erro para cada instância.

    Se um patch falhar com um status de NO_AGENT_DETECTED ou TIMED_OUT, isso normalmente significa que o serviço enviou uma solicitação ao agente para iniciar a aplicação do patch, mas nunca recebeu uma resposta do agente. Analise as possíveis causas e correções a seguir:

    • A instância não está em execução. Para corrigir isso, inicie a instância de VM.
    • Verifique a configuração usando a checklist de verificação.
    • As configurações de rede na rede VPC ou na instância não permitem que o agente de configuração do SO se comuniquem com a API OS Config. Verifique a configuração de rede para corrigir isso.

  2. Se os detalhes da instância não fornecerem informações suficientes, analise os registros do Cloud Logging ou o console da porta serial. O agente de Configuração do SO grava suas entradas de registro em ambos os locais. No Cloud Logging, é possível filtrar usando o código do job de patch para ver todas as entradas de registro relacionadas a esse job de patch. Também é possível ativar a geração de registros de depuração definindo o valor de metadados osconfig-log-level=debug no nível da VM ou do projeto do Cloud.

A seguir