Planejar seus ambientes

Concluído

Seu patrimônio do Azure consiste em vários componentes, incluindo configuração básica, recursos e configurações da organização toda e cargas de trabalho de aplicativo. Provavelmente, você também distribuiu seu patrimônio em vários ambientes, cada um com uma finalidade diferente.

Nesta unidade, você aprende sobre o benefício de usar o código de modo consistente em toda a implantação e a configuração. Depois, você considera os níveis de controle e automação que podem ser aplicados a cada um dos ambientes. Você também considera como as alterações avançam em cada fase do processo de implantação e quais são os controles e os tipos de governança necessários para dar suporte à estratégia de implantação escolhida.

Definir a infraestrutura como código

A implantação e a configuração do Azure abrangem muito mais do que aplicativos, máquinas virtuais, serviços de armazenamento e redes. Por exemplo, cada um dos seguintes itens é uma forma de configuração, com os recursos do Azure correspondentes:

• Organizar os recursos criando grupos de recursos, assinaturas e grupos de gerenciamento.
• Controlar como os outros recursos devem ser configurados ao definir e aplicar definições, iniciativas e atribuições do Azure Policy.
• Atribuir funções para permitir que usuários, grupos e identidades de carga de trabalho acessem recursos do Azure.
• Configurar o monitoramento, incluindo alertas, para observar os recursos do Azure e garantir que eles se comportem da maneira esperada.

Ao começar a definir a infraestrutura como código pela primeira vez, talvez você não tenha conhecimento de todos os itens que podem ser definidos em modelos ou definições. Mas, conforme você avança no aprendizado da automação, uma prática recomendada é definir como código tudo que está relacionado ao ambiente. Ao fazer isso, você pode usar um processo consistente, testado e aprovado para toda a configuração do Azure. E como o código tem controle de versão e é rastreado em um repositório Git, você pode examinar como o ambiente do Azure é alterado ao longo do tempo. Você pode usar o repositório Git para rastrear o histórico de cada alteração.

Por exemplo, suponha que você precise configurar os alertas do Azure Monitor. No início, você pode achar que não faz sentido usar a automação para implantar alertas. Mas os alertas são uma parte importante da configuração do Azure. Se um alerta não for criado corretamente, você poderá perder notificações de problemas críticos de produção. Com a definição de alertas no código:

• Os membros da equipe podem examinar os alertas e as respectivas configurações.
• Você pode implantar os alertas em ambientes que não sejam de produção primeiro para testá-los.
• Você conta com a rastreabilidade total das alterações na configuração do Azure.

Ambientes

Quando você planeja implantar a infraestrutura automaticamente, é bom listar os ambientes que pretende usar. Muitas organizações têm diversos tipos de ambiente, cada um com características diferentes. Por exemplo:

• Alguns ambientes executam código de produção, enquanto outros executam versões do mesmo código que não são de produção, talvez com configurações diferentes.
• Alguns ambientes duram bastante e não há intenção de excluí-los. Outros são efêmeros: criados automaticamente e destruídos quando não são mais usados.
• Alguns ambientes são usados pela equipe de desenvolvimento de infraestrutura ou de software. Outros são usados pela equipe de segurança ou até mesmo pela equipe de vendas para demonstrar um produto para clientes potenciais.

Considere os ambientes que sua empresa de brinquedos pode usar para o site:

Quando você faz alterações no aplicativo ou na infraestrutura e depois faz commit delas, o pipeline implanta as alterações em uma sequência de ambientes que não são de produção: desenvolvimento, teste e preparo. Você também pode inserir etapas de aprovação manuais em determinados pontos para que membros da equipe definidos possam verificar a configuração ou examinar o log do pipeline antes que a implantação continue. Depois, o pipeline finalmente implantará as alterações no ambiente de produção.

Além desses ambientes, a equipe de vendas tem o próprio ambiente de demonstração que usa para conversar com os clientes. A equipe de vendas usa uma cópia do ambiente de produção para criar o ambiente de demonstração. Às vezes, as equipes de segurança e de teste criam cópias temporárias do ambiente de produção para testes de penetração e teste de desempenho, respectivamente.

