Compreender as implantações de ponta a ponta
Os fluxos de trabalho do GitHub Actions são ferramentas flexíveis que você pode configurar de muitas maneiras diferentes para atender às suas necessidades. Nesta unidade, você aprenderá a usar fluxos de trabalho para implantar uma solução inteira, incluindo a configuração da infraestrutura do Azure, e a 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 executado no ambiente. Nessas situações, muitas vezes é tentador criar vários fluxos de trabalho, cada um de propriedade da 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 do seu site e outro fluxo de trabalho que implanta o aplicativo do site.
Embora essa abordagem possa lhe dar alguma flexibilidade em como você gerencia os fluxos de trabalho, pode ser um desafio manter tudo sincronizado. Por exemplo, suponha que sua equipe de site precise de uma nova configuração em seu aplicativo do Serviço de Aplicativo do Azure para habilitar um recurso que está criando. 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 tenha sido concluído com êxito. Além disso, pode tornar-se complicado enviar dados, como os nomes dos recursos do Azure criados pelo seu fluxo de trabalho de infraestrutura, entre os fluxos de trabalho.
Em vez disso, geralmente é melhor criar um único fluxo de trabalho que implante tudo o que é necessário para sua solução, mesmo que os componentes sejam gerenciados por pessoas diferentes ou equipes diferentes. Você pode usar ferramentas como Git e GitHub para coordenar seu trabalho. Quando um novo recurso é adicionado, você pode usar uma ramificação para fazer as alterações necessárias no arquivo Bicep. E quando a alteração está pronta para ser integrada e lançada, um único fluxo de trabalho executa todas as etapas necessárias para criar e implantar a solução, o que reduz a chance de as coisas ficarem fora de sincronia.
Gorjeta
Quando você estiver criando código para sua solução, provavelmente precisará implantá-lo com frequência para que possa testar como ele funciona. Você pode achar que implantar sua infraestrutura junto com o código do aplicativo faz com que seu fluxo de trabalho seja executado lentamente e inibe seu progresso.
Se você estiver nessa posição, considere 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 conseguir isso. No entanto, você deve deixar a sequência de implantação completa intacta para seus outros ambientes.
O plano de controlo e o plano de dados
Muitos recursos do Azure fornecem dois planos diferentes para 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 Gerenciador de Recursos do Azure. Você usa o Gerenciador de Recursos para definir a configuração de cada um dos seus recursos.
Mas seu fluxo de trabalho geralmente precisa fazer mais do que apenas interagir com o plano de controle. Por exemplo, talvez seja necessário:
- Carregue um blob para uma conta de armazenamento.
- Modifique um esquema de banco de dados.
- Faça uma chamada de API para um serviço de terceiros.
- Acione a atualização de um modelo de aprendizado de máquina.
- Implante um site em um aplicativo do Serviço de Aplicativo do Azure.
- Implante software em uma máquina virtual.
- Registre uma entrada DNS com um provedor de terceiros.
Quando você considera um fluxo de trabalho de ponta a ponta, normalmente precisa implantar seus recursos do Azure e, em seguida, executar uma série de operações nos planos de dados desses recursos. Às vezes, essas operações são chamadas de última milha 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.
Nota
Alguns recursos não têm uma divisão clara entre o plano de controle e o plano de dados. Estes incluem o Azure Data Factory e o Azure API Management. Ambos os serviços suportam implantações totalmente automatizadas usando o Bicep, mas exigem considerações especiais. Você encontrará links para mais informações na página Resumo no final do módulo.
Como realizar 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ê pode usar qualquer uma das três abordagens comuns:
- Scripts de implantação do Resource Manager
- Scripts de fluxo de trabalho
- Ações de fluxo de trabalho
Os scripts de implantação do Resource Manager são definidos no arquivo Bicep. Eles executam scripts Bash ou PowerShell e podem interagir com comandos da CLI do Azure e cmdlets do Azure PowerShell. Você cria uma identidade gerenciada para o script de implantação a ser usado para autenticar 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 em seu processo de implantação. No entanto, eles não fornecem facilmente acesso a outros elementos do seu fluxo de trabalho.
Você também pode executar sua própria lógica a partir 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 não conseguir encontrar uma ação que atenda às suas necessidades, você pode usar um script para executar seu próprio código Bash ou PowerShell. As ações e scripts do fluxo de trabalho são executados a partir do executor do fluxo de trabalho. Muitas vezes, 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. Eles também permitem que você acesse artefatos de fluxo de trabalho, sobre os quais você aprenderá em breve. Neste módulo, focamo-nos nas ações do fluxo de trabalho. Temos links para obter mais informações sobre scripts de implantação do Resource Manager na página Resumo no final do módulo.
Resultados
Normalmente, um fluxo de trabalho cria e configura seus recursos do Azure implantando um arquivo Bicep. As partes subsequentes do fluxo de trabalho interagem com o plano de dados desses recursos. Para poder interagir com os recursos, as ações e etapas 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ê deseja que seu fluxo de trabalho implante a conta de armazenamento e, em seguida, carregue alguns blobs para um contêiner de blob 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 blob para o qual carregar o arquivo.
É uma boa prática fazer com que o arquivo Bicep decida os nomes dos seus recursos do Azure. Ele pode usar parâmetros, variáveis ou expressões para criar os nomes da conta de armazenamento e do contêiner de blob. O arquivo Bicep pode então expor uma saída que fornece o nome de cada recurso. Etapas posteriores no fluxo de trabalho podem ler o valor da saída. Dessa forma, sua definição de fluxo de trabalho não precisa codificar nomes ou outras informações que possam mudar entre ambientes ou ser baseadas em regras definidas no arquivo Bicep.
Com as Ações do GitHub, você pode propagar os valores das saídas usando variáveis de fluxo de trabalho. A azure/arm-deploy ação cria automaticamente variáveis para cada uma das saídas de implantação do Bicep. Você também pode criar manualmente variáveis de fluxo de trabalho em scripts. Você encontrará links para mais informações na página Resumo no final do módulo.
Quando você acessa variáveis que foram criadas em outro trabalho, precisa 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 precise propagar a saída para seu appServiceAppName fluxo de trabalho. Use a palavra-chave para especificar que a outputsappServiceAppName variável de fluxo de trabalho deve ser definida como o valor da variável de appServiceAppName saída criada pela deploy etapa:
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 seguida, em um trabalho posterior, você cria uma dependência explícita no trabalho que criou a variável incluindo a needs palavra-chave e se refere à variável usando o nome da variável publicada:
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
Usando saídas Bicep e variáveis de fluxo de trabalho, você pode criar um fluxo de trabalho que implanta seu código Bicep e, em seguida, executa várias ações nos recursos como parte de sua implantação.