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 do Cortex Framework Data Foundation.

Processo de build

Depois de configurar o config.json arquivo, 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_NAME,_BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/CLOUD_BUILD_SA@SOURCE_PROJECT.iam.gserviceaccount.com'
```
Substitua:
- LOGS_BUCKET_NAME pelo nome do bucket para armazenamento de registros. A conta de serviço do Cloud Build precisa de acesso para gravar registros aqui.
- SOURCE_PROJECT pelo projeto de origem.
- CLOUD_BUILD_SA pelo ID da conta de serviço do Cloud Build criada na etapa 4 da implantação.
Siga o processo de build principal observando os registros no terminal ou no console do Cloud Build, se você tiver permissões suficientes. Consulte as imagens a seguir para mais informações.

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 secundárias acionadas no console do Cloud Build ou nos registros criados nas etapas. Consulte as imagens a seguir para mais informações.

Figura 3. Exemplo de acompanhamento das etapas de build secundárias no console.

Figura 4. Exemplo de acompanhamento das 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 origem replicada. A interface do BigQuery ajuda a identificar e comentar esses campos.

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

Mover arquivos para o bucket de DAGs do Serviço Gerenciado para Apache Airflow (Airflow)

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

  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 pelo bucket de saída.
COMPOSER_DAG_BUCKET pelo bucket de DAGs do Airflow Gerenciado (Airflow).

Personalizar e 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. Essas personalizações são específicas para cada cliente e configuradas 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 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 mesclá-los com visualizações ou tabelas atuais.
Reutilizar os modelos fornecidos para chamar outras APIs.
Modificar scripts de implantação.
Adaptar algumas tabelas ou APIs de destino para incluir campos adicionais nã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 cloudbuild.yaml scripts 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 mudanças de forma visível na bifurcação ou clonagem de um repositório, juntamente com alguma automação de implantação e teste, ajuda a realizar upgrades.

Suporte

Se você tiver problemas ou solicitações de recursos relacionados a esses modelos ou implantadores, crie um problema no repositório do Cortex Framework Data Foundation. Para ajudar a coletar 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 do Cortex Framework, acesse a seção de suporte na página de visão geral.

Looker Blocks e painéis

Aproveite os Looker Blocks e painéis disponíveis. Eles são essencialmente 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 Looker Blocks e painéis.