docker-composeはDockerコンテナを扱うためのツールで、複雑なアプリケーションのデプロイ問題は解決するものの、大衆向けのシンプルなセルフホスティングには十分ではありません- SQLデータベース、ローカルキャッシュ、永続ストレージ、サービスディスカバリ、リソース管理の概念を含む、より高水準の抽象化が必要です
Dockerの役割
- Dockerはコンテナ化を大衆化したツールで、ホストシステムは船にたとえることができます。
- ハードウェア、オペレーティングシステム、コンテナランタイムがあり、コンテナはランタイム内で実行され、データベースやWebサーバーのような他のサービスと通信します。
Docker-composeの役割
docker-composeは一緒に動作するコンテナ群を指定するためのツールで、セルフホスティングアプリケーションのデプロイを容易にします。- しかし、標準化されたインターフェースを壊し、コンテナが本来解決していた問題を再現してしまいます。
- 例: Pihole
- PiholeはDNSサーバーで、複雑な
docker-composeファイルを必要とします。
- コンテナ名、イメージ、ポート、環境変数、ボリューム、追加機能、再起動ポリシーなどを設定しなければなりません。
- 複雑な設定はユーザー自身が管理する必要があり、これはDocker Composeの欠点です
- 例: Jitsi Meet
- Jitsi Meetは複雑なソフトウェアで、4つのコンテナ、7つのボリューム、9つのポート、200個を超える環境設定を含む
docker-compose構成を生成します。
- 例: 他の人気セルフホスティングアプリケーションも同様の問題を抱えています
- Authentik、Nextcloud、Immich、Jellyfin、Paperless NGXなどさまざまなアプリケーションがあり、それぞれの
docker-compose構成は数十から数百のdockerコマンドを置き換えています。
- 各アプリケーションは独自のデータベース、キャッシュ、HTTPハンドラを含むことがあり、これは重複したリソース消費につながります。
問題点
docker-composeは柔軟すぎて細かすぎ、誤った抽象化レイヤーで動作しています。- 各アプリケーションはHTTP処理プロセス、キャッシュ、またはデータベースを持っています。データベースのバックアップはシステム運用者の責任です。
- 例: リバースHTTPプロキシ
- リバースHTTPプロキシは、受信したHTTPリクエストを別のプログラムへ転送するプログラムです。各プログラムはWebサーバーを含めるかどうかを決めなければなりません。
- Webサーバーを含む場合
- Webサーバーを含めればプログラムは動作しますが、特定のポートでしか動作せず、複数のコンテナがある場合はポートの再マッピングが必要になります。
- Webサーバーを含まない場合
- Webサーバーを含めなければリソースは無駄になりませんが、管理インターフェースなしでアプリケーションを構成しなければなりません。
- DNS
- Webインターフェースはアドレスを持ち、TLSを望むなら名前が必要です。複数のサービスを単一ホストで実行する場合、ドメイン名やパスでリクエストをルーティングする必要があります。
- ポート
docker-composeはポートの公開と再マッピングを許可しますが、実際には複雑なネットワーキング設定をサポートする必要があります。
- 例: データベース
- データベースでは、コンテナが削除されるとファイルへの変更がすべて削除されます。データベースコンテナはデータベース内容を保存するためにボリュームを追加する必要があります。
- N+1=2またはそれ以上
- データベースをバックアップするにはオフサイトバックアップが必要です。各サービスが別個のデータベースサーバープロセスをバンドルすると、計算資源が無駄になります。
解決策
- より高い抽象化レイヤーへ移行し、データベース、リバースWebプロキシ、キャッシュ、静的Webアセットなどのコンテナ種別を区別するセマンティクスを追加します。
- セマンティクスの例
- 新しい構成形式を導入し、アプリケーション名、ビルド、HTTPSリバースプロキシ、キャッシュサービスを指定します。
- 解決策 #1
- 各プログラムがリバースプロキシを要求できるようにし、重複と無駄を防ぎます。リバースプロキシはDNS名を提供し、すべてのパスをプログラムへ転送します。
- 解決策 #1.5
- データベースセクションを追加し、SQL標準に準拠したデータベースを要求できるようにし、プログラムは「完全な」権限を期待します。
- ポートに対する解決策
- 各プログラムは自身のIPv6アドレスを受け取り、標準のポート番号を使用できます。セキュリティのため、ファイアウォールを使ってリバースプロキシだけがそのポートへアクセスできるようにします。
Tealok - 新しいコンテナランタイム
- Tealokは、より高水準の抽象化と標準化されたインターフェースを提供する新しいコンテナランタイムです。
- TLS証明書、リバースプロキシ設定、DNSレコード、バックアップ管理などを自動的に処理します。
- IPv6を活用して各コンテナが独立したIPアドレスを持ち、標準のポート番号を使用できるようにします。
- アプリケーション開発者は複雑な設定なしに標準インターフェースを通じてアプリケーションをデプロイできます。
- 運用者に対しては、一貫したベストプラクティスを提供し、リソースの無駄を減らし、管理負担を軽減します。
- 開発者に対しては、デプロイ方法を単純化し、意思決定の負担を減らします。
- ユーザーはデータ所有権とクラウドコンピューティングからの独立性を保証されます。
6件のコメント
tealokを見てみると、代替になりそうな状態ではないですね？
ランタイムも削除してくれていたら本当によかったのですが
まだ
docker-composeを使って運用環境を作って入り込むことは必要だと思いますが…自分だけの特殊な環境での経験をもとに、それは間違いだから新しいものを作りました……というのは、ちょっと賛同しづらいですね（笑）。
うっかり誤解してしまいそうな内容ですね（笑）……
タイトルだけ見て、「あっ、開発環境で使うの、本当にしっくりこないよな……」と思っていたので……（笑）
本文のような用途で docker compose を使おうとすること自体、そもそも間違ったアプローチだと思います。
一部には同意しますが、アプローチが間違っていたとは思いません。
彼らにできる範囲では最善だったのでしょう :)
Hacker Newsのコメント
ポートマッピングやデータボリュームのバックアップ問題には、簡単な解決策がある
docker-composeファイルを使い、環境ごとに設定を変えて定義できる個人サーバーでDockerを使ってセルフホスティングしている者として、Docker設定の自由度を前向きに評価している
macvlanネットワークを使って、各コンテナに固有のIPアドレスとMACアドレスを割り当てているdocker-composeは主に開発または個人用途で使われており、V2はV1と違ってDockerに統合されたプラグインである本番環境ではKubernetesを使うのが望ましく、
docker-composeはローカル開発に適しているdocker-composeは小規模なセルフホスティング向けの製品で、技術的な背景がない人を対象としているDockerを制御するプログラムを書くのは思ったより簡単で、Pythonスクリプトを使って問題を解決できる
canine.shを使って、KubernetesクラスタをHerokuのように簡単に使えるよう開発中であるTealokが
docker-composeの代替を開発中である点は興味深いdocker-compose、Kubernetes、Helmは誤った抽象化レイヤーだと考えているdocker-composeが誤った抽象化レイヤーだという主張には戸惑いを感じる