- Piku é uma ferramenta inspirada no Dokku que permite fazer deploy de aplicações via
git push até mesmo em pequenos servidores próprios
- Segue um fluxo semelhante ao do Heroku/CloudFoundry, mas como na época o Dokku não funcionava em ARM e o Docker podia ser excessivo, o objetivo era um método de deploy mais simples
- Durante o deploy, detecta o runtime, instala dependências e depois lê o
Procfile para executar workers com uwsgi, incluindo suporte para Python, Node, Java, Clojure, Ruby e Go
- Permite implantar, gerenciar e escalar de forma independente vários apps em um único host, com suporte a hosts virtuais, SSL, sites estáticos, mapeamento de caminhos de URL e cache de respostas do backend
- Requer Python 3.10 ou superior, além de Python,
nginx, uwsgi e SSH, e é um projeto em estado estável com foco nas duas versões principais mais recentes de Debian e Ubuntu LTS
O problema que o Piku resolve
- Piku é uma ferramenta que permite fazer deploy via
git push no seu próprio servidor
- Foi inspirada no Dokku e tem como objetivo funcionar até mesmo em servidores muito pequenos
- A ideia era ter uma experiência de deploy parecida com Heroku/CloudFoundry em algumas placas ARM, mas na época o Dokku não funcionava em ARM e às vezes o Docker era excessivo, então era preciso uma solução mais simples
- Hoje, é possível implantar, gerenciar e escalar de forma independente várias aplicações por host tanto em arquiteturas ARM quanto Intel
- Funciona em provedores de nuvem e ambientes bare metal que consigam executar Python,
nginx e uwsgi
Instalação e estado do projeto
- A instalação básica pode ser feita com o seguinte comando
curl https://piku.github.io/get | sh
- A documentação de instalação também inclui outros métodos, como
cloud-init e instalação manual
- O projeto é considerado STABLE
- O conjunto de recursos está praticamente completo
- Recebe atualizações quando novos runtimes de linguagem são adicionados ou quando surgem bugs reproduzíveis
- Atualmente, requer Python 3.10 ou superior, e os testes também são feitos nessa faixa
- O objetivo de suporte são as duas versões principais mais recentes de Debian e Ubuntu LTS
Workflow baseado em Git Push
- O Piku oferece um workflow semelhante ao do Heroku
- Usa o nome do app como nome do repositório para criar um remote Git SSH apontando para o servidor Piku
git remote add piku piku@yourserver:appname
- Faça push do código para realizar o deploy
git push piku master
- Para enviar uma branch diferente da branch atual, use da seguinte forma
git push piku release-branch-name
- Durante o processo de deploy, o Piku detecta o runtime, instala as dependências necessárias e executa os builds quando preciso
- Apps Python isolam dependências com virtualenv por aplicação
- Apps Go definem um
GOPATH separado por aplicação
- Apps Node instalam em
node_modules os itens listados no package.json
- Apps Java fazem build conforme
pom.xml ou build.gradle
- Apps Clojure podem usar
leiningen ou a Clojure CLI com arquivo deps.edn
- Apps Ruby instalam gems em uma pasta isolada com
bundle install
Modelo de execução e configuração
- O Piku lê o
Procfile e executa os workers relacionados por meio do uwsgi
- O
uwsgi é usado como um gerenciador de processos genérico
- Opcionalmente, é possível definir um worker
release, que roda uma vez durante o deploy do app
- É possível alterar remotamente a configuração da aplicação ou aumentar e reduzir processos de worker
config:set altera a configuração da aplicaçãops:scale escala os processos de worker
- O arquivo
ENV pode incluir a configuração da aplicação e também a configuração do nginx
- Com o tipo de worker
static, também é possível publicar sites estáticos no estilo gh-pages
- O caminho raiz é especificado como argumento
- Também é possível executar uma tarefa
release que processa o conteúdo no servidor após o git push
Hosts virtuais, SSL e caminhos estáticos
- O Piku oferece suporte completo a hosts virtuais
- É possível hospedar vários apps no mesmo VPS
- Você pode usar aliases DNS para acessar apps por diferentes nomes de host
- Para ativar SSL, é possível configurar certificados próprios ou obter certificados do Let's Encrypt
- Se o acesso for feito em uma LAN por clientes macOS, iOS ou Linux, você pode usar
piku/avahi-aliases para anunciar hosts diferentes no mesmo IP via Avahi/mDNS/Bonjour
- Além de sites estáticos, também é possível mapear diretamente prefixes específicos de URL para caminhos no sistema de arquivos
- Também há suporte a cache de respostas do backend para reduzir a carga sobre as aplicações
- Os recursos de caminhos estáticos e cache são configurados por valores no arquivo
ENV
Plataformas e runtimes suportados
- O Piku foi projetado para funcionar em um ambiente semelhante a POSIX com Python,
nginx, uwsgi e SSH
- Casos de deploy incluem Linux, FreeBSD, Cygwin e Windows Subsystem for Linux
- O desenvolvimento começou em um Raspberry Pi Model B com 256MB, e ele ainda roda de forma estável nesse hardware
- Seu principal uso é como um micro PaaS para executar apps em servidores de nuvem com CPUs Intel e ARM
- As plataformas-alvo são Debian e Ubuntu Linux
- Atualmente suporta apps Python, Node, Clojure e Java, e há trabalho em andamento para algumas outras linguagens, como Go
- Como princípio geral, se algo pode ser chamado a partir do shell, pode ser executado dentro do Piku
Princípios de design
- Dá prioridade à execução em dispositivos de baixo recurso
- Deve ser acessível para desenvolvedores hobbyistas e também para escolas de ensino básico
- Busca manter cerca de 1500 linhas de código fáceis de ler
- Prefere estilo de código funcional
- Tem como meta manter poucas dependências
- Segue o 12 factor app
- Dá grande importância à simplificação da experiência do usuário
- Busca cobrir 80% dos casos de uso mais comuns
- Fornece valores padrão razoáveis para todos os recursos
- Aproveita os pacotes das distribuições Raspbian, Debian e Ubuntu
- Suporte a Alpine e RHEL está em andamento
- Usa ferramentas padrão como
git, ssh, uwsgi e nginx
- Mantém retrocompatibilidade sempre que possível
1 comentários
Comentários no Hacker News
Gosto do piku, então escrevi um tutorial de webapp para piku, e ele acabou entrando no repositório da organização oficial do piku no GitHub
https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
Ele explica como o piku funciona internamente e também mostra um exemplo mínimo de webapp em Python do ponto de vista do usuário
Passava a sensação de que a documentação presumía que você já sabia tudo o que era necessário para executar e usar o piku, então eu desisti, mas este tutorial preenche essa lacuna
Mesmo assim, procurei bastante e não consegui encontrar esse documento; se não fosse por estes comentários, eu nem saberia que ele existia
No mínimo, esse documento deveria estar linkado de forma bem visível no repositório do piku e na página inicial da documentação, e idealmente deveria ser incorporado por completo à página inicial da documentação
Indo além, seria muito mais útil adicionar um tutorial ponta a ponta que chegue até um domínio personalizado e certificado SSL com acesso público em um novo servidor bare metal
Mesmo que pareçam etapas não diretamente relacionadas ao piku, o que novos usuários realmente querem é colocar seu site no ar em algo como um Droplet de US$ 5, e muitas vezes ainda não conhecem as etapas intermediárias
Não importa qual método seja escolhido, e quem se importar com o método já sabe qual abordagem prefere
Como referência, aqui está um exemplo ponta a ponta do lado do Coolify: https://billyle.dev/posts/self-hosting-your-website-with-coo...
O objetivo não é apenas tornar isso funcionalmente possível, mas facilitar o começo para muito mais gente e aumentar bastante a adoção do piku
Eu não fazia ideia do que era Heroku nem do que ele fazia
Se entendi corretamente, o piku funciona instalando um agente na máquina remota e hooks de commit na máquina local?
Fiquei pensando se não daria para reduzir a sobrecarga transformando a máquina remota simplesmente em um repositório Git remoto e fazendo todo o trabalho no lado remoto ao dar push para uma branch específica
Parece bom, e o Dokku também foi muito estável para mim, mas remover a dependência de Docker significa que agora você fica preso às opções fornecidas pelo sistema operacional
Isso não é ideal para apps que podem rodar por anos sem manutenção, e logo você acaba esbarrando na necessidade de uma versão específica do sistema operacional
Usei o Dokku para hospedar pequenos side projects em uma VPS e atualizei a instalação ao longo de 3 ou 4 upgrades do Ubuntu LTS, e ele continuou funcionando sem problemas
docker run, mas claro que ele não foi projetado para esse usoA maioria dos deployments que vi estava em distribuições muito estáveis, geralmente versões LTS, então não era necessário atualizar o runtime a cada 6 meses, e meu site também continuou rodando no piku durante pelo menos duas trocas de Ubuntu LTS
Basta configurar variáveis de ambiente para usar facilmente coisas como
pyenvenvenvMeu sistema de automação residencial agora precisa de duas versões diferentes de Node, e configurei uma para cada app
Entendo o apelo elegante da postura de “simplesmente funciona” e também que o Docker nem sempre pode ser usado em todo lugar por causa da sobrecarga técnica e mental, mas gosto do fato de que contêineres isolam tudo e congelam o tempo, fazendo com que algo “simplesmente funcione” até daqui a 5 anos
No meu pequeno fluxo de trabalho, gerencio contêineres com lazydocker, faço deploy por push com um workflow do GitLab, e um pequeno VPS cuida do build, do push para o registro do GitLab e da execução
É um pouco exagerado, então talvez desse para fazer também com a combinação
Dockerfile+compose.yml+docker compose buildAinda não organizei a escalabilidade, mas felizmente não preciso disso agora, e quando precisar provavelmente vou trocar Docker por k8s e lazydocker por k9s
Estou começando agora em DevOps, então qualquer sugestão é bem-vinda
Como tem menos abstrações mágicas, para mim é melhor do que o Dokku
Não está diretamente relacionado a deploy com
git push, mas tem bastante relação com a experiência de PaaS: a equipe da qual faço parte está testando em preview a especificação pública da CNCF chamada Cloud Native Buildpacks (CNB)São Buildpacks voltados para OCI, e isso significa que é possível criar imagens Docker localmente com uma ferramenta de build que detecta o suporte de linguagem e faz o tratamento apropriado, como a lógica de
git pushdo HerokuAqui está um tutorial para buildar uma aplicação Rails usando um buildpack que eu mantenho: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
Se você testar, seja com impressões boas, ruins ou neutras, deixar sua experiência na discussão vinculada ajuda a melhorar
Foi a primeira vez que vi o piku.
Não sei por quê, mas a sensação de iniciar um deploy com
git push, como no piku, sempre parece mágica, e dá a impressão de que não tem como ser mais simples.Coincidentemente, ontem mesmo tornei open source um projeto para Kubernetes nessa mesma área, está aqui: https://github.com/pier-oliviert/sequencer
Enfim, parabéns, parece muito bom.
Basta criar um repositório Git no servidor com
git init --baree configurargit config receive.denyCurrentBranch updateInstead.Depois, você pode receber o upload, compilar e executar usando hooks do Git, mais especificamente o hook push-to-checkout.
O hook é um script de shell simples, e a forma mais básica pode ser alguma variação de
compile && install && systemctl restart service.Depois disso, é só clonar o repositório localmente, e quando você fizer push das mudanças o hook configurado será executado.
git clone root@yourserver.com:/path/to/git/folderPela descrição, parece lidar com templates de Kubernetes e
kubectl, não com deploy viagit push, então me parece um projeto de uma área totalmente diferente.A documentação reformulada do piku pode ser vista aqui: https://piku.github.io/
O commit inicial foi há 8 anos?
Queria ter conhecido esse projeto uns 18 meses atrás; eu estava procurando uma forma de fazer deploy em um Raspberry Pi com uma experiência de desenvolvimento no estilo Heroku, e o piku parece mirar exatamente nisso.
Acabei de configurar um novo VPS com CapRover e, durante cerca de uma hora procurando comparações de “PaaS self-hosted no estilo Heroku”, vi Dokku, CapRover, Coolify e Dokploy, mas não vi piku em lugar nenhum.
Sou o mantenedor e coautor.
Se você gosta de ferramentas de deploy simples e minimalistas, talvez também queira dar uma olhada em https://github.com/rcarmo/ground-init, que lida com cloud-init de uma forma muito mais prática.
Fiquei curioso se existe alguma forma de lidar com deploy sem downtime.
Por exemplo, se um serviço Python está rodando atrás do nginx na porta 8080 de uma máquina, como o piku faz a troca para uma nova instância na mesma porta?
git pushtermina.O tratamento de sockets e sessões depende de como o código foi escrito, se usa
uwsgiou se sobe seu próprio daemon HTTP.Um dos recursos que ele já suporta opcionalmente é encerrar instâncias não utilizadas e ociosas, iniciando com atraso quando chegam novas conexões.
Gosto do Epinio fazendo a mesma coisa em cima de Kubernetes.
Tem suporte da SUSE e, por exemplo, é mais leve que o KNative, que é a base do GCP Cloud Run, mas por ser baseado em Kubernetes ainda precisa de mais recursos do que Dokku ou piku.
Ainda assim, prefiro k8s pelo ecossistema amplo de soluções maduras.
Dá para rodar tudo até em um único servidor, só que precisa ser um pouco maior.
O novo Hetzner CX42, com 8 vCPU, 16 GB de RAM e 160 GB de disco, custa €16,40 por mês ou €0,0273 por hora, o que já é suficiente, e com o projeto Kube Hetzner dá para configurar em 5 minutos um cluster Kubernetes baseado em MicroOS com atualizações automáticas.
https://github.com/epinio/epinio/
https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...
O ponto central do piku parece ser oferecer uma experiência estilo Heroku sem Docker, com uma arquitetura realmente simples e que roda em ARM.
Concordo que Kubernetes roda em ARM, mas, até onde eu sei, o Kubernetes exige algum tipo de contêiner, seja Docker ou outra coisa, e a arquitetura claramente nunca é simples por motivos óbvios.
Além disso, nem sei se o Epinio permite um fluxo com
git push.O tutorial de início rápido parece dizer para usar um comando como
epinio push manifest.yamlpara fazer deploy da aplicação, então isso também não bate com a ideia de “experiência estilo Heroku”.No fim, parece que a única semelhança é que faz deploy.
Gostei da abordagem minimalista e pretendo testar.
Há também algumas alternativas parecidas que valem ver.
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