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
<a name="custom-bootstrap-actions-v3"></a>

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)

# Configurações para definir ações e argumentos
<a name="custom-bootstrap-actions-config-v3"></a>

As seguintes configurações são usadas para definir [`HeadNode`](HeadNode-v3.md) / [`CustomActions`](HeadNode-v3.md#HeadNode-v3-CustomActions) / [`OnNodeStart`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeStart) & [`OnNodeConfigured`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeConfigured) & [`OnNodeUpdated`](HeadNode-v3.md#yaml-HeadNode-CustomActions-OnNodeUpdated) e ações e argumentos [`Scheduling`](Scheduling-v3.md) / [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions) / [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) & [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured).

```
HeadNode:
  [...]
  CustomActions:
    OnNodeStart:
      # Script URL. This is run before any of the bootstrap scripts are run
      Script: s3://amzn-s3-demo-bucket/on-node-start.sh
      Args:
        - arg1
    OnNodeConfigured:
      # Script URL. This is run after all the bootstrap scripts are run
      Script: s3://amzn-s3-demo-bucket/on-node-configured.sh
      Args:
        - arg1
    OnNodeUpdated:
      # Script URL. This is run after the head node update is completed.
      Script: s3://amzn-s3-demo-bucket/on-node-updated.sh
      Args:
        - arg1
  # Bucket permissions
  Iam:
    S3Access:
      - BucketName: bucket_name
        EnableWriteAccess: false
Scheduling:
  Scheduler: slurm
   [...]
  SlurmQueues:
    - Name: queue1
      [...]
      CustomActions:
        OnNodeStart:
          Script: s3://amzn-s3-demo-bucket/on-node-start.sh
          Args:
            - arg1
        OnNodeConfigured:
          Script: s3://amzn-s3-demo-bucket/on-node-configured.sh
          Args:
            - arg1
      Iam:
        S3Access:
          - BucketName: bucket_name
            EnableWriteAccess: false
```

Usando a `Sequence` configuração (adicionada na AWS ParallelCluster versão 3.6.0):

```
HeadNode:
  [...]
  CustomActions:
    OnNodeStart:
      # Script URLs. The scripts are run in the same order as listed in the configuration, before any of the bootstrap scripts are run.
      Sequence:
        - Script: s3://amzn-s3-demo-bucket/on-node-start1.sh
          Args:
            - arg1
        - Script: s3://amzn-s3-demo-bucket/on-node-start2.sh
          Args:
            - arg1
        [...]
    OnNodeConfigured:
      # Script URLs. The scripts are run in the same order as listed in the configuration, after all the bootstrap scripts are run.
      Sequence:
        - Script: s3://amzn-s3-demo-bucket/on-node-configured1.sh
          Args:
            - arg1
        - Script: s3://amzn-s3-demo-bucket/on-node-configured2.sh
          Args:
            - arg1
        [...]
    OnNodeUpdated:
      # Script URLs. The scripts are run in the same order as listed in the configuration, after the head node update is completed.
      Sequence:
        - Script: s3://amzn-s3-demo-bucket/on-node-updated1.sh
          Args:
            - arg1
        - Script: s3://amzn-s3-demo-bucket/on-node-updated2.sh
          Args:
            - arg1
        [...]
  # Bucket permissions
  Iam:
    S3Access:
      - BucketName: bucket_name
        EnableWriteAccess: false
Scheduling:
  Scheduler: slurm
   [...]
  SlurmQueues:
    - Name: queue1
      [...]
      CustomActions:
        OnNodeStart:
          # Script URLs. The scripts are run in the same order as listed in the configuration, before any of the bootstrap scripts are run
          Sequence:
            - Script: s3://amzn-s3-demo-bucket/on-node-start1.sh
              Args:
                - arg1
            - Script: s3://amzn-s3-demo-bucket/on-node-start2.sh
              Args:
                - arg1
            [...]
        OnNodeConfigured:
          # Script URLs. The scripts are run in the same order as listed in the configuration, after all the bootstrap scripts are run
          Sequence:
            - Script: s3://amzn-s3-demo-bucket/on-node-configured1.sh
              Args:
                - arg1
            - Script: s3://amzn-s3-demo-bucket/on-node-configured2.sh
              Args:
                - arg1
            [...]
      Iam:
        S3Access:
          - BucketName: bucket_name
            EnableWriteAccess: false
```

A `Sequence` configuração é adicionada a partir da AWS ParallelCluster versão 3.6.0. Ao especificar `Sequence`, você pode listar vários scripts para uma ação personalizada. AWS ParallelCluster continua oferecendo suporte à configuração de uma ação personalizada com um único script, sem incluir `Sequence`.

AWS ParallelCluster não suporta a inclusão de um único script e `Sequence` da mesma ação personalizada. Por exemplo, AWS ParallelCluster falhará se você especificar a seguinte configuração.

```
[...]
  CustomActions:
    OnNodeStart:
      # Script URL. This is run before any of the bootstrap scripts are run
      Script: s3://amzn-s3-demo-bucket/on-node-start.sh
          Args:
            - arg1
      # Script URLs. The scripts are run in the same order as listed in the configuration, before any of the bootstrap scripts are run.
      Sequence:
        - Script: s3://amzn-s3-demo-bucket/on-node-start1.sh
          Args:
            - arg1
        - Script: s3://amzn-s3-demo-bucket/on-node-start2.sh
          Args:
            - arg1
[...]
```

# Argumentos
<a name="custom-bootstrap-actions-args-v3"></a>

No AWS ParallelCluster 2.x, os `$1` argumentos eram reservados, para armazenar a URL do script personalizado. Se você quiser reutilizar os scripts de bootstrap personalizados criados para AWS ParallelCluster 2.x com AWS ParallelCluster 3.x, você precisa adaptá-los considerando a mudança dos argumentos. Consulte [Passando de AWS ParallelCluster 2.x para 3.x](moving-from-v2-to-v3.md).

# Exemplo de cluster com ações de bootstrap personalizadas
<a name="custom-bootstrap-actions-example-cluster-v3"></a>

As etapas a seguir criam um script simples a ser executado após a configuração do nó, que instala os pacotes `R,` `curl` e `wget` nos nós do cluster.

1. Crie um script.

   ```
   #!/bin/bash
     echo "The script has $# arguments"
     for arg in "$@"
     do
         echo "arg: ${arg}"
     done
     yum -y install "${@:1}"
   ```

1. Faça upload do script com as permissões corretas para o Amazon S3. Se as permissões de leitura pública não forem apropriadas para você, use as sessões de configuração [`HeadNode`](HeadNode-v3.md) / [`Iam`](HeadNode-v3.md#HeadNode-v3-Iam) / [`S3Access`](HeadNode-v3.md#yaml-HeadNode-Iam-S3Access) e [`Scheduling`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues). Para obter mais informações, consulte [Trabalhar com o Amazon S3](s3_resources-v3.md).

   ```
   $ aws s3 cp --acl public-read /path/to/myscript.sh s3://amzn-s3-demo-bucket/myscript.sh
   ```
**Importante**  
Se o script foi editado no Windows, as terminações de linha devem ser alteradas de CRLF para LF antes que seja feito upload do script para o Amazon S3.

1. Atualize a AWS ParallelCluster configuração para incluir a nova `OnNodeConfigured` ação.

   ```
   CustomActions:
     OnNodeConfigured:
       Script: https://<amzn-s3-demo-bucket>.s3.<region>.amazonaws.com/myscript.sh
       Args:
         - "R"
         - "curl"
         - "wget"
   ```

   Se o bucket não tiver permissão de leitura pública, use `s3` como o protocolo de URL.

   ```
   CustomActions:
     OnNodeConfigured:
       Script: s3://amzn-s3-demo-bucket/myscript.sh
       Args:
         - "R"
         - "curl"
         - "wget"
   ```

1. Execute os clusters.

   ```
   $ pcluster create-cluster --cluster-name mycluster \
     --region <region> --cluster-configuration config-file.yaml
   ```

1. Verifique a saída.
   + Se você adicionou ações personalizadas à `HeadNode` configuração, faça login no nó principal e verifique o `cfn-init.log` arquivo localizado em `/var/log/cfn-init.log` executando o seguinte comando:

     ```
     $ less /var/log/cfn-init.log
       2021-09-03 10:43:54,588 [DEBUG] Command run
       postinstall output: The script has 3 arguments
       arg: R
       arg: curl
       arg: wget
       Loaded plugins: dkms-build-requires, priorities, update-motd, upgrade-helper
       Package R-3.4.1-1.52.amzn1.x86_64 already installed and latest version
       Package curl-7.61.1-7.91.amzn1.x86_64 already installed and latest version
       Package wget-1.18-4.29.amzn1.x86_64 already installed and latest version
       Nothing to do
     ```
   + Se você adicionou ações personalizadas à configuração `SlurmQueues`, verifique o `cloud-init.log` localizado no `/var/log/cloud-init.log` em um nó de computação. Use CloudWatch para visualizar esses registros.

   Você pode visualizar esses dois registros no CloudWatch console da Amazon. Para obter mais informações, consulte [Integração com Amazon CloudWatch Logs](cloudwatch-logs-v3.md).

# Exemplo de como atualizar um script de bootstrap personalizado para IMDSv2
<a name="custom-bootstrap-actions-example-imdsv2-v3"></a>

No exemplo a seguir, atualizamos um script de ação de bootstrap personalizado usado com o IMDSv1 para ser usado com o IMDSv2. O script IMDSv1 recupera metadados do ID da AMI da instância do EC2.

```
#!/bin/bash
AMI_ID=$(curl http://169.254.169.254/latest/meta-data/ami-id)
echo $AMI_ID >> /home/ami_id.txt
```

O seguinte mostra o script de ação de bootstrap personalizado modificado para ser compatível com o. IMDSv2

```
#!/bin/bash
AMI_ID=$(TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
         && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id)
echo $AMI_ID >> /home/ami_id.txt
```

Para obter mais informações, consulte [Recuperar metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#instancedata-meta-data-retrieval-examples) no *Guia do usuário do Amazon EC2* para instâncias Linux.

# Exemplo de como atualizar uma configuração para IMDSv1
<a name="custom-bootstrap-actions-example-imdsv1-v3"></a>

Veja a seguir um exemplo de uma configuração de cluster compatível com IMDSv1 o uso das AWS ParallelCluster versões 3.7.0 e anteriores.

```
Region: us-east-1
Imds:
  ImdsSupport: v1.0
Image:
  Os: alinux2
HeadNode:
  InstanceType: t2.micro
  Networking:
    SubnetId: subnet-abcdef01234567890
  Ssh:
    KeyName: key-name
  CustomActions:
    OnNodeConfigured:
      Script: Script-path
Scheduling:
  Scheduler: slurm
  SlurmQueues:
  - Name: queue1
    CustomActions:
      OnNodeConfigured:
        Script: Script-path
    ComputeResources:
    - Name: t2micro
      Instances:
      - InstanceType: t2.micro
      MinCount: 11
    Networking:
      SubnetIds:
      - subnet-abcdef01234567890
```