注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
このページでは、コンピュートモジュールで使用するための Docker の基本情報を提供します。詳細な説明については、Docker ドキュメント ↗を参照してください。
イメージをビルドおよび公開するには、まず Docker をインストールする必要があります。公式の手順に従ってください。Docker ドキュメント ↗をご参照ください。
Docker が実行されていることを確認するには、docker info コマンドを実行します。Cannot connect to the Docker daemon と表示される場合は、トラブルシューティングガイド ↗を参照して問題を解決してください。
Docker はアプリケーションをパッケージ化してデプロイするためのツールです。Docker は、実行環境を問わず一貫性のある実行と、隔離によるセキュリティを提供することで、アプリケーションの簡単な配布を可能にします。これは、コンテナ化 と呼ばれるプロセスによって実現され、アプリケーションの実行に必要なすべてをパッケージ化し、どこにデプロイされても一貫して実行されることを保証します。Docker コンテナ化の 2 つの基本プリミティブは、イメージとコンテナです。
Docker でイメージを作成するには、アプリケーションとその依存関係、ライブラリ、設定ファイルを単一のポータブルユニットにパッケージ化します。パッケージ化の指示は Dockerfile で定義されます。
Dockerfile は、アプリケーションの設定と実行方法を指示する一連のコマンドで構成されたテキストドキュメントです。以下のリストは、コンピュートモジュール用のイメージを作成する際に必要となる最も一般的なコマンドの概要です。完全なガイドについては、Dockerfile リファレンスドキュメント ↗をご参照ください。
FROM は Dockerfile の最初のステートメントでなければなりません。ターゲットプラットフォームを指定するために --platform linux/amd64 フラグを追加することもできます。latest 以外の任意のタグを使用する必要があります。コンピュートモジュールに適したイメージが用意できたら、以下の手順に従って Foundry にアップロードできます。完全な手順については、製作物の公開に関するドキュメントを参照してください。
コンピュートモジュールとしてデプロイしたいアプリケーションがあり、その構造は次のようになっています。
プロジェクト構造
myapplication
├── Dockerfile # Dockerの設定ファイル
├── requirements.txt # 必要なPythonパッケージのリスト
└── src
└── application.py # メインのアプリケーションコード
以下の手順に従って、1 行ずつ Dockerfile を作成できます。
FROM python:3.12 # ベースイメージとしてPython 3.12を使用
WORKDIR /app
# 作業ディレクトリを /app に設定する
# requirements.txt を /app にコピー
COPY ./requirements.txt /app
# requirements.txt の内容に基づいてパッケージをインストール
# キャッシュを使用せずにインストールすることで、イメージのサイズを小さく保つ
RUN pip install --no-cache-dir -r requirements.txt
RUN adduser --uid 5001 user
# 新しいユーザー 'user' を UID 5001 で追加
USER 5001
# 実行ユーザーを UID 5001 の 'user' に切り替え
COPY ./src/application.py /app # ./src/application.py を /app ディレクトリにコピーする
ENTRYPOINT ["python", "application.py"]
このコードは、Dockerfile内で使用され、Dockerコンテナが起動する際に実行されるデフォルトのコマンドを指定しています。ここでは、python コマンドを使って application.py スクリプトを実行するように設定されています。
ユーザーのDockerfileは次のようになります:
FROM python:3.12
# 作業ディレクトリを /app に設定
WORKDIR /app
# ホストマシンの requirements.txt をコンテナの /app にコピー
COPY ./requirements.txt /app
# 依存関係をインストール（キャッシュを使用しない）
RUN pip install --no-cache-dir -r requirements.txt
# UID 5001 のユーザーを追加
RUN adduser --uid 5001 user
# 実行ユーザーを UID 5001 のユーザーに切り替え
USER 5001
# ホストマシンの src/application.py をコンテナの /app にコピー
COPY ./src/application.py /app
# コンテナ起動時に実行されるコマンド
ENTRYPOINT ["python", "application.py"]
次のコマンドを実行して、Dockerfile から myimage という名前でタグ 0.0.0 のイメージをビルドできます。
docker build . -t myimage:0.0.0 --platform linux/amd64
Copied!1 2 3 4# Dockerイメージをビルドするコマンド # 現在のディレクトリにあるDockerfileを使用してビルドを行い、 # 作成したイメージに "myimage:0.0.0" というタグを付ける # ターゲットプラットフォームを "linux/amd64" に指定している
ログはコンテナレベルで設定でき、各コンテナのログを有効または無効にすることができます。この詳細な制御により、リソースの使用を最適化し、最も関連性の高いログデータに焦点を当てることができます。特定のコンテナのログ設定にアクセスするには、Containersセクションでコンテナの行を選択します。これにより、ログ設定を調整できるサイドパネルが開きます。
SLS形式は一貫性があり、簡単に解析できる構造化されたログ形式です。SLSログは、各ログエントリに追加のメタデータをサポートするように設計されています。
以下は、SLS形式でのログの例です： ログは以下のスタイルと制約に従うことに注意してください。
UnsafeArg を使用し、機密性のないデータには SafeArg を使用します。Standard System.out.println() ステートメントは SLS フォーマットではキャプチャされません。プレーンテキスト形式は、特定の構造がない人間が読みやすいログを提供します。プレーンテキストログは直接読みやすいですが、プログラム的に解析するのが難しい場合があります。
プレーンテキストが設定されている場合、出力は SLS ログのメッセージフィールドに挿入されます。これにより、既存の SLS ベースのツールとの互換性を保ちながら、読みやすさも維持されます。
デフォルトとしてプレーンテキストログを使用することで、プレーンテキストと SLS の両方のログがキャプチャされ、SLS ログはメッセージフィールドに JSON 形式で表示されます。
コンテナログは 2 つの主要なソースからキャプチャできます。各ソースには、効果的なログ収集を確保するための特定の要件と設定があります。
標準出力 (stdout) ソースは、コンテナの標準出力ストリームから直接ログを収集します。このログ方法を有効にするには、コンテナが以下の要件を満たしていることを確認してください。
/bin/sh にシェル実行可能ファイルがある必要があります。set と tee をサポートする必要があります。標準エラーの含有: オプションで標準エラー (stderr) をログに含めることができます。true に設定すると、stdout と stderr は同期され、単一のストリームにマージされます。
ログファイルソースは、コンテナ内の特定のファイルからログを収集します。2 つの設定パラメーターがあります。
例: /var/log/foo/ 内のすべての .log ファイルと特定のファイル /var/log/bar.txt からログをキャプチャするには、directoryPath を /var/log に設定し、filePathPatterns を /var/log/foo/*.log および /var/log/bar.txt に設定します。
ログファイルを使用する場合、計算モジュールが開始されるときに指定されたディレクトリパスが空である必要があります。
Docker 環境変数は、Dockerfile やコンテナイメージを変更することなく、Docker コンテナやアプリケーションの動作をカスタマイズできる動的な名前付き値です。環境変数は、次の目的で使用できます。
production と test の 2 つのコードパスがあり、test ではリクエストに関する追加のメタデータを返す場合があります。コードを変更して再展開することなく、コードが読み取って異なるパスを実行できる production 環境変数を作成できます。
いくつかの環境変数名は予約されています。予約された環境変数は上書きできません。これらは計算モジュールを作成する際に重要な情報を含んでいる可能性があるためです。以下の予約済み環境変数のリストを確認してください。
CLIENT_ID string
038120ac-ac39-4d91-be0e-55afabbb0912
CLIENT_SECRET string038120ac-ac39-4d91-be0e-55afabbb0912
RUNTIME_HOST hostlocalhost
RUNTIME_PORT port8945
RUNTIME_API hostnamelocalhost:8945
GET_JOB_PATH uri path/interactive-module/api/internal-query/job
GET_JOB_URI urihttps://localhost:8945/interactive-module/api/internal-query/job
POST_RESULT_PATH uri path/interactive-module/api/internal-query/results
POST_RESULT_URI urihttps://localhost:8945/interactive-module/api/internal-query/results
POST_SCHEMA_URI uri/interactive-module/api/internal-query/schemas
MAX_CONCURRENT_TASKS integer1
SOURCE_CREDENTIALS ファイルパス/opt/source-credentials/SOURCE_CREDENTIALS
SOURCE_CONFIGURATIONS_PATH ファイルパス/opt/source-credentials/SOURCE_CONFIGURATIONS_PATH
DEFAULT_CA_PATH file path/etc/ssl/rubix-ca/ca.pem
BUILD2_TOKEN file path/opt/build2-token/BUILD2_TOKEN