Entender as implantações de ponta a ponta
Os fluxos de trabalho do GitHub Actions são ferramentas flexíveis que podem ser configuradas de várias maneiras para atender às suas necessidades. Nesta unidade, você vai aprender a usar fluxos de trabalho para implantar uma solução inteira, incluindo a configuração da infraestrutura do Azure e para executar outras operações de implantação.
Quantos fluxos de trabalho?
Em algumas organizações, a equipe que gerencia o ambiente do Azure é diferente da equipe que desenvolve o código que é executado no ambiente. Nessas situações, muitas vezes é tentador criar vários fluxos de trabalho, cada um pertencente à equipe responsável por sua área específica. Por exemplo, você pode criar um fluxo de trabalho para implantar o código Bicep que implanta os recursos do Azure de seu site e outro fluxo de trabalho que implanta o aplicativo do site.
Embora essa abordagem possa dar alguma flexibilidade na forma em que você gerencia os fluxos de trabalho, pode ser desafiador manter tudo em sincronia. Por exemplo, suponha que sua equipe de site precise de uma nova configuração no aplicativo de Serviço de Aplicativo do Azure para habilitar um recurso que está sendo elaborado. O fluxo de trabalho de implantação de aplicativo não pode ser executado até que o fluxo de trabalho de implantação de infraestrutura seja concluído com êxito. Além disso, pode se tornar complicado enviar dados, como os nomes dos recursos do Azure criados por seu fluxo de trabalho de infraestrutura, entre os fluxos de trabalho.
Em vez disso, costuma ser melhor criar um só fluxo de trabalho que implante tudo o que é necessário para a sua solução, mesmo que pessoas ou equipes diferentes gerenciem os componentes. Você pode usar ferramentas como Git e GitHub para coordenar seu trabalho. Quando um recurso é adicionado, você pode usar uma ramificação para fazer as alterações necessárias ao arquivo Bicep. Quando a alteração estiver pronta para ser integrada e liberada, um fluxo de trabalho individual executará todas as etapas necessárias para compilar e implantar a solução, o que reduz a probabilidade de que as coisas fiquem fora de sincronia.
Dica
Quando você estiver criando código para sua solução, provavelmente precisará implantá-la com frequência para que possa testar como ela funciona. Você pode descobrir que implantar sua infraestrutura com o código do aplicativo torna o fluxo de trabalho lento e inibe seu progresso.
Se você estiver nesta posição, poderá considerar desabilitar a implantação de infraestrutura para seu ambiente de desenvolvimento. Você pode usar filtros de caminho, fluxos de trabalho reutilizáveis e condições para fazer isso. No entanto, deve deixar a sequência de implantação completa intacta para seus outros ambientes.
O plano de controle e o plano de dados
Muitos recursos do Azure fornecem dois planos diferentes para o acesso. O plano de controle implanta e configura o recurso. O plano de dados permite que você acesse a funcionalidade do recurso.
Ao criar e implantar arquivos Bicep, você interage com o plano de controle. No Azure, o plano de controle é o Azure Resource Manager. Você usa o Resource Manager para definir a configuração de cada um dos seus recursos.
No entanto, seu fluxo de trabalho geralmente precisa fazer mais do que apenas interagir com o painel de controle. Por exemplo, talvez seja necessário:
- Carregar um blob a uma conta de armazenamento.
- Modificar um esquema de banco de dados.
- Fazer uma chamada à API para um serviço de terceiros.
- Disparar uma atualização de modelo de machine learning.
- Implantar um site em um aplicativo de Serviço de Aplicativo do Azure.
- Implantar o software em uma máquina virtual.
- Registrar uma entrada DNS com um provedor de terceiros.
Quando você considera um fluxo de trabalho de ponta a ponta, normalmente, precisa implantar os recursos do Azure e depois executar uma série de operações nos planos de dados desses recursos. Às vezes, essas operações são chamadas de último quilômetro da implantação, porque você está executando a maior parte da implantação usando o plano de controle e apenas uma pequena quantidade de configuração permanece.
Observação
Alguns recursos não têm uma divisão clara entre o plano de controle e o plano de dados. Isso inclui o Azure Data Factory e o Gerenciamento de API do Azure. Os dois serviços dão suporte a implantações totalmente automatizadas usando Bicep, mas exigem considerações especiais. Você encontrará links para obter mais informações na página Resumo no final do módulo.
Como executar operações de plano de dados
Ao criar um fluxo de trabalho de implantação que interage com o plano de dados de seus recursos, você poderá usar qualquer uma das três abordagens comuns:
- Scripts de implantação do Resource Manager
- Scripts do fluxo de trabalho
- Ações do fluxo de trabalho
Scripts de implantação do Resource Manager são definidos no arquivo Bicep. Eles executam scripts do Bash ou do PowerShell e podem interagir com os cmdlets da CLI do Azure e do Azure PowerShell. Você cria uma identidade gerenciada para o script de implantação a ser usada para autenticação no Azure e o Azure provisiona e gerencia automaticamente os outros recursos necessários para executar o script de implantação.
Os scripts de implantação são bons quando você precisa executar um script básico no seu processo de implantação, mas eles não fornecem facilmente acesso a outros elementos do fluxo de trabalho.
Você também pode executar sua própria lógica de dentro de um fluxo de trabalho de implantação. O GitHub Actions fornece um rico ecossistema de ações para coisas comuns que você precisa fazer. Se você não encontrar uma ação que atenda às suas necessidades, poderá usar um script para executar seu código Bash ou PowerShell. As ações de fluxo de trabalho e os scripts são executados no executor do fluxo de trabalho. Geralmente, você precisa autenticar a ação ou o script no plano de dados do serviço que está usando, e a maneira como você faz isso depende do serviço.
As ações e scripts do fluxo de trabalho oferecem flexibilidade e controle. Também permitem que você acesse artefatos de fluxo de trabalho, que você verá em breve. Neste módulo, nos concentramos em ações do fluxo de trabalho. Há link para mais informações sobre scripts de implantação do Resource Manager na página Resumo no final do módulo.
Saídas
Um fluxo de trabalho normalmente cria e configura seus recursos do Azure implantando um arquivo Bicep. As partes seguintes do fluxo de trabalho interagem com o plano de dados desses recursos. Para interagir com os recursos, as tarefas e ações do fluxo de trabalho precisam de informações sobre o recurso do Azure que foi criado.
Por exemplo, suponha que você tenha um arquivo Bicep que implanta uma conta de armazenamento. Você quer que seu fluxo de trabalho implante a conta de armazenamento e depois carregue alguns blobs em um contêiner de blobs na conta de armazenamento. A etapa do fluxo de trabalho que carrega os blobs precisa saber o nome da conta de armazenamento à qual se conectar e o nome do contêiner de blobs para o qual carregar o arquivo.
É uma boa prática fazer com que o arquivo Bicep decida sobre os nomes dos seus recursos do Azure. Ele pode usar parâmetros, variáveis ou expressões para criar os nomes para a conta de armazenamento e o contêiner de blob. O arquivo Bicep pode expor uma saída que fornece o nome de cada recurso. As etapas posteriores do fluxo de trabalho podem ler o valor de saída. Dessa forma, sua definição de fluxo de trabalho não precisa codificar nenhum nome ou outras informações que possam mudar entre ambientes ou se basear em regras definidas em seu arquivo Bicep.
Com o GitHub Actions, você pode propagar os valores de saídas usando variáveis do fluxo de trabalho. A ação azure/arm-deploy cria automaticamente variáveis para cada uma de suas saídas de implantação do Bicep. Você também pode criar manualmente variáveis do fluxo de trabalho em scripts. Você encontrará links para obter mais informações na página Resumo no final deste módulo.
Ao acessar variáveis que foram criadas em outro trabalho, você precisará publicar a variável para torná-la acessível ao trabalho que a lê. Por exemplo, suponha que você crie um trabalho que implanta um arquivo Bicep e precisa propagar a saída appServiceAppName para o fluxo de trabalho. Use a palavra-chave outputs para especificar que a variável de fluxo de trabalho appServiceAppName deve ser definida como o valor da variável de saída appServiceAppName criada pela etapa deploy:
job1:
runs-on: ubuntu-latest
outputs:
appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy Bicep file
with:
failOnStdErr: false
deploymentName: ${{ github.run_number }}
resourceGroupName: Playground1
template: ./deploy/main.bicep
Em um trabalho posterior, você cria uma dependência explícita no trabalho que criou a variável, incluindo a palavra-chave needs, e faz referência à variável usando o nome da variável publicada:
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
Usando as saídas do Bicep e as variáveis do fluxo de trabalho, você pode criar um fluxo de trabalho que implante o código Bicep e execute várias ações nos recursos como parte da implantação.