Piku - la technologie qui permet le déploiement par Git Push sur son propre serveur

 (github.com/piku)
4 points par GN⁺ 2024-06-10 | 1 commentaires | Partager sur WhatsApp
  • Piku est un outil inspiré de Dokku qui permet de déployer des applications par git push, même sur de petits serveurs auto-hébergés
  • Il vise un flux de travail de type Heroku/CloudFoundry, mais comme Dokku ne fonctionnait pas alors sur ARM et que Docker pouvait être excessif, l’objectif était une approche de déploiement plus simple
  • Lors du déploiement, il détecte le runtime, installe les dépendances, lit le Procfile puis lance les workers avec uwsgi, avec une prise en charge de Python, Node, Java, Clojure, Ruby et Go
  • Plusieurs applications peuvent être déployées, gérées et mises à l’échelle indépendamment sur un même hôte, avec prise en charge des hôtes virtuels, de SSL, des sites statiques, du mapping de chemins d’URL et du cache des réponses backend
  • Il nécessite Python 3.10 ou supérieur, ainsi que Python, nginx, uwsgi et SSH, et le projet est considéré comme stable, avec pour objectif la prise en charge des deux dernières versions majeures de Debian et Ubuntu LTS

Le problème que résout Piku

  • Piku est un outil qui permet le déploiement par git push sur son propre serveur
  • Il est inspiré de Dokku et vise à fonctionner même sur de très petites machines
  • L’objectif était de retrouver une expérience de déploiement proche de Heroku/CloudFoundry sur quelques cartes ARM, mais comme Dokku ne fonctionnait pas alors sur ARM et que Docker pouvait être disproportionné, une solution plus simple était nécessaire
  • Il permet aujourd’hui de déployer, gérer et mettre à l’échelle indépendamment plusieurs applications par hôte, sur architectures ARM comme Intel
  • Il fonctionne chez les fournisseurs cloud comme sur du bare metal, dès lors qu’il est possible d’exécuter Python, nginx et uwsgi

Installation et état du projet

  • L’installation de base se fait avec la commande suivante
curl https://piku.github.io/get | sh
  • La documentation d’installation décrit aussi d’autres méthodes, notamment cloud-init et l’installation manuelle
  • Le projet est considéré comme STABLE
    • l’ensemble des fonctionnalités est quasiment complet
    • des mises à jour sont publiées lors de l’ajout de nouveaux runtimes ou de l’apparition de bugs reproductibles
  • Python 3.10 ou supérieur est actuellement requis, et les tests portent également sur Python 3.10+
  • L’objectif de support couvre les deux dernières versions majeures de Debian et Ubuntu LTS

Workflow basé sur Git Push

  • Piku prend en charge un workflow similaire à Heroku
  • Il suffit de créer une remote Git SSH pointant vers le serveur Piku, en utilisant le nom de l’application comme nom de dépôt
git remote add piku piku@yourserver:appname
  • Le déploiement se fait en poussant le code
git push piku master
  • Pour pousser une branche autre que la branche courante, on utilise par exemple
git push piku release-branch-name
  • Pendant le déploiement, Piku détecte le runtime, installe les dépendances nécessaires et effectue les étapes de build requises
    • les applications Python isolent leurs dépendances dans un virtualenv par application
    • les applications Go définissent un GOPATH distinct par application
    • les applications Node installent dans node_modules les éléments définis dans package.json
    • les applications Java sont construites selon pom.xml ou build.gradle
    • les applications Clojure peuvent utiliser leiningen ou la CLI Clojure avec un fichier deps.edn
    • les applications Ruby installent les gems dans un dossier isolé via bundle install

Modèle d’exécution et configuration

  • Piku lit le Procfile et exécute les workers correspondants via uwsgi
  • uwsgi est utilisé comme gestionnaire de processus générique
  • Il est possible de définir un worker release optionnel, exécuté une seule fois lors du déploiement de l’application
  • Il est possible de modifier à distance la configuration de l’application ou d’augmenter et réduire le nombre de processus worker
    • config:set permet de modifier la configuration de l’application
    • ps:scale permet de mettre à l’échelle les processus worker
  • Le fichier ENV peut contenir la configuration de l’application ainsi que celle de nginx
  • Le type de worker static permet aussi de déployer des sites statiques de type gh-pages
    • le chemin racine est fourni en argument
    • il est également possible d’exécuter une tâche release qui effectue des traitements côté serveur après git push

