Piku - 自前サーバーで Git Push デプロイを可能にする技術

 (github.com/piku)
4 ポイント 投稿者 GN⁺ 2024-06-10 | 1件のコメント | WhatsAppで共有
  • Piku は Dokku に着想を得たツールで、小さな自前サーバーにも git push 方式でアプリケーションをデプロイできるようにする
  • Heroku/CloudFoundry のような流れを目指しているが、当時は ARM で Dokku が動作せず、Docker も過剰になり得たため、よりシンプルなデプロイ方式を目標とした
  • デプロイ時にランタイムを判別して依存関係をインストールした後、Procfile を読み込んで uwsgi でワーカーを実行し、Python・Node・Java・Clojure・Ruby・Go 関連の処理を含む
  • 1つのホストで複数のアプリを独立してデプロイ・管理・スケーリングでき、仮想ホスト、SSL、静的サイト、URL パスマッピング、バックエンドレスポンスのキャッシュをサポートする
  • Python 3.10 以上と Python・nginx・uwsgi・SSH が必要で、最新2つの Debian および Ubuntu LTS メジャーバージョンのサポートを目標とする安定状態のプロジェクト

Piku が解決する問題

  • Piku は自前サーバーで git push デプロイを可能にするツール
  • Dokku に着想を得ており、ごく小さなサーバーでも動作することを目標としている
  • Heroku/CloudFoundry に似たデプロイ体験を数台の ARM ボードで使いたかったが、当時 Dokku が ARM で動作せず、Docker が過剰な場合もあったため、よりシンプルな解決策が必要だった
  • 現在は ARM と Intel の両アーキテクチャで、ホストごとに複数のアプリケーションをデプロイ・管理・独立スケーリングできる
  • Python、nginx、uwsgi を実行できるクラウドプロバイダーやベアメタル環境で動作する

インストールとプロジェクトの状態

  • 基本インストールは次のコマンドで可能
curl https://piku.github.io/get | sh
  • インストールドキュメント には、cloud-init や手動インストールを含む他のインストール方法もある
  • プロジェクトは STABLE 状態と見なされている
    • 機能セットはほぼ完成している
    • 新しい言語ランタイムが追加されたり、再現可能なバグが発生したりしたときに更新される
  • 現在は Python 3.10 以上が必要で、テスト対象も Python 3.10 以上
  • サポート目標は、最新2つの Debian および Ubuntu LTS メジャーバージョン

Git Push ベースのワークフロー

  • Piku は Heroku に似たワークフローをサポートする
  • アプリ名をリポジトリ名として使い、Piku サーバーを指す Git SSH remote を作成する
git remote add piku piku@yourserver:appname
  • コードを push してデプロイする
git push piku master
  • 現在のブランチではない別のブランチを push するには、次のように使う
git push piku release-branch-name
  • デプロイ過程で Piku はランタイムを判別し、必要な依存関係をインストールし、必要なビルドも実行する
    • Python アプリはアプリごとの virtualenv で依存関係を分離する
    • Go アプリはアプリごとに GOPATH を個別に定義する
    • Node アプリは package.json にある項目を node_modules にインストールする
    • Java アプリは pom.xml または build.gradle に従ってビルドする
    • Clojure アプリは leiningen または Clojure CLI と deps.edn ファイルを使用できる
    • Ruby アプリは隔離されたフォルダに gem を bundle install する

実行モデルと設定

  • Piku は Procfile を読み込み、関連するワーカーを uwsgi 経由で実行する
  • uwsgi は汎用のプロセスマネージャーとして使われる
  • 任意で release ワーカーを指定でき、このワーカーはアプリのデプロイ時に1回実行される
  • リモートからアプリケーション設定を変更したり、ワーカープロセスを増減したりできる
    • config:set でアプリケーション設定を変更する
    • ps:scale でワーカープロセスをスケーリングする
  • ENV ファイルにアプリケーション設定と nginx 設定を含めることができる
  • static ワーカータイプを使うと、gh-pages スタイルの静的サイトもデプロイできる
    • 引数としてルートパスを指定する
    • git push 後にサーバー側で処理を実行する release タスクも実行できる