A equipe de desenvolvimento também tem os próprios conjuntos de ambientes. Ela tem áreas restritas para seus membros usarem ao explorar novos recursos ou experimentar serviços do Azure. A equipe de desenvolvimento também cria ambientes de revisão de PR para cada solicitação de pull do GitHub que revisa e mescla.

Ambientes controlados

Em alguns desses ambientes, faz sentido exigir um processo formal para examinar e aplicar alterações. Ambientes desse tipo são chamados de ambientes controlados. O ambiente de produção sempre deve ser controlado. Também é uma prática recomendada aplicar controles a alguns ambientes que não são de produção. Assim, você pode garantir que todas as restrições impostas pelos controles sejam bem compreendidas e testadas antes da implantação de produção.

Por outro lado, ambientes não controlados não têm muitos controles formais e, às vezes, nenhum. Eles podem ter o mesmo código e uma configuração semelhante aos dos outros ambientes, mas permitem mais alterações de configuração ad hoc e de experimentação. Em um ambiente não controlado, os usuários podem ter permissão para modificar a configuração usando o portal do Azure ou executando diretamente comandos da CLI do Azure ou do Azure PowerShell. Eles também podem ter a capacidade de criar recursos sem usar o processo aprovado pela organização. As alterações feitas em ambientes não controlados precisam ser capturadas em código para que possam começar a ser aplicadas a ambientes controlados, como o ambiente de produção.

Observação

Às vezes, um ambiente pode representar vários ambientes físicos ou implantações. Por exemplo, quando você cria ambientes efêmeros para revisões de solicitação de pull, vários ambientes separados podem estar ativos ao mesmo tempo, porque a equipe tem várias solicitações de pull em aberto. Porém, com o objetivo de planejar os ambientes, você pode considerá-los equivalentes por terem as mesmas características e controles.

Após algumas discussões com a equipe, você designa quais ambientes são controlados e não controlados. Você também decide quem é o proprietário de cada ambiente.

Nome do ambiente	Descrição	Proprietário	Tempo de vida	Nível de controle
Desenvolvimento	Integra alterações de vários desenvolvedores em um só ambiente.	Equipe de operações	De longa duração	Controlado
Teste	Um ambiente para executar testes manuais e automatizados em relação a alterações.	Equipe de operações	De longa duração	Controlado
Staging	O ambiente de não produção final em que as alterações são implantadas antes da produção, com configuração semelhante ao de produção.	Equipe de operações	De longa duração	Controlado
Produção	Executa as cargas de trabalho de produção.	Equipe de operações	De longa duração	Controlado
Demonstração	Usado pela equipe de vendas para demonstrar o produto a novos clientes.	Equipe de vendas	De longa duração	Não controlado
Testes de desempenho	Criado dinamicamente como uma duplicata do ambiente de produção para executar testes de desempenho e de estresse e, depois, excluído quando os testes são concluídos.	Equipe de teste	De curta duração	Não controlado
Teste de penetração	Criado dinamicamente como uma duplicata do ambiente de produção para executar testes de penetração e de segurança e, depois, excluído quando os testes são concluídos.	Equipe de segurança	De curta duração	Não controlado
Revisões de PR	Criado dinamicamente para cada solicitação de pull que um membro da equipe cria para alterar o aplicativo ou a infraestrutura. O ambiente é excluído quando a solicitação de pull é fechada.	Equipe de desenvolvimento	De curta duração	Não controlado
Áreas restritas de desenvolvimento	Criadas por membros da equipe de desenvolvimento para experimentação ou exploração e, depois, excluídas quando não são mais necessárias.	Equipe de desenvolvimento	De curta duração	Não controlado

A lista de ambientes anterior é apenas um exemplo. Na sua organização, você precisa decidir quais ambientes são usados, qual deve ser o tempo de vida deles e qual nível de controle cada um exige.

Dica

É muito mais fácil executar lint, testar e revisar o código de infraestrutura quando você aplica esses processos no início das implantações, em vez de adicioná-los mais tarde e precisar corrigir vários códigos incorretos.

Da mesma forma, é muito mais fácil trabalhar com controles de segurança quando eles estão presentes desde o início e quando eles também são aplicados a alguns dos ambientes que não são de produção. Assim, a equipe se acostuma a trabalhar em um ambiente controlado.

