コンテナ・イメージの準備
ホストされたデプロイメント用のエージェント・コンテナ・イメージを準備、ビルドおよびプッシュします。
このトピックのガイドラインを使用して、Dockerイメージを準備します。
サポートされているコンテナ・イメージ・アーキテクチャ
イメージの場合、生成AIサービスは、64ビットのx86アーキテクチャ(コード名amd64)をサポートします。コンテナ・イメージを作成する場合は、プラットフォーム・タイプとしてlinux/amd64を使用します。
たとえば、
docker buildx build --platform linux/amd64 -t myimage:latestコードの準備
ホストされたデプロイメント環境で実行するには、Dockerコンテナが次の要件を満たしている必要があります。
- ホストおよびポート
-
- コンテナは、ホストでリスニングする必要があります
0.0.0.0。 - コンテナは、ポート
8080でリスニングする必要があります。
- コンテナは、ホストでリスニングする必要があります
- HTTPレスポンスのコンテンツ・タイプ
-
コンテナは、ユーザー定義パスを持つGET、PUT、POST、DELETE、PATCHなどのメソッドを使用して、RESTスタイルのリクエスト・エンドポイントとレスポンス・エンドポイントを実装するHTTPベースのサービスを公開する必要があります。
プラットフォームは、Acceptヘッダーを検査して、リクエストがストリーミング・レスポンスを予期するかどうかを決定します。
- Acceptヘッダーにtext/event-streamが含まれている場合、エンドポイントはコンテンツ・タイプがtext/event-streamのServer-Sent Events (SSE)レスポンスを返す必要があります。
- それ以外の場合、エンドポイントは、コンテンツ・タイプapplication/jsonの標準JSONレスポンスを返す必要があります。
この設定では、一貫性のある下位互換性のある方法で、ストリーミングと非ストリーミングの両方のやり取りのエンドポイントがサポートされます。
- 準備エンドポイント
-
Dockerコンテナは、アプリケーションが完全に初期化され、リクエストを処理する準備ができていることを確認するために、レディネス・エンドポイントを公開する必要があります。
- パス:
/ready - 目的:コンテナがトラフィックを受信する準備ができているかどうかを示します。
- レスポンス形式: HTTPステータス・コードのみ
- Content-Type:
application/json - 成功ステータス・コード:
200 OK(アプリケーションの準備完了)
- パス:
- Livenessエンドポイント
-
Dockerコンテナは、アプリケーションが正しく実行されており、再起動を必要としないことを確認するために、ライブ・エンドポイントを公開する必要があります。
- パス:
/health - 目的:コンテナが稼働中で機能しているかどうかを検出します。
- レスポンス形式: HTTPステータス・コードのみ
- Content-Type:
application/json - 成功ステータス・コード:
200 OK(アプリケーションは正常です)
- パス:
- イメージ・アーキテクチャ
-
このサービスは
amd64をサポートしています。 - 予約済みの環境変数
-
次の環境変数は、システムで使用するために予約されています。コンテナ・コードには定義しないでください。
PORT
K_SERVICE
K_CONFIGURATION
K_REVISION
OCI_RESOURCE_PRINCIPAL_VERSION
OCI_RESOURCE_PRINCIPAL_PRIVATE_PEM
OCI_RESOURCE_PRINCIPAL_RPST
KUBERNETES_*
イメージ・アーキテクチャ
イメージは、次の例に示すように、linux/amd64プラットフォーム用に構築する必要があります。
ファイルアクセス
コンテナ・ファイル・システムは読取り専用ですが、/tmpディレクトリは書込み可能です。アプリケーションでファイルをローカルに書き込む必要がある場合は、/tmpに書き込みます。
その他の制限事項
- カスタム・エントリ・ポイント・コマンドはサポートされていません。CMDまたはENTRYPOINTを使用して、エントリ・コマンドをDockerファイルに定義します。
- ボリューム・マッピングはサポートされていません。ローカル・ファイル・データは再デプロイメントまたはノードの置換時に保持されないため、コンテナはステートレスである必要があります。
プロジェクト構造
project_directory/
├── main.py # Your main agent code
├── requirements.txt # Dependencies for your agent
├── Dockerfile # Dockerfile for building the image
├── .dockerignore # Files not included in the image
└── __init__.py # Makes the directory a Python package
コンテナ・イメージの構築
次の例は、プロジェクト・ディレクトリ内のDockerfileを示しています。
FROM container-registry.oracle.com/os/oraclelinux:9-slim
ENV PYTHONUNBUFFERED=1 \
PIP_NO_CACHE_DIR=1
WORKDIR /app
RUN microdnf update -y && \
microdnf install -y \
python3.11 \
python3.11-pip \
ca-certificates \
iputils \
shadow-utils \
&& microdnf clean all \
&& rm -rf /var/cache/dnf /var/cache/yum
COPY requirements.txt .
RUN python3.11 -m pip install --no-cache-dir --upgrade pip setuptools wheel && \
python3.11 -m pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home --uid 1000 appuser && chown -R appuser:appuser /app
USER appuser
EXPOSE 8080
CMD ["python3.11", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]linux/amd64プラットフォームのDockerイメージを構築します。
docker buildx build --platform linux/amd64 -t my_agent:v1 .レジストリへのイメージのプッシュ
コンテナ・登録を作成します。コンテナ・レジストリの概要を参照してください。
docker CLIを使用して、Dockerイメージをコンテナ・レジストリにプッシュします。
ステップ1: コンテナ・レジストリへのサインインコード例:
docker login kix.ocir.ioステップ2: コンテナ・レジストリのURLおよびネームスペースを使用してイメージをタグ付けします。サンプル・コード:
docker tag my_agent:v1 ap-osaka-1.ocir.io/{your_tenancy_namespace}/my_agent:v1ステップ3: イメージのプッシュのコード例:
docker push ap-osaka-1.ocir.io/<your_tenancy_namespace>/my_agent:v1