仮想ホスト、SSL、静的パス

  • Piku は仮想ホストを完全にサポートする
    • 同じ VPS で複数のアプリをホストできる
    • DNS alias を使って、異なるホスト名でアプリにアクセスできる
  • SSL を有効化するためにプライベート証明書を設定するか、Let's Encrypt 証明書を取得できる
  • LAN で macOS、iOS、Linux クライアントからアクセスするなら、piku/avahi-aliases を使って、同じ IP に対して異なるホストを Avahi/mDNS/Bonjour で通知できる
  • 静的サイト以外にも、特定の URL prefix をファイルシステムパスに直接マッピングできる
  • バックエンドレスポンスをキャッシュしてアプリケーション負荷を減らす機能もサポートする
  • 静的パスとキャッシュ機能は ENV ファイルの値で設定する

サポートプラットフォームとランタイム

  • Piku は Python、nginx、uwsgi、SSH がある POSIX ライクな環境で動作するよう設計されている
  • デプロイ事例には Linux、FreeBSD、Cygwin、Windows Subsystem for Linux が含まれる
  • 開発は 256MB の Raspberry Pi Model B で始まり、現在もその機器で安定して実行されている
  • 主な用途は、Intel および ARM CPU を搭載したクラウドサーバーでアプリを実行するマイクロ PaaS
  • 対象プラットフォームは Debian および Ubuntu Linux
  • 現在は Python、Node、Clojure、Java アプリをサポートしており、Go などいくつかの言語も作業中
  • 一般原則として、シェルから呼び出せるものなら Piku 内で実行できる

設計原則

  • 低スペックデバイスで実行されることを重視する
  • 趣味の開発者や K-12 学校でも利用しやすいべきである
  • 約1500行の読みやすいコードを志向する
  • 関数型のコードスタイルを好む
  • 依存関係を少なくすることを目標とする
  • 12 factor app に従う
  • ユーザー体験の簡素化を重視する
  • 一般的なユースケースの80%をカバーすることを目標とする
  • すべての機能に合理的なデフォルト値を提供する
  • Raspbian、Debian、Ubuntu のディストリビューションパッケージを活用する
    • Alpine と RHEL のサポートは作業中
  • git、ssh、uwsgi、nginx のような標準ツールを活用する
  • 可能な場合は後方互換性を維持する

関連記事

1件のコメント

 
GN⁺ 2024-06-10
Hacker News の意見

  • piku が好きなので piku 向けの Web アプリチュートリアルを書いたところ、公式 GitHub の piku organization のリポジトリに入った
    https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
    内部的に piku がどう動くのかを説明し、ユーザー視点で最小限の Python Web アプリの例も示している

    • 新しい piku のドキュメントは見た目はきれいだが、piku を試そうとする新規ユーザーにとってはほとんど役に立たなかった
      ドキュメントが、すでに piku を実行して使うために必要なことを全部知っている前提のように感じて諦めたが、このチュートリアルはその隙間を埋めてくれる
      ただ、かなり長く探したにもかかわらずこのドキュメントは見つからず、ここのコメントがなければ存在自体を知らなかったはず
      少なくとも piku のリポジトリとドキュメントのホームから、このドキュメントへ目立つ形でリンクすべきで、できればドキュメントのホームに丸ごと含めたほうがよいと思う
      さらに、新しいベアメタルサーバーから、公開アクセス可能な カスタムドメインと SSL 証明書まで到達するエンドツーエンドのチュートリアルを追加すると、はるかに役に立つ
      piku と直接関係ない手順のように見えても、新規ユーザーが実際に望んでいるのは 5 ドルの Droplet のような場所に自分のサイトを載せることで、その間の手順をまだ知らない場合が多い
      どの方法を選んでも構わないし、方法にこだわる人はすでに自分の好みのやり方を知っている
      参考までに、Coolify 側のエンドツーエンドの例はこちら: https://billyle.dev/posts/self-hosting-your-website-with-coo...
      目標は機能的に可能にすることではなく、より多くの人が簡単に始められるようにして piku の採用率を大きく高めること
    • 「Heroku 式デプロイとは何か」を説明してくれてよかった
      Heroku が何なのか、何をするものなのかをまったく知らなかった
    • 公式リポジトリだけでは十分に明確ではなかったが、説明が助けになった
      理解が合っているなら、piku はリモートマシンにエージェントをインストールし、ローカルマシンにはコミットフックをインストールする構造なのか？
      リモートマシンを単に Git リモートリポジトリにして、特定のブランチへ push したときにリモート側ですべての作業をさせれば、オーバーヘッドを減らせたのではないかと思う
    • このチュートリアルは現在、ドキュメントのホームからリンクされている

  • 良さそうだし、Dokku も自分には非常に安定していたが、Docker 依存を取り除くと、今度は OS が提供する選択肢に縛られることになる
    何年もメンテナンスなしで動かすかもしれないアプリには理想的ではなく、結局すぐに特定の OS バージョンが必要だという状況に直面する

    • piku とは別のニッチだが Dokku もおすすめ
      小さなサイドプロジェクトを VPS に載せる用途で、Dokku のインストールを Ubuntu LTS で 3〜4 回アップグレードしてきたが、問題なくよく動作した
    • 場合によっては Docker は大げさで、Docker なしで使えるツールがあるのは本当にありがたい
    • piku と Docker を一緒に使うことはできる。Procfile に docker run 文を入れているものもいくつかあるが、もちろんそういう用途向けに設計されたものではない
      私が見たデプロイの大半は非常に安定したディストリビューション、たいていは LTS バージョン上で動いていたので、ランタイムを 6 か月ごとに上げる必要はなかったし、自分の Web サイトも Ubuntu LTS が 2 回以上変わる間ずっと piku で動き続けていた
      環境変数を設定するだけで pyenv、nvenv のようなものも簡単に使える
      ホームオートメーションシステムは今では異なる Node バージョンが 2 つ必要だが、アプリごとに 1 つずつ設定してある
    • こういうツールを使うとき、依存関係地獄はどう解決すればよいのだろう？
      「そのまま動く」という姿勢はエレガントだし、Docker が技術的・心理的オーバーヘッドのためにどこでも使えるわけではないことも理解しているが、コンテナはすべてを隔離して時間を止めたかのように固定できるので、5 年後にも「そのまま動く」ようにしてくれる点がよい
      自分の小さなワークフローでは、コンテナ管理は lazydocker、push デプロイは GitLab ワークフロー、ビルドと GitLab レジストリへの push および実行は小さな VPS 1 台で処理している
      少し大げさではあるので、Dockerfile と compose.yml、docker compose build の組み合わせでもできそうだ
      まだスケーリングは整理できていないが、今は必要ないので助かっているし、必要になったら Docker の代わりに k8s、lazydocker の代わりに k9s に切り替えると思う
      DevOps に入ったばかりなので、提案はいつでも歓迎
    • 私は docker compose + traefik を使っている
      魔法のような抽象化が少ないので、Dokku より自分には合っている

  • git push デプロイと直接関係するわけではないが、PaaS 体験とは密接に関連して、私のチームは CNCF の公開仕様である Cloud Native Buildpacks(CNB) をプレビュー中
    これは OCI を対象とする Buildpacks であり、Heroku の git push ロジックのように言語サポートを検出して適切に処理するビルドツールで、ローカルで Docker イメージを作れるという意味
    私が管理している buildpack で Rails アプリをビルドするチュートリアルはこちら: https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-ap...
    使ってみるなら、良い点でも悪い点でも淡々とした反応でも、リンク先の議論に体験を残してくれると改善の助けになる

  • pikuを初めて見た
    なぜかは分からないけれど、pikuのようにgit pushでデプロイが始まる感じはいつも魔法のようで、これ以上シンプルにはできないと感じる
    ちょうど昨日、同じ領域のKubernetes向けプロジェクトをオープンソースで公開したところで、ここにある: https://github.com/pier-oliviert/sequencer
    ともあれおめでとう。良さそう

    • 魔法のように動くけれど、学びたいなら自分で作るのもとても簡単
      サーバーでgit init --bareしてGitリポジトリを作り、git config receive.denyCurrentBranch updateInsteadを設定すればよい
      その後、Gitフック、より具体的にはpush-to-checkoutフックでアップロードを受け取り、コンパイルして実行できる
      フックは簡単なシェルスクリプトで、最も基本的な形ならcompile && install && systemctl restart serviceのようなバリエーションでよい
      その後ローカルにリポジトリをクローンすれば、変更をpushするときに設定したフックが実行される
      git clone root@yourserver.com:/path/to/git/folder
    • 自分が何か明らかな点を見落としているのか分からないけれど、sequencerがHeroku/Dokku/pikuに似ているなら、Gitによるデプロイをどう行うのか気になる
      説明を見る限り、git pushデプロイではなくKubernetesテンプレートとkubectlを扱うもののようで、それならまったく別領域のプロジェクトに見える

  • 新しく改訂されたpikuのドキュメントはここで見られる: https://piku.github.io/

    • これはDokkuの後継作なのか？ 2つ目のプロジェクトがあるとは知らなかった

  • 最初のコミットが8年前だったって？
    18か月ほど前にこのプロジェクトを知っていればよかった。Raspberry PiにHerokuのような開発体験でデプロイする方法を探していて、pikuはまさにそれを目指しているように見える

    • その通り。可視性の問題がある
      さっきCapRoverで新しいVPSをセットアップしたところだが、「Heroku風セルフホストPaaS」の比較を1時間ほど探している間にDokku、CapRover、Coolify、Dokployは見たものの、pikuはまったく見かけなかった

  • メンテナー兼共同作者です
    シンプルでミニマルなデプロイツールが好きなら、cloud-initをずっと現実的に扱うhttps://github.com/rcarmo/ground-initも見てもらえるとうれしい

    • READMEを見ただけでは、なぜcloud-initではだめなのかの答えがよく分からない

  • ゼロダウンタイムデプロイを扱う方法があるのか気になる
    例えばPythonサービスが1台のマシンの8080番ポートでnginxの背後で動いている場合、pikuは同じポートで新しいインスタンスへどう切り替えるのだろうか？

    • 現状では、新しいgit pushデプロイが終わってから実行中のプロセスを終了する
      ソケットやセッションの扱いは、コードがどうなっているか、uwsgiを使っているか、直接HTTPデーモンを立てているかによって変わる
      すでに選択的にサポートしている機能の一つに、使われていないインスタンスやアイドル状態のインスタンスを終了し、新しい接続が来たときに遅延起動するものがある
    • 少し話題から外れるが、systemdソケットアクティベーションを使えばゼロダウンタイムデプロイができる

  • 同じことをKubernetes上で行うEpinioが気に入っている
    SUSEが支援していて、例えばGCP Cloud Runの基盤であるKNativeより軽量だが、KubernetesベースなのでDokkuやpikuよりは依然として多くのリソースが必要
    それでも成熟したソリューションのエコシステムが広いので、k8sの方を好む
    単一サーバーでも全部動かせるが、少し大きめのサーバーが必要
    新しいHetzner CX42は8 vCPU、RAM 16GB、ディスク160GBで月額€16.40、時間あたり€0.0273なので十分で、Kube Hetznerプロジェクトを使えば自動更新されるMicroOSベースのKubernetesクラスターを5分以内にセットアップできる
    https://github.com/epinio/epinio/
    https://github.com/kube-hetzner/terraform-hcloud-kube-hetzne...

    • 「Epinioが同じことをKubernetes上で行う」というなら、実質的にはまったく同じではないのでは？
      pikuの核心は、DockerなしでHerokuのような体験を提供し、アーキテクチャが本当にシンプルで、ARMでも動くことにあるように見える
      KubernetesがARMで動くことは認めるが、自分の理解ではKubernetesはDockerであれ何であれ何らかの形のコンテナを必要とし、アーキテクチャも明白な理由から決してシンプルではない
      それにEpinioがgit pushフローを可能にするのかもよく分からない
      クイックスタートのチュートリアルでは、アプリケーションのデプロイにepinio push manifest.yamlのようなコマンドを使うようなので、「Herokuのような体験」にも合わない
      結局、共通点はデプロイを扱うことだけなのではないかと思う

  • ミニマルなアプローチが気に入ったので試してみるつもり
    似たものとして見る価値があるものもある
    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