Ações de inicialização

Quando cria um cluster do Dataproc, pode especificar ações de inicialização em ficheiros executáveis ou scripts que o Dataproc vai executar em todos os nós do cluster do Dataproc imediatamente após a configuração do cluster. As ações de inicialização configuram frequentemente dependências de tarefas, como a instalação de pacotes Python, para que as tarefas possam ser enviadas para o cluster sem ter de instalar dependências quando são executadas.

Pode encontrar exemplos de scripts de ações de inicialização nas seguintes localizações: Nota: a Google não suporta estes 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 contentores públicos.gs://goog-dataproc-initialization-actions-REGION Estes scripts são fornecidos como implementações de referência. Estes scripts são sincronizados com as alterações em curso no repositório do GitHub, e as atualizações a estes scripts podem interromper a criação do cluster. Em alternativa, copie a ação de inicialização do contentor público para uma pasta do contentor do Cloud Storage com controlo de versões, conforme mostrado no exemplo seguinte: 

    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 referindo-se à 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. Também são executados em cada nó adicionado quando os clusters são dimensionados ou dimensionados automaticamente.

  • Quando atualiza as ações de inicialização, por exemplo, quando sincroniza as ações de inicialização do Cloud Storage com as alterações feitas ao contentor público ou às ações de inicialização do repositório do GitHub, crie uma nova pasta (de preferência, com o nome da versão) para receber as ações de inicialização atualizadas. Se, em alternativa, atualizar a ação de inicialização no local, os novos nós, como os adicionados pelo dimensionamento automático, executam a ação de inicialização atualizada no local e não a ação de inicialização da versão anterior executada nos nós existentes. Essas diferenças na ação de inicialização podem resultar em nós de cluster inconsistentes ou danificados.

  • As ações de inicialização são executadas como o utilizador root. Não precisa de usar o 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 (como #!/bin/bash ou #!/usr/bin/python).

  • Se uma ação de inicialização terminar com um código de saída diferente de zero, a operação de criação do cluster vai comunicar um estado "ERROR" (ERRO). Para depurar a ação de inicialização, use o SSH para estabelecer ligação às instâncias de VM do cluster e, em seguida, examine os registos. Depois de corrigir o problema da ação de inicialização, pode eliminar e, em seguida, recriar o cluster.

  • Se criar um cluster do Dataproc com apenas endereços IP internos, as tentativas de acesso ao github.com através da Internet numa ação de inicialização falham, a menos que tenha configurado rotas para direcionar o tráfego através do Cloud NAT ou de uma Cloud VPN. Sem acesso à Internet, pode ativar o acesso privado à Google e colocar dependências de tarefas no Cloud Storage. Os nós do cluster podem transferir as dependências do Cloud Storage a partir de IPs internos.

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

  • Processamento de inicialização:

    • Clusters de imagens anteriores à versão 2.0:
      • Principal: para permitir que as ações de inicialização sejam executadas em principais para escrever ficheiros no HDFS, as ações de inicialização do nó principal não são iniciadas até que o HDFS seja gravável (até que o HDFS tenha saído do modo de segurança e, pelo menos, dois DataNodes do HDFS tenham aderido).
      • Worker: se definir a dataproc:dataproc.worker.custom.init.actions.mode propriedade do cluster como RUN_BEFORE_SERVICES, cada worker executa as respetivas ações de inicialização antes de iniciar os daemons HDFS datanode e YARN nodemanager. Uma vez que o Dataproc não executa ações de inicialização do nó principal até que o HDFS seja gravável, o que requer a execução de 2 daemons de nó de dados do HDFS, a definição desta propriedade pode aumentar o tempo de criação do cluster.

    • Clusters de imagens 2.0 ou superior:

      • Principal: as ações de inicialização do nó principal podem ser executadas antes de o HDFS ser gravável. Se executar ações de inicialização que preparam ficheiros no HDFS ou dependem da disponibilidade de serviços dependentes do HDFS, como o Ranger, defina a dataproc.master.custom.init.actions.mode propriedade do cluster para RUN_AFTER_SERVICES. Nota: uma vez que esta definição de propriedade pode aumentar o tempo de criação de clusters (consulte a explicação do atraso na criação de clusters para trabalhadores de clusters de imagens anteriores à versão 2.0), use-a apenas quando necessário (como prática geral, confie na definição RUN_BEFORE_SERVICES predefinida para esta propriedade).
      • Trabalhador: a dataproc:dataproc.worker.custom.init.actions.mode propriedade do cluster está definida como RUN_BEFORE_SERVICES e não pode ser transmitida ao cluster quando este é criado (não pode alterar a definição da propriedade). Cada trabalhador executa as respetivas ações de inicialização antes de iniciar os daemons do nó de dados do HDFS e do gestor de nós do YARN. Uma vez que o Dataproc não aguarda que o HDFS seja gravável antes de executar as ações de inicialização do nó principal, as ações de inicialização do nó principal e do nó de processamento são executadas em paralelo.

    • Recomendações:

      • Use metadados para determinar a função de um nó para executar condicionalmente uma ação de inicialização em nós (consulte a secção Usar metadados do cluster).
      • Crie uma cópia de uma ação de inicialização num contentor do Cloud Storage para estabilidade (consulte Como são usadas as ações de inicialização).
      • Adicione novas tentativas quando transferir a partir da Internet para ajudar a estabilizar a ação de inicialização.

Use ações de inicialização

As ações de inicialização de clusters podem ser especificadas independentemente da forma como cria um cluster:

Comando gcloud

Quando criar um cluster com o comando gcloud dataproc clusters create, especifique uma ou mais localizações do Cloud Storage (URIs) separadas por vírgulas dos executáveis ou scripts de inicialização com a flag --initialization-actions. Nota: não são suportados vários "/"s consecutivos num URI de localização do Cloud Storage após o "gs://" inicial, como "gs://bucket/my//object//name". Execute gcloud dataproc clusters create --help para ver informações sobre os comandos.

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 ...
Notas:
  • Use a flag --initialization-action-timeout para especificar um período de limite de tempo para a ação de inicialização. O valor de limite de tempo predefinido é de 10 minutos. Se o executável ou o script de inicialização não tiver sido concluído até ao final do período de limite de tempo, o Dataproc cancela a ação de inicialização.
  • Use a dataproc:dataproc.worker.custom.init.actions.mode propriedade cluster para executar a ação de inicialização nos trabalhadores principais antes de os daemons do gestor de nós e do nó de dados serem iniciados.

API REST

Especifique um ou mais scripts ou executáveis num array ClusterConfig.initializationActions como parte de um pedido da 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"
      }
    ]
  }
}

Consola

  • Abra a página do Dataproc Criar um cluster e, de seguida, selecione o painel Personalizar cluster.
  • Na secção Initialization actions (Ações de inicialização), introduza a localização do contentor do Cloud Storage de cada ação de inicialização nos campos Ficheiro executável. Clique em Procurar para abrir a página Google Cloud Navegador do Cloud Storage da consola para selecionar um script ou um ficheiro executável. Clique em Adicionar ação de inicialização para adicionar cada ficheiro.

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

    O Dataproc define valores de metadados especiais para as instâncias que são executadas nos seus clusters. Pode definir os seus próprios metadados personalizados como forma de transmitir argumentos às 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 forma:

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

    Seleção de nós

    Se quiser limitar as ações de inicialização aos nós principais, de controlador ou de processamento, pode adicionar uma lógica de seleção de nós simples ao seu 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 preparação

    Um cenário de inicialização de cluster comum é a preparação de ficheiros binários de trabalhos num cluster para eliminar a necessidade de preparar os ficheiros binários sempre que um trabalho é enviado. Por exemplo, suponha que o seguinte script de inicialização está armazenado em gs://my-bucket/download-job-jar.sh, uma localização do contentor 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 deste script pode ser transmitida 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 executa este script em todos os nós e, como consequência da lógica de seleção de nós do script, transfere o JAR para o nó principal. Em seguida, os trabalhos enviados podem usar o JAR pré-preparado:

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

    Exemplos de ações de inicialização

    Os scripts de ações de inicialização usados com frequência e outros exemplos estão localizados em gs://goog-dataproc-initialization-actions-<REGION>, um contentor público do Cloud Storage regional, e num repositório do GitHub. Para contribuir com um guião, reveja o documento CONTRIBUTING.md e, em seguida, apresente um pedido de obtenção.

    Registo

    O resultado da execução de cada ação de inicialização é registado 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 sucessiva. Por exemplo, se o seu cluster tiver duas ações de inicialização, as saídas são registadas em /var/log/dataproc-initialization-script-0.log e /var/log/dataproc-initialization-script-1.log.

    O que se segue?

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