Ações de inicialização

Ao criar um cluster do Serviço Gerenciado para Apache Spark, é possível especificar ações de inicialização em executáveis ou scripts que o Serviço Gerenciado para Apache Spark vai executar em todos os nós do cluster imediatamente após a configuração. 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 esses exemplos.

Considerações e diretrizes importantes

  • Não crie clusters de produção que façam referência a ações de inicialização localizadas nos 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 mudanças do repositório do GitHub em andamento, e as atualizações desses scripts podem interromper a criação do cluster. Em vez disso, copie a ação de inicialização do bucket público para uma pasta de bucket do Cloud Storage com controle de versão, conforme mostrado no 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. Elas também são executadas em cada nó adicionado ao fazer o escalonamento ou escalonamento automático do cluster.

  • Ao atualizar as ações de inicialização, por exemplo, ao sincronizar as ações de inicialização do Cloud Storage com as mudanças feitas nas ações de inicialização do bucket público ou do repositório do GitHub, crie uma nova pasta (de preferência com nome de versão) para receber as ações de inicialização atualizadas. Se, em vez disso, você atualizar a ação de inicialização no local, novos nós, como os adicionados pelo escalonador automático, vão executar a ação de inicialização atualizada no local, e não a ação de inicialização da versão anterior que foi executada nos nós atuais. Essas diferenças de ação de inicialização podem resultar em nós de cluster inconsistentes ou 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 uma linha shebang nas ações de inicialização para indicar como o script deve ser interpretado (por exemplo, #!/bin/bash ou #!/usr/bin/python).

  • Use finalizações de linha no estilo Unix (LF) nas ações de inicialização. Se você criar ações de inicialização no Windows, elas poderão conter finalizações de linha no estilo Windows (CRLF), o que pode causar falhas na execução do script.

  • 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 ação de inicialização, use o SSH para se conectar às instâncias de VM do cluster e examine os registros. Depois de corrigir o problema da ação de inicialização, exclua e recrie o cluster.

  • Se você criar um cluster do Serviço Gerenciado para Apache Spark apenas com endereços IP internos, as tentativas de acessar github.com pela Internet em uma ação de inicialização falharão, a menos que tenha configurado rotas para direcionar o tráfego por meio do Cloud NAT ou de uma Cloud VPN. Sem acesso à Internet, ative o Acesso privado do Google e coloque dependências de job no Cloud Storage. Os nós de cluster podem fazer o download das dependências do Cloud Storage de IPs internos.

  • Use imagens personalizadas do Serviço Gerenciado para Apache Spark 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 as ações de inicialização sejam executadas em mestres para gravar arquivos no HDFS, as ações de inicialização do nó mestre não são iniciadas até que o HDFS seja gravável (até que o HDFS tenha sido fechado no modo safe e pelo menos dois HDFS DataNodes tenham se unido).
      • Worker: se você definir a propriedade de cluster dataproc:dataproc.worker.custom.init.actions.mode como RUN_BEFORE_SERVICES, cada worker executará as ações de inicialização antes de iniciar o daemon do datanode HDFS e os daemons do nodemanager YARN. Como o Serviço Gerenciado para Apache Spark 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 datanode 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 dataproc.master.custom.init.actions.mode propriedade de cluster como RUN_AFTER_SERVICES. Observação: como essa configuração de propriedade pode aumentar o tempo de criação do cluster (consulte a explicação para atraso de criação de cluster para workers de clusters de imagem anteriores à versão 2.0), use-a somente quando necessário, como uma prática geral, confie na configuração padrão RUN_BEFORE_SERVICES para essa propriedade.
      • Worker: a dataproc:dataproc.worker.custom.init.actions.mode propriedade do cluster está definida como RUN_BEFORE_SERVICES e não pode ser transmitida para o cluster quando o cluster é criado (não é possível mudar a configuração da propriedade). Cada worker executa as ações de inicialização antes de iniciar o datanode HDFS e os daemons do nodemanager YARN. Como o Serviço Gerenciado para Apache Spark 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 quando você fizer o download da Internet para ajudar a estabilizar a ação de inicialização.

Usar ações de inicialização

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

CLI gcloud

Ao criar um cluster com o comando gcloud dataproc clusters create , especifique uma ou mais localizações, separadas por vírgulas, do Cloud Storage (URIs) dos arquivos de inicialização executáveis ou scripts com a --initialization-actions sinalização. Observação: vários "/"s consecutivos em um URI de local do Cloud Storage após o "gs://", como "gs://bucket/my//object//name", não são compatíveis. Execute gcloud dataproc clusters create --help para informações de 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 período limite, o Serviço Gerenciado para Apache Spark cancelará a ação de inicialização.
  • Use a dataproc:dataproc.worker.custom.init.actions.mode propriedade de cluster para executar a ação de inicialização nos workers principais antes que o gerenciador de nós e os daemons do datanode 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 a página Criar um cluster do Serviço Gerenciado para Apache Spark e selecione o painel Personalizar cluster.
  • Na seção "Ações de inicialização", insira o local do bucket do Cloud Storage de cada ação de inicialização nos campos Arquivo executável. Clique em Procurar para abrir a página Google Cloud Navegador do Cloud Storage para selecionar um script ou um arquivo executável. Clique em Adicionar ação de inicialização para adicionar cada arquivo.

    • Transmitir argumentos para ações de inicialização

    O Serviço Gerenciado para Apache Spark 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 mestre, de driver ou de trabalho, adicione a lógica de seleção de nós ao executável ou ao 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 seguinte script de inicialização esteja armazenado em gs://my-bucket/download-job-jar.sh, um local de bucket do Cloud Storage:

    #!/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 Serviço Gerenciado para Apache Spark executará esse script em todos os nós e, como consequência da lógica de seleção de nós do script, fará o download do arquivo jar para o nó 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 CONTRIBUTING.md documento 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.