Criar trabalhos de patch,Criar trabalhos de patch

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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

Para aplicar patches às suas VMs, conclua as seguintes etapas:

1. Configure sua VM .
2. Execute um trabalho de patch .

Antes de começar

• Revise as cotas de configuração do sistema operacional .
• Se ainda não o fez, configure a autenticação. Autenticação é o processo pelo qual sua identidade é verificada para acesso a Google Cloud serviços e APIs. Para executar códigos ou amostras em um ambiente de desenvolvimento local, você pode se autenticar 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. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

  REST

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

  After installing the Google Cloud CLI, initialize it by running the following command:

  gcloud init

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

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

Limitações

• Você pode implantar e executar jobs de patch somente para VMs em um único projeto do Google Cloud. Não é possível executar jobs de patch em projetos do Google Cloud, mesmo que as VMs estejam em uma VPC compartilhada. No entanto, você pode visualizar os dados de conformidade dos patches em todos os projetos .
• Por padrão, o VM Manager não corrige nenhuma VM que faça parte de um grupo de instâncias gerenciadas (MIG). A aplicação de patches nessas VMs é relatada como falhas no trabalho de patch. Você pode substituir esse comportamento padrão ao criar o trabalho de patch. As seguintes limitações se aplicam quando você aplica patches em VMs que fazem parte de um MIG:
  • Quando um MIG repara uma VM , ele recria a VM com base no modelo de 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 escalonamento automático habilitado. O escalonador automático exclui VMs corrigidas quando a carga cai 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 utilização desejada especificada para o escalonamento automático, o MIG poderá remover algumas das VMs corrigidas durante a expansão.

Sistemas operacionais suportados

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

Configure sua VM

Para usar o recurso Patch, execute as seguintes etapas:

1. Para todas as VMs, configure o VM Manager .
2. Para VMs do Windows, o Google recomenda desabilitar as atualizações automáticas nas VMs. 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 Google Cloud têm acesso total para executar e gerenciar jobs de patch. Para todos os outros usuários, você precisa conceder permissões. Você pode conceder uma das seguintes funções granulares:

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

Por exemplo, para conceder acesso a um usuário para executar tarefas 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 o seguinte:

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

Executar trabalhos de patch

Você pode executar um job de patch usando o console do Google Cloud , a CLI do Google Cloud ou o REST .

Quando você executa um trabalho de patch, a aplicação de patch das VMs começa simultaneamente em todas as instâncias especificadas pelo filtro de instância .

Depois de iniciar um trabalho de patch, você poderá monitorar seus patches usando o painel Patch . Demora aproximadamente 30 minutos após o início de um trabalho de patch para que os dados sejam preenchidos no painel.

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

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

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

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

{
  "instanceFilter": instance-filter
}

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"
    ]
  }
}

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"
    ]
  }
}

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

Você pode especificar as instâncias a serem incluídas em um trabalho de patch usando filtros. Os seguintes filtros são suportados para trabalhos de patch:

• Filtrar por nome: limite o trabalho de patch a instâncias com nomes específicos. Os nomes de instância devem ser especificados usando o URI completo. Os formatos de URI suportados incluem o seguinte:

  • 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: limite o trabalho de patch a instâncias com um prefixo específico em seu nome.

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

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

Você também pode executar jobs de patch em todas as instâncias de um projeto do Google Cloud definindo o campo all em instanceFilter como true . Para obter mais informações, consulte exemplos de filtros de instância .

Exemplos de filtros de instância

--instance-filter-all

{
  "instanceFilter":{
    "all":"true"
  }
}

--instance-filter-names="zones/us-east1-b/instances/instance1"

{
  "instanceFilter":{
    "instances":[
      "zones/us-east1-b/instances/instance1"
    ]
  }
}

--instance-filter-name-prefixes="app-"

{
  "instanceFilter":{
    "instanceNamePrefixes":[
      "app-"
    ]
  }
}

--instance-filter-zones="us-east1-b","us-east1-c"

{
  "instanceFilter":{
    "zones":[
      "us-east1-b",
      "us-east1-c"
    ]
  }
}

