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á.
Sintaxe e exemplos da política de implantação de atualização
Uma política de implantação de upgrade define como AWS os serviços aplicam atualizações automáticas 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.
Tópicos
Considerações
Ao implementar políticas de implantação de upgrade, considere estes fatores importantes:
-
Os nomes das políticas devem ser exclusivos em sua organização e devem ser claros e descritivos. Escolha nomes que reflitam a finalidade e o escopo da política. Para obter mais informações, consulte Otimize a eficiência operacional.
-
Os testes são cruciais antes de uma ampla implantação. Valide primeiro as novas políticas em ambientes que não sejam de produção e expanda gradualmente para garantir o comportamento desejado. Para obter mais informações, consulte Comece pequeno e expanda gradualmente.
-
As mudanças nas políticas podem levar várias horas para se propagar em toda a organização. Planeje suas implementações adequadamente e garanta que o monitoramento adequado esteja em vigor. Para obter mais informações, consulte Monitore e comunique as mudanças.
-
A formatação JSON deve ser válida e permanecer dentro do tamanho máximo da política de 5.120 bytes. Mantenha as estruturas de políticas o mais simples possível e, ao mesmo tempo, atenda às suas necessidades.
-
As revisões regulares das políticas ajudam a manter a eficácia. Agende avaliações periódicas de suas políticas para garantir que elas continuem atendendo às suas necessidades organizacionais. Para obter mais informações, consulte Estabeleça processos de revisão.
-
Os recursos sem um pedido de upgrade atribuído assumem como padrão o pedido “Segundo”. Considere definir explicitamente pedidos de upgrade para recursos essenciais em vez de confiar em padrões. Para obter mais informações, consulte Valide as mudanças de políticas de forma eficaz.
-
Os upgrades manuais têm precedência sobre os pedidos de upgrade definidos pela política. Garanta que seus processos de gerenciamento de mudanças sejam responsáveis por cenários de atualização automática e manual. Para obter mais informações, consulte Estabeleça processos de revisão.
nota
Ao implementar políticas de distribuição de upgrade com base em tags em sua conta de gerenciamento, esteja ciente de que a conta de gerenciamento não pode visualizar ou acessar diretamente as tags de nível de recurso nas contas dos membros. Recomendamos estabelecer um processo em que as contas dos membros apliquem tags de recursos consistentes e, em seguida, criar políticas em nível organizacional que façam referência a essas tags. Isso garante a coordenação adequada entre a marcação em nível de recursos e a aplicação da política organizacional. Você também pode usar Políticas de tag para ajudar a manter tags consistentes quando os recursos são marcados em toda a organização.
Estrutura básica da política
As políticas de implantação de upgrade usam uma estrutura JSON que inclui os seguintes elementos principais:
-
Metadados da política (como informações da versão)
-
Regras de segmentação de recursos
-
Especificações do pedido de atualização
-
Mensagens de exceção opcionais
-
Atributos específicos do serviço
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 upgrade consiste em dois componentes principais que trabalham 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 do pedido de patch
Quando você cria uma política de distribuição de atualização sem especificar nenhuma substituição específica do recurso, todos os recursos usam como padrão uma ordem básica de atualização. Você pode definir esse padrão usando o campo “padrão” em sua política. Recursos sem atribuições explícitas de pedidos de upgrade por meio de tags seguirão essa ordem padrão.
nota
Atualmente, a experiência do console exige que uma ordem padrão seja especificada.
O exemplo a seguir mostra como configurar todos os recursos para receber atualizações por último 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 criticidade 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 upgrade
Aqui estão os cenários comuns da política de implantação de upgrades:
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": { "upgrade_order": "first" } } } } }
Exemplo 2: último ambiente de produção
Este exemplo demonstra como garantir que seus ambientes de produção recebam atualizações por último. Ao definir explicitamente os recursos marcados de produção para o último pedido 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": { "upgrade_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 todos 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" } } } } } } }