Ao longo dos roteiros de aprendizagem, introduzimos alguns desses conceitos gradualmente. Geralmente, é bom adicionar esses elementos ao processo de implantação o mais cedo possível.

Isolamento de cada ambiente

É importante separar cada um dos ambientes e deixá-los autônomos sempre que possível. O uso de assinaturas dedicadas do Azure para cada ambiente pode ajudar, mas você ainda precisa ter cuidado para manter os ambientes separados.

Evite se conectar de um ambiente a outro. Por exemplo, não emparelhe a rede virtual de um ambiente de produção à rede virtual de um ambiente que não seja de produção. Se você fizer isso, alguém poderá alterar acidentalmente os dados de produção por meio de um ambiente que não seja de produção ou vazar dados confidenciais de produção para um ambiente que não seja de produção.

Verificações e portões

À medida que o processo de implantação prossegue, ele deve executar uma série de verificações para aumentar sua confiança na implantação. Você precisa determinar as verificações que fazem sentido para cada um dos ambientes pelos quais as implantações avançam.

As verificações de infraestrutura geralmente incluem:

• Revisões de código.
• Implantação do código em revisão em ambientes efêmeros e execução de testes automatizados ou manuais nos ambientes.
• Execução de lint.
• Validação de simulação.
• Teste manual.
• Aprovação manual.
• Teste funcional automatizado.
• Teste de fumaça automatizado.
• Aguardar sinais de integridade de um ambiente anterior antes de avançar para o próximo ambiente.

Você pode executar algumas dessas verificações várias vezes no processo de implantação, por exemplo, para cada ambiente controlado.

Dica

Ao projetar o processo de implantação, liste todas as etapas que você precisa executar, mesmo as que são pequenas ou parecem óbvias. Inclua o máximo de detalhes possível. Talvez você não queira automatizar tudo de imediato, mas ao seguir esta prática, você criará um blueprint que poderá ser usado para os próximos processos de implantação automatizados.

Um portão é uma verificação automatizada ou manual que precisa ter êxito para que a implantação continue.

Intervenção manual

Uma prática recomendada é automatizar o maior número possível de verificações durante os processos de revisão e implantação de código. No entanto, a organização pode exigir aprovação manual para implantação em ambientes de produção ou em outros ambientes controlados.

Ao usar portões de aprovação manual para implantações, siga estas práticas recomendadas:

• Defina claramente quem tem permissão para aprovar uma implantação. Use grupos do Microsoft Entra para definir aprovadores, em vez de especificar usuários individuais. Você poderá alterar facilmente a lista de aprovadores no futuro.
• Tenha um processo para implantações de emergência. Planeje quem pode aprovar uma implantação se os aprovadores normais não estiverem disponíveis. Uma implantação de emergência pode precisar acontecer no meio da noite ou durante um período de férias.
• Limite a intervenção humana apenas para aprovar ou rejeitar uma implantação. Evite exigir que pessoas executem operações de implantação, a menos que haja uma etapa que não possa ser automatizada.

Governança

O Azure oferece ferramentas e funcionalidades que ajudam a controlar o ambiente, incluindo:

• Azure Policy, para detectar recursos que foram configurados de maneiras que não estão de acordo com os requisitos da organização. Isso também pode ajudar a impedir que recursos sejam criados ou reconfigurados de modo que fiquem fora de conformidade.
• Bloqueios, para evitar alterações ou exclusão de recursos importantes.
• Grupos de gerenciamento, para ajudar você a organizar as assinaturas do Azure e configurar políticas e controle de acesso baseado em função de modo consistente em todos os ambientes.
• Azure Monitor, para registrar métricas e logs dos recursos, apresentá-los em painéis e enviar alertas automaticamente quando eles se desviarem dos valores esperados.

Ao criar seu patrimônio do Azure, considere usar zonas de destino do Azure. Usando uma zona de destino, você pode estabelecer a governança no ambiente desde o início. Muitas zonas de destino incluem arquivos Bicep e Terraform predefinidos que ajudam a configurar o ambiente. Há um link para mais informações no resumo.