Ações de inicialização

Ao criar um cluster do Dataproc, especifique ações de inicialização em executáveis ou scripts que o Dataproc executará em todos os nós do cluster do Dataproc logo depois da configuração do cluster. As ações de inicialização normalmente configuram dependências do job, como instalar pacotes do Python. Dessa maneira, os jobs podem ser enviados para o cluster sem a necessidade de instalar dependências quando os jobs são executados.

Você encontra exemplos de scripts de ação de inicialização nos seguintes locais: Observação: o Google não oferece suporte a essas amostras.

Considerações e diretrizes importantes

  • Não crie clusters de produção que façam referência de inicialização, localizadas no gs://goog-dataproc-initialization-actions-REGION buckets públicos. Esses scripts são fornecidos como implementações de referência. Eles são sincronizados com as alterações contínuas no repositório do GitHub, e as atualizações desses scripts podem interromper a criação do cluster. Em vez disso, copie a ação de inicialização o bucket público em uma pasta com controle de versão do bucket do Cloud Storage, conforme mostrado exemplo a seguir: 

    REGION=COMPUTE_REGION
gcloud storage cp gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
    gs://my-bucket/cloud-sql-proxy/v1.0/cloud-sql-proxy.sh
    Em seguida, crie o cluster referenciando a cópia no Cloud Storage: 
    gcloud dataproc clusters create CLUSTER_NAME \
    --region=${REGION} \
    --initialization-actions=gs://my-bucket/cloud-sql-proxy/v1.0/cloud-sql-proxy.sh \
    ...other flags...

  • As ações de inicialização são executadas em cada nó em série durante a criação do cluster. Eles também são executadas em cada nó adicionado scaling ou escalonamento automático clusters.

  • Quando você atualiza as ações de inicialização, por exemplo, ao sincronizar Ações de inicialização do Cloud Storage para alterações feitas no bucket público ou ações de inicialização de repositório do GitHub, crie um novo nome da versão) para receber as ações de inicialização atualizadas. Se, em vez disso, você atualizar a ação de inicialização, novos nós, como adicionados pelo escalonador automático, executarão a inicialização no local atualizada e não a ação de inicialização da versão anterior que foi executada nós. Essas diferenças nas ações de inicialização podem resultar em erros nós de cluster corrompidos.

  • As ações de inicialização são executadas como usuário root. Não é necessário usar sudo.

  • Use caminhos absolutos nas ações de inicialização.

  • Use um shebang line (link em inglês) em ações de inicialização para indicar como o script deve ser interpretado (como #!/bin/bash ou #!/usr/bin/python).

  • Se uma ação de inicialização for encerrada com um código de saída diferente de zero, a operação de criação do cluster relatará um status "ERROR". Para depurar a inicialização use SSH para se conectar às instâncias de VM do cluster e logs. Depois de corrigir o problema da ação de inicialização, exclua e recrie o cluster.

  • Se você criar um cluster do Dataproc apenas endereços IP internos, tenta acessar github.com pela Internet em uma ação de inicialização vai falhar, a menos que você tenha configurado rotas para direcionar o tráfego por meio de o Cloud NAT ou um Cloud VPN: Sem acesso à Internet, é possível ativar Acesso privado do Google colocar dependências de jobs no Cloud Storage; os nós do cluster podem fazer o download das dependências do Cloud Storage IPs internos.

  • Use imagens personalizadas do Dataproc em vez de ações de inicialização para configurar dependências de job.

  • Processamento de inicialização:

    • Clusters de imagem anteriores à 2.0:
      • Mestre: para permitir que ações de inicialização sejam executadas nos mestres. para gravar arquivos no HDFS, as ações de inicialização do nó mestre não são iniciadas até que O HDFS é gravável (até que o HDFS tenha saído do modo de segurança e pelo menos dois HDFS os DataNodes foram mesclados).
      • Worker: se você definir o dataproc:dataproc.worker.custom.init.actions.mode propriedade do cluster até RUN_BEFORE_SERVICES, cada worker executa o próprio ações de inicialização antes de iniciar o datanode HDFS e YARN os daemons do nodemanager. Como o Dataproc não executa ações de inicialização mestre até que o HDFS seja gravável, o que requer a execução de dois daemons do nodenode de HDFS, definir essa propriedade pode aumentar o tempo de criação do cluster.

    • Clusters de imagem 2.0+:

      • Mestre: as ações de inicialização do nó mestre podem ser executadas antes do HDFS ser gravável. Se você executar ações de inicialização que organizem arquivos no HDFS ou dependam da disponibilidade de serviços dependentes do HDFS, como o Ranger, defina a propriedade de cluster {dataproc.master.custom.init.actions.mode} 101}para RUN_AFTER_SERVICES. Observação: como esse pode aumentar o tempo de criação do cluster. Consulte a explicação sobre o atraso na criação de clusters do workers do cluster de imagem anteriores à 2.0: use apenas quando necessário (como prática geral, use o padrão RUN_BEFORE_SERVICES para esta propriedade).
      • Worker: o dataproc:dataproc.worker.custom.init.actions.mode propriedade do cluster é definido como RUN_BEFORE_SERVICES e não pode ser transmitido para o cluster quando ele for criado. (não é possível alterar a configuração da propriedade). Cada worker executa as ações de inicialização antes de iniciar o datanode HDFS e os daemons do nodenode YARN. Como o Dataproc não espera que o HDFS seja gravável antes de executar ações de inicialização do mestre, as ações do mestre e do worker são executadas em paralelo.

    • Recomendações:

      • Use metadados para determinar o papel de um nó para executar condicionalmente uma ação de inicialização nos nós. Consulte Como usar metadados de cluster.
      • Bifurque uma cópia de uma ação de inicialização para um bucket do Cloud Storage para mais estabilidade. Consulte Como as ações de inicialização são usadas.
      • Adicione novas tentativas ao fazer o download da Internet para estabilizar a ação de inicialização.

