Infraestrutura como código (IaC) é a prática de configurar e gerenciar infraestrutura, como redes ou arquivos legíveis por máquina, e é um dos resultados mais visíveis da ascensão da mentalidade DevOps . O IaC permite que os desenvolvedores forneçam aos ambientes de TI várias linhas de código e podem ser implantados em questão de minutos (em contraste com a infraestrutura manual, que pode levar horas, senão dias para ser implantada).

Neste artigo, veremos mais detalhadamente os benefícios e os limites do IaC. Após uma breve discussão sobre as vantagens de usar este paradigma, veremos os vários elementos aos quais ele pode ser aplicado, antes de uma discussão detalhada de como, em um nível prático, você pode aplicá-lo à sua própria infraestrutura.

Como veremos, obter infraestrutura adaptável por meio de IaC é possível, mas requer um planejamento cuidadoso, documentação rigorosa e programação habilidosa. Neste artigo, explicarei como isso pode ser feito, mas antes um aviso: tudo aqui se aplica ao desenvolvimento de software habilitado para rede, hospedado e amplamente baseado em nuvem. Se você estiver trabalhando com sistemas mais tradicionais, é improvável que se aplique ao seu fluxo de trabalho.

As vantagens do IaC

O paradigma IoC teve um aumento meteórico em popularidade nos últimos anos devido ao fato de permitir que os desenvolvedores implantem sua infraestrutura rapidamente, e isso teve efeitos colaterais em uma série de outras tecnologias que estão intimamente associadas a ele. A popularidade do IaC, por exemplo, é um dos principais motivos pelos quais o Kubernetes é tão popular agora, e a implementação de um pipeline de IaC costuma ser confundida com os processos de conformidade DevSecOps.

[Mergulhe fundo no mundo da tecnologia e cadastre-se no Avance Network a verdadeira comunidade criptografada]

Devido à maneira como o IaC é integrado a outras tecnologias e processos, pode ser difícil isolar as vantagens oferecidas pelo próprio IaC, em vez de suas práticas associadas. A conformidade eficiente, por exemplo, é consequência da forma como o IaC interage com as práticas gerenciais, e não uma característica do próprio IaC.

Na realidade, o IaC oferece uma série de vantagens bem definidas , principalmente para as equipes de DevOps:

Padronização da configuração da infraestrutura, o que pode ajudar a reduzir o erro humano.

Controle de provisionamento de infraestrutura por uma fonte centralizada.

Integração de código de infraestrutura em pipelines de CI / CD.

A capacidade (em princípio) de adaptar rapidamente a infraestrutura.

Basicamente, as implantações de IaC visam dar às equipes de DevOps a capacidade de criar ambientes temporários, substitutos e efêmeros que permitem que novos recursos sejam testados sem afetar a estabilidade das versões do ramo principal. No entanto, atingir esse objetivo requer planejamento e desenvolvimento cuidadosos.

A topologia IaC

Para entender como o IaC pode ser usado para obter recursos de rede e infraestrutura verdadeiramente adaptáveis, é instrutivo reconhecer a gama de áreas em que o IaC afeta o ciclo de vida de desenvolvimento. 

Para construir uma prática DevOps da maneira certa , o IaC pode ser considerado útil como sendo aplicado em uma topologia específica, que inclui não apenas o provisionamento de infraestrutura, mas também a configuração de servidores, conteinerização e orquestração. Vamos dar uma olhada em cada parte dessa topologia separadamente.

Provisionamento de infraestrutura

Para a maioria das equipes de DevOps, o principal motivo para adotar uma abordagem IaC é que ela lhes dá a capacidade de provisionar reativamente recursos de infraestrutura na forma de arquivos legíveis por máquina. Usando IaC, os desenvolvedores de software podem usar código para provisionar e implantar servidores e aplicativos em vez de depender de administradores de sistema. Os desenvolvedores também podem habilitar o escalonamento automático, o que significa que um programa pode ajustar automaticamente os recursos em tempo de execução para lidar com o aumento do tráfego. 

Na prática, isso significa que um desenvolvedor escreverá um processo de infraestrutura como código para provisionar e implantar um novo aplicativo para controle de qualidade ou implantação experimental. As operações assumirão então o controle da implantação ao vivo na produção. Com a configuração da infraestrutura escrita como código, ele pode passar pelo mesmo controle de versão, teste automatizado e outras etapas de um pipeline de integração contínua e entrega contínua (CI / CD) que os desenvolvedores usam para o código do aplicativo.

