Início Rápido: Implantar arquivos Bicep usando GitHub Actions

Artigo
09/26/2024

O GitHub Actions é um conjunto de recursos do GitHub para automatizar seus fluxos de trabalho de desenvolvimento de software. Neste início rápido, use o GitHub Actions de implantação do Azure Resource Manager para automatizar a implantação de um arquivo Bicep no Azure.

Ele fornece uma breve introdução a ações do GitHub e arquivos Bicep. Se você quiser etapas mais detalhadas sobre como configurar as ações do GitHub e o projeto, confira Implantar recursos do Azure usando o Bicep e o GitHub Actions.

Pré-requisitos

Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.
Uma conta do GitHub. Caso ainda não tenha uma, inscreva-se gratuitamente.
Um repositório do GitHub para armazenar seus arquivos do Bicep e seus arquivos de fluxo de trabalho. Para criá-lo, confira Como criar um repositório.

Criar grupo de recursos

Crie um grupos de recursos. Posteriormente, neste guia de início rápido, você implantará seu arquivo Bicep nesse grupo de recursos.

CLI
PowerShell

az group create -n exampleRG -l westus

New-AzResourceGroup -Name exampleRG -Location westus

O GitHub Actions é executado sob uma identidade. Use o comando az ad sp create-for-rbac para criar uma entidade de serviço para a identidade. Conceda à entidade de serviço a função de colaborador para o grupo de recursos criado na sessão anterior para que a ação do GitHub com a identidade possa criar recursos neste grupo de recursos. É recomendável que você conceda o acesso mínimo necessário.

az ad sp create-for-rbac --name {app-name} --role contributor --scopes /subscriptions/{subscription-id}/resourceGroups/exampleRG --json-auth

Substitua o espaço reservado {app-name} pelo nome do aplicativo. Substitua {subscription-id} por sua ID da assinatura.

A saída é um objeto JSON com as credenciais de atribuição de função que fornecem acesso ao aplicativo do Serviço de Aplicativo, semelhante à seguinte saída.

  {
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    ...
  }

Copie esse objeto JSON para uso posterior. Você só precisará das seções com os valores clientId, clientSecret, subscriptionId e tenantId. Verifique se não há uma vírgula extra no final da última linha, como na linha tenantId do exemplo anterior; caso contrário, isso resultará em um arquivo JSON inválido. Você receberá um erro durante a implantação dizendo "Falha no logon com o erro: o conteúdo não é um objeto JSON válido. Certifique-se de que o "tipo de autenticação" esteja correto."

O OpenID Connect é um método de autenticação que usa tokens de curta duração. A configuração do OpenID Connect com o GitHub Actions é um processo mais complexo que oferece segurança aprimorada.

Se você não tiver um aplicativo existente, registre um novo aplicativo do Active Directory e uma entidade de serviço que possa acessar recursos. Criar o aplicativo do Azure Active Directory.
```
az ad app create --display-name myApp
```
Esse comando gera um JSON com um appId que é seu client-id. Salve o valor para usar mais tarde como o segredo AZURE_CLIENT_ID do GitHub.

Você usará o valor objectId ao criar credenciais federadas com a API do Graph e ao referenciá-la como o APPLICATION-OBJECT-ID.
Crie uma entidade de serviço. Substitua $appID pelo AppID de sua saída JSON.

Esse comando gera uma saída JSON com um objectId diferente e será usado na próxima etapa. O novo objectId é o assignee-object-id.

