Ansible Tower を Cloud Assembly に統合すると、展開されたリソースの構成管理をサポートできます。統合の設定後、クラウド テンプレート エディタを使用して、新しい展開または既存の展開に Ansible Tower 仮想コンポーネントを追加できます。
前提条件
- 管理者以外のユーザーに、Ansible Tower へのアクセスに適切な権限を付与します。ほとんどの構成で機能する 2 つのオプションがあります。構成に最適なオプションを選択してください。
- 組織レベルでインベントリ管理者ロールおよびジョブ テンプレート管理者ロールをユーザーに付与します。
- 特定のインベントリに対する管理者権限と、プロビジョニングに使用するすべてのジョブ テンプレートに対する実行ロールをユーザーに付与します。
-
展開で使用する認証情報とテンプレートを Ansible Tower で適切に設定する必要があります。テンプレートには、ジョブ テンプレートまたはワークフロー テンプレートを使用できます。ジョブ テンプレートでは、展開で使用するインベントリと Playbook を定義します。ジョブ テンプレートと Playbook は 1:1 でマッピングされます。Playbook では、YAML に似た構文を使用して、テンプレートに関連付けられたタスクを定義します。最も一般的な展開では、認証にマシンの認証情報を使用します。
ワークフロー テンプレートを使用すると、ユーザーはジョブ テンプレート、プロジェクト同期、インベントリ同期の任意の構成によるシーケンスを作成することで、これらを相互にリンクして 1 つのユニットとして実行できます。Ansible Tower Workflow Visualizer は、ユーザーがワークフロー テンプレートを設計するのに役立ちます。最も一般的な展開では、認証にマシンの認証情報を使用できます。
- Ansible Tower にログインして、[テンプレート] セクションに移動します。
- [新規ジョブ テンプレートの追加] を選択します。
- すでに作成されている認証情報を選択します。これらは、Ansible Tower で管理されるマシンの認証情報です。それぞれのジョブ テンプレートでは、認証情報オブジェクトを 1 つ使用できます。
- [制限] の選択項目では [起動時にプロンプトを表示] を選択します。これにより、Cloud Assembly からプロビジョニングまたはプロビジョニング解除されるノードに対して、ジョブ テンプレートが実行されます。このオプションが選択されていない場合は、ジョブ テンプレートを含むブループリントを展開するときに、「制限が設定されていない」という旨のエラーが表示されます。
- 新規ワークフロー テンプレートの追加を選択します。
- すでに作成されている認証情報を選択し、インベントリを定義します。Workflow Visualizer を使用して、ワークフロー テンプレートを設計します。
ワークフロー テンプレートまたはジョブ テンプレートの [制限] ボックスでは、通常、[起動時にプロンプトを表示] を選択します。この選択により、ジョブ テンプレートまたはワークフロー テンプレートは、Cloud Assembly からプロビジョニングまたはプロビジョニング解除されるノードに対して実行されます。
- Cloud Assembly から起動されたジョブ テンプレートまたはワークフロー テンプレートの実行は、[Ansible Tower ジョブ] タブで確認できます。
手順
結果
Ansible Tower はクラウド テンプレートで使用できます。
次のタスク
目的のクラウド テンプレートに Ansible Tower コンポーネントを追加します。統合アカウントで指定されたユーザーに対して、実行権限を含む適切なジョブ テンプレートを指定する必要があります。
- [クラウド テンプレート キャンバス] 画面のブループリント オプション メニューで、[構成管理] の見出しの下にある [Ansible] を選択し、Ansible Tower コンポーネントをキャンバスにドラッグします。
- 右側のパネルで、ジョブ テンプレートなどの該当する Ansible Tower プロパティを構成します。
Ansible Tower タイルをクラウド テンプレートに追加すると、vRealize Automation は接続された仮想マシンのホスト エントリを Ansible Tower に作成します。デフォルトでは、vRealize Automation は仮想マシンのリソース名を使用してホスト エントリを作成しますが、ブループリント YAML の hostName プロパティを使用して任意の名前を指定できます。マシンと通信するために、vRealize Automation はホスト エントリのホスト変数 ansible_host: IP Address を作成します。デフォルトの動作をオーバーライドして、FQDN を使用して通信を構成できます。それには、キーワード ansible_host を hostVariables 下で指定し、その値として FQDN を指定します。次の YAML コード スニペットは、ホスト名と FQDN の通信を構成する方法の例を示しています。
Cloud_Ansible_Tower_1: type: Cloud Ansible Tower properties: host: name of host account: name of account hostName: resource name hostVariables: ansible_host:Host FQDN
この例では、FQDN を指定して、ansible_host のデフォルト値をオーバーライドします。これは、Ansible Tower を FQDN を使用してホスト マシンに接続するユーザーに役立つ場合があります。
YAML 内の hostVariables のデフォルト値は ansible_host:IP_address で、IP アドレスがサーバとの通信に使用されます。
Ansible Tower の YAML count プロパティが 1 を超える場合、ホスト名はそれぞれの仮想マシンのプロパティにマッピングできます。次の例は、アドレス プロパティをホスト名にマッピングする場合の Ubuntu-VM という名前の仮想マシン リソースのマッピングを示しています。
hostname: '${resource.Ubuntu-VM.address[count.index]}'
Ansible Tower コンポーネントをクラウド テンプレートに追加する際に、呼び出すジョブ テンプレートをクラウド テンプレート YAML で指定できます。ワークフロー テンプレート、またはジョブ テンプレートとワークフロー テンプレートの組み合わせを指定することもできます。テンプレート タイプを指定しない場合、デフォルトでは、vRealize Automation はジョブ テンプレートを呼び出すと見なします。
次の YAML スニペットは、Ansible Tower クラウド テンプレートでジョブ テンプレートとワークフロー テンプレートの組み合わせを呼び出す方法の例を示しています。
Cloud_Ansible_1:
type: Cloud.Ansible.Tower
properties:
host: ‘${resource.CentOS_Machine.*}’
account:
maxConnectionRetries: 2
maxJobRetries: 2
templates:
provision:
- name: My workflow
type: workflow
- name: My job template
Ansible 関連の障害を処理するために、maxConnectionsRetries および maxJobRetries を追加しました。クラウド テンプレートはカスタム値を受け入れ、値が指定されていない場合はデフォルト値を使用します。maxConnectionRetries のデフォルト値は 10、maxJobRetries のデフォルト値は 3 です。
Ansible Tower 統合のための Cloud Assembly クラウド テンプレートには true または false の値を持つ useDefaultLimit プロパティが含まれ、これにより、Ansible テンプレートが実行される場所が決まります。Ansible テンプレートには、ジョブ テンプレートまたはワークフロー テンプレートを使用できます。この値を true に設定すると、指定されたテンプレートは Ansible テンプレート画面の [制限] ボックスで指定されたマシンに対して実行されます。値が false に設定されている場合、テンプレートはプロビジョニングされたマシンに対して実行されますが、ユーザーは Ansible Tower テンプレート画面の [起動時にプロンプトを表示] チェックボックスをオンにする必要があります。デフォルトでは、このプロパティの値は false です。次の YAML の例は、クラウド テンプレートで useDefaultLimit プロパティがどのように記述されるかを示しています。
templates:
provision:
- name: ping aws_credentials
type: job
useDefaultLimit: false
extraVars: '{"rubiconSurveyJob" : "checkSurvey"}'
また、前の例に示すように、extraVars プロパティを使用して追加の変数または調査変数を指定できます。この機能は、入力を要求するテンプレートを実行するときに役立ちます。ユーザーが調査変数を管理している場合は、エラーを回避するために、クラウド テンプレートの extraVars セクションで変数を渡す必要があります。
クラウド管理者権限を持つユーザーは、Ansible オープン ソースおよび Ansible Tower のリソースを含む展開のプロジェクトを変更できます。この機能は、展開レベルで Day 2 アクションとして使用できます。
Ansible 展開のプロジェクトを変更するには、Cloud Assembly の [展開] 画面に表示されているように展開の [アクション] メニューで [プロジェクトの変更] オプションを選択し、ターゲット プロジェクトを選択して、表示されたダイアログで [送信] をクリックします。
Ansible Tower 統合はグループ プロパティをサポートしていませんが、次の記事で説明するように、仮想マシン タグと VMware インベントリ プラグインを使用して同等の機能を実装することもできます。https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_inventory_inventory.html
- クラウド テンプレートで
ansible_host（FQDN など）とhostNameを使用します。 - AWX で、起動時に更新するフラグをオンにします。つまり、Playbook を実行する前に、新しいホストの vCenter Server と同期するようにします。この同期により、vRealize Automation によって追加され、VMware インベントリ プラグインによってインポートされた FQDN ホスト エントリがマージされ、ホストがグループに割り当てられます。インベントリ グループは、上記の同期ソース変数を使用して仮想マシン タグの値から作成されます。
実装例については、次のクラウド テンプレートを参照してください。
# Created by Quickstart wizard.
name: RHEL 8
version: 0.0.1
formatVersion: 1
inputs:
image:
type: string
description: Select an OS Version
default: RHEL 8 Base
enum:
- RHEL 8 Base
- RHEL 7 Base
AWX:
type: string
description: Choose AWX Environment
enum:
- LabAWX
- FA/CC-AWX
envrionmnetTag:
type: string
description: Choose VM Environment
enum:
- cel
- mag
- wdr
purposeTag:
type: string
description: Choose Server Purpose
default: ''
enum:
- ''
- mariadb
- oracle
authGroupTag:
type: string
description: Choose Authentication Group
default: ''
enum:
- ''
- dbo_linux
- oracle
- postgres
hostname:
type: string
description: Desired hostname
default: changeme
cpuCount:
type: integer
description: Number of virtual processors
default: 1
totalMemoryMB:
type: integer
description: Machine virtual memory size in Megabytes
default: 1024
disk1Size:
type: integer
description: A SIZE of 0 will disable the disk and it will not be provisioned.
default: 0
disk2Size:
type: integer
description: A SIZE of 0 will disable the disk and it will not be provisioned.
default: 0
neededip:
type: string
description: Enter an available IP Address
title: Needed-IP-Address
vlan:
type: string
description: Enter in needed vlan
title: Enter VLAN ID example "vl500"
resources:
Cloud_Ansible_Tower_1:
type: Cloud.Ansible.Tower
metadata:
layoutPosition:
- 0
- 0
properties:
host: ${resource.Cloud_vSphere_Machine_1.*}
account: ${input.AWX}
hostName: ${input.hostname}
hostVariables:
ansible_host: ${input.hostname}.dcl.wdpr.disney.com
templates:
provision:
- name: Linux-Role
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
metadata:
layoutPosition:
- 0
- 1
properties:
image: ${input.image}
Infoblox.IPAM.Network.dnsSuffix: dcl.wdpr.disney.com
Infoblox.IPAM.Network.dnsView: Internal
customizationSpec: Rhel7Base
name: ${input.hostname}
cpuCount: ${input.cpuCount}
totalMemoryMB: ${input.totalMemoryMB}
attachedDisks: ${map_to_object(resource.Cloud_Volume_1[*].id + resource.Cloud_Volume_2[*].id, "source")}
networks:
- network: ${resource.Cloud_vSphere_Network_1.id}
assignment: static
address: ${input.neededip}
tags:
- key: Server-Team
value: ${input.envrionmnetTag}
- key: Server-Team
value: ${input.purposeTag}
- key: Server-Team
value: ${input.authGroupTag}
Cloud_Volume_1:
type: Cloud.Volume
metadata:
layoutPosition:
- 0
- 2
properties:
count: '${input.disk1Size == 0 ? 0 : 1 }'
capacityGb: ${input.disk1Size}
Cloud_Volume_2:
type: Cloud.Volume
metadata:
layoutPosition:
- 0
- 3
properties:
count: '${input.disk2Size == 0 ? 0 : 1}'
capacityGb: ${input.disk2Size}
Cloud_vSphere_Network_1:
type: Cloud.vSphere.Network
metadata:
layoutPosition:
- 1
- 0
properties:
networkType: existing
constraints:
- tag: ${input.vlan}
