Projetos
Apiary: a porta de entrada dos seus sistemas, sem um ponto único de falha
A Datapoint lançou o Apiary, um proxy inverso gratuito e de código aberto para Docker Swarm. Encaminha o tráfego para o serviço certo, renova sozinho os certificados HTTPS e continua a funcionar quando um servidor falha, sem mais uma base de dados para manter.
Todos os sites e aplicações na Internet têm uma porta de entrada: um componente que recebe o pedido de cada visitante, decide que serviço lhe deve responder e trata da ligação segura (HTTPS). Quase ninguém repara nela, até ao dia em que falha. Quando a porta de entrada vai abaixo, vão abaixo com ela todos os sites que estão por trás.
Para que essa porta nunca seja o ponto fraco, a Datapoint lançou o Apiary, um proxy inverso gratuito e de código aberto para Docker Swarm. Encaminha o tráfego para o serviço certo, obtém e renova sozinho os certificados HTTPS e continua a funcionar quando um servidor falha, sem precisar de mais uma base de dados para manter. O Apiary está em versão beta (1.0.0-beta.1), e qualquer pessoa pode ler, usar e melhorar o código no repositório em github.com/datapoint-software/apiary.
O rececionista do edifício
Imagine um edifício de escritórios com várias empresas. Os visitantes não sobem diretamente aos andares: passam pela receção, que confirma a identidade de cada um, verifica a que empresa vai e lhe indica o elevador certo. Se uma empresa muda de andar, só a receção precisa de saber. Os visitantes continuam a entrar pela mesma porta.
Um proxy inverso faz o mesmo trabalho para os sistemas de informação. Recebe todos os pedidos que chegam a loja.exemplo.pt, loja.exemplo.pt/api ou pagamentos.exemplo.pt e entrega cada um ao serviço que lhe deve responder. É também ali que se tratam os certificados que garantem que a ligação é segura, se limitam os abusos e se mostra uma página de manutenção quando é preciso.
Porque é que a porta de entrada não pode falhar
Muitas organizações já instalam as suas aplicações em contentores, com o Docker Swarm a distribuí-las por vários servidores. Se um servidor falha, o Swarm volta a arrancar as aplicações noutro. Mas de pouco serve ter as aplicações repartidas por vários servidores se todo o tráfego passar por uma única porta que pode cair.
Uma porta de entrada que depende de um único servidor transforma esse servidor no ponto único de falha de todos os sites.
A resposta habitual junta várias peças: um proxy, um armazenamento à parte para a sua configuração, uma ferramenta para os certificados e scripts que mantêm tudo sincronizado entre servidores. Cada peça é mais uma coisa para instalar, atualizar, copiar e manter disponível. O Apiary junta tudo isto numa única imagem, feita para o Swarm.
O que o Apiary faz
Encaminhamento. Uma rota liga um nome e um caminho, como
loja.exemplo.pt/api, a um serviço. O Apiary chega aos serviços pelo nome que têm na rede do Swarm, por isso não há endereços IP para manter atualizados. Suporta HTTP/1.1, HTTP/2, HTTP/3 e WebSockets, e encaminha também tráfego TCP e UDP para o que não é um site, como bases de dados, mensagens MQTT ou registos de sistema.HTTPS automático. Obtém os certificados na Let's Encrypt e renova-os antes de expirarem, sem passos manuais. Todos os servidores partilham os mesmos certificados. Também é possível carregar certificados próprios, por exemplo para nomes genéricos (wildcard) ou de uma autoridade de certificação interna.
Operação do dia a dia. Redirecionamentos, desativação de rotas, listas de endereços IP autorizados, limites de pedidos, pré-visualizações protegidas por palavra-passe, janelas de manutenção agendadas com uma mensagem própria e páginas para visitantes com o logótipo e as cores de cada projeto.
Observação. A visão geral mostra os pedidos por minuto, a latência, as taxas de erro, o estado de cada destino e os certificados prestes a expirar. As métricas e os rastreios ficam disponíveis para as ferramentas de monitorização.
Acesso e responsabilização. Os utilizadores entram com uma aplicação de autenticação ou com o início de sessão único da organização (OpenID Connect). Os perfis limitam quem pode alterar o quê, e o registo de auditoria guarda cada alteração, quem a fez e de onde.
Assistentes de IA. O Apiary pode ser gerido por assistentes de inteligência artificial através do MCP (Model Context Protocol), com início de sessão próprio, para que um assistente só faça o que o seu utilizador pode fazer.
Em português e em inglês. A interface está disponível em português europeu e em inglês.
Novas versões sem sobressaltos
Publicar uma nova versão de uma aplicação para todos os visitantes ao mesmo tempo é arriscado: se algo correr mal, corre mal para toda a gente. Com o Apiary, uma rota pode dividir o tráfego por pesos, por exemplo 90% para a versão atual e 10% para a nova. É o que se chama uma publicação canário. Se a nova versão se portar bem, aumenta-se a sua parte. Se não, volta-se atrás e só uma pequena parte dos visitantes foi afetada.
Quem está a testar pode chegar à nova versão de propósito, com um cabeçalho ou um cookie, e as sessões persistentes mantêm cada visitante na mesma versão durante uma hora, para que não salte de uma para a outra a meio de uma compra.
Uma colmeia de réplicas
O Apiary funciona como várias cópias (réplicas) em servidores diferentes, que se mantêm a par umas das outras com o Raft, um algoritmo de acordo bem conhecido. Uma das réplicas é a líder e as outras votam. Se um servidor falha, as restantes continuam a servir o tráfego e nenhum certificado se perde. Quando o Swarm arranca uma nova réplica, ela junta-se às outras sozinha.
A alta disponibilidade exige pelo menos três réplicas. Duas não são suportadas, porque não toleram mais falhas do que uma só. E se se perderem réplicas a mais para chegarem a acordo, o Apiary suspende as alterações, di-lo claramente na interface e continua a servir os visitantes com a última configuração conhecida. Num único servidor, ou num portátil com Docker Compose, o Apiary também funciona, mas sem alta disponibilidade. É uma boa forma de o experimentar.
Cada situação, uma resposta
| Situação | O que o Apiary faz |
|---|---|
| Um servidor falha | As outras réplicas continuam a servir o tráfego, com os mesmos certificados. |
| Perdem-se réplicas a mais | Suspende as alterações, avisa na interface e continua a servir com a última configuração conhecida. |
| Um certificado está perto do fim | Renova-o sozinho e, se a renovação falhar, avisa e mostra o registo do que correu mal. |
| Chega uma nova versão de uma aplicação | Divide o tráfego por pesos e deixa quem testa chegar à nova versão de propósito. |
| A equipa publica uma alteração | Aplica as rotas declaradas no ficheiro de stack e regista o que foi adicionado, alterado e removido. |
| É preciso atualizar o próprio Apiary | Substitui uma réplica de cada vez e volta atrás sozinho se algo falhar. |
A configuração ao lado do código
As equipas podem descrever as suas rotas como etiquetas no mesmo ficheiro de stack que instala os seus serviços. Depois de cada publicação, o processo de integração e entrega contínuas (CI/CD) envia esse ficheiro ao Apiary, e as rotas mudam no mesmo commit que o código. Os campos que vêm do ficheiro ficam bloqueados na interface, para que ninguém os altere por engano, mas desativar uma rota e agendar uma manutenção continuam disponíveis.
Há aqui uma escolha de segurança importante: o Apiary nunca mexe no Docker. Muitos proxies para Swarm precisam de acesso ao socket do Docker, o que, na prática, dá controlo sobre todo o servidor. No Apiary é o processo de publicação que lê o ficheiro de stack e envia ao Apiary apenas o que este declara.
Escolhas deliberadas
Sem base de dados externa. O Apiary guarda a configuração e os certificados ele próprio, replicados entre as suas réplicas. Não há mais nada para instalar, copiar ou manter disponível.
Instalado como qualquer outra aplicação do Swarm. Depois de criar uma chave secreta, instalar, atualizar e escalar o Apiary é um único
docker stack deploy.Predefinições seguras. A compressão está desligada por omissão, porque em algumas páginas pode revelar segredos; palavras-passe e certificados não podem ser colocados em ficheiros de stack, onde qualquer pessoa que consiga inspecionar um serviço os leria; e são recusadas as rotas que apontariam para a própria interface de administração do Apiary.
Uma interface escrita para pessoas. As mensagens de erro dizem o que fazer a seguir, as ações perigosas indicam exatamente o que afetam, e todas as horas são mostradas em UTC, para que equipas em fusos horários diferentes leiam o mesmo.
Para equipas técnicas
Esta secção é mais técnica. O servidor do Apiary é escrito em .NET 10 e usa o YARP, a biblioteca de proxy inverso da Microsoft; a replicação usa o Raft e a interface é feita em Angular. A imagem é datapointsoftware/apiary, no Docker Hub. Para usar certificados automáticos é preciso aceitar o acordo de subscritor da Let's Encrypt, um serviço de terceiros.
O Apiary está em beta: tem todas as funcionalidades previstas e pode ser atualizado no lugar a partir da 1.0.0-beta.1, mas alguns comportamentos ainda podem mudar antes da 1.0.0. É software livre, sob a GNU AGPL versão 3 com termos adicionais: qualquer pessoa o pode usar, alterar e partilhar, e as versões modificadas que sejam partilhadas ou disponibilizadas em rede têm de oferecer o seu código-fonte. A documentação, as instruções de instalação e o código estão no repositório, onde agradecemos sugestões e relatos de erros.
Como trabalhamos
Na Datapoint, desenvolvemos, implementamos e mantemos sistemas de informação, e sabemos que um sistema só está disponível se a sua porta de entrada também estiver. Publicámos o Apiary como código aberto para que qualquer equipa o possa usar, estudar e melhorar. Se quiser preparar a infraestrutura dos seus sistemas para não depender de um único servidor, fale connosco.