Copie o appOwnerTenantId para usar mais tarde como um segredo do GitHub para AZURE_TENANT_ID.
```
 az ad sp create --id $appId
```
Crie uma atribuição de função por assinatura e objeto. Por padrão, a atribuição de função é vinculada à sua assinatura padrão. Substitua $subscriptionId pela ID da assinatura, $resourceGroupName pelo nome do grupo de recursos e $assigneeObjectId pelo assignee-object-id gerado. Saiba como gerenciar as assinaturas do Azure com a CLI do Azure.
```
az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --assignee-principal-type ServicePrincipal --scopes /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/
```
Execute o comando a seguir para criar uma credencial de identidade federada para seu aplicativo do Active Directory.
- Substitua APPLICATION-OBJECT-ID pelo objectId (gerado durante a criação do aplicativo) do aplicativo Active Directory.
- Defina um valor de CREDENTIAL-NAME para referência posterior.
- Defina o subject. O valor disso é definido pelo GitHub dependendo do seu fluxo de trabalho:
  - Trabalhos em seu ambiente do GitHub Actions: repo:< Organization/Repository >:environment:< Name >
  - Para trabalhos não vinculados a um ambiente, inclua o caminho de referência para ramificação/marca com base no caminho de referência usado para disparar o fluxo de trabalho: repo:< Organization/Repository >:ref:< ref path>. Por exemplo, repo:n-username/ node_express:ref:refs/heads/my-branch ou repo:n-username/ node_express:ref:refs/tags/my-tag.
  - Para fluxos de trabalho disparados por um evento de solicitação de pull: repo:< Organization/Repository >:pull_request.
```
az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<APPLICATION-OBJECT-ID>/federatedIdentityCredentials' --body '{"name":"<CREDENTIAL-NAME>","issuer":"https://token.actions.githubusercontent.com","subject":"repo:organization/repository:ref:refs/heads/main","description":"Testing","audiences":["api://AzureADTokenExchange"]}'
```
Para saber como criar um aplicativo Active Directory, uma entidade de serviço e as credenciais federadas no portal do Azure, confira Conexão entre GitHub e Azure.

Configurar os segredos do GitHub

Entidade de serviço
OpenID Connect

Crie segredos para suas credenciais, seu grupo de recursos e suas assinaturas do Azure. Você usará esses segredos na seção Criar fluxo de trabalho.

Navegar até o repositório no GitHub.
Selecione Configurações > Segredos e variáveis > Ações > Novo segredo do repositório.
Cole toda a saída JSON do comando da CLI do Azure no campo valor do segredo. Nomeie o segredo como AZURE_CREDENTIALS.
Crie outro segredo chamado AZURE_RG. Adicione o nome do grupo de recursos ao campo de valor do segredo (exampleRG).
Crie outro segredo chamado AZURE_SUBSCRIPTION. Adicione sua ID de assinatura ao campo de valor do segredo (exemplo: 90fd3f9d-4c61-432d-99ba-1273f236afa2).

Você precisa fornecer a ID do cliente, a ID do locatário e a ID da assinatura do seu aplicativo para a ação de logon. Esses valores podem ser fornecidos diretamente no fluxo de trabalho ou podem ser armazenados em segredos do GitHub e referenciados em seu fluxo de trabalho. Salvar os valores como segredos do GitHub é a opção mais segura.

Abra o repositório do GitHub e vá para Configurações.
Selecione Configurações > Segredos > Novo segredo.
Crie segredos para AZURE_CLIENT_ID, AZURE_TENANT_ID e AZURE_SUBSCRIPTION_ID. Use esses valores do seu aplicativo do Active Directory para seus segredos do GitHub:

Segredo do GitHub Aplicativo do AD DS

AZURE_CLIENT_ID ID do aplicativo (cliente)

AZURE_TENANT_ID ID do diretório (locatário)

AZURE_SUBSCRIPTION_ID ID da assinatura
Salve cada segredo selecionando Adicionar segredo.

Segredo do GitHub	Aplicativo do AD DS
AZURE_CLIENT_ID	ID do aplicativo (cliente)
AZURE_TENANT_ID	ID do diretório (locatário)
AZURE_SUBSCRIPTION_ID	ID da assinatura

Adicionar um arquivo Bicep

Adicione um arquivo Bicep ao seu repositório do GitHub. O arquivo Bicep a seguir cria uma conta de armazenamento:

@minLength(3)
@maxLength(11)
param storagePrefix string

