18.2. コンテナーグループ
Ansible Automation Platform はコンテナーグループをサポートします。これにより、Automation Controller がスタンドアロン、仮想環境、コンテナーのいずれとしてインストールされているかに関係なく、Automation Controller でジョブを実行できます。コンテナーグループは、仮想環境内のリソースのプールとして機能します。OpenShift コンテナーを参照するインスタンスグループを作成できます。このインスタンスグループは、Playbook の実行期間中のみ存在する Pod として、オンデマンドでプロビジョニングされるジョブ環境です。これは一時的な実行モデルとして知られており、すべてのジョブの実行に対してクリーンな環境を確保します。
場合によっては、コンテナーグループを「常時オン」に設定することが必要な場合があります。これは、インスタンスの作成を通じて設定できます。
Automation Controller 4.0 より前のバージョンからアップグレードしたコンテナーグループはデフォルトに戻り、古い Pod 定義は削除され、移行中のすべてのカスタム Pod 定義は消去されます。
実行環境はコンテナーイメージであり、仮想環境を使用しないという点で、実行環境とコンテナーグループは異なります。詳細は、実行環境 を参照してください。
18.2.1. コンテナーグループの作成
ContainerGroup
は、OpenShift クラスターへの接続を可能にする認証情報が関連づけられた InstanceGroup
の一種です。
前提条件
- 起動できる namespace がある。すべてのクラスターには「デフォルト」の namespace がありますが、特定の namespace を使用することもできます。
- この namespace で Pod を起動および管理可能なロールを持つサービスアカウントがある。
-
プライベートレジストリーで実行環境を使用しており、Automation Controller でコンテナーレジストリー認証情報が実行環境に関連付けられている場合、サービスアカウントには、namespace でシークレットを取得、作成、削除するためのロールも必要です。これらのロールをサービスアカウントに付与しない場合は、
ImagePullSecrets
を事前に作成し、ContainerGroup
の Pod 仕様で指定できます。この場合、実行環境にコンテナーレジストリーの認証情報を関連付けることはできません。関連付けられている場合、Automation Controller は namespace にシークレットを作成しようとします。 - サービスアカウントに関連付けられたトークンがある。OpenShift または Kubernetes Bearer トークン。
- クラスターに関連付けられた CA 証明書がある。
次の手順では、Automation Controller を使用してコンテナーグループでジョブを実行するためのサービスアカウントを OpenShift クラスターまたは Kubernetes に作成する方法を説明します。サービスアカウントを作成すると、その認証情報が OpenShift or Kubernetes API Bearer Token 認証情報の形式で Automation Controller に提供されます。
手順
サービスアカウントを作成するには、以下のサンプルのサービスアカウント (
containergroup sa
) をダウンロードして使用し、認証情報を取得するために必要に応じて変更します。--- apiVersion: v1 kind: ServiceAccount metadata: name: containergroup-service-account namespace: containergroup-namespace --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: role-containergroup-service-account namespace: containergroup-namespace rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get"] - apiGroups: [""] resources: ["pods/attach"] verbs: ["get", "list", "watch", "create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: role-containergroup-service-account-binding namespace: containergroup-namespace subjects: - kind: ServiceAccount name: containergroup-service-account namespace: containergroup-namespace roleRef: kind: Role name: role-containergroup-service-account apiGroup: rbac.authorization.k8s.io
containergroup-sa.yml
から設定を適用します。oc apply -f containergroup-sa.yml
サービスアカウントに関連付けられているシークレット名を取得します。
export SA_SECRET=$(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"')
シークレットからトークンを取得します。
oc get secret $(echo ${SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token
CA 証明書を取得します。
oc get secret $SA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt
-
containergroup-sa.token
およびcontainergroup-ca.crt
の内容を使用して、コンテナーグループに必要な OpenShift or Kubernetes API Bearer Token の情報を提供します。
コンテナーグループを作成するには、コンテナーグループで使用する OpenShift または Kubernetes API Bearer Token 認証情報を作成します。詳細は、新しい認証情報の作成 を参照してください。
手順
-
ナビゲーションパネルから、
を選択します。 - Create container group を選択します。 をクリックし、
- 新しいコンテナーグループの名前を入力し、以前に作成した認証情報を選択して、コンテナーグループに割り当てます。
- をクリックします。
18.2.2. Pod 仕様のカスタマイズ
Ansible Automation Platform は単純なデフォルトの Pod 仕様を提供しますが、デフォルトの Pod 仕様をオーバーライドするカスタム YAML または JSON ドキュメントを提供できます。このフィールドは、有効な Pod JSON または YAML として「シリアル化」できる ImagePullSecrets
などのカスタムフィールドを使用します。オプションの完全なリストは、OpenShift ドキュメントの Pod およびサービス セクションにあります。
手順
-
ナビゲーションパネルから、
を選択します。 - Create container group を選択します。 をクリックし、
- Customize pod spec オプションをオンにします。
Pod spec override フィールドに、カスタムの Kubernetes または OpenShift Pod 仕様を入力します。
- をクリックします。
ジョブ起動時のイメージは、どの実行環境がジョブに関連付けられているかによって決まります。コンテナーレジストリーの認証情報を実行環境に関連付ける場合、Automation Controller はイメージをプルするために ImagePullSecret
を作成しようとします。シークレットを管理するパーミッションをサービスアカウントに付与しない場合は、ImagePullSecret
を事前に作成してそれを Pod 仕様で指定し、使用する実行環境から認証情報を削除する必要があります。
詳細は、Red Hat Container Registry Authentication の Allowing Pods to Reference Images from Other Secured Registries セクションを参照してください。
コンテナーグループが正常に作成されると、新しく作成されたコンテナーグループの Details タブが表示され、そこでコンテナーグループ情報を確認および編集できます。これは、Instance Groups リストビューから アイコンをクリックした場合に開くメニューと同じです。
Instances を編集し、このインスタンスグループに関連付けられた Jobs を確認することもできます。
コンテナーグループとインスタンスグループは適宜ラベル付けされます。
18.2.3. コンテナーグループ機能の検証
コンテナーのデプロイと終了を確認するには、以下を実行します。
手順
モックインベントリーを作成し、Instance groups フィールドにコンテナーグループの名前を入力して、コンテナーグループをそのインベントリーに関連付けます。詳細は、新規インベントリーの追加 を参照してください。
次の変数を使用して、インベントリーに
localhost
ホストを作成します。{'ansible_host': '127.0.0.1', 'ansible_connection': 'local'}
ping または setup モジュールを使用して、ローカルホストに対してアドホックジョブを起動します。Machine Credential フィールドは必須ですが、このテストでどれを選択するかは重要ではありません。
Jobs 詳細ビューで、アドホックジョブの 1 つを使用してコンテナーに正常にアクセスしたことが表示されます。
OpenShift UI を使用している場合、Pod はデプロイされると表示され、終了すると非表示になります。CLI を使用して namespace で get pod
操作を実行し、同イベントの発生をリアルタイムで監視することもできます。
18.2.4. コンテナーグループジョブの表示
コンテナーグループに関連付けられたジョブを実行すると、そのジョブの詳細が Details タブに表示されます。関連付けられたコンテナーグループと起動された実行環境も表示できます。
手順
-
ナビゲーションパネルから、
を選択します。 - コンテナーグループジョブを表示するジョブをクリックします。
- Details タブをクリックします。
18.2.5. Kubernetes API の障害状態
コンテナーグループを実行し、Kubernetes API がリソースクォータを超過したと応答すると、Automation Controller はジョブを保留状態にします。その他の障害の場合は、次の例のように、Error Details フィールドのトレースバックに障害の理由が表示されます。
Error creating pod: pods is forbidden: User "system: serviceaccount: aap:example" cannot create resource "pods" in API group "" in the namespace "aap"
18.2.6. コンテナーの容量制限
コンテナーの容量制限とクォータは、Kubernetes API のオブジェクトで定義します。
-
特定の namespace 内のすべての Pod に制限を設定するには、
LimitRange
オブジェクトを使用します。詳細は、OpenShift ドキュメントの クォータおよび制限範囲 セクションを参照してください。 - Automation Controller が起動する Pod 定義に制限を直接設定するには、Pod 仕様のカスタマイズ と OpenShift ドキュメントの コンピュートリソース セクションを参照してください。
コンテナーグループは、通常のノードが使用する容量アルゴリズムを使用しません。ジョブテンプレートレベルでフォークの数を設定する必要があります。Automation Controller でフォークを設定すると、その設定はコンテナーに渡されます。