このトピックでは、Function Computeのカスタムコンテナランタイムの背景情報、動作メカニズム、および使用制限について説明します。 このトピックでは、HTTPサーバーの設定に関する要件についても説明します。
背景情報
クラウドネイティブ時代では、コンテナイメージはソフトウェアの開発とデプロイで広く使用されています。 開発者エクスペリエンスを最適化し、開発と配信の効率を向上させるために、Function Computeはカスタムコンテナランタイムを提供します。 開発者は、コンテナイメージを関数の成果物として使用できます。 カスタムコンテナーランタイムには、次の利点があります。
コードの変更やバイナリファイルの再コンパイルが不要なため、移行を低コストで実行できます。 共有オブジェクト (*.so) は、開発環境と本番環境の一貫性を確保するために使用されます。
コードと依存関係の分離が回避され、配布と展開の手順が簡素化されます。
コンテナイメージは、キャッシュ階層にネイティブに格納されます。 これにより、コードのアップロードとプルの効率が向上します。
標準の複製可能なサードパーティライブラリを使用して、リソースの参照、共有、ビルド、および保存を行うことができます。 ライブラリは、コードのアップロードやバージョンの管理にも使用できます。 これにより、継続的な統合と継続的な展開 (CI/CD) のための包括的なオープンソースエコシステムが提供されます。
HTTPプロトコルは、Function Computeとのやり取りに使用できます。
相互作用を必要としない画像を実行することができる。
原則
Function Computeが実行インスタンスを初期化する前に、関数が属するサービスのロールを引き受け、一時的なユーザー名とパスワードを取得し、イメージを取得します。 イメージがプルされた後、Function Computeは指定されたstartupコマンドとArgsパラメーターを使用してイメージを開始します。
カスタムコンテナーランタイムの関数は、webサーバーモードまたは非webサーバーモードにすることができます。
Webサーバモード
webサーバーモードを設定するには、webServerModeパラメーターを空のままにするか、trueに設定します。 webサーバーモードでは、コンテナイメージの成果物にHTTPサーバーを含める必要があります。 Function Computeは、設定されたCAPortを使用して定義したHTTPサーバーをリッスンします。 HTTP Serverは、イベント関数やHTTP関数からの呼び出しを含む、Function Computeのすべてのリクエストを引き継ぎます。 関数の対話ロジックを開発する前に、関数がイベント関数かHTTP関数かを判断する必要があります。 イベント関数とHTTP関数の動作を次の図に示します。
イベント関数
HTTP関数
非webサーバーモード
非webサーバーモードを設定するには、webServerModeパラメーターをfalseに設定する必要があります。 非webサーバモードでは、コンテナイメージの成果物にHTTPサーバを定义する必要はありません。 コンテナーイメージの起動後、関数のタイムアウト期間内に実行および終了する必要があります。 非webサーバーモードでは、HTTPトリガーではなくイベントトリガーのみを使用して関数をトリガーできます。 これは、相互作用にポートが使用されないためです。 イベントは、環境変数の形式でコンテナに渡されます。 次の図は、webサーバー以外のモードの動作を示しています。
イベント関数 
非webサーバーモードは、中国 (杭州) 、中国 (上海) 、中国 (北京) 、中国 (張家口) 、中国 (深セン) 、中国 (香港) 、日本 (東京) 、シンガポール、米国 (バージニア) 、および米国 (シリコンバレー) の各リージョンでサポートされています。
制限事項
画像サイズ
Container Registry Personal EditionおよびContainer Registry Enterprise Edition (Basic Edition、Standard Edition、Advanced Edition) では、最大10 GBの非圧縮イメージがサポートされています。
画像起動の高速化
関数が作成または更新された後、Function Computeコンソールで関数を呼び出す前に、アクセラレーションイメージが使用可能になるまで待つ必要があります。
イメージリポジトリ
Container Registry Enterprise EditionおよびPersonal Editionインスタンスのイメージをプルできます。 詳細については、「Container Registryとは」をご参照ください。
画像アクセス
Container Registry Personal Editionインスタンスでのみ、アカウントとリージョン間のパブリックイメージリポジトリからイメージを読み取ることができます。 Container Registry Enterprise Editionインスタンスでは、同じリージョン内で同じアカウント内のプライベートイメージリポジトリからのみイメージを読み取ることができます。
コンテナ内のファイルの読み取りおよび書き込み権限
デフォルトでは、コンテナーのrun-as-user UIDはrootユーザーのIDです。 この場合、UID=0である。 Dockerfileでユーザーを指定した場合、コンテナーイメージは指定したユーザーによって実行されます。
コンテナ内の書き込み可能レイヤーのストレージ制限
読み取り専用のイメージレイヤーを除き、コンテナーによって生成されるデータのサイズは512 MBまたは10 GBに制限されます。これは、機能の高度な構成のディスクサイズと同じです。 詳細については、「関数の作成」をご参照ください。
コンテナの書き込み可能層に格納されたデータは永続的ではありません。 コンテナが削除されると、データも削除されます。 永続ストレージが必要な場合は、Apsara File storage NAS (NAS) またはObject Storage Service (OSS) をFunction Computeにマウントできます。 詳細については、「NASファイルシステムの設定」および「OSSファイルシステムの設定」をご参照ください。 などの別の共有ストレージサービスを使用することもできます。 テーブルストア
画像アーキテクチャ
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サーバーのリスニングポートはポート9000である必要があります。 カスタムコンテナーのリスニングポートがポート8080の場合、HTTPサーバーのリスニングポートはポート8080である必要があります。
Function ComputeとHTTPサーバー間の接続を維持し、リクエストタイムアウト時間を15分以上に設定する必要があります。 例：
// In this example, the Express framework for Node.js is used. var server = app.listen(PORT, HOST); server.timeout = 0; // never timeout server.keepAliveTimeout = 0; // keepalive, never timeoutHTTPサーバーは120秒以内に起動する必要があります。
共通リクエストヘッダー
カスタムコンテナーが受け取ることができる共通リクエストヘッダーは、カスタムランタイムが受け取ることができるものと同じです。 詳細については、「Function Computeの一般的なリクエストヘッダー」をご参照ください。
ログフォーマット
カスタムコンテナーで標準出力 (stdout) に出力されるすべてのログは、Log Serviceの指定されたLogstoreに自動的に収集されます。 ロギング機能の設定方法の詳細については、「ロギングの設定」をご参照ください。
カスタムコンテナーは、カスタムランタイムと同じログ形式を使用します。 詳細については、「関数ログの形式」をご参照ください。
コールドスタート最適化のベストプラクティス
コードパッケージと比較して、コンテナーイメージは実行環境に依存しており、ダウンロードと解凍に時間がかかります。 コールドスタートを最適化するには、次のベストプラクティスをお勧めします。
Function Computeと同じリージョンのVPCイメージアドレスを使用して、イメージプルレイテンシを短縮し、安定性を向上させます。
画像のサイズを最小化します。 AlpineやUbuntuなどの最小化されたイメージに基づいてカスタムイメージを作成できます。 イメージ内の必要な依存関係のみを保持し、重要でないドキュメント、データ、およびファイルを削除します。
プロビジョニングされたインスタンスと一緒にコンテナーイメージを使用します。 詳細については、「プロビジョニングされたインスタンスと自動スケーリングルールの設定」をご参照ください。
スレッドのセキュリティが保証され、リソースが豊富な場合は、インスタンスを使用して複数のリクエストを同時に処理し、コールドスタートとコストを削減できます。 詳細については、「インスタンス同時実行の設定」をご参照ください。
関数を作成または更新した後、function Computeで自動的に有効になるイメージ起動アクセラレーション機能を使用して、イメージの起動時間を短縮できます。 詳細については、「Container Registry Personal Editionのイメージの起動の高速化」および「Container Registry Enterprise Editionのイメージの起動の高速化」をご参照ください。
課金
カスタムコンテナの課金対象アイテムは、他の種類のランタイムの課金対象アイテムと同じです。 詳細については、「課金の概要」をご参照ください。
イメージリソースの使用量は、イメージプル期間によって異なります。 この期間は、インスタンスがイメージリポジトリからイメージをプルし始めてからイメージプルが完了するまでの期間です。 たとえば、1024 MBのメモリを持つインスタンスからイメージをプルするのに10秒かかる場合、10 GB秒のリソースが消費されます。
一部のコンテナイメージはキャッシュされます。 したがって、コールドスタートによってはキャッシュされたイメージが使用される場合があり、これらのイメージのプルに対して課金されません。