機械翻訳について
  1. Private Automation Hubユーザーズ・ガイド
  2. カスタム実行環境の作成

5 カスタム実行環境の作成

ビルダー・ユーティリティを使用すると、Private Automation Hubにアップロードできる実行環境をカスタマイズおよび作成できます。この環境では、Oracle Linux Automation Managerからアクセスしてプレイブックを実行できます。 カスタマイズされたコンテナ・イメージを実行環境として使用してプレイブックを実行できるため、プレイブックを一貫性のある信頼できる方法で実行するために必要なコンテナ・イメージに必要なすべてのパッケージおよび依存関係を確保できます。

ノート:

Builderユーティリティを使用すると、カスタム実行環境を作成できますが、カスタム実行環境の問題が発生した場合、Oracleサポートでは、Oracle提供のOLAM-EEデフォルト・イメージに戻して問題をトラブルシューティングするよう求められる場合があります。
Builderユーティリティを使用してカスタマイズする実行環境には、次のものが含まれます:
  • Oracle Container Registryからアクセス可能なベースOLAM-EEコンテナ・イメージ。
  • Builderユーティリティで作成されたイメージに必要な特殊なビルダー・イメージ。
  • 1つ以上の不可解なコレクション。
  • Pythonまたはシステムの依存関係(モジュール、コレクションのプラグイン、カスタム・スクリプト、bashコマンドなど)、または両方の組合せ。

Builderユーティリティを使用して、バージョン1またはバージョン2のフォーマットで実行環境を作成できます。

Oracle Container Registryで使用可能なデフォルトのlam-eeでは、Oracle Linux 8コンテナ・イメージの最新バージョンが使用されます。 カスタム実行環境を構築する場合、提供されるOracle Linux 8リリースには、ansible-coreの最新バージョンとそのpython依存関係を常に使用します。 たとえば、ansible-core 2.14には、依存関係としてPython 3.11があります。

場合によっては、Oracle Linux Automation Managerで実行されている異なる実行環境でジョブを実行するために、異なるバージョンのPythonを指定する必要があることがあります。 これが発生するいくつかの例を次に示します:
  • ビルダー・ユーティリティは、Python 3.9を使用して実行環境を構築します。 Pypiパッケージおよびモジュールを使用するカスタム実行環境を構築する場合、ジョブを実行するカスタム実行環境がPython 3.9を使用するように、ジョブ・テンプレートで次の変数を指定します: 
    "ansible_python_interpreter: /usr/bin/python3.9"
  • OCI SDKを使用したOCI ansibleコレクションは、Python 3.8を使用して構築されました。 OCI SDKを使用するカスタム実行環境を構築する場合、ジョブを実行するカスタム実行環境がPython 3.8を使用するように、ジョブ・テンプレートで次の変数を指定します: 
    "ansible_python_interpreter: /usr/bin/python3.8"

ジョブ・テンプレートでの変数の設定の詳細は、「Oracle Linux Automation Manager 2: ユーザーズ・ガイド」を参照してください。

フォーマット1を使用したカスタム実行環境の構成

書式1を使用してカスタム実行環境を構成するには、次の手順を実行します:
  1. Builderユーティリティをインストールしたホストで、Builderユーティリティの作業ディレクトリを作成します。 たとえば、 
    mkdir ~/builder-utility 
cd ~/builder-utility
  2. 次のファイルを作成します。 
    touch ansible.cfg execution-environment.yml requirements.yml requirements.txt bindep.txt
  3. execution-environment.ymlファイルで、次のパラメータを追加します:
    ---
