Gerir análises à escala da cloud
Atualmente, o DevOps mudou a cultura de como as pessoas pensam e trabalham, acelerando o ritmo a que 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 é frequentemente associado a ferramentas de engenharia de software que suportam a integração contínua (CI) e práticas de entrega contínua (CD). Estas ferramentas e práticas incluem gestores de código fonte (como Git, Apache Subversion ou Controlo de Versões do Team Foundation) e gestores automáticos de compilação e entrega (tais como Pipelines do Azure ou GitHub Actions).
O DevOps combinado com a observabilidade é fundamental para fornecer uma plataforma ágil e dimensionável. O DevOps dá às equipas a capacidade de implementar controlo de origem, pipelines ci/CD, infraestrutura como código, Fluxos de trabalho e automatização. Embora a observabilidade permita aos proprietários de empresas, engenheiros do DevOps, arquitetos de dados, engenheiros de dados e engenheiros de fiabilidade do site detetar, prever, prevenir e resolver problemas de forma automatizada e evitar eliminar períodos de indisponibilidade que, de outra forma, iriam interromper a análise de produção e a IA.
Controlo de código fonte
O controlo de origem garante que o código e as configurações persistem e que as alterações são controladas e com o controlo de versões. A maioria dos sistemas de controlo de origem também tem processos incorporados para rever e trabalhar em ramos diferentes de um repositório de código. Atualmente, o tipo de controlo de origem mais popular atualmente é o Git, que é um sistema de controlos de versão distribuído que permite que os indivíduos trabalhem offline e sincronizem com repositórios centrais. Normalmente, os fornecedores do Git também utilizam ramos e seguem as orientações de pedidos Pull para suportar o fluxo de alteração e revisão.
Os ramos isolam alterações ou desenvolvimentos de funcionalidades sem afetar outros trabalhos que ocorrem ao mesmo tempo. A utilização de ramos deve ser promovida para desenvolver funcionalidades, corrigir erros e experimentar com segurança novas ideias. Os pedidos Pull intercalam as alterações feitas de um ramo no ramo predefinido e suportam um processo de revisão controlado. Para fins de segurança, o ramo principal deve utilizar pedidos Pull para garantir revisões de código.
Importante
Siga estas diretrizes para repositórios de análise à escala da cloud:
- Proteja o ramo principal do repositório ao impor ramos e pedidos Pull para garantir processos de revisão controlados.
- Os repositórios do Azure DevOps ou do GitHub devem ser utilizados para o controlo de código fonte para controlar as alterações ao código fonte e permitir que vários membros da equipa desenvolvam código ao mesmo tempo.
- As configurações do código da aplicação e da infraestrutura devem ser verificadas num repositório.
Pipelines CI/CD
A CI permite que as equipas testem e criem automaticamente código fonte e permite iterações rápidas e ciclos de feedback para garantir uma elevada qualidade de código no CD. Os pipelines são formas de configurar a CI de alterações (código de software ou código de infraestrutura) e CD das alterações empacotadas/compiladas. Isto também é conhecido como compilação e versão. O CD descreve a implementação automática de aplicações num ou mais ambientes. Normalmente, o CD segue um processo de CI e utiliza testes de integração para validar toda a aplicação.
Os pipelines podem conter várias fases com várias tarefas e podem ter fluxos de aprovação simples e complexos para garantir a conformidade e a validação. Com base na preferência, os pipelines também podem ser configurados com vários acionadores automáticos. Para a implementação de IA e à escala empresarial, os passos de produção devem ter sempre pré-aprovação humana, o que está incorporado no modelo de operação. Os pipelines ci/CD devem ser criados com GitHub Actions ou pipelines do Azure e devem ser acionadores automatizados.
Infraestrutura como código
Muitas vezes, o termo código na IaC suscita preocupações para a equipa de TI sem formação para programadores, mas a IaC não se refere à escrita de código da forma como os programadores de software típicos o fazem. No entanto, adota muitas das mesmas ferramentas e princípios dos processos de desenvolvimento de software para fornecer infraestrutura num formato previsível.
A IaC ajuda a infraestrutura a ser aprovisionada, configurada e gerida como parte de um pipeline de DevOps com controlos de alteração completos, histórico de auditoria, testes, validações e processos de aprovação, garantindo que as tarefas podem ser delegadas às funções adequadas para o projeto sem comprometer a segurança e a conformidade.
As duas abordagens à IaC são declarativas e imperativas:
Declarativo refere-se a especificar o estado pretendido da infraestrutura e fazer com que um motor de orquestração execute as ações necessárias para alcançar o estado pretendido. No Azure, isto é feito com modelos de Resource Manager do Azure. Também estão disponíveis camadas de abstração de terceiros, como o Terraform, para esta abordagem.
A abordagem imperativa refere-se à execução de comandos específicos por uma ordem definida. Para o Azure, isto pode ser conseguido com a interface de linha de comandos ou o PowerShell, mas os kits de programador de software de linguagem de programação nativa, por exemplo. NET, Python e Java, também estão disponíveis se forem necessárias soluções integradas.
No Azure Resource Manager modelos, o aprovisionamento principal está na secção recursos e a configuração dos recursos individuais é definida numa secção de propriedades. Para uma Azure Data Lake Storage Gen2, a configuração tem o seguinte aspeto:
{
"$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
Todas as camadas de análise à escala da cloud, como a zona de destino da gestão de dados, as zonas de destino de dados ou as aplicações de dados (que criam produtos de dados), devem ser definidas com uma linguagem declarativa, como o Azure Resource Manager ou o Terraform, verificadas num repositório e implementadas através de pipelines de CI/CD. Isto permite que as equipas controlem e alterem a versão da infraestrutura e da configuração do âmbito do Azure, ao mesmo tempo que suportam diferentes níveis de arquitetura para serem automatizadas de uma forma ágil. Esta orientação leva as equipas a utilizar repositórios Git para terem sempre visibilidade sobre o estado de âmbitos específicos do Azure.
Fluxos de trabalho e automatização
O Teams deve utilizar pipelines de CI/CD em várias fases para garantir que o código desenvolvido está sem erros e pronto para produção. Algumas das melhores práticas são ter um ambiente de desenvolvimento, um ambiente de teste e um ambiente de produção. Estas fases também devem ser refletidas no Azure através da utilização de serviços separados para cada ambiente.
A equipa de plataforma é responsável por fornecer e manter modelos de implementação para dimensionar rapidamente numa organização e simplificar as implementações de equipas que não estão familiarizadas com a IaC. Estes modelos servem de linha de base para novos artefactos no cenário e têm de ser mantidos ao longo do tempo para representar as melhores práticas e padrões comuns na empresa.
As implementações para teste e produção só devem ser geridas através de um pipeline ci/CD e de uma ligação de serviço com permissões elevadas para impor melhores práticas comuns (por exemplo, modelos de Resource Manager do Azure).
Atenção
As equipas de aplicações de dados só devem ter acesso de leitura a ambientes de teste e produção, e as implementações nestes ambientes só devem ser executadas através de pipelines de CI/CD e ligações de serviço com permissões elevadas. Para acelerar o caminho para a produção, as equipas de aplicações de dados devem ter acesso de escrita ao ambiente de desenvolvimento.