Compartilhar via


Provisionar a análise de escala de nuvem

Processo de implantação da zona de destino de gerenciamento de dados

A equipe de operações da plataforma de dados é responsável pela implantação de uma zona de destino de gerenciamento de dados. A zona de destino do gerenciamento de dados deve ter seu próprio repositório mantido pela equipe de operações de plataforma de dados.

Cuidado

Crie e implante uma zona de destino de gerenciamento de dados antes de qualquer zona de destino de dados ser implantada.

Processo de implantação da zona de destino de dados

As equipes podem usar os modelos fornecidos pela equipe de operações da plataforma de dados para evitar recomeçar do zero para cada ativo. Recomendamos um padrão de bifurcação para automatizar a implantação de uma nova zona de destino.

Por exemplo, uma equipe de operações de zona de destino de dados solicita uma nova zona de destino de dados usando uma ferramenta de gerenciamento de TI ou o Power Apps. Após a aprovação da solicitação, inicie o seguinte fluxo de trabalho usando parâmetros da solicitação:

  1. Implante uma nova assinatura para a nova zona de destino de dados.
  2. Bifurque a ramificação principal do modelo de zona de destino de dados para criar um novo repositório.
  3. Crie uma conexão de serviço no novo repositório.
  4. Atualize os parâmetros no novo repositório com base nos parâmetros da solicitação.
  5. Crie um pipeline de implantação para implantar os serviços disparados pelo check-in dos parâmetros atualizados.
  6. Notifique a equipe de operações da zona de destino de dados que a nova zona de destino está disponível.

A equipe de operações da zona de destino de dados agora pode alterar ou adicionar modelos do Azure Resource Manager.

Esse fluxo de trabalho pode ser automatizado usando vários conjuntos de serviços na plataforma do Azure. Manipule algumas das etapas, como renomear parâmetros em arquivos de parâmetro, usando pipelines de CI/CD. Outras etapas podem ser executadas usando outras ferramentas de orquestração de fluxo de trabalho, como Aplicativos Lógicos.

Diagram of forked DevOps model.

O padrão de bifurcação permite que as equipes atualizem seus modelos dos modelos originais usados para bifurcá-los. Além disso, se os aprimoramentos ou novos recursos forem implementados nos repositórios de modelos, as equipes de operações poderão obtê-los em sua bifurcação.

Adote as práticas recomendadas para repositórios, como:

  • Proteger a ramificação principal.
  • Use ramificações para alterações, atualizações e aprimoramentos.
  • Defina os proprietários de código que aprovam solicitações de pull antes de mesclar as alterações na ramificação principal.
  • Valide ramificações por meio de testes automatizados.
  • Limite o número de ações e pessoas na equipe, como quem pode disparar pipelines de lançamento e compilação.

Dica

Coordene as atividades entre as equipes para garantir que os aprimoramentos ou novos recursos nos modelos originais sejam replicados em todas as instâncias de zona de destino de dados. As equipes de operações podem efetuar pull de alterações de modelo originais em sua bifurcação.

Diagram of a data landing zone automation process.

O processo de integração é separado do processo de implantação da zona de destino de dados. Essa separação se baseia na suposição de que a maioria das organizações tem um processo de implantação de assinatura do Azure padrão como parte de seu modelo operacional em nuvem. O processo de integração implanta componentes corporativos padrão (como uma ferramenta de gerenciamento de serviços de TI de terceiros). Componentes específicos da zona de destino de dados são implantados em seguida.

Não há nenhuma API do Git disponível para clonar/atualizar/confirmar/enviar por push na solução de automação proposta. Portanto, nossa abordagem é usar uma conta de Automação do Azure que contenha runbooks do PowerShell que:

  • Configuram uma zona de destino de dados
  • Bifurcam o repositório principal em um repositório Git da plataforma de dados
  • Configuram as definições de sub-rede para a zona de destino de dados
  • Configurar o Microsoft Entra ID

Os runbooks usam funções Git do módulo PowerShell GitAutomation para trabalhar com repositórios Git. Ao instalar esse módulo dentro de uma conta de Automação do Azure, os usuários podem realizar operações de criação, clonagem, consulta, push, pull e confirmação em repositórios Git. A imagem a seguir mostra o módulo GitAutomation instalado dentro de uma conta de Automação do Azure:

Diagram of `GitAutomation` module for working with Git repositories.

Use a função Copy-GitRepository do módulo GitAutomation para clonar o repositório Git principal da URL especificada pelo URL para o caminho Git da plataforma de dados especificado por DestinationPath.

