Num ambiente em nuvem a infraestrutura como código e automação predominam, diferente de um ambiente de infraestrutura tradicional, em que você precisa comprar hardware e alocar no seu datacenter próprio.
No ambiente tradicional você se trabalha com recursos fixos e devido ao custo inicial e ao lead time para colocar o novo hardware para operar.
Nesses ambientes tradicionais também é comum se utilizar práticas como o login manual em servidores para configurar software ou corrigir problemas, codificar endereços IP e executar testes ou processar workloads sequencialmente.
Quando você migra sua infraestrutura para a Nuvem da AWS é muito importante você pode aproveitar a natureza dinamicamente, escalável e elástica da computação em nuvem.
Na Nuvem, você pode pensar em servidores e outros recursos computacionais como temporários, isso porque, você pode criar quantos precisar e usá-los apenas pelo tempo que precisar deles.
Outro problema com servidores fixos é a configuração deles, alterações e patches que são aplicados ao longo do tempo podem resultar em configurações não testadas e heterogêneas em diferentes ambientes (stating, teste, produção, etc.).
Você pode resolver esse problema com um padrão de infraestrutura imutável. Com essa abordagem, um servidor, uma vez iniciado, nunca é atualizado. Em vez disso, quando há um problema ou uma necessidade de atualização, o servidor com problema é substituído por um novo servidor com a configuração mais recente.
Isso permite que os recursos estejam sempre em um estado consistente (e testado) e facilita a execução de reversões. Isso é mais facilmente suportado com arquiteturas stateless
Configuração de Servidores
Existem diversas abordagens para lidar com configurações de servidores sendo as seguintes as mais comuns.
Boostraping
Boostrap actions são scripts que podem ser executados no momento em que um servidor é iniciado.
Golden Images
Golden Images são cópias de um servidor num determinado estado (snapshots) que podem ser utilizados para iniciar novos servidores com a mesma exata configuração, para isso utilizam-se AMIs (Amazon Machine Image).
Containers
Em vez de utilizar AMIs que são imagens para se criar servidores virtuais (EC2), você também pode utilizar imagens para instanciar containers docker a serem executados num cluster ECS ou Kubernetes (EKS).
Infraestrutura como código
É de suma importância que se você precisar replicar o seu ambiente (para criar um ambiente adicional para testes, por exemplo) seja possível fazer isso de forma automatizada sem a necessidade de procedimentos manuais.
Por isso, cada vez, mais se utilizar infraestrutura como código, automatização a criação de servidores e configuração.
Existem diversos frameworks para isso como Puppet, Chef, e Ansible. A AWS também permite que você crie templates com todas as definições do seu ambiente utilizado o AWS CloudFormation, os arquivos de definição do CloudFormation podem ser armazenados e versionados num repositório Git.
O CloudFormation permite usar um arquivo de texto simples para modelar e provisionar de forma automática e segura todos os recursos necessários para os aplicativos em todas as regiões e contas.
Com o AWS CloudFormation, você escreve modelos para definir o conjunto de recursos necessários para seus aplicativos.
Esses recursos podem incluir instâncias de EC2, instâncias do Amazon RDS e load balancers, por exemplo.
O modelo descreve quais recursos você precisa e o AWS CloudFormation provisiona esses recursos, cria-os em paralelo, sempre que possível, e lida com quaisquer falhas ou problemas.
O CloudFormation pode ser integrado com frameworks Chef e Puppet.
Chef é uma solução de automação de infraestrutura open source, escrita em Ruby que automatiza a configuração de seus servidores, é um aplicação client-server em que todos os clients puxam a configuração do servidor Chef.
Já o Puppet é uma plataforma de serviços de TI de código aberto que permite que você possa gerenciar o provisionamento, o patch e a configuração de sistemas operacionais e seus aplicativos. O Puppet também é uma aplicação cliente-servidor em que os clients obtêm a configuração do server.
Para quem não quiser utilizar um serviço nativo da AWS por medo de Lock In, recomendo o usar o Terraform que possui funcionalidades similares porém é Multi-cloud (suporta AWS, Google Cloud, Azure, etc.).
Para conhecer um pouco mais sobre o Terraform com exemplo no ambiente AWS, veja uma palestra do Hugo Posca da Pagar.me (em português).
AWS Cloud Development Kit
Complementar ao CloudFormation, o AWS CDK (Cloud Development Kit) é um framework open source para modelar e provisionar sua infraestrutura na nuvem utilizando uma de suas linguagens de programação de preferência (TypeScript, JavaScript, Python, C#/.NET, e Java).
Basicamente você consegue criar a sua infraestrutura através de uma linguagem de programação que depois será convertida para o CloudFormation.
Uma das vantagens do CDK é que desenvolvedores podem definir componentes reutilizáveis chamados de Constructs para compor Stacks e Apps.
Um Construct é um componente da AWS, como um Bucket do S3, uma fila do SQS, ou uma tabela do DynamoDB.
Seus Constructs então são agrupados em Stacks, que são instanciadas através de Apps.
Veja essa palestra apresentada no AWS re:Invent para entender com mais detalhes as vantagens e benefícios do CDK para você utilizar sua infra-estrutura como código e ainda criar componentes reutilizáveis.
Inventário e Patches com o Systems Manager
Outro serviço da que vale bastante a pena conhecer é o AWS Systems Manager permite que você possa ver dados operacionais de vários serviços da AWS de uma vez assim como automatizar tarefas operacionais em lote.
Você pode agrupar recursos de nuvem, como instâncias EC2, buckets do S3, instâncias do RDS.
O AWS Systems Manager permite automatizar ações, por exemplo é possível aplicar automaticamente patches, atualizações e alterações de configuração em qualquer grupo de recursos.
O AWS Systems Manager também é útil para manter a segurança e a conformidade por meio da verificação do cumprimento de políticas de patch, configuração e políticas personalizadas pelas instâncias.
Você pode definir linhas de base de patch, manter definições atualizadas de antivírus e aplicar políticas de firewall.
Também é possível gerenciar servidores remotamente em grande escala, sem necessidade de fazer login manualmente em cada servidor.
Além disso, o Systems Manager oferece um armazenamento centralizado para gerenciar dados de configuração em texto simples, como strings de conexão com bancos de dados ou senhas.
Veja na palestra abaixo como a Verizon usa o AWS Systems Manager para fazer o inventário, manter compliance, e analisar os patch de seus servidores.
Conclusão
Especialmente depois de migrar para nuvem, é importante mudar algumas práticas em se tratando de infra-estrutura:
- Evite acessar servidores manualmente (via SSH, por exemplo).
- Não se apegue aos servidores: crie e delete, evite alterar.
- Use servidores imutáveis para facilitar o rollback e versionamento.
- Toda a alteração de infra e configuração deve ser feita em código-fonte e versionada, seja diretamente pelo AWS CloudFormation ou pelo Cloud Development Kit (CDK), ou ainda aliando o AWS CloudFormation com ferramentas como o Puppet e o Chef.
- Use o AWS Systems Manager para agrupar recursos, fazer inventário, e gerir a aplicação de patches.
