Configurar armazenamento e bancos de dados

Concluído

Muitas vezes, parte do processo de implantação exige que você se conecte a bancos de dados ou serviços de armazenamento. Essa conexão pode ser necessária para aplicar um esquema de banco de dados, adicionar alguns dados de referência a uma tabela de banco de dados ou carregar alguns blobs. Nesta unidade, você aprenderá como estender seu fluxo de trabalho para trabalhar com dados e serviços de armazenamento.

Configurar seus bancos de dados a partir de um fluxo de trabalho

Muitos bancos de dados têm esquemas, que representam a estrutura dos dados contidos no banco de dados. Muitas vezes, é uma boa prática aplicar um esquema ao banco de dados a partir do fluxo de trabalho de implantação. Essa prática ajuda a garantir que tudo o que sua solução precisa seja implantado em conjunto. Ele também garante que, se houver um problema quando o esquema for aplicado, seu fluxo de trabalho exibirá um erro, para que você possa corrigir o problema e reimplantá-lo.

Ao trabalhar com o Azure SQL, você precisa aplicar esquemas de banco de dados conectando-se ao servidor de banco de dados e executando comandos usando scripts SQL. Esses comandos são operações de plano de dados. Seu fluxo de trabalho precisa se autenticar no servidor de banco de dados e, em seguida, executar os scripts. O GitHub Actions fornece a ação que pode se conectar a azure/sql-action um servidor de banco de dados SQL do Azure e executar comandos.

Alguns outros serviços de dados e armazenamento não precisam ser configurados usando uma API de plano de dados. Por exemplo, quando você trabalha com o Azure Cosmos DB, armazena seus dados em um contêiner. Você pode configurar seus contêineres usando o plano de controle, diretamente de dentro do arquivo Bicep. Da mesma forma, você também pode implantar e gerenciar a maioria dos aspetos dos contêineres de blob do Armazenamento do Azure no Bicep. No próximo exercício, você verá um exemplo de como criar um contêiner de blob a partir do Bicep.

Adicionar dados

Muitas soluções exigem que os dados de referência sejam adicionados aos seus bancos de dados ou contas de armazenamento antes de funcionarem. Os fluxos de trabalho podem ser um bom lugar para adicionar esses dados. Isso significa que, depois que o fluxo de trabalho é executado, seu ambiente está totalmente configurado e pronto para uso.

Também é útil ter dados de exemplo em seus bancos de dados, especialmente para ambientes que não são de produção. Os dados de amostra ajudam os testadores e outras pessoas que usam esses ambientes a testar sua solução imediatamente. Esses dados podem incluir produtos de amostra ou coisas como contas de usuário falsas. Geralmente, você não deseja adicionar esses dados ao seu ambiente de produção.

A abordagem que você usa para adicionar dados depende do serviço que você usa. Por exemplo:

  • Para adicionar dados a um banco de dados SQL do Azure, você precisa executar um script, de forma muito semelhante à configuração de um esquema.
  • Quando você precisa inserir dados no Azure Cosmos DB, precisa acessar sua API de plano de dados, o que pode exigir que você escreva algum código de script personalizado.
  • Para carregar blobs em um contêiner de blob de Armazenamento do Azure, você pode usar várias ferramentas de scripts de fluxo de trabalho, incluindo o aplicativo de linha de comando AzCopy, o Azure PowerShell ou a CLI do Azure. Cada uma dessas ferramentas entende como autenticar no Armazenamento do Azure em seu nome e como se conectar à API do plano de dados para carregar blobs.

Idempotência

Uma das características dos fluxos de trabalho de implantação e da infraestrutura como código é que você deve ser capaz de reimplantar repetidamente sem quaisquer efeitos colaterais adversos. Por exemplo, quando você reimplanta um arquivo Bicep que já implantou, o Azure Resource Manager compara o arquivo enviado com o estado existente de seus recursos do Azure. Se não houver alterações, o Resource Manager não fará nada. A capacidade de executar novamente uma operação repetidamente é chamada de idempotência. É uma boa prática garantir que seus scripts e outras etapas do fluxo de trabalho sejam idempotentes.

