- Un proxy inverso para tunelizar hacia redes externas
- Maneja tráfico de nivel de producción y está diseñado para que el hosting sea sencillo, especialmente en Kubernetes
- Permite exponer servicios en redes de clientes, servicios BYOC (Bring Your Own Cloud) o conectarse a dispositivos IoT
- Puede alojarse como un clúster de nodos para tolerancia a fallos, escalabilidad y despliegues sin interrupciones
Cómo funciona Piko
- Los servicios upstream se conectan a Piko para registrar endpoints
- Piko enruta las solicitudes para esos endpoints hacia los servicios upstream registrados mediante conexiones solo de salida
- Esto significa que puedes exponer servicios sin abrir puertos públicos
- Las solicitudes HTTP(S) entrantes identifican el ID del endpoint de destino usando el encabezado
Host o el encabezado x-pico-endpoint
- Si varios servicios upstream registran el mismo endpoint, Piko balancea la carga de las solicitudes para ese endpoint entre los upstream registrados
Objetivos de diseño de Piko
Manejo de tráfico de producción
- Piko está diseñado para manejar tráfico de producción, no como una herramienta de pruebas o desarrollo
- Con Piko puedes acceder a redes de clientes, construir soluciones BYOC y acceder a dispositivos IoT
- Para soportar esto, Piko puede ejecutarse como un clúster de nodos para tolerancia a fallos, escalado horizontal y despliegues sin tiempo de inactividad
- También ofrece herramientas de observabilidad para monitoreo y depuración
Facilidad de hosting
- Piko está diseñado para ser fácil de alojar en Kubernetes
- Un clúster de Piko puede alojarse como un
StatefulSet de Kubernetes detrás de un balanceador de carga HTTP o un Kubernetes Gateway
- Las conexiones de los servicios upstream y las solicitudes de clientes proxy pueden balancearse entre todos los nodos del clúster, y Piko se encarga de enrutar las solicitudes al upstream correcto
Seguridad
- Los servicios upstream se conectan a Piko mediante conexiones solo de salida
- Piko enruta todas las solicitudes al upstream a través de esas conexiones
- Por lo tanto, el upstream no necesita abrir puertos para recibir solicitudes
- Piko admite autenticar a los servicios upstream antes de que registren endpoints
- Como Piko puede autohospedarse, puede alojarse en la misma red que los clientes proxy para no aceptar solicitudes desde redes externas
- Por ejemplo, puedes permitir que servicios upstream autenticados se registren desde internet mediante TLS y luego ofrecer rutas internas solo a clientes proxy que estén en la misma red que Piko
6 comentarios
Esto significa que puedes exponer servicios sin abrir un puerto público.
Por ejemplo, supongamos que el estudiante universitario A de ingeniería en computación está trabajando en un proyecto.
Después de desarrollar con mucho esfuerzo, al acercarse el día de la presentación, A quiere hacer una demostración de este servicio.
Pero A apenas sabe programar un servidor y no sabe cómo levantar ningún servidor ni ninguna instancia.
Además, como vive en la residencia universitaria, no puede exponer el servicio mediante port forwarding.
Aquí es donde aparece el tunneling.
Si en la laptop que está en la residencia escribe
ngork http 8080, se genera una URL aleatoria, y cuando durante la demostración en el aula un usuario entra a esa URL, la solicitud HTTP se transmite del servidor de ngrok al cliente de ngrok y luego al programa de servidor de A, de modo que puede exponer el servicio sin necesidad de configurar port forwarding por separado.https://github.com/andydunstall/piko/pull/20
Parece que el nombre del proyecto cambió de Pico a Piko. Da la impresión de que lo cambiaron por un conflicto, ya que ya existe un editor llamado pico.
Ver una respuesta de alguien que no conocía el editor pico me hizo sentir lo ruco que estoy. Antes de nano era pico ;_;
Lo busqué ayer, lo pedí y lo publiqué, pero mientras tanto ya lo cambiaron... uf. Lo corregí.