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á. # Ações de bootstrap personalizadas Se você definir as [`OnNodeStart`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeStart)configurações [`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)/, AWS ParallelCluster executará um código arbitrário imediatamente após o início do nó. Se você definir as [`OnNodeConfigured`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeConfigured)configurações [`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)/, AWS ParallelCluster executará o código depois que a configuração do nó for concluída corretamente. A partir da AWS ParallelCluster versão 3.4.0, o código pode ser executado após a atualização do nó principal, se você definir as [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated)configurações [`HeadNode`[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)](HeadNode-v3.md)//. Na maioria dos casos, esse código é armazenado no Amazon Simple Storage Service (Amazon S3) e acessado por meio de uma conexão HTTPS. O código é executado como `root` e pode estar em qualquer linguagem de script compatível com o sistema operacional do cluster. Muitas vezes, o código está em *Bash* ou *Python*. **nota** A partir da AWS ParallelCluster versão 3.7.0, a configuração [`ImdsSupport`](Imds-cluster-v3.md#yaml-cluster-Imds-ImdsSupport)padrão [`Imds`](Imds-cluster-v3.md#Imds-cluster-v3.title)/cluster é. `v2.0` Ao criar um novo cluster para atualizar para a versão 3.7.0 e versões posteriores, atualize seus scripts de ação de bootstrap personalizados para serem compatíveis IMDSv2 ou [`ImdsSupport`](Imds-cluster-v3.md#yaml-cluster-Imds-ImdsSupport)defina [`Imds`](Imds-cluster-v3.md#Imds-cluster-v3.title)/como `v1.0` no arquivo de configuração do cluster. **Atenção** É sua responsabilidade configurar os scripts e argumentos personalizados conforme descrito no [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/). Verifique se seus scripts e argumentos de bootstrap personalizados são de fontes nas quais você confia que possam ter acesso total aos nós do cluster. **Atenção** AWS ParallelCluster não suporta o uso de variáveis internas fornecidas por meio do `/etc/parallelcluster/cfnconfig` arquivo. Esse arquivo pode ser removido como parte de uma versão futura. As ações `OnNodeStart` são chamadas antes que qualquer ação de bootstrap de implantação de nó seja iniciada, como configurar o NAT, o Amazon Elastic Block Store (Amazon EBS) ou o programador. As ações de bootstrap `OnNodeStart` podem incluir a modificação do armazenamento, a adição de usuários extras e a adição de pacotes. **nota** Se você configurar [`DirectoryService`](DirectoryService-v3.md)um [`OnNodeStart`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeStart)script [`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)/para seu cluster, AWS ParallelCluster configura `DirectoryService` e reinicia o`sssd`, antes de executar o `OnNodeStart` script. As ações `OnNodeConfigured` são chamadas após a conclusão dos processos de bootstrap do nó. As ações `OnNodeConfigured` servem como as últimas ações que ocorrem antes que uma instância seja considerada totalmente configurada e concluída. Algumas ações `OnNodeConfigured` podem incluir a alteração de configurações do programador, a modificação do armazenamento ou a modificação de pacotes. Você pode passar argumentos para scripts especificando-os durante a configuração. As ações `OnNodeUpdated` são chamadas depois que a atualização do nó principal é concluída e o programador e o armazenamento compartilhado estão alinhados com as alterações mais recentes na configuração do cluster. Quando as ações personalizadas `OnNodeStart` ou `OnNodeConfigured` são bem-sucedidas, o sucesso é indicado com o código de saída zero (0). Qualquer outro código de saída indica que o bootstrap da instância falhou. Quando as ações personalizadas `OnNodeUpdated` são bem-sucedidas, o sucesso é sinalizado com o código de saída zero (0). Qualquer outro código de saída indica que a atualização falhou. **nota** Se você configurar [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated), deverá restaurar manualmente as ações `OnNodeUpdated` para o estado anterior em caso de falhas de atualização. Se uma ação personalizada `OnNodeUpdated` falhar, a atualização voltará ao estado anterior. No entanto, a ação `OnNodeUpdated` só é executada no momento da atualização e não no momento da reversão da pilha. Você pode especificar scripts diferentes para o nó principal e para cada fila, nas seções de [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)configuração [`HeadNode`](HeadNode-v3.md)/[`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions)e i [`Scheduling`[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)](Scheduling-v3.md)///. [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated)só pode ser configurado na `HeadNode` seção. **nota** Antes da AWS ParallelCluster versão 3.0, não era possível especificar scripts diferentes para nós principais e de computação. Consulte [Passando de AWS ParallelCluster 2.x para 3.x](moving-from-v2-to-v3.md). **Topics** + [Configurações para definir ações e argumentos](custom-bootstrap-actions-config-v3.md) + [Argumentos](custom-bootstrap-actions-args-v3.md) + [Exemplo de cluster com ações de bootstrap personalizadas](custom-bootstrap-actions-example-cluster-v3.md) + [Exemplo de como atualizar um script de bootstrap personalizado para IMDSv2](custom-bootstrap-actions-example-imdsv2-v3.md) + [Exemplo de como atualizar uma configuração para IMDSv1](custom-bootstrap-actions-example-imdsv1-v3.md)