すべてのプロダクト
Search

このプロダクト

    Function Compute:概要

    ドキュメントセンター

    Function Compute:概要

    最終更新日:Aug 28, 2024

    このトピックでは、Function Computeのカスタムコンテナランタイムの背景情報、原則、および制限について説明します。 このトピックでは、HTTPサーバー設定の要件についても説明します。

    背景

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

    • コードの変更やバイナリファイルの再コンパイルが不要なため、移行を低コストで実行できます。 共有オブジェクト (*.so) は、開発環境と本番環境の一貫性を確保するために使用されます。

    • コードと依存関係の分離が回避され、配布と展開の手順が簡素化されます。

    • コンテナイメージは、キャッシュ階層にネイティブに格納されます。 これにより、コードのアップロードとプルの効率が向上します。

    • 標準の複製可能なサードパーティライブラリを使用して、リソースの参照、共有、ビルド、および保存を行うことができます。 ライブラリは、コードのアップロードやバージョンの管理にも使用できます。 これにより、継続的な統合と継続的な展開 (CI/CD) のための包括的なオープンソースエコシステムが提供されます。

    • HTTPプロトコルは、Function Computeとのやり取りに使用できます。

    • 相互作用を必要としない画像を実行することができる。

    原則

    Function Computeが実行インスタンスを初期化する前に、関数用に設定されたロールを引き受け、一時的なユーザー名とパスワードを取得し、イメージを取得します。 イメージがプルされた後、Function Computeは指定されたstartupコマンドとArgsパラメーターを使用してイメージを開始します。

    コンテナイメージの成果物にHTTPサーバーを含める必要があります。 Function Computeは、設定されたCAPortを使用してHTTPサーバーをリッスンします。 HTTPサーバーは、API呼び出しやHTTP呼び出しによるリクエストを含む、Function Computeへのすべてのリクエストを引き継ぎます。 関数の対話ロジックを開発する前に、関数がAPI呼び出しまたはHTTP要求を使用して呼び出されるかどうかを確認する必要があります。

    • API呼び出しbuhuo1containercustom1による呼び出し

    • HTTPリクエストnuhuo2customcintainer2による呼び出し

    制限事項

    画像サイズ

    最大10 GBの非圧縮Container Registry Personal Editionイメージがサポートされています。

    イメージリポジトリ

    のインスタンスからイメージをプルできます。 Alibaba Cloud Container Registryの個人版。 詳細については、「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である必要があります。

    • 接続のキープアライブ機能を有効にし、サーバー側のリクエストタイムアウト時間を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 timeout

    • HTTPサーバーは120秒以内に起動する必要があります。

    共通リクエストヘッダー

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

    Log formats

    カスタムコンテナランタイムで標準出力 (stdout) に印刷されたログは、Simple Log Serviceの指定されたLogstoreに自動的に収集されます。 詳細については、「ロギング機能の設定」をご参照ください。

    カスタムコンテナランタイムのログ形式は、カスタムランタイムのログ形式と同じです。 詳細については、「関数ログの形式」をご参照ください。

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

    コードパッケージと比較して、コンテナーイメージは実行環境に依存しており、ダウンロードと解凍に時間がかかります。 コールドスタートを最適化するには、次のベストプラクティスをお勧めします。

    • Function Computeと同じリージョンの仮想プライベートクラウド (VPC) イメージアドレスを使用して、イメージプルレイテンシを短縮し、安定性を向上させます。

    • 画像のサイズを最小限に抑えます。 AlpineやUbuntuなどの最小化されたイメージに基づいてカスタムイメージを作成できます。 イメージ内の必要な依存関係のみを保持し、重要でないドキュメント、データ、およびファイルを削除します。

    • プロビジョニングされたインスタンスと一緒にコンテナーイメージを使用します。 詳細は、「プロビジョニング済みインスタンスの設定」をご参照ください。

    • スレッドのセキュリティが保証され、十分なリソースがある場合は、インスタンスを使用して複数のリクエストを同時に処理し、コールドスタートとコストを削減できます。 詳細については、「インスタンス同時実行の設定」をご参照ください。

    課金説明

    カスタムコンテナ関数の課金対象項目は、他のタイプのランタイムで実行される関数と同じです。 詳細については、「課金の概要」をご参照ください。

    プルが開始されてからプルが終了されるまでのイメージプル期間は、イメージリソース使用に対する料金を計算するための基準として使用される。 たとえば、1,024 MBのメモリで構成されている関数インスタンスでイメージをプルするのに10秒かかると、10 GB秒のリソースが消費されます。

    コンテナイメージは、特定の期間内にキャッシュされます。 したがって、コールドスタートごとに必ずしも画像を引き出すための料金が発生するわけではありません。

    追加情報