Planeje seus ambientes

Concluído

Seu patrimônio do Azure consiste em muitos componentes, incluindo configuração básica, recursos e configurações em toda a organização e cargas de trabalho de aplicativos. É provável que você também tenha espalhado seu patrimônio por vários ambientes, cada um com um propósito diferente.

Nesta unidade, você aprende sobre o benefício de usar o código de forma consistente para toda a sua implantação e configuração. Em seguida, você considera os níveis de controle e automação que podem ser aplicados a cada um dos seus ambientes. Você também considera como suas alterações progridem em cada estágio do processo de implantação e os controles e tipos de governança necessários para dar suporte à estratégia de implantação escolhida.

Defina sua 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 rede. Por exemplo, cada um dos seguintes itens é uma forma de configuração, com recursos correspondentes do Azure:

• Organizar seus recursos criando grupos de recursos, assinaturas e grupos de gerenciamento.
• Controlando como seus outros recursos devem ser configurados, definindo e aplicando definições, iniciativas e atribuições da Política do Azure.
• 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 seus recursos do Azure e garantir que eles se comportem da maneira esperada.

Quando você começa a definir sua infraestrutura como código, talvez não esteja ciente de todos os itens que podem ser definidos em seus modelos ou definições. Mas, à medida que o uso da automação amadurece, é uma boa prática definir tudo sobre seu ambiente como código. Ao fazer isso, você pode usar um processo consistente, testado e aprovado para toda a sua configuração do Azure. E como o código é versionado e rastreado em um repositório Git, você pode analisar como seu ambiente do Azure mudou 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 seus alertas do Azure Monitor. A princípio, você pode pensar que usar a automação para implantar alertas não faria sentido. Mas os alertas são uma parte importante da sua configuração do Azure. Se um alerta não for criado corretamente, você poderá perder notificações de problemas críticos de produção. Ao definir seus alertas no código:

• Os membros da sua equipa podem rever os alertas e a sua configuração.
• Você pode implantar os alertas em ambientes que não são de produção primeiro para testá-los.
• Você tem rastreabilidade total das alterações em sua configuração do Azure.

Ambientes

Quando você planeja implantar sua infraestrutura automaticamente, é útil listar os ambientes que você planeja usar. Muitas organizações têm vários tipos de ambiente, cada um com características diferentes. Por exemplo:

• Alguns ambientes executam código de produção, enquanto outros executam versões não produtivas do mesmo código, talvez com configurações diferentes.
• Alguns ambientes são de longa duração e nunca foram feitos para serem excluídos. Outros são efêmeros: criados automaticamente e destruídos quando não são mais usados.
• Alguns ambientes são usados por sua equipe de desenvolvimento de infraestrutura ou software. Outros são usados pela sua equipa de segurança, ou mesmo pela sua equipa de vendas quando precisa de demonstrar um produto a potenciais clientes.

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

Quando você faz e confirma alterações em seu aplicativo ou em sua infraestrutura, seu pipeline implanta suas alterações por meio de uma sequência de ambientes que não são de produção: desenvolvimento, teste e preparação. Você também pode ter etapas de aprovação manual em determinados pontos para que os membros da equipe definidos possam verificar a configuração ou examinar o log do pipeline antes que a implantação continue. Em seguida, seu pipeline eventualmente implanta suas alterações em seu ambiente de produção.

Além desses ambientes, sua equipe de vendas tem seu 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 seu ambiente de demonstração. Suas equipes de segurança e teste ocasionalmente criam cópias temporárias do ambiente de produção para testes de penetração e testes de desempenho, respectivamente.

Sua equipe de desenvolvimento também tem seus próprios conjuntos de ambientes. Ele tem sandboxes para os membros da equipe de desenvolvimento usarem quando estiverem explorando novos recursos ou experimentando os serviços do Azure. A equipe de desenvolvimento também cria ambientes de revisão de RP para cada solicitação pull do GitHub que ela revisa e mescla.

Ambientes controlados

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

Em contraste, os ambientes não controlados não têm muitos, ou nenhum, controles formais. Eles podem ter o mesmo código e configuração semelhante aos outros ambientes, mas permitem mais experimentação e alterações de configuração ad-hoc. 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/Azure PowerShell. Eles também podem ser capazes de criar recursos sem usar o processo aprovado pela organização. As alterações feitas em ambientes não controlados devem ser capturadas em código antes de começarem a ser aplicadas a ambientes controlados, como o ambiente de produção.

Nota

Às vezes, um ambiente pode realmente representar vários ambientes físicos ou implantações. Por exemplo, quando você cria ambientes efêmeros para revisões de solicitação pull, vários ambientes separados podem estar ativos ao mesmo tempo porque sua equipe tem várias solicitações pull abertas. Mas, para fins de planejamento de seus ambientes, você pode considerá-los equivalentes porque eles têm as mesmas características e controles.

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

Nome do ambiente	Description	Proprietário	Vitalício	Nível de controlo
Desenvolvimento	Integra alterações de vários desenvolvedores em um único ambiente.	Equipa de operações	Longa vida	Controlado
Teste	Um ambiente para executar testes manuais e automatizados contra alterações.	Equipa de operações	Longa vida	Controlado
Processo de teste	O ambiente final de não produção onde as alterações são implantadas antes da produção, com configuração semelhante à produção.	Equipa de operações	Longa vida	Controlado
Produção	Executa suas cargas de trabalho de produção.	Equipa de operações	Longa vida	Controlado
Demonstração	Utilizado pela equipa de vendas para demonstrar o produto a novos clientes.	Equipa de vendas	Longa vida	Descontrolado
Testes de desempenho	Criado dinamicamente como uma duplicata do ambiente de produção para executar testes de desempenho e de esforço e, em seguida, excluído quando os testes são concluídos.	Equipa de teste	Curta duração	Descontrolado
Testes de penetração	Criado dinamicamente como uma duplicata do ambiente de produção para executar testes de penetração e segurança e, em seguida, excluído quando os testes são concluídos.	Equipa de segurança	Curta duração	Descontrolado
Avaliações de RP	Criado dinamicamente para cada solicitação pull que um membro da equipe cria para alterar o aplicativo ou a infraestrutura. O ambiente é excluído quando a solicitação pull é fechada.	Equipa de desenvolvimento	Curta duração	Descontrolado
Ambientes de teste de desenvolvimento	Criado por membros da equipe de desenvolvimento para experimentar ou explorar e, em seguida, excluído quando não for mais necessário.	Equipa de desenvolvimento	Curta duração	Descontrolado

A lista anterior de ambientes é apenas um exemplo. Em sua própria organização, você precisa decidir quais ambientes você usa, qual deve ser sua vida útil e qual o nível de controle que cada ambiente precisa.

Gorjeta

É muito mais fácil usar, testar e revisar seu código de infraestrutura quando você aplica esses processos no início de suas implantações, em vez de adicioná-los mais tarde e ter que corrigir muitos códigos quebrados.

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

Ao longo dos percursos de aprendizagem, introduzimos alguns destes conceitos gradualmente. Muitas vezes, é uma boa ideia adicionar esses elementos ao seu processo de implantação o mais cedo possível.

Isolamento de cada ambiente

É importante separar cada um dos seus ambientes e torná-los independentes sempre que possível. Usar assinaturas dedicadas do Azure para cada ambiente pode ajudar, mas você ainda precisa ter cuidado para manter seus ambientes separados.

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

Controlos 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 suas implantações progridem.

As verificações da infraestrutura geralmente incluem:

• Revisões de código.
• Implantação de seu código em revisão em ambientes efêmeros e execução de testes automatizados ou manuais nos ambientes.
• Forro.
• Validação de comprovação.
• Testes manuais.
• Aprovação manual.
• Testes funcionais automatizados.
• Teste automatizado de fumaça.
• Esperar por sinais de saúde de um ambiente anterior antes de progredir para o próximo ambiente.

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

Gorjeta

Ao projetar seu processo de implantação, liste todas as etapas que você precisa executar, não importa quão pequenas ou óbvias. Seja o mais detalhado possível. Você pode não optar por automatizar tudo no início, mas seguir essa prática o ajudará a criar um plano para seus processos de implantação automatizados no futuro.

Um gate é uma verificação automatizada ou manual que deve ser bem-sucedida para que a implantação continue.

Intervenção manual

É uma boa ideia automatizar o maior número possível de verificações durante os processos de revisão de código e implantação. No entanto, sua organização pode exigir aprovação manual para implantação em ambientes de produção ou outros ambientes controlados.

Se você usar portas de aprovação manuais 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ê pode facilmente alterar a lista de aprovadores no futuro.
• Ter um processo para implantações de emergência. Planeje quem pode aprovar uma implantação se os aprovadores normais não estiverem disponíveis. Pode ser necessário um destacamento de emergência a 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 humanos executem qualquer uma das operações de implantação, a menos que haja uma etapa que você não possa automatizar.

Governação

O Azure fornece ferramentas e recursos para ajudá-lo a controlar seu ambiente, incluindo:

• Política do Azure para detetar recursos que foram configurados de formas que não se ajustam aos requisitos da sua organização. Também pode ajudar a impedir que os recursos sejam criados ou reconfigurados de uma forma que os torne fora de conformidade.
• Bloqueios para impedir alterações ou exclusão de recursos importantes.
• Grupos de gerenciamento para ajudá-lo a organizar suas assinaturas do Azure e configurar políticas e controle de acesso baseado em função de forma consistente em seus ambientes.
• Azure Monitor para registrar métricas e logs de seus recursos, apresentá-los em painéis e alertá-lo automaticamente quando eles se desviarem dos valores esperados.

Ao criar seu patrimônio do Azure, considere usar as zonas de aterrissagem do Azure. Usando uma zona de pouso, você pode criar governança em seu ambiente desde o início. Muitas zonas de pouso incluem arquivos pré-construídos Bicep e Terraform para ajudá-lo a configurar seu ambiente. Temos links para mais informações no resumo.