--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"
        }
      }
    ]
  }
}

Combinando filtros de instância

Filtros de instância também podem ser combinados. Por exemplo, para executar um trabalho de patch para instâncias que possuem o prefixo test- , que estão localizadas na zona us-east1-c e que possuem 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 patches

Ao executar um trabalho de patch, você pode especificar parâmetros para controlar os patches aplicados na VM. Os parâmetros de configuração do patch dependem da plataforma e geralmente são transmitidos às 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.

Você pode especificar as seguintes configurações de patch para suas VMs:

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

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

  • Para patches direcionados a VMs RHEL e Rocky Linux, você pode especificar pacotes minimal e security .
  • Para VMs CentOS, não há metadados security no repositório CentOS yum . Portanto, não é necessário especificar a opção de security ao atualizar pacotes de segurança. Se você não especificar nenhum pacote, o trabalho de patch atualizará todos os pacotes, inclusive aqueles com atualizações de segurança.
  • Você também pode excluir pacotes específicos. Para obter mais informações, consulte as páginas de manual yum .

• Para Debian e Ubuntu, o sistema subjacente é apt . Para patches direcionados a essas VMs, você pode especificar dist-upgrade ou uma atualização padrão. Você também pode excluir pacotes específicos. Para obter mais informações, consulte as páginas man do Debian ou as páginas man do Ubuntu .

• Para SuSE, o sistema subjacente é zypper , especificamente usando zypper patches . Para patches direcionados a essas VMs, você pode especificar opções como:

  • with update : atualiza 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 aplicados

  Você também pode excluir patches específicos.

Opcionalmente, para todos os sistemas operacionais suportados, você pode optar por instalar patches aprovados apenas especificando essas atualizações. Isso permite inserir uma lista de pacotes ou patches aprovados. Ao selecionar esses patches aprovados, somente os pacotes ou patches aprovados serão instalados. Todos os outros parâmetros de configuração do patch são ignorados durante a atualização.

Exemplos

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

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

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"
    }
}

Janela de manutenção

Uma janela de manutenção é o tempo total que você permite que um trabalho de patch seja executado. Os trabalhos de patch atingirão 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 trabalho de patch será iniciado 60 minutos após o horário de início. Alguns processos, como download de um arquivo ou reinicialização, podem ocorrer fora desta janela de manutenção; no entanto, nenhum novo trabalho de patch será iniciado.

Opções de reinicialização

Ao executar um trabalho de patch, você pode 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 sistema operacional. Várias reinicializações podem ocorrer durante a aplicação de patches e antes da instalação de qualquer patch.
• 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 foram totalmente aplicados.

Scripts pré-patch e pós-patch

Ao executar um trabalho de patch, você pode especificar scripts a serem executados como parte do processo de patch. Esses scripts são úteis para executar tarefas como encerrar um aplicativo e realizar verificações de integridade.

• Os scripts de pré-patch são executados antes do início da aplicação do patch. Se for necessária uma reinicialização do sistema antes do início da aplicação de patch, o script de pré-patch será executado antes da reinicialização.
• Os scripts pós-patch são executados após a conclusão do patch. Se uma reinicialização do sistema for necessária como parte da aplicação de patch, o script pós-patch será executado após a reinicialização.

Uma tarefa de patch aceita um script de pré-patch e um script de pós-patch para Linux, e um script de pré-patch e um script de pós-patch para Windows. Os scripts do Linux e do Windows precisam ser fornecidos usando sinalizações, parâmetros ou seções apropriadas quando especificados na CLI do Google Cloud , no REST ou no console do Google Cloud , respectivamente. Os scripts do Linux são executados apenas em VMs do Linux e os scripts do Windows são executados apenas em VMs do Windows.

Esses arquivos de script podem ser armazenados na VM ou em um bucket versionado do Cloud Storage.

Armazenar scripts de patch em intervalos do Cloud Storage

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

• Se o objeto do Cloud Storage não puder ser lido publicamente, verifique se a conta de serviço anexada à instância tem as permissões de IAM necessárias para ler os 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.
• Quando você seleciona um script do Cloud Storage usando o console do Google Cloud, a versão mais recente do objeto do Cloud Storage especificado é usada por padrão.

