Compartilhar via


Gerenciar análise de escala de nuvem

Hoje, o DevOps mudou a cultura de como as pessoas pensam e trabalham, acelerando a taxa na qual as empresas percebem valor, ajudando indivíduos e organizações a desenvolver e manter práticas de trabalho sustentáveis. O DevOps combina desenvolvimento e operações e, muitas vezes, está associado a ferramentas de engenharia de software que dão suporte a práticas de integração contínua (CI) e de entrega contínua (CD). Essas ferramentas e práticas incluem gerenciadores de código-fonte (como o Git, o Apache Subversion ou o Controle de Versão do Team Foundation) e gerentes de compilação e entrega automáticos (como o Azure Pipelines ou o GitHub Actions).

O DevOps combinado com a observabilidade é fundamental para fornecer uma plataforma ágil e escalonável. O DevOps oferece às equipes a capacidade de implementar controle do código-fonte, pipelines de CI/CD, infraestrutura como código, Fluxos de trabalho e automação. Embora a observabilidade permita que proprietários de negócios, engenheiros de DevOps, arquitetos de dados, engenheiros de dados e engenheiros de confiabilidade do site detectem, prevejam, impeçam e resolve problemas de forma automatizada e evitem eliminar o tempo de inatividade que, de outra forma, interromperia a análise de produção e a IA.

Controle do código-fonte

O controle do código-fonte garante que o código e as configurações persistam e que as alterações sejam rastreadas e passem por controle de versão. A maioria dos sistemas de controle do código-fonte também tem processos internos para revisão e trabalho em diferentes ramificações de um repositório de código. Atualmente, o tipo de controle do código-fonte mais popular é o Git, que é um sistema de controles de versão distribuído que permite que os indivíduos trabalhem offline e sincronizem com repositórios centrais. Os fornecedores do Git normalmente também usam ramificações e seguem as diretrizes de solicitação de pull para dar suporte ao fluxo de alteração e revisão.

As ramificações isolam as alterações ou desenvolvimentos de recursos sem afetar outros trabalhos que ocorrem ao mesmo tempo. O uso de ramificações deve ser promovido para desenvolver recursos, corrigir bugs e experimentar com segurança novas ideias. As solicitações de pull mesclam as alterações feitas de uma ramificação na ramificação padrão e oferecem suporte a um processo de revisão controlado. Para fins de segurança, a ramificação principal deve usar solicitações de pull para garantir revisões de código.

Importante

Siga estas diretrizes para repositórios de análise de escala de nuvem:

  • Proteja a ramificação principal do repositório através da imposição de ramificações e solicitações de pull para garantir um processo de revisão controlado.
  • Os repositórios do Azure DevOps ou GitHub devem ser usados para o controle do código-fonte a fim de controlar as alterações no código-fonte e permitir que vários membros da equipe desenvolvam código ao mesmo tempo.
  • O código do aplicativo e as configurações de infraestrutura devem ser verificados em um repositório.

Pipelines de CI/CD

A CI permite que as equipes testem e compilem automaticamente o código-fonte e permite iterações rápidas e loops de comentários para garantir a alta qualidade de código na CD. Os pipelines são maneiras de configurar a CI de alterações (código de software ou código de infraestrutura) e a CD das alterações empacotadas/compiladas. Isso também é conhecido como build e versão. A CD descreve a implantação automática de aplicativos em um ou mais ambientes. A CD geralmente segue um processo de CI e usa testes de integração para validar o aplicativo inteiro.

Os pipelines podem conter vários estágios com várias tarefas e podem ter fluxos de aprovação simples a complexos para garantir a conformidade e a validação. Com base na preferência, os pipelines também podem ser configurados com vários gatilhos automáticos. Para a implantação em escala empresarial e de inteligência artificial, as etapas de produção sempre devem ter a pré-aprovação humana, e isso é incorporado ao modelo de operação. Os pipelines de CI/CD devem ser criados com o GitHub Actions ou o Azure Pipelines e devem ser gatilhos automatizados.

Infraestrutura como código

O termo código na IaC geralmente gera preocupações para a equipe de TI sem uma experiência de desenvolvedor, mas a IaC não se refere à escrita de código da maneira como os desenvolvedores de software típicos fazem isso. No entanto, ele adota muitas das mesmas ferramentas e princípios dos processos de desenvolvimento de software para fornecer infraestrutura em um formato previsível.