Isso ajuda a superar alguns dos desafios das soluções hospedadas, dando às equipes a capacidade de criar instâncias isoladas de vários tipos de recursos sem servidor. Esse provisionamento geralmente é obtido por meio de ferramentas integradas, como AWS Cloud, PowerShell ou Google's Deployment Manager. 

Configuração do servidor

A próxima etapa na topologia IaC é o processo e a prática de criação, provisionamento e configuração de máquinas virtuais. Na maioria das implementações de IaC, isso é feito por meio do uso de modelos de servidor. Isso permite que as equipes de DevOps usem imagens, que contêm configurações padrão como modelos, e automatizem a aplicação dessas em máquinas virtuais recém-criadas.

Esses modelos de servidor podem conter uma ampla variedade de dados de configuração, incluindo aqueles relacionados ao reforço de segurança de máquinas virtuais, hierarquias de diretório, limitações de montagem de disco e até mesmo protocolos de configuração de rede. Novamente, criar imagens de servidor e aplicá-las a máquinas virtuais geralmente é feito por meio de um conjunto de ferramentas gratuitas, incluindo Ansible, PowerShell DSC, Chef, Puppet e SaltStack.

Conteinerização

Uma abordagem diferente para a criação de VMs é implantar aplicativos dentro de contêineres. Esse tipo de implementação independente de servidor pode oferecer escalonamento de aplicativo eficiente , mas pode ter um custo significativo em termos de desempenho. Na prática, a maior parte da conteinerização hoje é obtida por meio do Docker, que se tornou a ferramenta padrão para criar e trabalhar com contêineres. Isso se deve parcialmente à flexibilidade oferecida pela interface do Docker, na qual a configuração das imagens do Docker pode ser controlada junto com a implantação das próprias imagens dentro de um Dockerfile. 

No entanto, existem limites impostos ao trabalhar com o Docker dessa maneira. Especificamente, a configuração de um contêiner não pode ser modificada. Isso significa que usar a conteinerização é essencialmente uma maneira de negociar agilidade para compatibilidade entre ambientes DevOps - embora os contêineres possam ser mais fáceis de trabalhar, especialmente em grandes equipes, eles podem acabar replicando o mesmo tipo de abordagem monolítica que o IaC foi desenvolvido para evitar . 

Em particular, as equipes de DevOps devem se certificar de que entendem as diferenças entre o Teste de Segurança de Aplicativos Estáticos (SAST) e o Teste de Segurança de Aplicativos Dinâmicos (DAST) e as limitações que o uso de contêineres impõe a essas abordagens. O teste dinâmico é um processo de uso intensivo de recursos que, quando implantado em código em contêiner, pode esgotar rapidamente os recursos de computação.

Implantação via Kubernetes

A parte final da topologia IaC é a que será mais visível e familiar para as equipes de operações de TI. Esses são os orquestradores de contêineres que controlam a maneira como os contêineres são implantados e provisionados. O mais difundido desses orquestradores é, sem dúvida, o Kubernetes.

No entanto, a onipresença do Kubernetes criou um problema - que a maioria da equipe de operações de TI e, na verdade, muitos desenvolvedores pensam que IaC e Kubernetes são sinônimos. Não quero dizer isso como uma crítica ao Kubernetes. O sistema é talvez a expressão mais pura do paradigma IaC: eminentemente portátil, mas também capaz de ser adaptado para funcionar com eficiência em uma ampla variedade de hardware. 

No entanto, o Kubernetes está longe de representar toda a gama do que pode ser alcançado por uma combinação cuidadosa de contêineres, VMs e um uso criativo de orquestradores de contêiner. Em outras palavras, o Kubernetes é o início de sua jornada de IaC, não o fim. Embora seja um ótimo lugar para começar a explorar o provisionamento adaptável e a integração contínua, muitas empresas precisarão desenvolver estratégias de conteinerização sob medida para trabalhar com sistemas obscuros: aqueles que interagem com hardware legado, por exemplo, ou precisam ser otimizados para determinado hardware .

Práticas recomendadas de IaC

