Esta página foi traduzida pela API Cloud Translation.

Etapa 6: executar a implantação

Esta página descreve a sexta etapa para implantar o Cortex Framework Data Foundation, o núcleo do Cortex Framework. Nesta etapa, você executa a implantação da base de dados do Cortex Framework.

Processo de versão

Depois de configurar o arquivo config.json conforme descrito na Etapa 5: configurar o deployment, siga estas instruções para criar seu processo.

Execute o comando a seguir para se localizar no repositório clonado:
```
cd cortex-data-foundation
```
Execute o comando de build com o bucket de registro de destino:
```
gcloud builds submit --project EXECUTION_PROJECT\
    --substitutions=_GCS_BUCKET=LOGS_BUCKET
```
Substitua:
- EXECUTION_PROJECT com o projeto de execução, provavelmente o projeto de origem.
- LOGS_BUCKET com o nome do bucket para armazenamento de registros. A conta de serviço do Cloud Build precisa de acesso para gravar aqui.
Siga o processo de build principal analisando os registros no terminal ou no console do Cloud Build, se você tiver permissões suficientes. Consulte as imagens a seguir para mais referências.

Figura 1. Exemplo de visualização do progresso dos registros no terminal.

Figura 2. Exemplo de visualização do progresso dos registros no console.
Acompanhe as etapas de build filhas acionadas no console do Cloud Build ou nos registros criados a partir das etapas. Consulte as imagens a seguir para mais referências.

Figura 3. Exemplo de rastreamento de etapas de build filhas no console.

Figura 4. Exemplo de rastreamento de etapas de build secundárias nos registros.
Identifique problemas com builds individuais. Corrija os erros, se houver. É recomendado colar o SQL gerado no BigQuery para identificar e corrigir os erros. A maioria dos erros está relacionada a campos selecionados, mas não presentes na origem replicada. A interface do BigQuery ajuda a identificar e comentar esses dados.

Figura 5. Exemplo de identificação de problemas nos registros do Cloud Build.

Mover arquivos para o bucket do DAG do Cloud Composer (Airflow)

Se você optou por gerar arquivos de integração ou CDC e tem uma instância do Cloud Composer (Airflow), é possível movê-los para o bucket final com o seguinte comando:

  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/dags/ gs://COMPOSER_DAG_BUCKET/
  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/data/ gs://COMPOSER_DAG_BUCKET/

Substitua:

OUTPUT_BUCKET com o bucket de saída.
COMPOSER_DAG_BUCKET com o bucket do DAG do Cloud Composer (Airflow).

Personalizar e se preparar para o upgrade

Muitos clientes corporativos têm personalizações específicas dos sistemas, como documentos adicionais em um fluxo ou tipos específicos de um registro. Eles são específicos para cada cliente e configurados por analistas funcionais conforme as necessidades de negócios surgem.

O Cortex usa tags ## CORTEX-CUSTOMER no código para indicar lugares em que essas personalizações provavelmente são necessárias. Use o comando grep -R CORTEX-CUSTOMER para verificar todos os comentários ## CORTEX-CUSTOMER que você precisa personalizar.

Além das tags CORTEX-CUSTOMER, talvez seja necessário personalizar ainda mais o seguinte, confirmando todas essas mudanças com uma tag clara no código para seu próprio repositório bifurcado ou clonado:

Adicionar regras de negócios.
Adicionar outros conjuntos de dados e combiná-los com visualizações ou tabelas
Reutilize os modelos fornecidos para chamar outras APIs.
Modificar scripts de implantação.
Aplicação de outros conceitos da malha de dados.
Adaptar algumas tabelas ou APIs de destino para incluir campos adicionais que não estão incluídos no padrão.

Adote um pipeline de CI/CD que funcione para sua organização para manter esses aprimoramentos testados e sua solução geral em um estado confiável e robusto. Um pipeline pode reutilizar os scripts cloudbuild.yaml para acionar a implantação completa periodicamente ou com base em operações do Git, dependendo do repositório escolhido, automatizando builds.

Use o arquivo config.json para definir diferentes conjuntos de projetos e conjuntos de dados para ambientes de desenvolvimento, preparação e produção. Use testes automatizados com seus próprios dados de amostra para garantir que os modelos sempre produzam o que você espera.

Marcar suas próprias alterações de forma visível no fork ou clone de um repositório junto com algumas implantações e automação de testes ajuda a fazer upgrades.

Suporte

Se você tiver problemas ou tiver solicitações de recursos relacionados a esses modelos ou implantadores, crie um problema no repositório Cortex Framework Data Foundation. Para ajudar a coletar as informações necessárias, execute support.sh no diretório clonado. Este script orienta você por uma série de etapas para ajudar a resolver problemas.

Para solicitações ou problemas do Cortex Framework, acesse a seção suporte na página de visão geral.

Looker Blocks e painéis

Aproveite os blocos e painéis do Looker disponíveis. Esses são modelos de dados reutilizáveis para padrões analíticos comuns e fontes de dados do Cortex Framework. Para mais informações, consulte Visão geral dos blocos e painéis do Looker.