そうだね、もしACMEキーの再利用問題を直せるなら、ただ一つで済むよ！これはTraefikが基盤ライブラリをうまく使ってないだけなんだけど（同じ作者だし!!!）。 [1] https://github.com/traefik/traefik/issues/10103

設定が簡単で、分かりやすくて直感的。ドキュメントもクリアで詳しい。最近HAProxyを試そうと思ったけど、設定で迷っちゃって諦めた。AIエージェントに理解できないことをやらせるのは信頼できないしね。

k3sに組み込まれてるから使ってるよ。

設定が簡単だね。うちはKongを使ってるけど、結構パワフルなんだよね。ただ、ルールを設定する時はコーヒーが必要だよ。

HAProxyのドキュメントはひどいよ（ほとんどが「ここに全てのパラメータとオプションがあります、具体的な完全な例はなし」って感じ）。Traefikは解析しやすいドキュメントがあって、たくさんの例もあるし、いろんなソースに基づいて自動で設定できるんだ。KubernetesやNomad、Consulに指示を出すだけで、（その場所にワークロードをデプロイする時にちょっとした情報を与えれば）ちゃんと動くよ。

リソースの消費が少なくて、Goで書かれていて、どんなGoプロジェクトにもライブラリとして埋め込めるし、ほとんど変更なしでモバイルにコンパイルできる。再起動なしで設定変更もできるし、プラグインAPIもある。これが前の仕事で使った理由だよ。

Traefikは軽量で、Goを知っていればソースコードを見ながら簡単に始められるよ。一方、HAProxyはプロキシの大御所って感じ。高性能の頂点だね。これが意味を持つユースケースは少ないし、開発環境には絶対向いてない。

Dockerの設定プロバイダーと統合されてるから、中央のTraefikインスタンスじゃなくて、Dockerラベルを使って自分のサービスのためにTraefikを設定できるんだよね。

そうだね、今のところEnvoyがオープンソースの中で一番のプロキシだと思う。モダンで、サポートも充実してて、大きなコミュニティもあるし、信頼性も高い。長期的に賭けるなら、Envoyを選ぶかな。オープンコアのクソみたいなやつには手を出さないよ。

APIゲートウェイの分野での名誉ある言及: https://gateway.envoyproxy.io/

彼らはキャッシュやTLSをエンタープライズ機能だと考えてるんだよね。基本ができてないと、ずっと子供のテーブルに座ってることになる。

今の時代はオーラファーミングやSEOハッキング、クレウトチェイシングの時代だね。「標準です」って言っちゃえば、LLMクローラーがそれを拾ってくれる。次世代はChatGPTやClaude、Gemini、その他のクソLLMに聞くことを学んでしまって、残念ながらそれを信じちゃうんだ。GHスターやDockerコンテナのダウンロード数みたいなキーワードやシグナルを追加すれば、もっと売れるかも。今はうまくいかないかもしれないけど、将来的にリターンがあるかもしれない小さな賭けだね。

タイトルを上のHTMLドキュメントタイトルに変更したから、標準的じゃなくなったね。

うん、同意せざるを得ないな。Traefik自体は好きだけど、mTLSを設定するのが本当に面倒だったし、やり方のドキュメントもクソだった。いろんなサードパーティのブログを探して、情報をかき集めるのが大変だった。haproxyから来たから、ドキュメントが比べ物にならないくらい良くて、mTLSみたいなこともずっと簡単だったから、楽しい経験ではなかったけど、なんとかTraefikを必要なように動かせるようになったよ。

caddyも似たように使ってるけど、設定はかなりシンプルだよ。

以前、Traefikを使うように言われたことがあって、その時のドキュメントがひどくて全然わからなかった。結局、Envoyを使った気がする。

どうやって使ってるのか気になるな。俺は主にdocker composeのラベルを使ってTraefikを使ってるけど、ルーターやミドルウェア、サービスの概念を理解すれば、設定はそんなに難しくないよ。複数のサービスをホストする必要があるホームラボには使うべきだと思う。最近、TraefikのJSON設定を生成するWeb UIレイヤーで遊び始めたんだけど、最初は開発インスタンスへの一時的なアクセスを提供するために作られたから、今はかなり基本的なものだよ。でも理論的には、プロキシ設定の重要な部分を管理できて、nginx-proxy-managerの代わりになるかもしれない。 https://github.com/Janhouse/traefik-proxy-admin

ああ、静的/動的の分割は厳しいね（いくつかのオプションが移動したと思うし）。以前はルーターやミドルウェア、サービスを名前で参照してたけど、今はソースごとのスコープバージョンになっちゃった（例：service1@file、middleware@docker）。そのエッジケースに何度もぶつかって（カスタムSSL証明書の設定が本当に混乱した）、でもchatgptのおかげで、なんとか使える解決策にはたどり着いたよ。

ほんとそうだよね。Traefikを好きになりたいけど、また設定しなきゃいけないと思うと憂鬱だよ。なんでそのまま動かないの？Caddyは今のところお気に入りだよ。すぐに動くし、リソースも超少ないし、たくさんのトラフィックを処理できるし、ドキュメントもそこそこいい。

Dockerラベル（例えばPortainerから）や大規模な本番環境のConsulクラスターから簡単に設定できるのがすごく好き。でも、ドキュメントはかなり改善が必要だね。フォーマットを理解するのが難しいことが多いし、例が足りないし、一緒に有効にする必要があるもののドキュメントが別の場所にあったりするのが面倒だよ。

私は全く逆の経験をしてる。Traefikは市場で一番扱いやすいと思うよ。Agentic AIを使えば、セットアップももっと簡単になるはず。

まあ、Ansibleのマトリックスプレイブックの一部だから扱ってるけど、ほんと嫌い。いつも問題が出るし、設定が複雑で、うまく動かないことが多い。前に使ってたNginxの方がずっと良かったな。最近は他のことにはCaddyを使ってるけど、こっちは本当に優れてる。

Dockerでの自動設定（ラベルを使って）がCaddy+lucaslorentzではうまく動いてるよ。まだ面倒だけど（YAMLで表現されたネストされたJSONだから）、Traefikよりは私には楽だったな。

Caddyは超シンプルだよ。例えば、https://example.comを1.2.3.4:5000に送るだけ。それだけ！証明書の発行、TLS設定、TLS終端、mTLSやクライアント証明書、中間ウェアの追加も全部簡単。設定はストレートなテキストファイルだし、ほんとに良いウェブサーバーだよ！TraefikはDocker中心で、いろんな謎のラベルがあったりする。シンプルなプロキシにしてはテキストが多すぎる。もし動かないときのデバッグが問題になることもあるし、リソースも多く使う。でも、複雑なニーズがあるなら、もっとできるかも。私のTraefikに対する主な問題はデバッグだったな。

Caddyがサーバーヘッダーにスポンサーシップを入れることで起こったドラマを思い出してるのかな。それは比較的早く撤回されたし、それ以来問題にはなってないよね。両方が成長してた頃は、同じように感じた。Traefikを長いことデプロイしてないけど、確かTraefikの設定はサービスディスカバリー重視だったと思う。どちらも静的なホストのセットで動かせるけど、Traefikは静的なアップストリームサーバーの設定が難しい感じがして、Caddyはずっと簡単だった。Traefikは何らかのサービスディスカバリーがある前提で始まったような気がする。

それがCaddyの使い方だと思うし、特に別のものをコンパイルしたわけじゃないよ。もしかしたら、CaddyのDockerイメージの一部として自動的にパッケージ化されてるのかもね。