Para a maioria das equipes de DevOps, a implantação de cada parte da topologia IaC que descrevi acima exigirá um equilíbrio cuidadoso entre a liderança estratégica e o trabalho de desenvolvimento focado. No nível mais amplo, as equipes precisarão definir os resultados desejados, especialmente o nível de agilidade da infraestrutura que desejam alcançar. 

Eles então precisarão esboçar um roteiro: um que detalha a maneira como as VMs e os contêineres serão criados, configurados, gerenciados e testados. Indivíduos ou pequenas equipes podem trabalhar no desenvolvimento real dessa "infraestrutura de infraestrutura".

Trabalhar em direção a esse objetivo requer que as equipes de desenvolvimento e operações trabalhem com base nos mesmos padrões e com os mesmos requisitos. Como tal, há uma série de princípios e regras que devem ser seguidos por todas as equipes que trabalham em ambientes IaC.

Estes variam do geral ao específico. Entre os primeiros tipos de regras e princípios podem ser encontrados aqueles que não são específicos para ambientes IaC, mas são particularmente importantes dentro deles:

Use uma nomenclatura consistente, idealmente obtida por meio de reuniões de alto nível entre as equipes de desenvolvimento e operacionais.

Não sobrecarregue o código com comentários desnecessários e “notas para mim mesmo” (embora veja o ponto oposto sobre a documentação abaixo).

Sempre que possível, use pequenas funções e uma biblioteca de aplicativos compartilhada.

Implemente o tratamento de erros em todas as funções, aplicativos e contêineres, não importa o quão pequenos e não importa o quão “temporários” eles sejam considerados.

Adote uma abordagem de segurança em primeiro lugar quando se trata de programação, especialmente quando se trata de programação de código aberto ou código que você planeja compartilhar com os desenvolvedores.

Afinal, essas são as boas práticas básicas de desenvolvimento de software de maneira mais geral. No entanto, seguir esses princípios torna-se mais importante do que nunca quando o código tem o poder de mudar radicalmente a maneira como a infraestrutura é implantada e gerenciada.

Desenvolvimento de ambientes IaC

Além dessas regras gerais, há também um conjunto de boas práticas que decorrem da maneira como os ambientes de IaC funcionam. Como a promessa central desses ambientes é que o provisionamento e a configuração de VMs e contêineres sejam automatizados, é mais importante do que nunca que o código que executa essa automação seja consistente, confiável e livre de erros.

Esta observação permite que uma série de regras-chave de desenvolvimento de ambientes IaC sejam derivadas:

Automatizar o máximo possível do código deve reduzir os erros e melhorar a velocidade. Isso pode significar que várias estruturas IaC precisarão ser usadas.

O código da infraestrutura deve ser armazenado (na medida do possível) com o código do aplicativo e, de preferência, nos mesmos repositórios. Na prática, isso pode ser difícil, mas deve ser tentado sempre que possível. Sem isso, uma das principais vantagens do IaC (provisionamento adaptável, conforme mencionado anteriormente) é perdida.

Integre o IaC ao processo mais amplo de CI / CD para que o código e os aplicativos desenvolvidos em seu ambiente de IaC possam ser rigorosamente testados. Ao vincular seu sistema IaC ao pipeline de CI / CD, você pode integrar e implantar o código em diferentes ambientes.

A documentação deve ser clara, concisa e contida no próprio código IaC. 

Na medida do possível, o IaC também deve ser desenvolvido como um sistema de elementos modulares de código.

Como fica evidente nesta lista, o desenvolvimento de ambientes IaC deve ser feito com cuidado e de forma a garantir a integridade de cada elemento do sistema. Isso é mais do que possível, é claro, mas requer um gerenciamento cuidadoso e um alto grau de integração entre as equipes de DevOps.

Desafios e oportunidades

IaC é uma abordagem poderosa, mas muitas vezes mal compreendida. Muitas equipes de DevOps reconheceram (com razão) o valor que o IaC pode oferecer , mas persistem em usar o termo como sinônimo para a implantação de contêinerização básica e Kubernetes.

Como espero ter indicado neste artigo, na realidade, IaC vai muito além disso - na melhor das hipóteses, IaC se refere a uma ampla topologia de elementos que redefinem a maneira como o código é desenvolvido, empacotado e testado. Trabalhar em tal ambiente pode ser desafiador, mas seguir os princípios que esbocei acima também pode ser altamente recompensador.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.