- Piku es una herramienta inspirada en Dokku que permite implementar aplicaciones con el método
git push incluso en servidores propios pequeños
- Apunta a un flujo similar al de Heroku/CloudFoundry, pero como en ese momento Dokku no funcionaba en ARM y Docker podía ser excesivo, busca un método de despliegue más simple
- Durante el despliegue, detecta el runtime, instala dependencias, lee el
Procfile y ejecuta workers con uwsgi; incluye manejo para Python, Node, Java, Clojure, Ruby y Go
- Permite implementar, administrar y escalar varias apps de forma independiente en un solo host, y soporta hosts virtuales, SSL, sitios estáticos, mapeo de rutas URL y caché de respuestas del backend
- Requiere Python 3.10 o superior, además de Python,
nginx, uwsgi y SSH; es un proyecto en estado estable que apunta a soportar las dos versiones principales más recientes de Debian y Ubuntu LTS
El problema que resuelve Piku
- Piku es una herramienta que permite desplegar con
git push en tu propio servidor
- Está inspirada en Dokku y apunta a funcionar incluso en servidores muy pequeños
- Se quería una experiencia de despliegue similar a Heroku/CloudFoundry en algunas placas ARM, pero en ese momento Dokku no funcionaba en ARM y Docker a veces era excesivo, por lo que hacía falta una solución más simple
- Actualmente permite desplegar, administrar y escalar de forma independiente varias aplicaciones por host, tanto en arquitecturas ARM como Intel
- Funciona en proveedores cloud y entornos bare metal capaces de ejecutar Python,
nginx y uwsgi
Instalación y estado del proyecto
- La instalación básica puede hacerse con el siguiente comando
curl https://piku.github.io/get | sh
- La documentación de instalación también incluye otros métodos, como
cloud-init e instalación manual
- El proyecto se considera en estado STABLE
- El conjunto de funcionalidades está casi completo
- Se actualiza cuando se agregan nuevos runtimes de lenguaje o aparecen bugs reproducibles
- Actualmente requiere Python 3.10 o superior, y las pruebas también apuntan a Python 3.10 o superior
- El objetivo de soporte son las dos versiones principales más recientes de Debian y Ubuntu LTS
Flujo de trabajo basado en Git Push
- Piku soporta un flujo de trabajo similar al de Heroku
- Usa el nombre de la app como nombre del repositorio y crea un remote Git por SSH que apunte al servidor Piku
git remote add piku piku@yourserver:appname
- Despliega haciendo push del código
git push piku master
- Para hacer push de una rama distinta a la rama actual, se usa así
git push piku release-branch-name
- Durante el despliegue, Piku detecta el runtime, instala las dependencias necesarias y realiza los builds requeridos
- Las apps Python separan sus dependencias mediante un virtualenv por app
- Las apps Go definen un
GOPATH separado por app
- Las apps Node instalan en
node_modules los elementos definidos en package.json
- Las apps Java se compilan según
pom.xml o build.gradle
- Las apps Clojure pueden usar
leiningen o la CLI de Clojure junto con el archivo deps.edn
- Las apps Ruby ejecutan
bundle install de las gems en una carpeta aislada
Modelo de ejecución y configuración
- Piku lee el
Procfile y ejecuta los workers correspondientes mediante uwsgi
uwsgi se usa como gestor de procesos de propósito general- Opcionalmente se puede definir un worker
release, que se ejecuta una vez durante el despliegue de la app
- Es posible cambiar la configuración de la aplicación o aumentar y reducir los procesos worker de forma remota
config:set cambia la configuración de la aplicaciónps:scale escala los procesos worker
- El archivo
ENV puede incluir la configuración de la aplicación y de nginx
- Con el tipo de worker
static, también se pueden desplegar sitios estáticos al estilo gh-pages
- Se especifica la ruta raíz como argumento
- También se puede ejecutar una tarea
release que realice procesamiento en el servidor después de git push
Hosts virtuales, SSL y rutas estáticas
- Piku soporta plenamente hosts virtuales
- Permite alojar varias apps en el mismo VPS
- Se puede acceder a las apps con distintos nombres de host usando alias DNS
- Para habilitar SSL, se puede configurar un certificado privado u obtener un certificado de Let's Encrypt
- Si se accede desde una LAN con clientes macOS, iOS o Linux, se puede usar
piku/avahi-aliases para anunciar distintos hosts para la misma IP mediante Avahi/mDNS/Bonjour
- Además de sitios estáticos, se puede mapear directamente un prefijo de URL específico a una ruta del sistema de archivos
- También soporta caché de respuestas del backend para reducir la carga de la aplicación
- Las rutas estáticas y la caché se configuran mediante valores en el archivo
ENV
Plataformas y runtimes soportados
- Piku está diseñado para funcionar en entornos tipo POSIX con Python,
nginx, uwsgi y SSH
- Los casos de despliegue incluyen Linux, FreeBSD, Cygwin y Windows Subsystem for Linux
- El desarrollo comenzó en una Raspberry Pi Model B de 256 MB y todavía se ejecuta de forma estable en ese equipo
- Su uso principal es como micro PaaS para ejecutar apps en servidores cloud con CPU Intel y ARM
- Las plataformas objetivo son Debian y Ubuntu Linux
- Actualmente soporta apps Python, Node, Clojure y Java, y también se está trabajando en algunos lenguajes como Go
- Como principio general, si se puede invocar desde el shell, se puede ejecutar dentro de Piku
Principios de diseño
- Prioriza ejecutarse en dispositivos de bajos recursos
- Debe ser accesible también para desarrolladores aficionados y escuelas K-12
- Apunta a unas 1500 líneas de código fácil de leer
- Prefiere un estilo de código funcional
- Busca tener pocas dependencias
- Sigue el enfoque de 12 factor app
- Prioriza simplificar la experiencia de usuario
- Apunta a cubrir el 80% de los casos de uso comunes
- Ofrece valores predeterminados razonables para todas las funciones
- Aprovecha los paquetes de distribución de Raspbian, Debian y Ubuntu
- El soporte para Alpine y RHEL está en desarrollo
- Usa herramientas estándar como
git, ssh, uwsgi y nginx
- Mantiene la compatibilidad hacia atrás siempre que sea posible
1 comentarios
Opiniones de Hacker News
Me gusta piku, así que escribí un tutorial de una app web para piku, y terminó entrando como repositorio en la organización oficial de piku en GitHub
https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
Explica cómo funciona piku internamente y también muestra, desde la perspectiva del usuario, un ejemplo mínimo de una app web en Python
Sentí que la documentación asumía que ya sabía todo lo necesario para ejecutar y usar piku, así que me rendí; este tutorial llena ese vacío
Sin embargo, aunque busqué bastante durante mucho tiempo, no encontré este documento, y si no fuera por este comentario ni habría sabido que existía
Como mínimo, deberían enlazarlo de forma visible desde el repositorio de piku y la página principal de la documentación; si es posible, sería mejor incluirlo completo en la página principal de la documentación
Más aún, sería mucho más útil agregar un tutorial de punta a punta que vaya desde un servidor bare metal nuevo hasta un dominio personalizado y certificado SSL accesibles públicamente
Aunque parezcan pasos no relacionados directamente con piku, lo que en realidad quiere un usuario nuevo es subir su propio sitio a algo como un Droplet de US$5, y muchas veces todavía no conoce los pasos intermedios
No importa qué método elijan; quien quiera discutir el método ya sabe cuál prefiere
Como referencia, aquí hay un ejemplo de punta a punta de Coolify: https://billyle.dev/posts/self-hosting-your-website-with-coo...
El objetivo no es simplemente hacer que sea funcionalmente posible, sino facilitar que más gente empiece y así aumentar mucho la adopción de piku
No tenía idea de qué era Heroku ni qué hacía
Si entendí bien, ¿piku instala un agente en la máquina remota y un hook de commit en la máquina local?
Me pregunto si no se podría reducir el overhead haciendo que la máquina remota sea simplemente un repositorio Git remoto y que, al hacer push a una rama específica, todo el trabajo se haga del lado remoto
Se ve bien, y Dokku también me resultó muy estable, pero si se elimina la dependencia de Docker, quedas atado a las opciones que ofrece el sistema operativo
No es ideal para apps que podrían correr durante años sin mantenimiento, y al final te encuentras rápidamente con que necesitas una versión específica del sistema operativo
Lo usé para subir pequeños proyectos secundarios a un VPS y actualicé la instalación de Dokku a través de 3 o 4 versiones de Ubuntu LTS sin problemas; funcionó muy bien
docker run, aunque por supuesto no fue diseñado para ese usoLa mayoría de los despliegues que he visto están sobre distribuciones muy estables, normalmente versiones LTS, así que no hizo falta actualizar el runtime cada 6 meses, y mi sitio web siguió corriendo en piku durante más de dos cambios de Ubuntu LTS
Con solo configurar variables de entorno, también se pueden usar fácilmente cosas como
pyenvynvenvMi sistema de automatización del hogar ahora necesita dos versiones de Node distintas, y tengo configurada una por app
Entiendo que la actitud de “simplemente funciona” es elegante, y que Docker no puede usarse en todas partes por su overhead técnico y mental, pero lo bueno de los contenedores es que aíslan todo y permiten dejarlo fijo como si se detuviera el tiempo, de modo que 5 años después “simplemente funcione”
En mi pequeño flujo de trabajo, la gestión de contenedores la hago con lazydocker, el despliegue por push con un workflow de GitLab, y la compilación, el push al registry de GitLab y la ejecución con un pequeño VPS
Es un poco excesivo, así que creo que también podría hacerse con una combinación de
Dockerfile,compose.ymlydocker compose buildTodavía no tengo resuelto el escalado, pero por suerte ahora no lo necesito; si llegara a necesitarlo, probablemente cambiaría Docker por k8s y lazydocker por k9s
Recién estoy entrando en DevOps, así que cualquier sugerencia es bienvenida
Para mí es mejor que Dokku porque tiene menos abstracciones mágicas
No está directamente relacionado con el despliegue con
git push, pero sí muy ligado a la experiencia PaaS: el equipo en el que estoy está probando una vista previa de Cloud Native Buildpacks (CNB), una especificación abierta de la CNCFSon Buildpacks orientados a OCI, lo que significa que puedes crear imágenes Docker localmente con una herramienta de build que detecta el soporte de lenguaje y actúa en consecuencia, como la lógica de
git pushde HerokuAquí hay un tutorial para compilar una app Rails con un buildpack que mantengo: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
Si lo pruebas, ya sea que tu reacción sea buena, mala o indiferente, dejar tu experiencia en la discusión enlazada ayudará a mejorarlo
Vi piku por primera vez.
No sé por qué, pero esa sensación de que el despliegue empieza con
git push, como en piku, siempre me pareció mágica, y siento que no puede ser más simple que eso.Justo ayer publiqué como open source un proyecto para Kubernetes en el mismo ámbito; está aquí: https://github.com/pier-oliviert/sequencer
En fin, felicitaciones, se ve bien.
En el servidor, creas un repositorio Git con
git init --barey configurasgit config receive.denyCurrentBranch updateInstead.Luego, con un hook de Git, más específicamente un hook push-to-checkout, puedes recibir la subida, compilar y ejecutar.
El hook es un script de shell sencillo, y en su forma más básica basta con una variante como
compile && install && systemctl restart service.Después, si clonas el repositorio en local, al hacer push de los cambios se ejecuta el hook configurado.
git clone root@yourserver.com:/path/to/git/folderPor la descripción, parece que maneja plantillas de Kubernetes y
kubectl, no despliegues congit push, así que parece un proyecto de un ámbito completamente distinto.La documentación renovada de piku se puede ver aquí: https://piku.github.io/
¿El commit inicial fue hace 8 años?
Ojalá hubiera conocido este proyecto hace unos 18 meses, cuando estaba buscando una forma de desplegar en una Raspberry Pi con una experiencia de desarrollo tipo Heroku; piku parece apuntar exactamente a eso.
Acabo de configurar un VPS nuevo con CapRover y, mientras buscaba durante más o menos una hora comparativas de “PaaS self-hosted al estilo Heroku”, vi Dokku, CapRover, Coolify y Dokploy, pero no vi piku en absoluto.
Soy maintainer y coautor.
Si te gustan las herramientas de despliegue simples y minimalistas, también agradecería que vieras https://github.com/rcarmo/ground-init, que aborda cloud-init de una forma mucho más realista.
Me da curiosidad si hay alguna forma de manejar despliegues sin downtime.
Por ejemplo, si un servicio Python está corriendo detrás de nginx en el puerto 8080 de una máquina, ¿cómo hace piku para cambiar a una nueva instancia en el mismo puerto?
git push.El manejo de sockets y sesiones depende de cómo esté escrito el código y de si usa
uwsgio levanta un daemon HTTP directamente.Una de las funciones que ya se soportan opcionalmente es finalizar instancias no usadas e instancias inactivas, y hacer arranque diferido cuando llega una conexión nueva.
Me gusta Epinio, que hace lo mismo sobre Kubernetes.
Está respaldado por SUSE y, por ejemplo, es más liviano que KNative, que es la base de GCP Cloud Run, pero al estar basado en Kubernetes sigue requiriendo más recursos que Dokku o piku.
Aun así, prefiero k8s porque tiene un ecosistema amplio de soluciones maduras.
También se puede correr todo en un solo servidor, solo que se necesita uno un poco más grande.
El nuevo Hetzner CX42 tiene 8 vCPU, 16 GB de RAM y 160 GB de disco por €16.40 al mes, €0.0273 por hora, así que alcanza; y con el proyecto Kube Hetzner se puede configurar en menos de 5 minutos un clúster Kubernetes basado en MicroOS con actualizaciones automáticas.
https://github.com/epinio/epinio/
https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...
El punto central de piku parece ser ofrecer una experiencia tipo Heroku sin Docker, con una arquitectura realmente simple, y que además funcione en ARM.
Concedo que Kubernetes funciona en ARM, pero hasta donde sé Kubernetes requiere algún tipo de contenedor, ya sea Docker u otra cosa, y su arquitectura, por razones obvias, nunca es simple.
Además, ni siquiera tengo claro si Epinio permite un flujo con
git push.El tutorial de inicio rápido parece indicar que para desplegar una aplicación se use un comando como
epinio push manifest.yaml, así que tampoco encaja con la “experiencia tipo Heroku”.Al final, creo que lo único que tienen en común es que gestionan despliegues.
Me gusta el enfoque minimalista, así que pienso probarlo.
También hay cosas similares que vale la pena mirar.
https://kamal-deploy.org/
https://github.com/basecamp/kamal
https://dokku.com/
https://github.com/dokku/dokku/
https://clace.io/
https://github.com/claceio/clace