Arquitetura de Infraestrutura: Containers Criando Quarto Plano
Na infraestrutura de rede tradicional, geralmente há três planos arquitetônicos associados à infraestrutura de rede: dados, controle e gerenciamento.
As definições exatas para isso podem variar dependendo do gênero e da implementação específica da infraestrutura, mas os arquétipos são amplamente precisos para a maioria das infraestruturas de rede.
- Plano de dados
- Às vezes chamado de caminho de dados no vernáculo moderno, o plano de dados é o caminho pelo qual os pacotes (dados) são passados. O plano de dados é responsável por aceitar um pacote e encaminhá-lo ao destino correto.
- Plano de controle
- Geralmente, o plano de controle determina para onde os dados são encaminhados. Os protocolos de roteamento são bons exemplos de funções de plano de controle, assim como a tomada de decisões de ordem superior que hoje pode ser mais dinâmica. A implementação específica varia, mas pode variar desde o plano de dados passando dados para o plano de controle para uma decisão até o plano de controle observando dados de forma transparente e agindo em gatilhos específicos. Os planos de controle geralmente também são responsáveis por monitorar a integridade dos dispositivos e coletar estatísticas.
- Plano de gestão
- O plano de gerenciamento é o mais visível dos três planos porque é onde interagimos com o plano de controle. Os planos de gerenciamento tradicionais usam CLI (interfaces de linha de comando), enquanto os planos de gerenciamento modernos preferem API (interfaces de programação de aplicativos). Independentemente do método usado, o plano de gerenciamento permite que os operadores definam políticas que são aplicadas pelo plano de controle. Isso inclui opções de configuração, como algoritmos de balanceamento de carga e políticas de permissão/negação com base em características como endereço IP e tipo de dispositivo.
Mas há outro tipo de orquestração em ação que fica oculto e passa despercebido pelos operadores. Não tem nada a ver com gestão, exceto que está se apropriando de algumas responsabilidades de operadores humanos.
A distinção aqui é que as ações são acionadas automaticamente por alterações no ambiente durante a execução, e não como um evento de implantação. Mas a informação sobre o que mudou é vital, e isso significa que ela precisa ser obtida em algum lugar.
Em um modelo operacional tradicional, essas informações geralmente vêm de tickets ou solicitações de alteração. No caso de modelos operacionais modernos e, especificamente, contêineres, essas informações vêm de registros de serviço por meio de um mecanismo de descoberta.
Registros de serviços e descoberta
A natureza dos ambientes de contêiner inclui a suposição de que os endereços IP efetivamente não importam para o ambiente do aplicativo. Mas eles são importantes para a infraestrutura porque os dados ainda precisam ser roteados e encaminhados de um dispositivo para outro para percorrer o caminho entre o cliente e o aplicativo. Em ambientes modernos, esses endereços IP geralmente existem por curtos períodos de tempo (a vida útil de um contêiner/serviço).
Considere estas descobertas do DataDog (ênfase adicionada):
A rápida adoção de orquestradores ( veja fato 4 ) parece estar levando os contêineres a vidas úteis ainda mais curtas, já que a inicialização e a parada automatizadas dos contêineres levam a uma maior taxa de rotatividade. Em organizações que executam um orquestrador, a vida útil típica de um contêiner é de cerca de 12 horas. Em organizações sem orquestração, o contêiner médio vive por seis dias.
De < https://www.datadoghq.com/docker-adoption >
Imagine se você, como operador, tivesse que atualizar as tabelas de roteamento ou os pools de balanceamento de carga a cada seis dias, e muito menos a cada doze horas. Você não faria muito mais do que isso. O potencial para configuração incorreta seria significativo e provavelmente aumentaria quanto mais tempo você fosse forçado a operar no modo manual para gerenciar as alterações em um cluster de contêineres.
Um registro de serviço - como o Consul - se torna um componente crítico da implantação do seu contêiner. Os registros de serviço rastreiam instâncias e serviços e seus endereços IP associados. Nesse aspecto, eles podem ser comparados a um "DNS para contêineres e serviços".
Portanto, o registro de serviço rastreia as características atuais dos contêineres no cluster. Descoberta é o processo de conexão ao registro de serviço (via API ou assinando uma fila de mensagens) de instâncias correspondentes a endereços IP.
Isso significa que, para uma infraestrutura que precisa rotear tráfego para um serviço ou instância específica dentro de um cluster de contêineres, ela deve ser capaz de recuperar um endereço IP. Porque, por mais que os contêineres ocultem a rede do aplicativo, eles ainda dependem dela para levar dados de um lugar para outro.
O Quarto Plano: Orquestração
O que isso faz é introduzir uma nova camada arquitetônica na infraestrutura que interage com ambientes de orquestração de contêineres. Esta camada - a camada de orquestração - integra-se ao ambiente do contêiner e faz uso de recursos como descoberta de serviços para automatizar a descoberta de serviços e instâncias. Isso significa que um balanceador de carga pode descobrir automaticamente os membros de um pool e atualizá-lo continuamente com base nas alterações no ambiente. Isso alivia a carga das operações de atualizar pools de balanceamento de carga manualmente — uma tarefa cada vez mais tediosa quando os contêineres vivem em média menos de uma semana.
Este avião não foi feito para interação com operadores. A configuração, o monitoramento e a operação ainda são realizados por meio de um plano de gerenciamento. A localização de um registro de serviço seria configurada por meio do plano de gerenciamento, mas usada pelo plano de orquestração para conectar e comunicar alterações ao plano de controle.
Podemos definir o plano de orquestração da seguinte forma.
- O plano de orquestração é um dos planos menos visíveis na arquitetura de infraestrutura. A interação com ele é realizada por meio do plano de gerenciamento, que é o principal responsável por apontar o plano de orquestração para o registro de serviço apropriado. Sua responsabilidade é atualizar componentes dinâmicos no plano de controle para garantir o encaminhamento e a disponibilidade adequados dos recursos em contêineres.
Ainda restam dúvidas se esse plano deve ser integrado ao dispositivo junto com os planos de controle e dados ou se é simplesmente uma fachada sobre o plano de gerenciamento (o que mudaria um pouco nosso diagrama, mas não afetaria a interação entre planos e componentes). Muitos dispositivos tradicionais já oferecem suporte a esse plano emergente, fornecendo extensões que se integram a ambientes de contêiner e fazem alterações por meio do plano de gerenciamento. Este é um bom exemplo de refatoração de arquiteturas tradicionais para estender a funcionalidade em ambientes modernos. Mas, no final das contas, pode não ser a solução ideal.
POR QUE ISSO É IMPORTANTE?
Pode parecer à primeira vista que a introdução de um quarto avião para infraestrutura não importa. Afinal, sua função é retirar dos operadores parte da responsabilidade por tarefas tediosas. Isso não pode ser ruim.
Não é ruim, mas é importante entender que essa mudança de configuração estática para dinâmica tem consequências para algumas das funções mais importantes do plano de controle. A criticidade da descoberta de serviços torna-se tal que sua disponibilidade e segurança devem ser imperativas. Ele se torna, na verdade, o único ponto de falha no qual toda a sua infraestrutura de aplicativos se baseia.
Os registros de serviço são criados nas mesmas premissas da maioria dos aplicativos modernos: eles são criados para lidar com falhas. Você pode acabar em uma situação em que o endereço IP que você acabou de descobrir desaparece antes que você possa encaminhar o tráfego para sua instância. A maior parte da infraestrutura é capaz de retransmitir nesse ponto, mas o processo leva tempo. Microssegundos são importantes na economia digital, então opções tradicionais como tempos limite e intervalos de descoberta farão a diferença em arquiteturas modernas que dependem de descoberta. O monitoramento também se torna muito mais crítico, pois a capacidade de determinar a integridade e a disponibilidade o mais rápido possível pode fazer a diferença entre um usuário ficar satisfeito e um usuário desistir. Ambas são preocupações de nível empresarial que todos em uma organização moderna devem estar cientes e incorporar em suas próprias métricas e expectativas.
A implementação do plano de orquestração em sua infraestrutura, bem como a escolha do registro de serviço, tornam-se fatores importantes no seu processo de tomada de decisão sobre qual tecnologia usar. Pense cuidadosamente em suas escolhas, pois elas afetam tanto a disponibilidade quanto o desempenho dos aplicativos entregues por meio de arquiteturas baseadas em contêineres.