Hôtes virtuels, SSL et chemins statiques

  • Piku prend entièrement en charge les hôtes virtuels
    • plusieurs applications peuvent être hébergées sur le même VPS
    • des alias DNS permettent d’accéder aux applications via des noms d’hôte différents
  • Pour activer SSL, on peut configurer un certificat privé ou obtenir un certificat Let's Encrypt
  • Pour un accès sur un réseau local depuis des clients macOS, iOS ou Linux, piku/avahi-aliases permet d’annoncer différents hôtes pour une même IP via Avahi/mDNS/Bonjour
  • Au-delà des sites statiques, il est aussi possible de mapper directement un préfixe d’URL vers un chemin du système de fichiers
  • La mise en cache des réponses backend pour réduire la charge applicative est également prise en charge
  • Les chemins statiques et le cache se configurent via des valeurs dans le fichier ENV

Plateformes et runtimes pris en charge

  • Piku est conçu pour fonctionner dans un environnement de type POSIX disposant de Python, nginx, uwsgi et SSH
  • Les déploiements recensés incluent Linux, FreeBSD, Cygwin et le Windows Subsystem for Linux
  • Le développement a commencé sur un Raspberry Pi Model B de 256 Mo, et il fonctionne encore aujourd’hui de manière fiable sur cette machine
  • Son usage principal est celui d’un micro-PaaS pour exécuter des applications sur des serveurs cloud équipés de CPU Intel ou ARM
  • Les plateformes cibles sont Debian et Ubuntu Linux
  • Il prend actuellement en charge les applications Python, Node, Clojure et Java, tandis que certaines autres comme Go sont en cours de développement
  • En règle générale, si quelque chose peut être appelé depuis un shell, cela peut être exécuté dans Piku

Principes de conception

  • priorité à l’exécution sur du matériel peu puissant
  • doit rester accessible aux développeurs hobbyistes et aux écoles K-12
  • vise environ 1500 lignes de code lisibles
  • privilégie un style de code fonctionnel
  • cherche à limiter les dépendances
  • suit les principes du 12 factor app
  • accorde une grande importance à la simplicité de l’expérience utilisateur
  • vise à couvrir 80 % des cas d’usage courants
  • fournit des valeurs par défaut raisonnables pour toutes les fonctionnalités
  • s’appuie sur les paquets des distributions Raspbian, Debian et Ubuntu
    • la prise en charge d’Alpine et de RHEL est en cours
  • exploite des outils standard comme git, ssh, uwsgi et nginx
  • maintient si possible la rétrocompatibilité

À lire aussi

