- 個人開発者でも簡単にKubernetesを活用できるように作られたオープンソースプラットフォームで、既存のHerokuに近い手軽さを提供
- DockerとDocker Compose環境で動作し、簡単なコマンドでインストールと実行が可能
- 既存スタートアップで経験した予想外のITコスト増加の問題を解決するために開発された
- 複雑な機能の代わりにIngress、Services、Deployments、Pods、CronJobsなどの中核要素のみを公開し、シンプルさを追求
- Helmを通じてほぼすべてのオープンソースアプリをデプロイでき、YAML設定をダウンロードしてCanineから離脱することも可能
- アカウント、デプロイ、ダッシュボードなどKubernetesに標準ではない機能も補完し、小規模チームに適した開発プラットフォームを目指す
概要
- CanineはオープンソースのKubernetesデプロイプラットフォームで、Herokuのように手軽にアプリをデプロイできるよう設計されている
- 独自のKubernetesクラスター上で動作し、必要に応じてYAML設定をダウンロードして分散的な運用に移行することも可能
- Ingress、Services、Deployments、Pods、CronJobsなどの中核リソースのみを公開し、シンプルで直感的な使い勝手を提供する
問題意識: 複雑な構造と急増するコスト
- 既存のスタートアップ運営経験において、ITコストが想定よりはるかに速く増加した
- コストは主に組織の複雑さと連携サービスの増加に応じて膨らみ、サーバーやコンピューティング使用量とは無関係な場合が多かった
- 次のようなサードパーティーツールが積み重なり、ITコストを急増させた:
- Looker、Redshift、Databricks、DBT Cloud、FiveTranなどのデータ関連ツール
- Datadog、New Relic、Sentryなどのモニタリングツール
- Google Maps API、AWSなどのインフラツール
- 一部はオープンソースで代替可能だったが、モニタリング・ヘルスチェック・通知などの運用インフラ構築の負担から採用をためらっていた
Kubernetesの可能性と限界
- Kubernetesは単一ノードから数千クラスターまで拡張可能なプラットフォームであり、ほぼすべてのクラウドで標準的に提供されている
- しかし初心者や小規模チームにとっては、複雑で壊れやすいシステムと認識されている
- 特にCoreDNSの削除のようなミスによって、クラスター全体が動作しなくなる可能性がある
- コストと運用の複雑さが積み重なると、従来の抽象化されたPaaSがかえって足かせになる
Canineの特徴
- Kubernetesの最小限必要な機能だけを公開し、シンプルさと制御しやすさを確保
- 不足する部分は次のような機能で補完:
- アカウント管理
- デプロイ管理
- シンプルなワンオフスクリプト実行
- メトリクスダッシュボード
- 直感的なデプロイプラットフォームにより、初心者でも簡単にKubernetes環境へアプリケーションをデプロイできる
- DockerおよびDocker Composeさえ用意されていれば、コマンド一発でインストールと起動が可能
- Kubernetesの複雑な設定や保守負担を減らすUIベースの管理環境を提供する
- Helm統合により、Sentryのようなオープンソースアプリも簡単にデプロイ可能
移行性と自由度
- Canineは既存のKubernetes上に載せて使うため、そこから離れるのも容易
- すべての構成はYAMLとしてダウンロード可能で、将来的に別のプラットフォームへ移行するのも容易
重要性と差別化ポイント
- 一般的なKubernetesツールと比べて初心者に優しいUIと簡単なインストール手順を提供する
- Herokuに似た利用体験をKubernetesエコシステムに持ち込み、参入障壁を大きく下げる
- オープンソースを基盤とした柔軟な拡張性とコミュニティ主導の改善が可能
- 小規模開発チームやスタートアップでも手軽にKubernetesの利点を活用できる点で大きな効果が期待される
- Apache 2.0 Licenseの下で自由に利用、配布、修正が可能
1件のコメント
Hacker News のコメント
私は「Heroku に近い体験」を自分のサーバーで実現したくて、いつもより良いソリューションを探しているので、これは本当にうれしい
Canine の Kubernetes 関連ドキュメントはとても取っつきやすく、これまで見た中でもかなり親切な部類に感じる
ドキュメントを見ていて疑問に思ったのは、Canine は Digital Ocean のような場所のマネージド K8s 環境でも使えるのか、という点だったが、読んだ限りでは自分で K8s クラスタを管理する必要があるように見える
いくつか疑問点を挙げる
一般的には 1 はステージング/開発アプリ、2 は本番アプリ向け
2 の場合は Digital Ocean などでノード数を管理し、Kubernetes がワークロードを自動で再スケジュールしたり、オートスケール機能を使ったりできる
質問の核心だと思うが、Canine が Hetzner 環境で直接マルチノードクラスタを作る機能はまだサポートしていない
Hetzner の terraform で K8s クラスタを作る方法もあるが、Canine にはまだ組み込まれていない
UI の改善などを進めたあとで関心はある
現時点では K3s を単一 VPS にインストールするガイドを使ってもらうか、すでにクラスタが用意されている場合に使える、という前提
参考リンク: terraform-hcloud-kube-hetzner
こういうプロジェクトは絶対に必要だと思っているので応援したい
今なら Canine か Dokploy を検討すると思う（Docker Swarm も過小評価されている技術だと思う）
フィードバックとして、「なぜ Canine を使うべきでないのか」セクションは率直で新鮮かと思ったが、少し皮肉っぽいニュアンスがあって引っかかった
単に、サーバーを購入して管理しなければならないこと、落ちたときは自分で責任を負うこと、1人開発の初期プロダクトであること、といった現実的なデメリットを明確に書いてくれればよかったと思う
Docker Swarm は今、保守やサポートの状況がどうなっているのか気になる
数年前に、当時の Docker チームが開発を止めたように見えて追うのをやめた記憶がある
他のランディングページとの差別化を狙ってああいう書き方にしたが、実際のユーザーからのフィードバックはとてもありがたい
もう一度見直してみたい
世の中にあるさまざまな PaaS プラットフォームをまとめて管理しているリストの共有
awesome-paas
ちょうどこういうリストにプロジェクトを登録しようと探していたので、これのおかげで PR を出す予定
dokku は VPS で運用できるミニマルな PaaS プラットフォームで、dokku-scheduler-kubernetes もある
dokku-scheduler-kubernetes
ただし Helm chart は未対応
クラウドコンピューティング全般の構造や、さまざまな比較リンクも整理されている
Cloud computing architecture
Cloud-computing comparison
Category:Cloud_platforms
awesome-selfhosted にも serverless/FaaS があるが、これは awesome-sysadmin > PaaS につながっている
awesome-selfhosted FaaS/Serverless
OP（投稿者）への質問
こういうプロジェクトを作るに至った背景が気になる
何か複雑なものを最初から最後まで作ってみたい気持ちはあるが、これまで扱ったのは API と React の統合くらい
複雑なアイデアを現実的なタスクに分解して、オープンソースの「Heroku 代替」として成立させるまでの過程が知りたい
私なら Heroku の利用経験がほとんどないので、「実装すべき機能」を把握するために価格ページなどを参考にしそうだが、そのやり方は非効率ではないかと不安になる
Kubernetes ベースの Heroku 代替というのは興味深い
でも K8s や Helm chart のことを知っていないと使えないなら、自分にとっては実質 Heroku 代替ではない
もちろん、運営側の立場では echo hello レベルに単純化できる場合もあるのは理解している
ただ、自分はできるだけ早く何かを載せたいときに、「Kubernetes と Helm chart」という言葉自体を思い浮かべたくない
ユーザーは Kubernetes の存在自体を知らなくてもよく、その成熟したエコシステムだけを享受できる
そして、いつでもより強力な機能が必要になれば、Kubernetes API のような専門的機能を自分で直接開いて使うこともできる
細かい点だが指摘
Kubernetes が動かしているのは docker コンテナではなく、Open Container Initiative（OCI）規格に準拠したコンテナ
Docker は商標名だ
もう1つ細かい指摘:
Canine Kubernetes Crash Course では「1万台のサーバーをサポート」と説明されているが
公式には Kubernetes は最大 5,000 ノードまでサポートと明記されている
kubernetes 公式ドキュメント参照
もちろん、さらに大きなクラスタも可能だが、その場合は大幅なカスタマイズが必要になる（API registry の全面置き換えなど）
当然ワークロードにも左右される
Kubernetes は out-of-the-box で巨大クラスタまで対応できる段階にはまだないが、リリースごとに進歩している
docker 必須と言われるのは嫌だ
最近は docker の代わりに podman や containerd を中心に運用している
このプロジェクトを作るのはものすごく楽しくて、人生でいちばん楽しい開発体験だった
あらゆる「技術スタック」を自分の手の中に収めている感覚が最高
Rails app、Canine infra、Raspberry pi サーバー、さらには自分が使っている ISP まで
すべてを自分で管理しながらアプリを動かしている体験を共有したい
Web サイトにはライセンス表記が 2024 年 MIT License になっていて
実際の github には Apache License と書かれている
年が合っているかどうか以上に、ライセンスの種類が違うのは重要な差に見える
実際に適用されるライセンスがどちらなのか気になる
Self-hosting で docker と K8s の中間段階が欲しくて、似たようなものを自分でも探したことがある
Nomad も検討したが、それでも dead simple な docker よりは少し複雑で、エコシステムも物足りなかった
結局ホームサーバーは docker だけで運用し、デプロイ中のダウンタイムは受け入れている
本番環境で Canine が K8s をどの程度まで抽象化してくれるのか気になる
内部を覗き込む必要が出てくるのか、K8s 初心者なので、そうした中間地点が本当に成立するのか半信半疑だ
uncloud
目標は、Docker 的な CLI と Docker Compose のマルチマシン/本番機能を提供しつつ、運用用コントロールプレーンなしでシンプルさを保つこと
まだ開発中だが、どのレイヤーで何が起きているのかを簡単に把握でき、トラブルシューティングもしやすいことを目指している
コンセプトが本当に気に入った
K8s は素晴らしい技術だが、その複雑さが参入障壁になっている
公開されている資料を見る限り、本質をかなりよく理解しているように思える
特に PVE、Microcloud、Cockpit のようなソリューションが人気の self-hosting 分野ではさらに有用そうだ
家に遊んでいる N100 NUC があるので、Microcloud はやめて Canine を試してみたくなった
helm は時々面倒なところがある
values.yaml を編集して適用される値と、最初から設定しておかなければならない値の違いがややこしい
helm インストールによってはサービスが多すぎて、どれをいつ再起動していいのかわかりにくい
一方で core kubernetes は stateless job に関しては本当に快適だ
最近の K8s の「複雑さ」という話がどこから来るのかよくわからない
昔は kubespray で2時間かけてセットアップ、みたいなこともあったが
今は rke のようなツールを使えば、yaml ファイル1つと ssh キー1つだけでもクラスタを作れる