A idempotência é especialmente importante quando você interage com serviços de dados, porque eles mantêm o estado. Imagine que você está inserindo um usuário de exemplo em uma tabela de banco de dados do seu fluxo de trabalho. Se você não tiver cuidado, toda vez que executar seu fluxo de trabalho, um novo usuário de exemplo será criado. Este resultado provavelmente não é o que você quer.

Ao aplicar esquemas a um banco de dados SQL do Azure, você pode usar um pacote de dados, também chamado de arquivo DACPAC, para implantar seu esquema. Seu fluxo de trabalho cria um arquivo DACPAC a partir do código-fonte e cria um artefato de fluxo de trabalho, assim como em um aplicativo. Em seguida, o trabalho de implantação em seu fluxo de trabalho publica o arquivo DACPAC no banco de dados:

Diagram showing a workflow uploading and then referring to an artifact named 'database'.

Quando um arquivo DACPAC é implantado, ele se comporta de forma idempotente, comparando o estado de destino do seu banco de dados com o estado definido no pacote. Em muitas situações, isso significa que você não precisa escrever scripts que sigam o princípio da idempotência, porque as ferramentas lidam com isso para você. Algumas das ferramentas do Azure Cosmos DB e do Armazenamento do Azure também se comportam corretamente.

Mas quando você cria dados de exemplo em um banco de dados SQL do Azure ou outro serviço de armazenamento que não funciona automaticamente de forma idempotente, é uma boa prática escrever seu script para que ele crie os dados somente se eles ainda não existirem.

Também é importante considerar se talvez seja necessário reverter implantações, por exemplo, executando novamente uma versão mais antiga de um fluxo de trabalho de implantação. A reversão de alterações em seus dados pode se tornar complicada, portanto, considere cuidadosamente como sua solução funcionará se você precisar permitir reversões.

Segurança da rede

Às vezes, você pode aplicar restrições de rede a alguns de seus recursos do Azure. Essas restrições podem impor regras sobre solicitações feitas ao plano de dados de um recurso, como:

  • Este servidor de banco de dados só é acessível a partir de uma lista especificada de endereços IP.
  • Essa conta de armazenamento só pode ser acessada a partir de recursos implantados em uma rede virtual específica.

As restrições de rede são comuns com bancos de dados, porque pode parecer que não há necessidade de nada na Internet para se conectar a um servidor de banco de dados.

No entanto, as restrições de rede também podem dificultar o trabalho dos fluxos de trabalho de implantação com os planos de dados dos recursos. Quando você usa um corredor hospedado no GitHub, seu endereço IP não pode ser facilmente conhecido com antecedência e pode ser atribuído a partir de um grande pool de endereços IP. Além disso, os corredores hospedados no GitHub não podem ser conectados às suas próprias redes virtuais.

Algumas das ações que ajudam você a executar operações de plano de dados podem contornar esses problemas. Por exemplo, a azure/sql-action ação:

Diagram illustrating the firewall update process.

Quando você usa a azure/sql-action ação para trabalhar com um servidor lógico SQL do Azure ou banco de dados, ele usa sua identidade de carga de trabalho para se conectar ao plano de controle para o servidor lógico SQL do Azure. Ele atualiza o firewall para permitir que o corredor acesse o servidor a partir de seu endereço IP. Em seguida, ele pode enviar com êxito o arquivo DACPAC ou script para execução . Em seguida, a ação remove automaticamente a regra de firewall quando terminar.

Em outras situações, não é possível criar exceções como esta. Nessas circunstâncias, considere o uso de um corredor auto-hospedado, que é executado em uma máquina virtual ou outro recurso de computação que você controla. Em seguida, você pode configurar este corredor como precisar. Ele pode usar um endereço IP conhecido ou pode ser conectado à sua própria rede virtual. Não discutimos corredores auto-hospedados neste módulo, mas fornecemos links para mais informações na página Resumo no final do módulo.

Seu fluxo de trabalho de implantação

No próximo exercício, você atualizará seu fluxo de trabalho de implantação para adicionar novos trabalhos para criar os componentes de banco de dados do seu site, implantar o banco de dados e adicionar dados de semente:

Diagram showing the revised workflow, including a new database build job, a database deployment job, and data seeding jobs in the test environment.