1 commentaires

 
GN⁺ 2024-06-10
Avis de Hacker News

  • J’aime piku, j’ai donc écrit un tutoriel d’application web pour piku, et il a été intégré comme dépôt de l’organisation GitHub officielle de piku
    https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
    Il explique comment piku fonctionne en interne et montre aussi, du point de vue utilisateur, un exemple minimal d’application web Python

    • La nouvelle documentation de piku est jolie, mais elle était presque inutile pour un nouvel utilisateur qui voulait essayer piku
      Elle donnait l’impression de supposer qu’on savait déjà tout ce qu’il fallait pour exécuter et utiliser piku, ce qui m’a fait abandonner ; ce tutoriel comble cette lacune
      Pourtant, même après avoir pas mal cherché, je ne l’avais pas trouvé, et sans ce commentaire je n’aurais même pas su qu’il existait
      Il faudrait au minimum le mettre en lien bien visible depuis le dépôt piku et la page d’accueil de la documentation, et si possible l’intégrer entièrement à cette page
      Mieux encore, ajouter un tutoriel de bout en bout partant d’un nouveau serveur bare metal jusqu’à un domaine personnalisé et un certificat SSL accessibles publiquement serait beaucoup plus utile
      Même si certaines étapes semblent ne pas être directement liées à piku, ce que veulent réellement les nouveaux utilisateurs, c’est mettre leur site en ligne sur quelque chose comme un Droplet à 5 $, et ils ne connaissent souvent pas encore les étapes intermédiaires
      Peu importe la méthode choisie ; ceux qui veulent discuter de la méthode savent déjà laquelle ils préfèrent
      À titre de référence, voici un exemple de bout en bout côté Coolify : https://billyle.dev/posts/self-hosting-your-website-with-coo...
      L’objectif n’est pas de rendre cela fonctionnellement possible, mais de permettre à davantage de personnes de démarrer facilement et d’augmenter fortement l’adoption de piku
    • J’ai apprécié l’explication de ce qu’est un “déploiement à la Heroku”
      Je ne savais absolument pas ce qu’était Heroku ni ce que ça faisait
    • Le dépôt officiel seul n’était pas suffisamment clair, mais cette explication m’a aidé
      Si j’ai bien compris, piku installe un agent sur la machine distante et un hook de commit sur la machine locale ?
      Je me demande si l’overhead n’aurait pas pu être réduit en faisant simplement de la machine distante un dépôt Git distant, puis en lui faisant effectuer tout le travail côté distant lors d’un push vers une branche donnée
    • Ce tutoriel est désormais lié depuis la page d’accueil de la documentation

  • Ça a l’air bien, et Dokku a aussi été très stable pour moi, mais si l’on supprime la dépendance à Docker, on se retrouve alors limité aux options fournies par le système d’exploitation
    Ce n’est pas idéal pour des apps qui peuvent tourner pendant des années sans maintenance, et on se retrouve vite confronté au besoin d’une version précise du système d’exploitation

    • C’est un créneau différent de piku, mais je recommande aussi Dokku
      Pour héberger de petits side projects sur un VPS, j’ai fait passer mon installation Dokku par 3 ou 4 mises à niveau d’Ubuntu LTS, et tout a continué à très bien fonctionner
    • Parfois, Docker est excessif, et c’est vraiment appréciable d’avoir un outil utilisable sans Docker
    • On peut utiliser piku avec Docker. J’ai quelques Procfile contenant des instructions docker run, même si ce n’est évidemment pas conçu pour cet usage
      La plupart des déploiements que j’ai vus tournaient sur des distributions très stables, généralement des versions LTS, donc il n’était pas nécessaire de mettre à niveau le runtime tous les six mois ; mon site web aussi a continué à tourner sur piku pendant au moins deux changements d’Ubuntu LTS
      Il suffit de définir des variables d’environnement pour utiliser facilement des outils comme pyenv ou nvenv
      Mon système de domotique a maintenant besoin de deux versions de Node différentes, et j’en ai configuré une par application
    • Comment gérer l’enfer des dépendances avec ce genre d’outil ?
      Je comprends l’élégance de l’approche “ça marche, tout simplement”, et aussi que Docker ne peut pas être utilisé partout à cause de son overhead technique et mental, mais ce que j’aime avec les conteneurs, c’est qu’ils isolent tout et peuvent presque figer le temps, de sorte que, cinq ans plus tard, “ça marche toujours”
      Dans mon petit workflow, la gestion des conteneurs passe par lazydocker, le déploiement par push par un workflow GitLab, et la build, le push vers le registre GitLab ainsi que l’exécution sont gérés par un petit VPS
      C’est un peu excessif, et je pense qu’une combinaison Dockerfile, compose.yml et docker compose build pourrait aussi suffire
      Je n’ai pas encore vraiment réglé la question de la montée en charge, mais pour l’instant je n’en ai heureusement pas besoin ; si cela devient nécessaire, je remplacerai sans doute Docker par k8s et lazydocker par k9s
      Je viens tout juste d’arriver dans le DevOps, donc toutes les suggestions sont les bienvenues
    • J’utilise docker compose + traefik
      Il y a moins d’abstractions magiques, donc ça me convient mieux que Dokku

  • Ce n’est pas directement lié au déploiement par git push, mais c’est étroitement lié à l’expérience PaaS : l’équipe dont je fais partie teste en avant-première Cloud Native Buildpacks (CNB), une spécification ouverte de la CNCF
    Il s’agit de Buildpacks ciblant OCI, ce qui signifie qu’on peut créer localement des images Docker avec un outil de build qui détecte la prise en charge des langages et applique le traitement approprié, à la manière de la logique git push de Heroku
    Voici un tutoriel pour construire une app Rails avec un buildpack que je maintiens : https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
    Si vous l’essayez, que votre retour soit positif, négatif ou indifférent, laisser votre expérience dans la discussion liée aidera à l’améliorer

  • Je découvrais piku pour la première fois
    Je ne sais pas pourquoi, mais cette sensation où le déploiement démarre avec un git push, comme avec piku, m’a toujours paru magique, et j’ai l’impression qu’on ne peut pas faire plus simple
    Justement, hier, j’ai publié en open source un projet pour Kubernetes dans le même domaine ; il est ici : https://github.com/pier-oliviert/sequencer
    En tout cas, félicitations, ça a l’air bien

    • Ça fonctionne comme par magie, mais si on veut apprendre, le faire soi-même est aussi très simple
      Sur le serveur, il suffit de créer un dépôt Git avec git init --bare et de configurer git config receive.denyCurrentBranch updateInstead
      Ensuite, avec un hook Git, plus précisément un hook push-to-checkout, on peut recevoir l’upload, compiler et exécuter
      Le hook est un simple script shell, et dans sa forme la plus basique, une variante de compile && install && systemctl restart service suffit
      Ensuite, une fois le dépôt cloné en local, le hook configuré s’exécute quand on pousse des changements
      git clone root@yourserver.com:/path/to/git/folder
    • Je ne sais pas si je rate quelque chose d’évident, mais si sequencer ressemble à Heroku/Dokku/piku, je me demande comment il fait le déploiement avec Git
      D’après la description, il semble plutôt gérer des templates Kubernetes et kubectl, pas un déploiement par git push, donc ça ressemble à un projet d’un tout autre domaine

  • La nouvelle documentation remaniée de piku est disponible ici : https://piku.github.io/

    • C’est le successeur de Dokku ? Je ne savais pas qu’il y avait un deuxième projet

  • Le commit initial remonte à il y a 8 ans ?
    J’aurais aimé connaître ce projet il y a environ 18 mois : je cherchais une façon de déployer sur un Raspberry Pi avec une expérience de développement à la Heroku, et piku semble viser exactement cela

    • Exactement. Il y a un problème de visibilité
      Je viens de configurer un nouveau VPS avec CapRover, et pendant environ une heure de recherches comparant les « PaaS self-hosted façon Heroku », j’ai vu Dokku, CapRover, Coolify et Dokploy, mais pas du tout piku

  • Je suis mainteneur et co-auteur
    Si vous aimez les outils de déploiement simples et minimalistes, vous pouvez aussi jeter un œil à https://github.com/rcarmo/ground-init, qui traite cloud-init de façon beaucoup plus réaliste

    • À la lecture du README seul, je ne vois pas bien pourquoi cela ne devrait pas être cloud-init

  • Je me demande s’il existe une façon de gérer les déploiements sans interruption
    Par exemple, si un service Python tourne derrière nginx sur le port 8080 d’une machine, comment piku bascule-t-il vers une nouvelle instance sur le même port ?

    • Pour l’instant, il ne termine le processus en cours d’exécution qu’une fois le nouveau déploiement par git push terminé
      La gestion des sockets et des sessions dépend de la façon dont le code est écrit, selon qu’on utilise uwsgi ou qu’on lance directement un démon HTTP
      L’une des fonctionnalités déjà prises en charge de manière optionnelle consiste à arrêter les instances inutilisées et inactives, puis à les démarrer à la demande avec un délai quand une nouvelle connexion arrive
    • C’est un peu hors sujet, mais avec l’activation de socket systemd, on peut faire des déploiements sans interruption

  • J’aime bien Epinio, qui fait la même chose sur Kubernetes
    Il est soutenu par SUSE et, par exemple, il est plus léger que KNative, qui sert de base à GCP Cloud Run, mais comme il repose sur Kubernetes, il nécessite tout de même plus de ressources que Dokku ou piku
    Cela dit, je préfère k8s, car l’écosystème de solutions matures est vaste
    On peut tout faire tourner même sur un seul serveur, mais il faut simplement une machine un peu plus grosse
    Le nouveau Hetzner CX42 offre 8 vCPU, 16 Go de RAM et 160 Go de disque pour 16,40 € par mois, ou 0,0273 € de l’heure, ce qui est suffisant ; avec le projet Kube Hetzner, on peut mettre en place en moins de 5 minutes un cluster Kubernetes basé sur MicroOS avec mises à jour automatiques
    https://github.com/epinio/epinio/
    https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

    • Si « Epinio fait la même chose sur Kubernetes », alors en fait ce n’est pas du tout la même chose, non ?
      Le cœur de piku semble être d’offrir une expérience à la Heroku sans Docker, avec une architecture vraiment simple, et qui fonctionne aussi sur ARM
      J’admets que Kubernetes fonctionne sur ARM, mais à ma connaissance Kubernetes exige une forme de conteneur, Docker ou autre, et son architecture n’est clairement jamais simple pour des raisons évidentes
      En plus, je ne suis même pas sûr qu’Epinio permette un flux avec git push
      Le tutoriel de démarrage rapide semble demander d’utiliser une commande comme epinio push manifest.yaml pour déployer une application, donc ça ne correspond pas non plus à une « expérience à la Heroku »
      Au final, j’ai l’impression que leur seul point commun est de gérer le déploiement

  • J’aime l’approche minimaliste, donc je vais l’essayer
    Il y a aussi des choses similaires à regarder
    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