• Se sua organização aplicar a restrição de local de recurso , você deverá armazenar seus scripts em buckets do Cloud Storage em regiões e zonas permitidas pela política da sua organização.

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"

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

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"
      }
    }
  }
}

Opções de implementação de patch

Você pode optar por corrigir as VMs em uma zona por vez (zona por zona) ou corrigir todas as zonas de uma vez (zonas simultâneas).

Além de fazer uma seleção para a implantação da zona, você também pode especificar um orçamento de interrupção da zona para suas VMs.

Orçamento de interrupção de zona

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

O que é considerado uma VM interrompida?

Durante a aplicação de patches, uma VM é considerada interrompida a partir do momento em que o agente de configuração do sistema operacional é notificado para começar até a conclusão da aplicação de patches. Esse tempo de interrupção inclui o tempo para concluir a reinicialização e quaisquer etapas pós-patch.

Uma VM também é contabilizada como parte do orçamento de interrupção se atender a qualquer uma das seguintes condições:

• A operação de patch falha ao aplicar os patches
• A operação de patch falha ao executar etapas pré ou pós patch
• A operação de patch não responde com uma notificação de sucesso antes do tempo limite

Como funcionam os orçamentos de interrupção

Para implementações zona por zona, se o orçamento de interrupção em uma zona for excedido, o trabalho de patch será interrompido. Isso acontece porque continuar para a próxima zona requer a conclusão do processo de patch na zona anterior.

Por exemplo, se o orçamento de interrupção tiver um valor de 10 e 8 VMs não conseguirem corrigir a zona atual, o trabalho de patch continuará a corrigir 2 VMs de cada vez até que a zona seja concluída. Quando essa zona for concluída com êxito, a aplicação de patches começa com 10 VMs por vez na próxima zona. Se 10 VMs na próxima zona falharem no patch, o trabalho de patch será interrompido.

Exemplos

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=zone-by-zone \
   --rollout-disruption-budget=10

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=concurrent-zones \
   --rollout-disruption-budget-percent=50

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"
  }
}

Habilitar a correção de software da Microsoft em VMs do Windows

Quando você executa um trabalho de patch em VMs do Windows, por padrão, o Patch aplica apenas os patches do sistema operacional Windows.

Você pode aplicar atualizações para software da Microsoft, como o Microsoft SQL Server, o SharePoint Server ou o .NET Framework em execução nas VMs do Windows ao executar um trabalho de patch. Por padrão, a correção desses aplicativos está desativada para evitar a interrupção do serviço e para separar as atualizações planejadas para esses softwares. Para habilitar a correção automática de software da Microsoft, você pode usar a interface do usuário do Windows ou o PowerShell.

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

Depurar um trabalho de patch

Se o seu patch falhar, você pode usar as etapas a seguir para ajudar a encontrar e resolver os problemas.

1. Revise os detalhes da instância do trabalho 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 NO_AGENT_DETECTED ou TIMED_OUT , isso geralmente significa que o serviço enviou uma solicitação ao agente para iniciar o patch, mas nunca recebeu resposta do agente. Revise as seguintes possíveis causas e soluções:

   • A instância não está em execução. Para corrigir isso, inicie a instância da VM .
   • Verifique a configuração usando a lista de verificação de verificação .
   • As configurações de rede na rede VPC ou na instância não permitiam que o agente OS Config se comunicasse com a API OS Config. Para corrigir isso, verifique as configurações de rede.

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

O que vem a seguir?

• Saiba mais sobre Patch .
• Gerencie seus trabalhos de patch .
• Agende trabalhos de patch .

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

Para aplicar patches às suas VMs, conclua as seguintes etapas:

1. Configure sua VM .
2. Execute um trabalho de patch .

Antes de começar