Essa abordagem para a implantação da zona de destino de dados é flexível, garantindo que as ações sejam compatíveis com os requisitos organizacionais. O gerenciamento do ciclo de vida é habilitado aplicando-se novos recursos ou otimizações dos modelos originais.

Processo de implantação de aplicativo de dados

Após a criação de uma zona de destino de dados, a integração pode ser iniciada para as equipes de aplicativo de dados. A plataforma de dados ou as equipes de operações da zona de destino de dados concedem aprovação de implantação.

A implantação é feita diretamente usando ferramentas de DevOps ou chamadas por meio de pipelines/fluxos de trabalho expostos como APIs. Semelhante à zona de destino de dados, a implantação começa com a bifurcação do repositório original de aplicativos de dados.

Diagram of the data application deployment automation.

  1. O usuário faz uma solicitação para novos serviços de aplicativo de dados.
  2. O processo de fluxo de trabalho solicita aprovação da equipe de operações da plataforma de dados ou da zona de destino de dados.
  3. O fluxo de trabalho chama a API de gerenciamento de serviços de TI para criar grupos de recursos necessários e a criação de uma conexão de serviço do Azure DevOps. O fluxo de trabalho atribui uma equipe ao projeto do Azure DevOps.
  4. O fluxo de trabalho bifurca o repositório original de aplicativos de dados para criar o destino do projeto do Azure DevOps.
  5. O fluxo de trabalho cria um arquivo de parâmetro e pipelines do modelo do Azure Resource Manager.
  6. Em seguida, o fluxo de trabalho inicia um pipeline do Azure para criar os requisitos de rede e outro pipeline do Azure para implantar os serviços de aplicativo de dados.
  7. O fluxo de trabalho notifica o usuário sobre a conclusão.

Dica

Se você for novo no DataOps, revise o DataOps para o laboratório prático de data warehouse moderno no Centro de Arquitetura do Azure. O cenário do laboratório descreve um escritório de planejamento de cidade fictícia que pode usar essa solução de implantação. A solução de implantação fornece um pipeline de dados de ponta a ponta que segue o padrão de arquitetura do data warehouse moderno, juntamente com os processos de DevOps e DataOps correspondentes, para avaliar o uso do estacionamento e tomar decisões de negócios fundamentadas.

Resumo

Os padrões acima fornecem controle, agilidade, autoatendimento e gerenciamento do ciclo de vida das políticas.

Diagram of the overall DataOps model.

No início do projeto, a plataforma de dados tem um projeto Azure DevOps com um ou mais Azure Boards. As equipes de DevOps individuais se concentram em:

  • Um repositório para a zona de destino de gerenciamento de dados, pipelines e uma conexão de serviço para o ambiente de nuvem.
  • Um repositório de modelos para a zona de destino de dados, pipelines para implantar uma instância de zona de destino de dados e conexões de serviço para ambientes de nuvem.
  • Um repositório de modelos para serviços de produto de dados, pipelines para implantar uma instância de produto de dados e conexões de serviço para ambientes de nuvem. Essas conexões são bifurcadas no Azure DevOps Projects da zona de destino.

Depois que as zonas de destino de dados forem implantadas, a análise de escala de nuvem prescreverá que:

  • Cada zona de destino de dados terá seu próprio projeto do Azure DevOps com um ou mais Azure Boards.
  • Para cada aplicativo de dados, a bifurcação de projeto do Azure DevOps da zona de destino de dados é criada após a aprovação da solicitação.
  • Cada aplicativo de dados inclui:
    • Uma conexão de serviço.
    • Um pipeline registrado.
    • Uma equipe de DevOps com acesso ao seu painel e repositório do Azure.
    • Um conjunto diferente de políticas para o repositório bifurcado.

Para controlar a implantação de aplicativos de dados, siga estas práticas:

  • A equipe de operações da zona de destino de dados possui e protege a ramificação principal do repositório.
  • Somente a ramificação principal é usada para implantar em ambientes de teste e produção.
  • As ramificações de recursos podem ser implantadas em ambientes de desenvolvimento.
  • As ramificações de recursos são de propriedade das equipes de DataOps. Eles são usados para testar recursos novos ou modificados.
  • As equipes de DataOps podem mesclar ramificações de recursos em outras ramificações de recursos sem aprovação.
  • As equipes de DataOps criam uma solicitação de pull para mesclar ramificações de recursos na ramificação principal, e a equipe de operações da zona de destino de dados dá a aprovação.
  • Novos recursos ou aprimoramentos nos modelos originais são mesclados no repositório bifurcado para mantê-los atualizados.

Próximas etapas