Run any Dockerfile on Vercel｜Vercel で任意の Dockerfile を実行可能に

コンテナ内にサーバーがあります。Go サービス、Rails アプリ、Spring Boot API、あるいは nginx の背後にある Web サーバーかもしれません。HTTP を扱い、ポートをリッスンしています。ただ実行場所が必要なのです。 プロジェクトに Dockerfile.vercel ファイルを追加すると、Vercel が Fluid compute 上でイメージのビルド、保存、デプロイ、自動スケーリングを行います。そのため、コードが使用する CPU の分だけ支払いが発生します。ローカルで実行するデーモン、設定するレジストリ、世話を続けるクラスターは不要です。 仕組みについて 以下は $PORT でリッスンしている小さな Go 製の HTTP サーバーの例です： これを小さなイメージにビルドして実行するための Dockerfile.vercel ファイルを追加します： 次にデプロイします： これだけです。2 つのファイルで、すぐにライブになります。git push を行うたびにイメージが再ビルドされ、新しいプレビュー URL が提供されます。あるいは vercel コマンドを実行してコミットせずにデプロイすることも可能です。 この例では Go を使用しましたが、あらゆるスタックが動作します。Rails、Spring Boot、Express、Laravel、ASP.NET、FastAPI、そして nginx の背後にある Web サーバーもすべて同じ方法でデプロイされます。唯一のルールは、サーバーが $PORT でリッスンすることです（デフォルト値は 80 です）。HTTP を扱えば、デプロイ可能です。Java でも、PHP でも同様です。 得られるもの Vercel 上のコンテナはファーストクラス・シチズンとして扱われます。フロントエンドや Vercel 上の他のサービスと同じプラットフォームおよび同じコンピューティングリソース上で動作します。 すべてのプッシュに対するプレビューデプロイメント：すべてのコミットに、開いて共有し、ロールバックも可能な一意の不変 URL が割り当てられます。 両方向への自動スケーリング：トラフィックが到着すればスケールアウトし、トラフィックが止まればインスタンスはシャットダウンします。ファームのサイズを事前に決めたり、並行処理数を推測したりする必要はありません。 アクティブ CPU 課金：コードが実際に実行されている時間に対して流体コンピューティングの請求が発生するため、アイドル状態のサーバーが、低速なクエリやアップストリームの API を待機している間に CPU を無駄に消費することはありません。実行時間に課金し、壁時計（経過）時間には課金しません。 観測性の標準装備：ログ、トレース、メトリクスは、あなたがデプロイする他のすべてのものと同じダッシュボード上に存在します。 1 プロジェクト 1 ドメイン：コンテナはフロントエンドやその他のサービスと共に配置され、Vercel ネットワークを介してプライベートに通信します。フルスタックが単一のデプロイとして出荷されます。 高速起動のために設計された コンテナの良し悪しは、最初の要求に応答するまでの時間で決まります。 Vercel がイメージを構築する際、それは最適化されたブートイメージとして保存されます。これは高速な起動のために調整された、コンテナディスクの圧縮スナップショットです。 コンテナが起動すると、全体像をダウンロードしてから実行を開始するのではなく、そのスナップストリームをストリーミングし、必要な時にデコンプレッションを行います。サーバーは完全なイメージが揃う前にリクエストの処理を開始できるため、大きなイメージでも最初にダウンロード完了を待つ必要はありません。 一度インスタンスが稼働すると、Fluid compute がそれをウォーム状態に保ち、各要求ごとに新しいコピーを起動するのではなく、1 つのインスタンスから多数の要求に応答します。アイドル時にはスリープするサーバーの請求額で、ウォームサーバーのような応答性を得ることができます。 各コンテナはステートレスプロセスです：リクエストを受け取り、レスポンスを返し、その間に何も保持しません。永続的な状態は、データベースや Vercel マーケットプレイスからのキャッシュなど、接続するバックエンドサービスに存在します。インスタンスには生存する必要のあるデータが何もないため、Vercel はトラフィックが発生した際にインスタンスを追加し、トラフィックが止まるとそれらを廃棄できます。また、コンテナに接続される永続ストレージの提供も近日中に開始予定です。 なぜ今なのか？ 私たちの最初のプラットフォームでは、単一のコマンドで Dockerfile をデプロイできました。それは 10 年前の話ですが、アイデア自体は正しくても、それを素晴らしいものにするためのインフラストラクチャはまだ存在していませんでした。 それ以来の数年間、私たちはこれを適切に処理するためのプリミティブ（基本構成要素）の開発に注力してきました。これらは Vercel で実行されるすべてのものを支えています：ビルド、関数、サンドボックス、そして今やコンテナです。すべてはトラフィックに合わせてスケールし、使用した CPU 分のみに対して課金されます。コンテナはもはやファーストクラス・シチズン（一等市民）となり、他のすべてのものと同じシステム上で実行されています。 フレームワークの検出が私たちのフロントドアです。あなたのフレームワークを認識すると、コードを読み取り、アプリに必要なインフラストラクチャを導き出します。なぜなら、コード自体が何を行うべきかをすでに記述しているからです。ほとんどのアプリにとって、これが最も迅速な配信方法です。Dockerfile はそれ以外のすべて向けです：FFmpeg や Chromium などのシステムライブラリが必要なサービスや、まだ自動検出していないフレームワーク、あるいは既存の動作をそのまま持ち込みたいアプリなどです。これはプログラムがどのように構築されるべきかを記述する普遍的な方法であり、読み込むべきフレームワークがない場合、私たちはそれを直接受け入れます。 Dockerfile の周囲はすべてゼロ構成です。イメージを指定するだけで、ビルド、レジストリ、ロールアウト、スケーリング、URL などがすべて自動的に実行されます。 バックエンドが復活しました あなたのバックエンドも、フロントエンドと同じように、1 つのプッシュで、1 つのプレビュー環境で、1 つのプラットフォーム上で配信されるようになりました。あなたが何を作るか、今から楽しみです。 ドキュメントを読むか、例をデプロイして始めましょう。 もっと読む

Vercel で任意の Dockerfile を実行可能に

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト