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á.

Configure as ações do ciclo de vida do nó no AWS PEÇAS

Você define as ações do ciclo de vida dos nós na configuração do grupo de nós de computação. Este tópico descreve como definir um script, controlar se ele é executado novamente na reinicialização, armazená-lo, passar argumentos, lidar com falhas, armazená-lo em cache, validar sua integridade e ler seus registros.

Como definir um script

Cada script tem umname, ascriptSource, opcionalarguments, uma onError política e umexecutionPolicy. Os campos de localização e integridade estão agrupados emscriptSource.

{
  "name": "My script",
  "scriptSource": {
    "scriptLocation": "s3://my-bucket/my-script.sh",
    "s3VersionId": "optional, S3 only",
    "checksum": "optional 64-char SHA-256 hex"
  },
  "arguments": ["arg1", "arg2"],
  "onError": "TERMINATE",
  "executionPolicy": "FIRST_BOOT_ONLY"
}

Adicionar ações do ciclo de vida a um grupo de nós de computação

Você pode adicionar ações de ciclo de vida ao criar ou atualizar um grupo de nós de computação. Use o Console de gerenciamento da AWS ou AWS CLI o.

Console de gerenciamento da AWS

Para adicionar ações do ciclo de vida usando o console

1. Abra o console AWS PCS.

2. Abra a página de criação ou atualização de um grupo de nós de computação.

3. Na seção Ações do ciclo de vida do Node, escolha Adicionar script.

4. Selecione a fonte do script:

   1. Adicionar da biblioteca de scripts AWS PCS — Faça referência a um script AWS mantido. Para obter mais informações, consulte Use AWS-scripts mantidos para ações do ciclo de vida do nó em AWS PEÇAS.

   2. Adicionar via S3 — Faça referência a um script pelo URI do Amazon S3.

   3. Adicionar via HTTPS — Faça referência a um script pelo URL HTTPS.

5. Selecione o estágio do nó.

6. Para um script que você adiciona via S3 ou HTTPS, especifique estas configurações:

   1. Local do script — Insira o URI do S3 ou o URL HTTPS para o script.

   2. Nome — Insira um nome para o script.

   3. (Opcional) Soma de verificação — Insira uma SHA-256 soma de verificação para verificar a integridade do script. Para obter mais informações, consulte Integridade do script (somas de verificação).

   4. (Opcional) Para um script que você adiciona via S3, insira uma versão para referenciar uma versão específica do objeto.

7. Para todas as fontes de script, especifique estas configurações:

   1. Comportamento de tratamento de erros — Selecione TERMINATESTOP_SEQUENCE,, ouCONTINUE.

   2. Política de execução — Selecione FIRST_BOOT_ONLY ouEVERY_BOOT.

   3. Argumentos (Opcionais) — Adicione argumentos para passar para o script.

8. Para adicionar mais scripts, repita essas etapas.

9. Os scripts são executados de cima para baixo em um estágio. Para alterar a ordem de execução, escolha Ações para um script e escolha Mover para cima ou Mover para baixo.

10. Para Política de armazenamento em cache, selecione CACHE_ONCE ouREFRESH_ON_REBOOT. A política de armazenamento em cache se aplica a todos os scripts. Para obter mais informações, consulte Cache e atualizações de scripts.

AWS CLI

Use o --node-lifecycle-actions parâmetro com o update-compute-node-group comando create-compute-node-group ou. Para ver a estrutura dos parâmetros, consulte NodeLifecycleActionsRequest a Referência da API AWS PCS. Para obter comandos de exemplo, consulteExemplos de ações do ciclo de vida do nó para AWS PEÇAS.

Controlar o comportamento de reinicialização

Defina executionPolicy por script para controlar se ele é executado novamente na reinicialização.

Os scripts são configurados para serem FIRST_BOOT_ONLY executados uma vez e são ignorados na reinicialização. Os scripts são configurados para serem EVERY_BOOT executados em cada inicialização e devem ser idempotentes (seguros para serem executados mais de uma vez com o mesmo resultado).

Locais de armazenamento de scripts

Você pode armazenar scripts no Amazon S3 ou servi-los por HTTPS. Os scripts não podem ser carregados em linha por meio da API, e cada script não deve ter mais de 2 MiB — o agente rejeita qualquer script que exceda esse tamanho.

O armazenamento externo fornece controle de versão, auditabilidade e reutilização entre equipes. Scripts embutidos ou enviados não são suportados.

Passando argumentos para scripts

Passe argumentos como uma matriz ordenada. Eles acessam seu script como parâmetros posicionais da linha de comando.

arguments: ["fs-12345678", "/shared", "nfs4"]
# script.sh fs-12345678 /shared nfs4   ($1=fs-12345678, $2=/shared, $3=nfs4)

O agente exporta variáveis de ambiente para cada script. Essas variáveis contêm metadados de cluster e node.

#!/usr/bin/env bash
echo "Configuring node $PCS_NODE_ID in cluster $PCS_CLUSTER_NAME"

Tratamento de erros

Cada script tem um onError campo que controla o que acontece quando um script sai diferente de zero ou é eliminado por um sinal.

Um script falhará se sair diferente de zero ou for interrompido por um sinal (por exemplo,SIGSEGV). Os scripts não são repetidos. Se uma operação apresentar falhas transitórias, adicione a lógica de repetição dentro do script. A recuperação do script (download), no entanto, é repetida — até 3 tentativas com recuo exponencial (aproximadamente 17 segundos no máximo) — antes que o comportamento seja aplicado. onError

Cache e atualizações de scripts

O agente baixa cada script para a instância na primeira inicialização e o armazena localmente. Dois campos controlam o comportamento na reinicialização: scriptCachingPolicy controla o novo download e executionPolicy controla a reexecução.

A configuração do ciclo de vida (quais scripts são executados, seus argumentos, tratamento de erros e política de execução) é sempre imutável por instância. A alteração UpdateComputeNodeGroup afeta somente as novas instâncias e aciona a DRAIN estratégia, portanto, os trabalhos em execução são concluídos antes que os nós sejam substituídos.

Integridade do script (somas de verificação)

Opcionalmente, forneça um SHA-256 checksum em um scriptscriptSource, como uma string hexadecimal de 64 caracteres. O agente o valida no download; uma incompatibilidade é tratada como uma falha no download e é acionada. onError Recomendamos uma soma de verificação para produção, especialmente para scripts de fontes compartilhadas ou externas.

sha256sum mount-efs.sh   # use the 64-char hex hash as the checksum value

Registro e depuração

Cada script grava em seu próprio arquivo de log e o agente mantém seu próprio log operacional.

# agent: download, caching, checksum, orchestration
/var/log/amazon/pcs/lifecycle/actions/executor.log
# each script's stdout/stderr
/var/log/amazon/pcs/lifecycle/actions/<stage>/<script-name>.log

O nome do arquivo de log usa o nome do script conforme você o definiu. Os espaços são preservados. Por exemplo, um script chamado Mount EFS home directory write toMount EFS home directory.log. Conecte-se com o SSH ou o AWS Systems Manager Session Manager para lê-los — ambos estão disponíveis por nodeBootstrapped estágio. Como os nós que falham TERMINATE são substituídos, encaminhe os logs para fora da instância para depuração após o encerramento: adicione um script inicializado do nó que configure o CloudWatch agente da Amazon para enviar o diretório de logs do ciclo de vida para o Amazon Logs. CloudWatch O configure-cloudwatch-logs.sh script AWS-maintened faz isso. Para obter mais informações, consulte Use AWS-scripts mantidos para ações do ciclo de vida do nó em AWS PEÇAS.