Infraestrutura imutável: redes

Se você trabalha com infraestrutura de rede, sabe que ela tende a acumular problemas, ou seja, a se desviar da configuração original. Um dos nossos objetivos ao criar o Fugue como sistema operacional (SO) para a nuvem e fonte única de verdade e confiança para sua infraestrutura é evitar esse desvio, mantendo-a no estado confiável conhecido. Afinal, “um sistema confiável só faz aquilo que seu autor pretende.”

Até agora, nosso foco foram os “problemas” que surgem nas instâncias de computação, mas esse problema também existe em outros componentes da infraestrutura, como as redes. O desvio de configuração em redes costuma ocorrer quando é necessário intervir manualmente para implantá-las e mantê-las. Já vi configurações de rede ocupando centenas de linhas em planilhas e sendo implantadas manualmente, linha por linha. Quando o aplicativo não funciona direito, a solução mais comum é intervir manualmente para abrir portas e intervalos de endereços IP.

Isso geralmente significa que a nova configuração não é atualizada na planilha original. Assim, correções temporárias acabam se tornando permanentes porque são esquecidas. Quando um novo serviço é adicionado ao aplicativo, são necessárias ainda mais intervenções manuais. Além de expor os aplicativos a possíveis riscos de segurança — por exemplo, pela abertura inadvertida de regras de grupos de segurança —, essas intervenções podem causar longos períodos de indisponibilidade quando regras ou rotas são excluídas por engano.

O desafio de configurar redes foi parcialmente resolvido com ferramentas e serviços de DevOps, como o AWS CloudFormation, que substitui a implementação manual pela automação da infraestrutura. Nesse modelo, as configurações de rede podem ser definidas em uma linguagem específica de domínio (DSL) controlada ou em um template reproduzível, auditável e testável.

No entanto, muitas dessas ferramentas não são suficientes. Elas simplesmente implantam as configurações de rede, mas não impõem o estado desejado após a implantação inicial. Isso fica evidente quando uma alteração manual é feita na rede depois que ela foi implantada com essas ferramentas. No pior cenário, as alterações permanecem como estão. No melhor, apenas as regras implantadas originalmente são impostas.

O Fugue leva a automação e o controle de redes um passo adiante. O Fugue se empenha em sempre restaurar as redes ao estado desejado definido na implantação. Se regras definidas originalmente em uma composição forem excluídas, o Fugue as restaurará. Se novas regras não definidas na composição forem adicionadas à rede, o Fugue as removerá.

Para ilustrar, vamos conferir um exemplo curto, mas poderoso, com grupos de segurança da AWS:

security-group web-elb-sg:
description:
'Allow port 80 from the world' ingress-rules:
{ 80: all-tcp } egress-rules:
{ 0-65535: all-tcp }security-group web-server-sg:
description:
'Allow port 80 from the web-elb-sg Security Group' ingress-rules:
{ 80: allow-from-web-elb } egress-rules:
{ 0-65535: all-tcp }rule allow-from-web-elb:
ip-protocol:
'tcp' groups:
[ web-elb-sg ]

No código Ludwig acima, definimos o grupo de segurança web-server-sg, que permite o tráfego de entrada pela porta 80 com origem no grupo web-elb-sg. Quando esse código é compilado e executado, o Fugue Conductor garante que os grupos de segurança e as regras definidos na composição sejam implantados na sua conta da AWS.

Mas o Conductor não para por aí. Assim como faz com as instâncias EC2, o Conductor verifica periodicamente (atualmente, a cada 10 segundos) a composição em execução e a compara com o que foi definido e compilado originalmente. Se a infraestrutura de rede não corresponder à composição que o Conductor detecta, ele fará as alterações necessárias na sua infraestrutura para mantê-la fiel à definição original.

Vamos testar o Fugue criando alguns problemas na nossa rede. Para isso, vou interpretar o papel de um administrador de sistemas bem-intencionado, mas inexperiente, que queria consultar alguns logs do servidor enquanto os servidores web estavam em execução (vamos supor que ele não sabia da existência do sistema de gerenciamento de logs recém-implementado).

Vou entrar no console de gerenciamento da AWS e adicionar uma regra de grupo de segurança que permita conexões SSH de 0.0.0.0/0. Como você pode ver no vídeo abaixo, poucos segundos depois de adicionar a regra, ela é removida e o grupo de segurança volta à configuração original.

Agora, vamos analisar a situação por outro ângulo. Imagine que é sexta-feira à tarde e nosso administrador de sistemas bem-intencionado quer conferir as regras de segurança da conta da AWS antes de sair para o fim de semana. Neste caso, vamos simular uma situação em que ele exclui sem querer a regra do grupo de segurança que permite o tráfego de entrada pela porta 80 até os servidores web. Sem perceber o que fez, ele fecha o laptop e vai para o bar.

Em uma situação típica, isso poderia causar uma grande interrupção no site. Mas, se analisarmos esse cenário, veremos que o site ficaria indisponível por no máximo 10 segundos. O Conductor faz sua verificação e recria rapidamente a regra do grupo de segurança, exatamente como foi definida na composição Ludwig.

Isso não se aplica apenas a grupos de segurança e suas regras. O Conductor também mantém a configuração de outros componentes de rede, como rotas de VPC, ACLs de rede, gateways de internet e sub-redes, entre outros.

Mas e se eu quiser alterar algo na minha composição?

É simples fazer alterações em uma composição em execução. Digamos que você queira adicionar uma regra ao grupo de segurança do ELB para permitir o tráfego da internet pela porta 443. Primeiro, modifique sua composição Ludwig para incluir essas alterações.

security-group web-elb-sg:
description:
'Allow port 80 and 443 from the world' ingress-rules:
{ 80: all-tcp, 443: all-tcp } egress-rules:
{ 0-65535: all-tcp }security-group web-server-sg: 
description:
'Allow port 80 from the web-elb-sg Security Group' ingress-rules:
{ 80: allow-from-web-elb } egress-rules:
{ 0-65535: all-tcp }rule allow-from-web-elb:
ip-protocol:
'tcp'
groups:
[ web-elb-sg ]

Quando terminar de editar, acesse a CLI do Fugue e execute os seguintes comandos:

$ fugue load foo.lw$ fugue update foo.lw

O comando load do Fugue compila a composição modificada e a envia para o S3. Em seguida, o comando update do Fugue sinaliza ao Conductor para obter a versão atualizada do S3 e aplicar as alterações à composição existente em execução.

Por que isso é importante?

Você pode passar horas toda semana mantendo e modificando manualmente as configurações de rede e, ainda assim, os problemas continuarão surgindo. Simplesmente não é um bom uso dos recursos da equipe. O Fugue oferece uma maneira automatizada e determinística de implantar, manter e atualizar componentes da infraestrutura. Diga ao Conductor o que você quer e ele fará acontecer — e manterá tudo assim.

Com o Fugue, você pode manter a fidelidade das suas redes e, ao mesmo tempo, reduzir o tempo de implantação e o trabalho contínuo de manutenção. Como a DSL Ludwig é baseada em intenção, reproduzível, aplicável e auditável, você pode operar seus aplicativos com a confiança de que as configurações de rede são mantidas continuamente no estado desejado.

Com uma infraestrutura de rede imutável, você pode atender aos rigorosos requisitos internos e externos de segurança e conformidade dos seus aplicativos com apenas algumas linhas de código.