• Revise as cotas de configuração do sistema operacional .
• Se ainda não o fez, configure a autenticação. Autenticação é o processo pelo qual sua identidade é verificada para acesso a Google Cloud serviços e APIs. Para executar códigos ou amostras em um ambiente de desenvolvimento local, você pode se autenticar 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. After installing the Google Cloud CLI, initialize it by running the following command:

     gcloud init

     If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  2. Set a default region and zone.

  REST

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

  After installing the Google Cloud CLI, initialize it by running the following command:

  gcloud init

  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

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

Limitações

• Você pode implantar e executar jobs de patch somente para VMs em um único projeto do Google Cloud. Não é possível executar jobs de patch em projetos do Google Cloud, mesmo que as VMs estejam em uma VPC compartilhada. No entanto, você pode visualizar os dados de conformidade dos patches em todos os projetos .
• Por padrão, o VM Manager não corrige nenhuma VM que faça parte de um grupo de instâncias gerenciadas (MIG). A aplicação de patches nessas VMs é relatada como falhas no trabalho de patch. Você pode substituir esse comportamento padrão ao criar o trabalho de patch. As seguintes limitações se aplicam quando você aplica patches em VMs que fazem parte de um MIG:
  • Quando um MIG repara uma VM , ele recria a VM com base no modelo de 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 escalonamento automático habilitado. O escalonador automático exclui VMs corrigidas quando a carga cai 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 utilização desejada especificada para o escalonamento automático, o MIG poderá remover algumas das VMs corrigidas durante a expansão.

Sistemas operacionais suportados

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

Configure sua VM

Para usar o recurso Patch, execute as seguintes etapas:

1. Para todas as VMs, configure o VM Manager .
2. Para VMs do Windows, o Google recomenda desabilitar as atualizações automáticas nas VMs. 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 Google Cloud têm acesso total para executar e gerenciar jobs de patch. Para todos os outros usuários, você precisa conceder permissões. Você pode conceder uma das seguintes funções granulares:

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

Por exemplo, para conceder acesso a um usuário para executar tarefas 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 o seguinte:

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

Executar trabalhos de patch

Você pode executar um job de patch usando o console do Google Cloud , a CLI do Google Cloud ou o REST .

Quando você executa um trabalho de patch, a aplicação de patch das VMs começa simultaneamente em todas as instâncias especificadas pelo filtro de instância .

Depois de iniciar um trabalho de patch, você poderá monitorar seus patches usando o painel Patch . Demora aproximadamente 30 minutos após o início de um trabalho de patch para que os dados sejam preenchidos no painel.

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

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

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

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

{
  "instanceFilter": instance-filter
}

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"
    ]
  }
}

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"
    ]
  }
}

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

Você pode especificar as instâncias a serem incluídas em um trabalho de patch usando filtros. Os seguintes filtros são suportados para trabalhos de patch:

• Filtrar por nome: limite o trabalho de patch a instâncias com nomes específicos. Os nomes de instância devem ser especificados usando o URI completo. Os formatos de URI suportados incluem o seguinte:

  • 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: limite o trabalho de patch a instâncias com um prefixo específico em seu nome.

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

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

Você também pode executar jobs de patch em todas as instâncias de um projeto do Google Cloud definindo o campo all em instanceFilter como true . Para obter mais informações, consulte exemplos de filtros de instância .

Exemplos de filtros de instância

--instance-filter-all

{
  "instanceFilter":{
    "all":"true"
  }
}

--instance-filter-names="zones/us-east1-b/instances/instance1"

{
  "instanceFilter":{
    "instances":[
      "zones/us-east1-b/instances/instance1"
    ]
  }
}

--instance-filter-name-prefixes="app-"

{
  "instanceFilter":{
    "instanceNamePrefixes":[
      "app-"
    ]
  }
}

--instance-filter-zones="us-east1-b","us-east1-c"

{
  "instanceFilter":{
    "zones":[
      "us-east1-b",
      "us-east1-c"
    ]
  }
}

--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"
        }
      }
    ]
  }
}

Combinando filtros de instância

Os filtros de instância também podem ser combinados. Por exemplo, para executar um trabalho de patch para instâncias que tenham o test- de prefixo, localizado na zona us-east1-c e que possuem 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 do patch

