- Proxy reverso para tunelamento para redes externas
- Lida com tráfego em nível de produção e foi projetado para ser simples de hospedar, especialmente no Kubernetes
- Pode expor serviços em redes de clientes, serviços BYOC (Bring Your Own Cloud) ou conectar-se a dispositivos IoT
- Pode ser hospedado como um cluster de nós para tolerância a falhas, escalabilidade e deploy sem downtime
Como o Piko funciona
- Os serviços upstream se conectam ao Piko para registrar endpoints
- O Piko roteia requisições para endpoints aos serviços upstream registrados por meio de conexões somente de saída
- Isso significa que é possível expor serviços sem abrir portas públicas
- As requisições HTTP(S) recebidas identificam o ID do endpoint de destino usando o cabeçalho Host ou o cabeçalho
x-pico-endpoint
- Se vários serviços upstream registrarem o mesmo endpoint, o Piko faz balanceamento de carga das requisições desse endpoint entre os upstreams registrados
Objetivos de design do Piko
Processamento de tráfego de produção
- O Piko foi projetado para lidar com tráfego de produção, não como uma ferramenta de teste e desenvolvimento
- Com o Piko, é possível acessar redes de clientes, construir soluções BYOC e acessar dispositivos IoT
- Para dar suporte a isso, o Piko pode ser executado como um cluster de nós para tolerância a falhas, escalabilidade horizontal e deploy sem downtime
- Também fornece ferramentas de observabilidade para monitoramento e depuração
Facilidade de hospedagem
- O Piko foi projetado para ser fácil de hospedar no Kubernetes
- Um cluster Piko pode ser hospedado como um Kubernetes StatefulSet atrás de um load balancer HTTP ou de um Kubernetes Gateway
- As conexões dos serviços upstream e as requisições dos clientes proxy podem receber balanceamento de carga em qualquer nó do cluster, e o Piko gerencia o roteamento das requisições para o upstream correto
Segurança
- Os serviços upstream se conectam ao Piko por meio de conexões somente de saída
- O Piko roteia todas as requisições ao upstream por meio dessa conexão
- Portanto, o upstream não precisa abrir portas para receber requisições
- O Piko oferece suporte à autenticação dos serviços upstream antes que eles registrem endpoints
- Como o Piko pode ser self-hosted, ele pode ser hospedado na mesma rede que os clientes proxy para não aceitar requisições de redes externas
- Por exemplo, é possível permitir que serviços upstream autenticados se registrem pela internet via TLS e, em seguida, fornecer rotas internas apenas para clientes proxy na mesma rede do Piko
6 comentários
Isso significa que é possível expor serviços sem abrir uma porta pública
Por exemplo, suponha que o estudante A de graduação em Ciência da Computação esteja fazendo um projeto.
Depois de desenvolver tudo com muito esforço, com o dia da apresentação se aproximando, A quer demonstrar esse serviço.
Mas A mal acabou de aprender a programar um servidor e não sabe como subir nenhum servidor nem nenhuma instância.
Além disso, como mora no dormitório, não pode expor o serviço por meio de port forwarding.
É aí que entra o tunelamento.
Se no notebook do dormitório ele digitar
ngork http 8080, será gerada uma URL aleatória, e quando um usuário acessar essa URL durante a demonstração na sala de aula, a requisição HTTP será encaminhada do servidor do ngrok para o cliente do ngrok e então para o programa de servidor de A, permitindo expor o serviço sem necessidade de port forwarding.https://github.com/andydunstall/piko/pull/20
Parece que o nome do projeto mudou de Pico para Piko. Ao que tudo indica, a mudança foi feita por causa de um conflito, já que já existe um editor chamado pico.
Ao ver a resposta dizendo que não conheciam o editor pico, sinto o peso da minha idade. Antes do nano, era o pico T_T
Eu procurei, organizei e postei isso ontem... mas nesse meio-tempo já mudou T_T. Corrigi agora.