Usar as ações de inicialização

É possível especificar ações de inicialização de cluster independentemente de como ele é criado:

Comando gcloud

Ao criar um cluster com o gcloud dataproc clusters create especifique um ou mais locais do Cloud Storage (URIs) separados por vírgula dos executáveis ou scripts de inicialização com o --initialization-actions. Observação: vários "/"s consecutivos em um URI de local do Cloud Storage após o "gs://" inicial, como "gs://bucket/my//object//name", não são compatíveis. Executar gcloud dataproc clusters create --help para informações sobre o comando.

gcloud dataproc clusters create cluster-name \
    --region=${REGION} \
    --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
    --initialization-action-timeout=timeout-value (default=10m) \
    ... other flags ...
Observações:
  • Use a sinalização --initialization-action-timeout para especificar um período limite para a ação de inicialização. O valor de tempo limite padrão é 10 minutos. Se o executável ou o script de inicialização não tiver sido concluído até o final do tempo limite, o Dataproc cancelará a ação de inicialização.
  • Use a propriedade de cluster dataproc:dataproc.worker.custom.init.actions.mode para executar a ação de inicialização nos workers principais antes que o gerenciador de nós e os datanode daemons sejam inicializados.
.

API REST

Especifique um ou mais scripts ou executáveis em uma matriz ClusterConfig.initializationActions como parte de uma solicitação de API clusters.create.

Exemplo

POST /v1/projects/my-project-id/regions/us-central1/clusters/
{
  "projectId": "my-project-id",
  "clusterName": "example-cluster",
  "config": {
    "configBucket": "",
    "gceClusterConfig": {
      "subnetworkUri": "default",
      "zoneUri": "us-central1-b"
    },
    "masterConfig": {
      "numInstances": 1,
      "machineTypeUri": "n1-standard-4",
      "diskConfig": {
        "bootDiskSizeGb": 500,
        "numLocalSsds": 0
      }
    },
    "workerConfig": {
      "numInstances": 2,
      "machineTypeUri": "n1-standard-4",
      "diskConfig": {
        "bootDiskSizeGb": 500,
        "numLocalSsds": 0
      }
    },
    "initializationActions": [
      {
        "executableFile": "gs://cloud-example-bucket/my-init-action.sh"
      }
    ]
  }
}