Ao executar um trabalho de patch, você pode especificar parâmetros para controlar os patches aplicados na VM. Os parâmetros de configuração do patch são dependentes da plataforma e geralmente são passados ​​para as ferramentas de atualização do sistema subjacente. Os patches reais são provenientes dos repositórios de pacotes (Linux) ou do Windows Update Server (Windows) configurados na VM.

Você pode especificar as seguintes configurações de patch para suas VMs:

• Para o Windows, você especifica a classificação de patches a ser aplicada (por exemplo, Security e Critical ) ou direcionar KBS específico para excluir. Para obter mais informações sobre a classificação do patch, consulte a documentação de suporte da Microsoft .

• Para Rhel, Rocky Linux e Centos, o sistema subjacente é yum .

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

• Para Debian & Ubuntu, o sistema subjacente é apt . Para patches direcionados a essas VMs, você pode especificar dist-upgrade ou uma atualização padrão. Você também pode excluir pacotes específicos. Para obter mais informações, consulte as páginas do Debian Man ou o Ubuntu Man Pages .

• Para o SUSE, o sistema subjacente é zypper , usando especificamente os patches do Zypper . Para patches direcionados a essas VMs, você pode especificar opções como:

  • with update : atualize todos os pacotes não cobertos por patches
  • with optional : os patches opcionais são tratados conforme necessário
  • As categorias ou severidades dos patches para aplicar

  Você também pode excluir patches específicos.

Opcionalmente, para todos os sistemas operacionais suportados, você pode selecionar instalar patches aprovados apenas especificando essas atualizações. Isso permite inserir 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 do patch são ignorados durante a atualização.

Exemplos

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

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

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"
    }
}

Janela de manutenção

Uma janela de manutenção é o tempo total em que você permite que um trabalho de patch seja executado. Os trabalhos de patches do tempo limitarão se eles não concluírem na janela de manutenção especificada.

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

Reiniciar as opções

Ao executar um trabalho de patch, você pode especificar as opções de reinicialização para o patch. As seguintes opções estão disponíveis:

• Padrão: o agente decide se uma reinicialização é necessária, verificando sinais bem conhecidos em cada sistema operacional. Várias reinicializações podem ocorrer durante o patch e podem ocorrer antes que qualquer patches seja instalado.
• Sempre: a máquina reinicia 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 estão totalmente aplicados.

Scripts pré-patch e pós-patch

Ao executar um trabalho de patch, você pode especificar scripts para ser executado como parte do processo de patch. Esses scripts são úteis para executar tarefas, como desligar um aplicativo e executar verificações de saúde.

• Os scripts pré-patch são executados antes do início do patch. Se uma reinicialização do sistema for necessária antes do início do patch, o script pré-patch será executado antes da reinicialização.
• Os scripts pós-patch são executados após a conclusão do patch. Se uma reinicialização do sistema for necessária como parte do patch, o script pós-patch será executado após a reinicialização.

Um trabalho de patch aceita um script pré-patch e um pós-patch para o Linux e um script pré-patch e um pós-patch para o Windows. Os scripts Linux e Windows devem ser fornecidos usando os sinalizadores, parâmetros ou seções apropriados quando especificados da CLI do Google Cli , REST ou do Google Cloud Console , respectivamente. Os scripts do Linux são executados apenas em VMs Linux e scripts do Windows são executados apenas no Windows VMS.

Esses arquivos de script podem ser armazenados na VM ou em um balde de armazenamento em nuvem de versões .

Armazene scripts de patch em baldes de armazenamento em nuvem

Se você deseja usar um balde de armazenamento em nuvem para armazenar seus scripts, crie um balde de armazenamento em nuvem e faça o upload de seus scripts no balde. Ao usar um balde de armazenamento em nuvem, considere o seguinte:

• Se o seu objeto de armazenamento em nuvem não for legível publicamente, verifique se a conta de serviço anexada à instância possui as permissões de IAM necessárias para ler os objetos de armazenamento em nuvem. Para garantir que você tenha as permissões corretas, verifique as configurações de permissão no objeto de armazenamento em nuvem.
• Quando você seleciona um script do Cloud Storage usando o console do Google Cloud, a versão mais recente do objeto de armazenamento em nuvem especificada é usada por padrão.

• Se a sua organização aplicar a restrição de restrição do local do recurso , você deverá armazenar seus scripts em baldes de armazenamento em nuvem em regiões e zonas que sua política de organização permite.

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"

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

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"
      }
    }
  }
}

Opções de lançamento de patch

Você pode optar por corrigir as VMs uma zona de cada vez (zona por zona) ou corrigir todas as zonas ao mesmo tempo (zonas simultâneas).

Além de fazer uma seleção para a zona lançada, você também pode especificar um orçamento de interrupção da zona para suas 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 para interromper a qualquer momento.

O que é considerado uma VM interrompida?

Durante o patch, uma VM é considerada interrompida a partir do momento em que o agente de configuração do SO é notificado para começar até que o patch seja concluído. Esse tempo de interrupção inclui o tempo para concluir a reinicialização e quaisquer etapas pós-patch.

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

• A operação de patch falha ao aplicar os patches
• A operação de patch falha ao executar etapas pré ou postagens
• A operação de patch não responde com uma notificação de sucesso antes de chegar ao tempo

Como funcionam os orçamentos de interrupção

Para lançamentos de zona zona, se o orçamento de interrupção em uma zona for excedido, o trabalho de patch para. Isso acontece porque a continuação da próxima zona requer a conclusão do processo de patch na zona anterior.

Por exemplo, se o orçamento de interrupção tiver um valor de 10 e 8 VMs falharem em corrigir na zona atual, o trabalho do patch continuará corrigindo 2 VMs por vez até que a zona seja concluída. Quando essa zona é concluída com sucesso, o patch começa com 10 VMs por vez na próxima zona. Se 10 VMs na próxima zona não conseguirem corrigir, o trabalho de patch para.

Exemplos

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=zone-by-zone \
   --rollout-disruption-budget=10

gcloud compute os-config patch-jobs execute \
   --instance-filter-all \
   --rollout-mode=concurrent-zones \
   --rollout-disruption-budget-percent=50

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"
  }
}

Ative o software Microsoft Patching Microsoft no Windows VMS

Quando você executa um trabalho de patch no Windows VMS, por padrão, o patch aplica apenas os patches para o sistema operacional do Windows.

Você pode aplicar atualizações para software Microsoft, como o Microsoft SQL Server, o SharePoint Server ou o .NET Framework em execução no seu Windows VMS quando você executa um trabalho de patch. Por padrão, a corrigindo esses aplicativos está desativada para evitar a interrupção do serviço e separar atualizações planejadas para esses softwares. Para ativar o Patching Microsoft Software automaticamente, você pode usar a interface do Windows ou o PowerShell.

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

Depure um trabalho de patch

Se o seu patch falhar, você poderá usar as etapas a seguir para ajudar a encontrar e resolver os problemas.

1. Revise os detalhes da instância para o trabalho de patch afetado. Isso ajuda a identificar em quais instâncias falharem ou em que estado elas estão presas. 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 geralmente significa que o serviço enviou uma solicitação ao agente para começar a corrigir, mas nunca mais recebeu resposta do agente. Revise as seguintes causas e correções possíveis:

   • A instância não está em execução. Para corrigir isso, inicie a instância da VM .
   • Verifique a configuração usando a lista de verificação de verificação .
   • As configurações de rede na rede VPC ou na instância não permitiram que o agente de configuração do SO se comunicasse com a API de configuração do SO. Para corrigir isso, verifique as configurações de rede.

2. Se os detalhes da instância não fornecerem informações suficientes, revise os registros de log em nuvem ou o console de porta serial . O agente de configuração do SO escreve suas entradas de log em ambos os locais. No registro da nuvem, você pode filtrar usando o ID do trabalho do patch para ver todas as entradas de log relacionadas a esse trabalho de patch. Você também pode ativar o log de depuração, definindo o valor dos metadados osconfig-log-level=debug no nível do projeto da VM ou Google Cloud.

O que vem a seguir?

• Saiba mais sobre patch .
• Gerencie seus trabalhos de patch .
• Agende trabalhos de patch .