Implantar ambientes efêmeros para revisões
O lint do código do Bicep fornece algumas indicações das chances de êxito da implantação do Azure. Também é útil realmente implantar o código Bicep em algum lugar, para ver a aparência do ambiente depois que o pull request for mesclado e a implantação for concluída.
Nesta unidade, você aprenderá a implantar seu código em um ambiente temporário diretamente em uma solicitação de pull.
Por que implantar seu código diretamente de uma solicitação de pull?
Ao revisar uma solicitação de pull que inclui código do Bicep, a prática recomendada é implantar o código em um ambiente real do Azure. Ao fazer isso, você ajuda a criar confiança de que suas alterações funcionarão quando atingirem seu ambiente de produção. Se há um problema, é interessante descobri-lo rapidamente. As solicitações de pull oferecem uma ótima oportunidade para descobrir e realçar problemas, pois você está recebendo comentários imediatos dos seus revisores.
Até agora, você esteve acostumado com a ideia de implantar alterações em um ou mais ambientes de não produção, como Teste, Garantia de qualidade e Processo de preparo, antes de implantá-las em seu ambiente de produção. Em muitas organizações, esses ambientes são de longa duração, o que significa que são atualizados quando as alterações são distribuídas e os ambientes geralmente não são excluídos.
Por outro lado, um ambiente efêmero é aquele que você cria dinamicamente e se sente confortável em excluí-lo quando ele não for mais útil. Os ambientes efêmeros devem existir apenas por um curto período de tempo (por exemplo, somente por tempo suficiente para que suas alterações sejam examinadas).
Ambientes efêmeros são uma boa opção quando você implanta ambientes para solicitações de pull, pois você pode ter muitas solicitações de pull separadas abertas ao mesmo tempo, representando diferentes tipos de alterações. Se você tiver vários pull requests em aberto, compartilhar seus ambientes de não produção de longa duração significa que você só pode visualizar uma alteração por vez.
Criar ambientes efêmeros
Como você está tão acostumado a criar sua infraestrutura do Azure como código e investiu na criação de seus arquivos Bicep para implantar recursos, você pode reutilizar esses mesmos ativos para implantar um ambiente efêmero. Você pode até mesmo implantar vários ambientes efêmeros ao mesmo tempo, se necessário. Você só precisa garantir que as implantações sejam suficientemente parametrizadas e generalizadas, para que seja possível criar facilmente ambientes independentes. Por exemplo, você precisa garantir que alguns recursos do Azure receberão nomes globalmente exclusivos, que não podem ser iguais aos nomes de recursos em qualquer outro ambiente efêmero ou de longa duração.
Ambientes efêmeros oferecem muitos benefícios:
- Você pode testar com segurança novos recursos e funcionalidades em um ambiente isolado sem afetar suas outras cargas de trabalho de produção ou de não produção.
- Você pode exibir suas alterações no próprio branch, permitindo que você mostre facilmente seu trabalho para seus colegas ou permita acesso aos revisores.
- Pode haver vários membros da equipe testando suas diferentes alterações ao mesmo tempo, mesmo que as alterações sejam incompatíveis.
- Como envolvem a execução de seus arquivos Bicep regularmente, os ambientes efêmeros ajudam você a testar continuamente a precisão e a integridade do código do Bicep e de outros scripts. Como resultado, você pode ter mais confiança de que o código será executado perfeitamente em seu ambiente de produção.
Neste módulo, você criará ambientes efêmeros para ajudar você a aumentar a confiança sobre as alterações nas solicitações de pull. Qualquer pessoa que examina a solicitação de pull pode acessar o ambiente efêmero, incluindo as novas adições e atualizações, antes de aprovar e mesclar a solicitação de pull.
Implantação
Quando você trabalha com ambientes efêmeros, é melhor criar um grupo de recursos do Azure separado para cada solicitação de pull que a equipe criar. Se um autor tiver duas solicitações de pull distintas abertas, cada uma terá seu próprio ambiente efêmero. Isso ajuda a manter cada alteração separada das outras e pode ajudar a evitar confusão ou substituição acidental dos recursos.
Para que essa abordagem funcione, seu fluxo de trabalho de validação de solicitação de pull precisa criar grupos de recursos dinamicamente. Os grupos de recursos exigem nomes exclusivos e você também precisa conseguir encontrar facilmente o grupo de recursos para testar os recursos e excluí-los quando a solicitação de pull for fechada. Para lidar com nomes de grupo de recursos com eficiência, você pode usar o número da solicitação de pull dentro do nome do grupo de recursos. Você verá como fazer isso no próximo exercício.
Quando for a hora de excluir o ambiente efêmero, será fácil para que o fluxo de trabalho encontre e exclua todo o grupo de recursos. Todos os recursos usados no ambiente efêmero são excluídos ao mesmo tempo.
Permissões
A criação de grupos de recursos requer permissões no nível da assinatura e normalmente exige que a função Colaborador seja atribuída à entidade de serviço da identidade de carga de trabalho.
A prática recomendada é usar uma assinatura dedicada do Azure para ambientes efêmeros. Com essa abordagem, você pode conceder acesso à identidade de carga de trabalho do fluxo de trabalho e aos membros da equipe sem fornecer acesso a seus outros ambientes acidentalmente.
Importante
Os colaboradores com escopo de assinatura são poderosos, portanto, você precisa garantir que tenha a governança adequada em relação à identidade de carga de trabalho do fluxo de trabalho e das alterações que ela pode implantar. Ao usar uma assinatura dedicada para ambientes efêmeros, você reduz o risco para seus outros ambientes.
Identidade do fluxo de trabalho
Seu fluxo de trabalho de implantação usa uma identidade de carga de trabalho e uma credencial federada para autenticação no Azure. Ao usar fluxos de trabalho de validação de solicitação de pull, você precisa configurar a credencial federada para trabalhar com solicitações de pull.
Em um exercício anterior neste módulo, você executou um comando para criar uma credencial federada. A cadeia de caracteres de política era semelhante à seguinte:
repo:my-github-user/my-repo:pull_request
O pull_request final da cadeia de caracteres especifica que a credencial federada funciona com fluxos de trabalho de validação de solicitação de pull.
Gerenciamento de custo
Quando você cria ambientes efêmeros dinamicamente, há um risco de que os custos do Azure aumentem. Se sua equipe tiver um grande número de solicitações de pull abertas, você poderá implantar um grande número de recursos caros no Azure.
Dica
Se sua equipe fechar solicitações de pull rapidamente, os maiores custos serão menos preocupante porque um ambiente efêmero será excluído quando a solicitação de pull correspondente for fechada.
Usando uma assinatura dedicada do Azure, você também pode monitorar facilmente os custos dos ambientes efêmeros. Além disso, você pode aplicar políticas em toda a assinatura que limitam as SKUs de seus recursos efêmeros, o que pode ajudar a evitar ultrapassar os custos.
Adicionalmente, o Azure fornece muitas maneiras de ajudar você a controlar os custos de ambientes efêmeros, incluindo:
- O Gerenciamento de Custos da Microsoft permite definir orçamentos para uma assinatura. Os orçamentos disparam notificações para que sua equipe fique ciente de que o custo está se aproximando do limite especificado.
- Diversos tipos de recursos do Azure fornecem camadas mais baratas ou até mesmo gratuitas para cargas de trabalho de não produção. Considere se você pode usar esses SKUs e camadas de preço.
- Os preços de Desenvolvimento/Teste do Azure estão disponíveis para alguns clientes usarem com as assinaturas de não produção.
- As marcas de recurso podem ajudar você a identificar os recursos associados a cada ambiente efêmero e calcular o custo de cada um.
- Você pode criar scripts de automação para excluir seus recursos efêmeros após um período definido ou até mesmo, por exemplo, todas as noites, após o horário comercial.
Você também pode considerar o compartilhamento de determinados recursos entre ambientes efêmeros. Por exemplo, seu código do Bicep pode definir muitos recursos, alguns dos quais são caro ou levam muito tempo para provisionamento. Você pode criar um grupo de recursos compartilhado e de longa duração para todas as suas solicitações de pull compartilharem os recursos caros e criar grupos de recursos efêmeros separados para os outros recursos. No entanto, essa abordagem torna difícil e propenso a erros o processo de gerenciar seus ambientes efêmeros e difícil de mantê-los separados o suficiente para serem úteis durante o processo de revisão. É melhor evitar essa abordagem, a menos que o custo de seus ambientes efêmeros se torne muito alto.