カスタムコンテナイメージの原則と使用方法 - Function Compute

このトピックでは、カスタムイメージの背景、基本原則、制限、および HTTP サーバーの構成要件について説明します。

背景情報

クラウドネイティブ時代において、コンテナイメージはソフトウェアのデプロイメントと開発のための標準ツールとなっています。開発者エクスペリエンスを最適化し、開発と配信の効率を向上させるために、Function Compute はカスタムイメージを提供します。これにより、開発者はコンテナイメージを関数の成果物として使用できます。カスタムイメージを使用すると、次の利点があります。

コードの変更やバイナリファイルの再コンパイルなしで低コストの移行が可能です。オブジェクトファイル (*.so) を共有して、開発環境と本番環境の一貫性を保つことができます。
コードと依存関係を一緒にパッケージングすることで、配布とデプロイメントを簡素化します。
階層化されたキャッシュにより、コードのアップロードとプル効率を向上させます。
オープンソースエコシステムの豊富な継続的インテグレーションと継続的デリバリー (CI/CD) の経験を活用します。これにより、サードパーティのライブラリやコードの参照、共有、ビルド、アップロード、保存、バージョン管理のための標準的で再利用可能なメソッドが提供されます。
HTTP プロトコルを介して Function Compute システムと対話します。
非対話型イメージを実行します。

仕組み

Function Compute システムが実行環境インスタンスを初期化する前に、関数のサービスロールを偽装します。次に、一時的なユーザー名とパスワードを取得してイメージをプルします。イメージがプルされた後、指定された起動コマンド (Command) と引数 (Args) を使用して起動されます。

コンテナイメージには HTTP サーバーが含まれている必要があります。Function Compute は、構成された `CAPort` でカスタム HTTP サーバーをリッスンします。このサーバーは、API 呼び出しや HTTP 呼び出しを含む、Function Compute へのすべてのリクエストを処理します。関数の対話ロジックを開発する前に、関数が API 呼び出しによって呼び出されるか、HTTP リクエストによって呼び出されるかを決定する必要があります。原則は次のとおりです。

API 呼び出しによる関数の呼び出し
HTTP リクエストによる関数の呼び出し

制限

イメージサイズの制限

ACR Personal Edition または Enterprise Edition (Basic、Standard、または Premium) の場合、非圧縮イメージの最大サイズは CPU インスタンスで 10 GB、GPU インスタンスで 15 GB です。

イメージリポジトリ

Function Compute は、Container Registry Enterprise Edition および Personal Edition のリポジトリからのイメージのプルをサポートしています。

説明

ACR Economy Edition インスタンスはイメージアクセラレーションをサポートしていません。そのため、Function Compute は ACR Economy Edition インスタンスのイメージリポジトリをサポートしていません。関数を作成または更新するには、ACR Personal Edition または Enterprise Edition (Basic、Standard、または Premium) インスタンスのイメージを使用する必要があります。

イメージアクセス

現在、ACR Personal Edition のパブリックイメージにのみ、同じリージョン内の他のアカウントからアクセスできます。他のイメージは、同じアカウントおよびリージョン内のプライベートイメージリポジトリからのみアクセスできます。

コンテナ内のファイルの読み取りおよび書き込み権限

デフォルトでは、コンテナはルートユーザー (UID=0) として実行されます。Dockerfile でユーザーを指定した場合、コンテナイメージはそのユーザーとして実行されます。

コンテナの書き込み可能レイヤーのストレージ制限

コンテナの書き込み可能レイヤーは 512 MB または 10 GB に制限されています。この制限は、関数の詳細設定で指定されたディスクサイズに対応します。詳細については、「関数を作成する」をご参照ください。

説明

コンテナの書き込み可能レイヤーのデータは永続的ではありません。データはコンテナが破棄されるときに削除されます。永続ストレージの場合は、Function Compute に NAS ファイルシステムまたは OSS バケットをマウントできます。詳細については、「NAS ファイルシステムを構成する」および「Object Storage Service を構成する」をご参照ください。Tablestore などの他の共有ストレージサービスも使用できます。

イメージアーキテクチャの制限

