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ê vai executar a implantação da base de dados do framework Cortex.

Processo de versão

Depois de configurar o arquivo config.json conforme descrito na Etapa 5: configurar a implantação, 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 registros de destino:
```
 gcloud builds submit \
 --substitutions=_GCS_BUCKET=LOGS_BUCKET,\
 _BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/SERVICE_ACCOUNT@SOURCE_PROJECT.iam.gserviceaccount.com'
```
Substitua:
- LOGS_BUCKET com o nome do bucket para armazenamento de registros. A conta de serviço do Cloud Build precisa de acesso para gravar os registros aqui.
- SOURCE_PROJECT com o projeto de origem.
- SERVICE_ACCOUNT com o ID da conta de serviço.
Siga o processo principal de build 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 como ver o progresso dos registros no terminal.

Figura 2. Exemplo de como visualizar o progresso dos registros no console.
Acompanhe as etapas de build secundárias acionadas no console do Cloud Build ou nos registros criados pelas etapas. Confira as imagens a seguir para mais referências.

Figura 3. Exemplo de acompanhamento das etapas de build da criança 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. Recomendamos 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 fonte replicada. A interface do BigQuery ajuda a identificar e comentar esses elementos.

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

Mover arquivos para o bucket de DAGs do Cloud Composer (Airflow)

Se você optou por gerar arquivos de integração ou CDC e tem uma instância do Cloud Composer (Airflow), mova-os 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 de 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 extras 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 comerciais 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 precisam ser personalizados.

Além das tags CORTEX-CUSTOMER, talvez seja necessário personalizar ainda mais o seguinte. Para isso, faça commit de 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 uni-los a visualizações ou tabelas atuais
Reutilizar os modelos fornecidos para chamar outras APIs.
Modificar scripts de implantação.
Aplicar outros conceitos de malha de dados.
Adaptar algumas tabelas ou APIs de destino para incluir campos extras não incluídos no padrão.

Adote um pipeline de CI/CD que funcione para sua organização e mantenha 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, ao automatizar 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 mudanças de forma visível no fork ou clone de um repositório junto com alguma automação de implantação e teste ajuda a fazer upgrades.

Suporte

Se você encontrar problemas ou tiver solicitações de recursos relacionadas a esses modelos ou implantadores, crie um problema no repositório Cortex Framework Data Foundation. Para ajudar a reunir as informações necessárias, execute support.sh no diretório clonado. Esse script orienta você em uma série de etapas para ajudar na solução de problemas.

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

Looker Blocks e painéis

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