version: 1
build_arg_defaults:
  EE_BASE_IMAGE: 'container-registry.oracle.com/oracle_linux_automation_manager/olam-ee:latest'
  EE_BUILDER_IMAGE: 'container-registry.oracle.com/oracle_linux_automation_manager/olam-builder:latest'
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--ignore-certs"
ansible_config: 'ansible.cfg'
dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt
additional_build_steps:
  prepend: |
    RUN whoami
    RUN cat /etc/os-release
  append:
    - RUN echo This is a post-install command!
    - RUN ls -la /etc
    この例では、次のようになります。
    • EE_BASE_IMAGE: このパラメータには、container-registry.oracle.com/oracle_linux_automation_manager/olam-eeから取得できるベースlam-eeが必要です。 または、この目的のためにPrivate Automation Hubを構成している場合は、Private Automation Hubからこのイメージのコピーを取得することもできます。
    • EE_BUILDER_IMAGE: このパラメータには、container-registry.oracle.com/oracle_linux_automation_manager/olam-builderから取得できるlam-builderイメージが必要です。 ビルダー・コンテナ・イメージには、顧客実行環境の作成に必要なビルド・ライブラリが含まれています。 または、この目的のためにPrivate Automation Hubを構成している場合は、Private Automation Hubからこのイメージのコピーを取得することもできます。
    • ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--ignore-certs"オプションを使用します。 このパラメータを使用すると、自己署名証明書を使用せずにリポジトリからイメージを取得できます。
    • ansible_config: ansible.cfgファイルを指定して、プライベート・アカウントのトークンおよびその他の設定をPrivate Automation Hubサーバーに渡すことができます。 それ以外の場合、ビルダー・ユーティリティはansible.galaxyを使用してAnsibleコレクションをダウンロードします。 構成ファイルのパスを文字列としてリストすると、ビルドの初期フェーズでビルド引数として含められます。
    • 依存関係: このセクションは、最後のコンテナにインストールする必要があるAnsible Galaxy、Pythonおよびシステム依存関係を定義するディクショナリ値です。

      ノート:

      この項にリストされている、カバレッジのOracle LinuxまたはOracle Linux Automation Manager範囲外の依存関係は、サポートの対象範囲外です。
      このセクションの有効なキーは次のとおりです:
      • 銀河: このパラメータは、コレクションの依存関係を定義するファイルへのパスです。 Builderユーティリティは、これらをansible-galaxy collection install -r requirements.ymlコマンドでインストールします。 指定する値は、実行環境定義のフォルダのディレクトリからの相対パス、または絶対パスです。
        requirements.ymlファイルでコレクションを指定する形式は、次のとおりです:
        ---
collections:
  - name: <namespace>.<collection_name>

        前述の例では、<namespace>はコレクションのネームスペース(oracleなど)、<collection_name>はインストールされるコレクションの名前(ociなど)です。 この組合せは、使用するコレクションごとに繰り返すことができます。

        特定のバージョン、ソース・タイプおよびソースのロケーションを次のように指定することもできます:
        ---
collections:
- name <namespace>.<collection_name>
  version: <version_number or "<range_identifyer><version_number>"
  type: <source_type>
        前述の例では、<version_number>は任意のコレクション・バージョン番号にできます。 1つ以上の<range_identifyer>で指定されている場合、バージョン番号は、指定された範囲内で可能なコレクションの最新バージョンです。 たとえば、次の例は、バージョンが4.0.0以上で、5.0.0未満であることを示します: 
        ---
collections:
- name: oracle.oci
  version: ">=4.0.0,<5.0.0"
  type: galaxy
        次の範囲識別子を使用できます:
        • *

          最新バージョン。 これはデフォルトです。

        • !=

          指定されたバージョンと等しくありません。

        • ==

          指定されたバージョン。

        • >=

          指定したバージョン以上。

        • >

          指定されたバージョンを超えています。

        • <=

          指定したバージョン以下。

        • <

          指定したバージョン未満。

      • python: この文字列値は、pip install -r requirements.txtコマンドでインストールされるPythonの依存関係を含むファイルへのパスです。 指定する値は、実行環境定義のフォルダのディレクトリからの相対パス、または絶対パスです。

        requirements.ymlファイルでpython依存関係を指定する形式は、次のとおりです:

        <someproject>
<someproject><version_specifier><version_number>
<someproject><version_specifier><version_number>,<version_specifier><version_number>
        前述の例では、<someproject>はプロジェクトの名前です。 プロジェクト名のみを指定して、そのプロジェクトの最新バージョンを検索するか、または1つ以上の<version_identifier>と<verion_number>の組合せでプロジェクトを指定して、インストールするプロジェクトの特定のバージョンを返すことができます。 たとえば: 
        requests>=2.4.2
xmltodict
azure-cli-core==2.11.1

        使用可能なバージョン指定子の詳細は、https://peps.python.org/pep-0440/#version-specifiersを参照してください。

      • system: この文字列値は、bindep.txt要件ファイルを示します。 これはbindepで処理され、dnfに渡されます。他のプラットフォームはまだサポートされていません。 たとえば: 
        gcc
libcurl-devel
libxml2-devel
python39-devel
openssl-devel

        システム要件ファイルの記述およびオプションでバージョン制約の指定の詳細は、https://docs.opendev.org/opendev/bindep/latest/readme.html#writing-requirements-filesを参照してください。

    • additional_build_steps: additional_build_stepsセクションには、メイン・ビルド・ステップの前(準備)または後(追加)のいずれかで、追加のコマンドを指定できます。 構文は次のいずれかである必要があります:
      • 複数行の文字列(上の前頭のセクションに示されている例)
      • リスト(appendで表示)
  4. ファイルを保存します。
  5. 必要に応じて、ansible.cfgおよび依存関係ファイルを実行します。
  6. 作業ディレクトリから次のコマンドを実行します: 
    ansible-builder build -t <repository:tag>
    前述の例では、<repository:tag>はカスタム実行環境のリポジトリおよびタグです。 たとえば、host1/'custom_ee:latestです。

    ノート:

    ビルダー・ユーティリティ・プロセスの詳細は、コマンドの最後に -v 3オプションを使用して最も多くの情報を提供し、1は最小です。 たとえば、 
    ansible-builder build -v 3
  7. イメージが作成されていることを確認します。 次のPodmanコマンドを実行します: 
    podman images

形式2を使用したカスタム実行環境の構成

形式2を使用してカスタム実行環境を構成するには、次の手順を実行します:
  1. Builderユーティリティをインストールしたホストで、Builderユーティリティの作業ディレクトリを作成します。 たとえば、 
    mkdir ~/builder-utility 
cd ~/builder-utility
  2. 次のファイルを作成します。 
    touch ansible.cfg execution-environment.yml requirements.yml requirements.txt bindep.txt
  3. execution-environment.ymlファイルで、次のパラメータを追加します:
    ---
version: 2

build_arg_defaults:
 ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--ignore-certs"

ansible_config: 'ansible.cfg'

dependencies:
 galaxy: requirements.yml
 python: requirements.txt
 system: bindep.txt

images:
 base_image:
  name: container-registry.oracle.com/oracle_linux_automation_manager/olam-ee:latest
 builder_image:
  name: container-registry.oracle.com/oracle_linux_automation_manager/olam-builder:latest
    この例では、次のようになります。
    • ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: "--ignore-certs" option.Thisパラメータを使用すると、自己署名証明書を使用せずにリポジトリからイメージを取得できます。
    • ansible_config: ansible.cfgファイルを指定して、Private Automation Hubサーバーのトークンおよびその他の設定を渡すことができます。 構成ファイルのパスを文字列としてリストすると、ビルドの初期フェーズでビルド引数として含められます。
    • 依存関係: このセクションは、最後のコンテナにインストールする必要があるAnsible Galaxy、Pythonおよびシステム依存関係を定義するディクショナリ値です。 このセクションの有効なキーは次のとおりです:
      • 銀河: このパラメータは、コレクションの依存関係を定義するファイルへのパスです。 Builderユーティリティは、これらをansible-galaxy collection install -r requirements.ymlコマンドでインストールします。 指定する値は、実行環境定義のフォルダのディレクトリからの相対パス、または絶対パスです。
        requirements.ymlファイルでコレクションを指定する形式は、次のとおりです:
        ---
collections:
- name <namespace>.<collection_name>

        前述の例では、<namespace>はコレクションのネームスペース(oracleなど)、<collection_name>はインストールされるコレクションの名前(ociなど)です。 この組合せは、使用するコレクションごとに繰り返すことができます。

        特定のバージョン、ソース・タイプおよびソースのロケーションを次のように指定することもできます:
        ---
collections:
  - <namespace>.<collection_name>
     version: <version_number or "<range_identifyer><version_number>"
     type: <source_type>
        前述の例では、<version_number>は任意のコレクション・バージョン番号にできます。 1つ以上の<range_identifyer>で指定されている場合、バージョン番号は、指定された範囲内で可能なコレクションの最新バージョンです。 たとえば、次の例は、バージョンが4.0.0以上で、5.0.0未満であることを示します: 
        ---
collections:
- name: oracle.oci
  version: ">=4.0.0,<5.0.0"
  type: galaxy
        次の範囲識別子を使用できます:
        • *

          最新バージョン。 これはデフォルトです。

        • !=

          指定されたバージョンと等しくありません。

        • ==

          指定されたバージョン。

        • >=

          指定したバージョン以上。

        • >

          指定されたバージョンを超えています。

        • <=

          指定したバージョン以下。

        • <

          指定したバージョン未満。

      • python: この文字列値は、pip install -r ...コマンドでインストールされるPython依存関係を含むファイルへのパスです。 指定する値は、実行環境定義のフォルダのディレクトリからの相対パス、または絶対パスです。

        requirements.ymlファイルでpython依存関係を指定する形式は、次のとおりです:

        <someproject>
<someproject><version_specifier><version_number>
<someproject><version_specifier><version_number>,<version_specifier><version_number>
        前述の例では、<someproject>はプロジェクトの名前です。 プロジェクト名のみを指定して、そのプロジェクトの最新バージョンを検索するか、または1つ以上の<version_identifier>と<verion_number>の組合せでプロジェクトを指定して、インストールするプロジェクトの特定のバージョンを返すことができます。 たとえば: 
        requests>=2.4.2