現在、Function Compute は AMD64 イメージアーキテクチャのみをサポートしています。したがって、Apple チップを搭載した Mac や ARM アーキテクチャのマシンでイメージをビルドする場合は、ビルドプラットフォームを `linux/amd64` として指定する必要があります。コマンドの例は docker build --platform linux/amd64 -t $IMAGE_NAME . です。

説明

ビルドが完了したら、docker inspect を実行してアーキテクチャを確認できます。出力に "Architecture" : "amd64" が含まれている場合、イメージは正しくビルドされています。

HTTP サーバーの構成要件

以下の要件は、Web サーバーを使用するカスタムイメージ関数にのみ適用されます。

カスタムイメージによって開始されたサービスは、0.0.0.0:CAPort または *:CAPort でリッスンする必要があります。サービスが 127.0.0.1:CAPort でリッスンしている場合、リクエストはタイムアウトし、次のエラーが発生します。
```
{
    "ErrorCode":"FunctionNotStarted",
    "ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000"
}
```
カスタムイメージのリスナーポートは、`CAPort` 関数プロパティによって定義され、デフォルトは 9000 です。カスタムイメージ内の HTTP サーバーは、`CAPort` で指定されたポートでリッスンする必要があります。たとえば、`CAPort` が 8080 に設定されている場合、HTTP サーバーもポート 8080 でリッスンする必要があります。
サーバーは `Connection: Keep-Alive` をサポートする必要があり、サーバー側のリクエストタイムアウト期間は 15 分以上に設定する必要があります。次の例は、タイムアウトを構成する方法を示しています。
```
// たとえば、Node.js で Express を使用する場合。
var server = app.listen(PORT, HOST);
server.timeout = 0; // タイムアウトしない
server.keepAliveTimeout = 0; // keepalive、タイムアウトしない
```
HTTP サーバーは 120 秒以内に起動する必要があります。

共通のリクエストヘッダー

カスタムイメージの共通のリクエストヘッダーは、カスタムランタイムのものと同じです。詳細については、「Function Compute の共通リクエストヘッダー」をご参照ください。

ログフォーマット

カスタムイメージの標準出力 (stdout) に出力されるすべてのログは、指定した Simple Log Service プロジェクトによって自動的に収集されます。ロギング機能の構成方法の詳細については、「ロギング機能を構成する」をご参照ください。

カスタムイメージのログフォーマットは、カスタムランタイムのものと同じです。詳細については、「関数ログのフォーマット」をご参照ください。

コールドスタート最適化のベストプラクティス

コードパッケージと比較して、コンテナイメージはベース環境のダウンロードと解凍に余分な時間を必要とします。より良いコールドスタート体験のために、以下のベストプラクティスに従ってください。

イメージのプルレイテンシーを削減し、安定性を向上させるために、Function Compute と同じリージョンにある VPC イメージアドレスを使用します。
イメージサイズを最小限に抑えます。Alpine や Ubuntu などの最小イメージ、または別のイメージの合理化されたバージョンに基づいてカスタムイメージをビルドします。必要な依存関係のみを保持し、不要なドキュメント、データ、その他のファイルを削除します。
プロビジョニングされたインスタンスでコンテナイメージを使用します。詳細については、「最小インスタンス数の弾力性ポリシーを構成する」をご参照ください。
リソースが許容し、関数がスレッドセーフである場合は、単一インスタンス複数同時実行機能を使用します。これにより、不要なコールドスタートを回避し、コストを削減できます。詳細については、「Web 関数を作成する」をご参照ください。

課金

カスタムイメージの課金項目は、他のランタイムのものと同じです。詳細については、「課金の概要」をご参照ください。

イメージのリソース使用量については、実行時間はリポジトリからのイメージのプルの開始から終了までで計算されます。たとえば、1,024 MB のメモリを持つインスタンスがイメージをプルするのに 10 秒かかる場合、このプルのリソース使用量は 10 GB 秒です。

コンテナイメージは一定期間キャッシュされます。したがって、すべてのコールドスタートでイメージのプル料金が発生するわけではありません。

Function Compute:カスタムイメージ (Custom Container)