o IaC ajuda a infraestrutura a ser provisionada, configurada e gerenciada como parte de um pipeline de DevOps com controles de alteração completos, histórico de auditoria, testes, validações e processos de aprovação, garantindo que as tarefas possam ser delegadas às funções apropriadas para o projeto sem comprometer a segurança e a conformidade.

As duas abordagens à IaC são declarativas e imperativas:

  • “Declarativa” refere-se à especificação do estado desejado da infraestrutura e de ter um mecanismo de orquestração para executar as ações necessárias para atingir o estado desejado. No Azure, isso é feito com modelos do Azure Resource Manager. Camadas de abstração de terceiros, como a Terraform, também estão disponíveis para essa abordagem.

  • A abordagem imperativa refere-se à execução de comandos específicos em uma ordem definida. Para o Azure, isso pode ser feito com a interface de linha de comando ou o PowerShell, porém, os kits de desenvolvedor de software de linguagem de programação nativa, por exemplo, .NET, Python e Java, também estarão disponíveis se as soluções integradas forem necessárias.

Em modelos do Azure Resource Manager, o provisionamento principal está na seção de recursos e a configuração dos recursos individuais é definida em uma seção de propriedades. Para um Azure Data Lake Storage Gen2, a configuração é semelhante ao seguinte:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.MachineLearningServices/workspaces/datastores",
            "name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
            "apiVersion": "2020-05-01-preview",
            "location": "[parameters('location')]",
            "properties": {
                "DataStoreType": "adls-gen2",
                "SkipValidation": "[parameters('skipValidation')]",
                "ClientId": "[parameters('clientId')]",
                "ClientSecret": "[parameters('clientSecret')]",
                "FileSystem": "[parameters('fileSystem')]",
                "AccountName": "[parameters('accountName')]",
                "TenantId": "[parameters('tenantId')]",
                "ResourceUrl": "[parameters('resourceUrl')]",
                "AuthorityUrl": "[parameters('authorityUrl')]"
            }
        }
    ]
}

Importante

Cada camada de análise em escala de nuvem, como zona de destino de gerenciamento de dados, zonas de destino de dados ou aplicativos de dados (que criam produtos de dados), deve ser definida com uma linguagem declarativa como a Resource Manager do Azure ou o Terraform, verificada em um repositório e implantada por meio de pipelines de CI/CD. Isso permite que as equipes acompanhem e controlem as alterações na infraestrutura e na configuração do escopo do Azure, oferecendo suporte a diferentes níveis de arquitetura para serem automatizados de forma ágil. Este guia leva as equipes a usar os repositórios do Git para sempre ter visibilidade do estado de escopos específicos do Azure.

Fluxos de trabalho e automação

As equipes devem usar pipelines de CI/CD em vários estágios para garantir que o código desenvolvido esteja sem erros e pronto para produção. Algumas melhores práticas são ter um ambiente de desenvolvimento, um ambiente de teste e um ambiente de produção. Essas fases também devem ser refletidas no Azure por meio do uso de serviços separados para cada ambiente.

A equipe de plataforma é responsável por fornecer e manter modelos de implantação a fim de dimensionar rapidamente dentro de uma organização e simplificar implantações para equipes que não conhecem o IaC. Esses modelos servem como uma linha de base para novos artefatos dentro do cenário e precisam ser mantidos ao longo do tempo para representar melhores práticas e padrões comuns dentro da empresa.

As implantações para teste e produção somente devem ser gerenciadas por meio de um pipeline de CI/CD e de uma conexão de serviço com permissões elevadas para impor melhores práticas comuns (por exemplo, modelos do Azure Resource Manager).

Cuidado

As equipes de aplicativos de dados só devem ter acesso de leitura para ambientes de teste e produção, e as implantações nesses ambientes só devem ser executadas por meio de pipelines de CI/CD e conexões de serviço com permissões elevadas. Para acelerar o caminho para a produção, as equipes de aplicativos de dados devem ter acesso de gravação ao ambiente de desenvolvimento.

Próximas etapas

Automação de plataforma