As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Atualize a sintaxe e os exemplos da política de implantação

Uma política de implantação de upgrades define como AWS os serviços aplicam os upgrades automáticos em seus recursos. Compreender a sintaxe da política ajuda você a criar políticas eficazes que atendam aos requisitos de atualização da sua organização.

Considerações

Ao implementar políticas de implantação de upgrades, considere estes fatores importantes:

Estrutura básica da política

As políticas de implantação de upgrade usam uma estrutura JSON que inclui os seguintes elementos principais:

O exemplo a seguir mostra uma estrutura básica de política de implantação de upgrade:

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}

Componentes da política

Uma política de implantação de upgrades consiste em dois componentes principais que funcionam juntos para controlar como os upgrades são aplicados em seus recursos. Esses componentes incluem opções de configuração para comportamentos padrão e substituições baseadas em tags. Entender como esses componentes interagem ajuda você a criar políticas eficazes que atendam às suas necessidades organizacionais.

Configuração padrão da ordem de patch

Quando você cria uma política de distribuição de upgrade sem especificar nenhuma substituição específica de um recurso, todos os recursos assumem como padrão uma ordem básica de upgrade. Você pode definir esse padrão usando o campo “padrão” em sua política. Os recursos sem atribuições explícitas de pedidos de upgrade por meio de tags seguirão essa ordem padrão.

O exemplo a seguir mostra como definir todos os recursos para receber atualizações por padrão, a menos que sejam substituídos por tags. Essa abordagem é útil quando você deseja garantir que a maioria dos recursos seja atualizada posteriormente no ciclo de atualização:

"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}

Substituição do nível de recurso por meio de tags

Você pode substituir a ordem de atualização padrão para recursos específicos usando tags. Isso permite que você crie um controle granular sobre quais recursos recebem atualizações e em qual ordem. Por exemplo, você pode atribuir diferentes pedidos de upgrade com base nos tipos de ambiente, nos estágios de desenvolvimento ou na importância da carga de trabalho.

O exemplo a seguir mostra como configurar os recursos de desenvolvimento para receber os upgrades primeiro e os recursos de produção para recebê-los por último. Essa configuração garante que seus ambientes de desenvolvimento possam validar as atualizações antes que elas cheguem à produção:

"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}

Exemplos de políticas de implantação de atualizações

Aqui estão os cenários comuns de políticas de implantação de atualizações:

Exemplo 1: Ambiente de desenvolvimento em primeiro lugar

Este exemplo mostra como configurar recursos em seu ambiente de desenvolvimento para receber atualizações primeiro. Ao direcionar recursos com a tag de ambiente “desenvolvimento”, você garante que seus ambientes de desenvolvimento sejam os primeiros a receber e validar novas atualizações. Esse padrão ajuda a identificar possíveis problemas antes que os upgrades cheguem a ambientes mais críticos:

{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                }
            }
        }
    }
}

Exemplo 2: Ambiente de produção por último

Este exemplo demonstra como garantir que seus ambientes de produção recebam os upgrades por último. Ao definir explicitamente os recursos marcados de produção para a última ordem de atualização, você mantém a estabilidade em seu ambiente de produção e, ao mesmo tempo, permite testes adequados em ambientes de pré-produção. Essa abordagem é particularmente útil para organizações com requisitos rígidos de gerenciamento de mudanças:

{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}

Exemplo 3: Vários pedidos de upgrade usando tags

O exemplo a seguir demonstra como usar uma única chave de tag com valores diferentes para especificar os três pedidos de upgrade. Essa abordagem é útil quando você deseja gerenciar pedidos de upgrade por meio de um único esquema de marcação:

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}