Console

  • Abra o Dataproc Criar um cluster e selecione o painel Personalizar cluster.
  • Na seção "Initialization actions", insira o nome do Cloud Storage Local do bucket de cada ação de inicialização em Arquivo executável campos. Clique em Procurar para abrir o navegador do Cloud Storage no console do Google Cloud para selecionar um script ou arquivo executável. Clique em Add Initialization Action. para adicionar cada arquivo.

    • Como passar argumentos para ações de inicialização

    O Dataproc define valores especiais de metadados para as instâncias executadas nos clusters. Defina os próprios metadados personalizados como uma maneira de passar argumentos para ações de inicialização.

    gcloud dataproc clusters create cluster-name \
    --region=${REGION} \
    --initialization-actions=Cloud Storage URI(s) (gs://bucket/...) \
    --metadata=name1=value1,name2=value2... \
    ... other flags ...

    Os valores de metadados podem ser lidos nas ações de inicialização da seguinte maneira:

    var1=$(/usr/share/google/get_metadata_value attributes/name1)

    Seleção de nós

    Se você quiser limitar ações de inicialização a nós mestres, de drivers ou de trabalho, adicione lógica simples de seleção de nós ao executável ou script.

    ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
if [[ "${ROLE}" == 'Master' ]]; then
  ... master specific actions ...
else if [[ "${ROLE}" == 'Driver' ]]; then
  ... driver specific actions ...
else
  ... worker specific actions ...
fi

    Binários de preparo

    Na inicialização de um cluster, é comum o teste de binários de job em um cluster para eliminar a necessidade de serem testados sempre que um job é enviado. Por exemplo, suponha que o script de inicialização a seguir esteja armazenado em gs://my-bucket/download-job-jar.sh, um bucket do Cloud Storage local:

    #!/bin/bash
ROLE=$(/usr/share/google/get_metadata_value attributes/dataproc-role)
if [[ "${ROLE}" == 'Master' ]]; then
  gcloud storage cp gs://my-bucket/jobs/sessionalize-logs-1.0.jar home/username
fi

    A localização desse script pode ser passada para o comando gcloud dataproc clusters create:

    gcloud dataproc clusters create my-dataproc-cluster \
    --region=${REGION} \
    --initialization-actions=gs://my-bucket/download-job-jar.sh

    O Dataproc executará esse script em todos os nodes e, como consequência da lógica de seleção de node do script, fará o download do arquivo jar para o node mestre. Os jobs enviados podem usar o jar testado anteriormente:

    gcloud dataproc jobs submit hadoop \
    --cluster=my-dataproc-cluster \
    --region=${REGION} \
    --jar=file:///home/username/sessionalize-logs-1.0.jar

    Amostras de ações de inicialização

    Os scripts de ações de inicialização mais usados e outros exemplos estão localizados em gs://goog-dataproc-initialization-actions-<REGION>, um intervalo público regional do Cloud Storage, e em um repositório do GitHub. Para contribuir com um script, revise o documento CONTRIBUTING.md e, em seguida, registre uma solicitação de envio.

    Logging

    A saída da execução de cada ação de inicialização é registrada para cada instância em /var/log/dataproc-initialization-script-X.log, onde X é o índice baseado em zero de cada script de ação de inicialização sucessivo. Por exemplo, se o cluster tiver duas ações de inicialização, as saídas serão registradas em /var/log/dataproc-initialization-script-0.log e /var/log/dataproc-initialization-script-1.log.

    A seguir

    Conheça as ações de inicialização do GitHub.