xmltodict
azure-cli-core==2.11.1

        使用可能なバージョン指定子の詳細は、https://peps.python.org/pep-0440/#version-specifiersを参照してください。

      • system: この文字列値は、bindep要件ファイルを示します。 これはbindepで処理され、dnfに渡されます。他のプラットフォームはまだサポートされていません。 たとえば: 
        gcc 
libcurl-devel 
libxml2-devel  
python39-devel 
openssl-devel

        システム要件ファイルの記述およびオプションでバージョン制約の指定の詳細は、https://docs.opendev.org/opendev/bindep/latest/readme.html#writing-requirements-filesを参照してください。

    • additional_build_steps: additional_build_stepsセクションには、メイン・ビルド・ステップの前(準備)または後(追加)のいずれかで、追加のコマンドを指定できます。 構文は次のいずれかである必要があります:
      • 複数行の文字列(上の前頭のセクションに示されている例)
      • リスト(appendで表示)
    • イメージ: イメージ・キーを使用して、ベース・イメージとビルダー・イメージを定義できます。 バージョン2の形式では、実行環境定義で、--container-policy CLIオプションの値に基づいて、ビルダーが結果のイメージを構築する前にシグネチャを検証する必要があるベースおよびビルダーのコンテナ・イメージを指定できます。 主なオプションは次のとおりです:
      • base_image: このパラメータには、container-registry.oracle.com/oracle_linux_automation_manager/olam-eeから取得できるベースlam-eeが必要です。 または、この目的のためにPrivate Automation Hubを構成している場合は、Private Automation Hubからこのイメージのコピーを取得することもできます。
      • builder_image: このパラメータには、container-registry.oracle.com/oracle_linux_automation_manager/olam-builderから取得できるlam-builderイメージが必要です。 ビルダー・コンテナ・イメージには、顧客実行環境の作成に必要なビルド・ライブラリが含まれています。 または、この目的のためにPrivate Automation Hubを構成している場合は、Private Automation Hubからこのイメージのコピーを取得することもできます。
  4. ファイルを保存します。
  5. 必要に応じて、ansible.cfgおよび依存関係ファイルを実行します。
  6. 作業ディレクトリから次のコマンドを実行します: 
    ansible-builder build -t <repository:tag>
    前述の例では、<repository:tag>はカスタム実行環境のリポジトリおよびタグです。 たとえば、host1/'custom_ee:latestです。

    ノート:

    ビルダー・ユーティリティ・プロセスの詳細は、コマンドの最後に -v 3オプションを使用して最も多くの情報を提供し、1は最小です。 たとえば、 
    ansible-builder build -v 3
  7. イメージが作成されていることを確認します。 次のPodmanコマンドを実行します: 
    podman images

カスタム実行環境のアップロード

カスタム実行環境をアップロードするには、次を実行します:
  1. カスタム実行環境を作成したホストから、Podmanを使用して、カスタム実行環境をアップロードするPrivate Automation Hubインスタンスにログインします。 たとえば、 
    podman login <ip address or hostname> -u admin -p <password> --tls-verify=false

    前の例では、<ip address or hostname>はPrivate Automation HubインスタンスのIPアドレスまたはホスト名、<password>はPrivate Automation Hubインスタンスの管理ユーザーのパスワードです。

  2. アップロードするカスタム・イメージを識別します。 たとえば、 
    podman images
  3. イメージをPrivate Automation Hubにプッシュします。 たとえば、 
    podman push <podman_image_id or repository:tag> <ip address or hostname/image_name:tag> --tls-verify=false
    前述の例では、<podman_image_id or repository:tag>はプッシュするカスタム実行環境のイメージIDまたはリポジトリおよびタグで、<ip address or hostname/image_name:tag>はIPアドレスまたはホスト名、その後にイメージ名とPrivate Automation Hubインスタンスのタグが続きます。 たとえば、次の例では、ポッドマン・リポジトリ名とタグを使用し、その後にホスト名、イメージ名およびタグを指定して、プライベート自動化ハブ・インスタンスで使用します: 
    podman push localhost/custom-image:2.1.3 private_automation_hub_host/custom-image:2.1.3 --tls-verify=false
    次に、ポッドマン・イメージIDと、プライベート自動化ハブ・インスタンスで使用するホスト名、イメージ名およびタグを使用します: 
    podman push 330928308c01 private_automation_hub_host/custom-image:2.1.3 --tls-verify=false
  4. 実行環境がPrivate Automation Hubインスタンスに存在することを確認します。 このタスクの詳細については、「実行環境詳細の表示」を参照してください。