@allowed([
  'Standard_LRS'
  'Standard_GRS'
  'Standard_RAGRS'
  'Standard_ZRS'
  'Premium_LRS'
  'Premium_ZRS'
  'Standard_GZRS'
  'Standard_RAGZRS'
])
param storageSKU string = 'Standard_LRS'

param location string = resourceGroup().location

var uniqueStorageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource stg 'Microsoft.Storage/storageAccounts@2023-04-01' = {
  name: uniqueStorageName
  location: location
  sku: {
    name: storageSKU
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

output storageEndpoint object = stg.properties.primaryEndpoints

O arquivo Bicep exige um parâmetro chamado storagePrefix com 3 a 11 caracteres.

Você pode colocar o arquivo em qualquer lugar do repositório. O exemplo de fluxo de trabalho na próxima seção considera que o arquivo Bicep é denominado main.bicep e está armazenado na raiz do repositório.

Criar fluxo de trabalho

Um fluxo de trabalho define as etapas a serem executadas quando disparadas. É um arquivo YAML (.yml) no caminho .github/workflows/do do seu repositório. A extensão do arquivo do fluxo de trabalho pode ser .yml ou .yaml.

Para criar um fluxo de trabalho, tome as seguintes etapas:

No repositório GitHub, selecione Actions no menu superior.
Selecione Novo fluxo de trabalho.
Selecione Configurar fluxo de trabalho por conta própria.
Renomeie o arquivo do fluxo de trabalho se preferir usar um nome diferente de main.yml. Por exemplo: deployBicepFile.yml.

Substitua o conteúdo do arquivo yml pelo seguinte código:

Entidade de serviço
OpenID Connect

name: Deploy Bicep file
on: [push]
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

    - name: Checkout code
      uses: actions/checkout@main

    - name: Log into Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Deploy Bicep file
      uses: azure/arm-deploy@v1
      with:
        subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
        resourceGroupName: ${{ secrets.AZURE_RG }}
        template: ./main.bicep
        parameters: 'storagePrefix=mystore storageSKU=Standard_LRS'
        failOnStdErr: false

Substitua mystore pelo seu prefixo de nome da conta de armazenamento.

Observação

Em vez disso, você pode especificar um arquivo de parâmetros de formato JSON na ação De implantação do ARM (exemplo: .azuredeploy.parameters.json).

A primeira seção do arquivo de fluxo de trabalho inclui:

nome: Nome do fluxo de trabalho.
Ativado: o nome dos eventos do GitHub que acionam o fluxo de trabalho. O fluxo de trabalho é acionado quando há um evento de push na ramificação principal.

on: [push]
name: Azure ARM
permissions:
  id-token: write
  contents: read
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:

      # Checkout code
    - uses: actions/checkout@main

      # Log into Azure
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      # Deploy Bicep file
    - name: deploy
      uses: azure/arm-deploy@v1
      with:
        subscriptionId: ${{ secrets.AZURE_SUBSCRIPTION }}
        resourceGroupName: ${{ secrets.AZURE_RG }}
        template: ./main.bicep
        parameters: 'storagePrefix=mystore storageSKU=Standard_LRS'
        failOnStdErr: false

Selecione Confirmar alterações.
Selecione Confirmar diretamente na ramificação principal.
Selecione Confirmar novo arquivo (ou Confirmar alterações).

A atualização do arquivo de fluxo de trabalho ou do arquivo Bicep dispara o fluxo de trabalho. O fluxo de trabalho é iniciado logo após o commit das alterações.

Verificar status do fluxo de trabalho

Selecione a guia Actions. Você verá um fluxo de trabalho chamado Criar deployBicepFile.yml listado. O fluxo de trabalho leva de um a dois minutos para ser executado.
Selecione o fluxo de trabalho para abri-lo e verifique se o Status é Success.

Limpar os recursos

Quando seu grupo de recursos e repositório não forem mais necessários, limpe os recursos implantados excluindo o grupo de recursos e o repositório GitHub.

CLI
PowerShell

az group delete --name exampleRG

Remove-AzResourceGroup -Name exampleRG

Próximas etapas

Estrutura e sintaxe de arquivos Bicep

Compartilhar via