最近、サーバーが SSL 終了を処理できるようにする Ruby アプリのデプロイメント スクリプトをセットアップしました。
「古い」時代は、次のような方法でアプリのリバース プロキシを使用して Caddy を設定していました。
# Caddyfile yourdomain.com { reverse_proxy localhost:3000 tls }
これに加えて、私は通常、すべてを簡単にインストールおよび再インストールできるように、docker-compose.yml ファイル内の依存関係の 1 つとして Caddy を実行します。
最近、Basecamp は、Thruster という gem で Ruby アプリを提供するために必要なものすべてを処理するシンプルなリバース プロキシ サーバーをリリースしました。
GitHub リポジトリによると、このサーバーがもたらすものは次のとおりです:
世の中のユースケースの 99% において、これは要件を完全に満たします。そして何よりも、これをRuby アプリと同じコンテナで実行できました。これは、Caddy を実行するために別のコンテナーが必要ないことを意味します。
この gem は「構成不要」ソフトウェアであると記載されていますが、これはほぼ真実です。
実際には、(少なくとも) SSL 証明書を要求するドメインを Thruster に指定する必要があります。
これは環境変数 TLS_DOMAIN を介して行われます。
これの良い点は、複数のドメインを指定できるため、Thruster がそれぞれのドメインに対して正しい Let's Encrypt 証明書を自動的に要求できることです。
たとえば、アプリがdomain1.comとdomain2.comからサービスを提供している場合、TLD_DOMAIN=domain1.com,domain2.comと指定するだけで、Thrusterはこれを問題なく認識します。
Thruster を実行するには、Ruby アプリの実行に通常使用するコマンドを先頭に付けるだけです。
たとえば、Rails を使用している場合は、通常、bin/rails server と入力します。
スラスターの変更は、スラストビン/レールサーバーになります。
これが私がスラスターをとても好きな理由だと思います。 Caddy を使用する場合は、リバース プロキシを設定する必要がありました (Caddyfile で試行錯誤することがよくありました)。 Thruster を使用すると、3 ~ 5 分以内にセットアップを完了できました。
最近では、運用環境で Ruby (および Rails) アプリからの Web リクエストを処理するためのオプションが多数あります。
あなたが管理するサーバー上にある場合、ほとんどの場合、オプション (1) と (2) が最も合理的だと思います。
(3) については、 という特別な使用例、つまり自己ホスト型アプリケーションがあります。言い換えれば、顧客が独自のインフラストラクチャ上で実行する Ruby アプリであり、アプリをインストールするのは顧客です。
ここで説明した 3 つのオプションの違いは、(1) と (2) の場合、DevOps 担当者が作業を開始して簡単に再構成できることです。
セルフホストするために Docker イメージを顧客に提供する場合 (おそらく最も一般的なシナリオ)、問題が発生する可能性がたくさんあります。
たとえば、顧客は自分のサーバーの管理に慣れていない可能性があります。あるいは、顧客は物事を機能させるためにリバース プロキシをいじりたくないのかもしれません。
このような場合は、「問題なく動作する」Docker コンテナを引き渡す方が簡単です。
セルフホスト型電子メール マーケティング ソフトウェアの開発中にこの問題に遭遇しましたが、幸いなことに Thruster が利用可能でした。
とにかくすべてをコンテナにパッケージ化し、docker-compose.yml ファイルを提供したので、これによりコンテナの依存関係も 4 から 3 に減り、nginx や Caddy を実行する必要がなくなりました。
Thruster は、Ruby アプリへのリバース プロキシを処理するための非常に優れた代替手段です。
シンプルな「構成不要」オプションにより、多くのシナリオで非常にうまく機能します。
私自身、自分が制御していない環境 (つまり、顧客のマシン上の自己ホスト型アプリ) で実行する必要がある Ruby アプリをパッケージ化する場合、これが最善の方法です。
以上がRuby アプリ用の Thruster Web サーバーの使用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。