Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

Ansible Automation Platform 1.2 から 2 への移行ガイド

Red Hat Ansible Automation Platform 2.4

Anshul Behl

Roger Lopez

概要

本書では、Ansible Automation Platform 1.2 から Ansible Automation Platform 2 に移行する方法について説明します。

コメントとフィードバック
リンクのコピー

オープンソースの精神を大切にしています。リファレンスアーキテクチャーに関するフィードバックやコメントをお聞かせください。文書は社内で確認していますが、何らかの問題や誤字脱字があるかもしれません。フードバックにより、当社は作成文書の品質を向上でき、読者も改善点や内容の拡充などについてご意見いただけます。文書に関するフィードバックは、電子メールで ansible-feedback@redhat.com に送信してください。その際には、メール本文内で文書のタイトルを記載してください。

第1章 概要
リンクのコピー

Ansible Automation Platform 1.2 から Ansible Automation Platform 2 への移行ガイドでは、Ansible Automation Platform インストーラーを使用してサイドバイサイド移行を行う方法を説明します。本書では、バックアップ、Ansible Automation Platform 2 へのインポート、および Ansible Automation Platform 2 へのアップグレードプロセスが成功したことを確認する手順を説明します。このリファレンスアーキテクチャーは、Ansible Automation Platform 2 の最新バージョンへの移行を検討しているシステムおよびプラットフォーム管理者に最適です。

このサイドバイサイド移行のリファレンスアーキテクチャーには、環境 A と 環境 B の 2 つの環境があります。この環境では、お使いの 環境 A Ansible Automation Platform 1.2 環境にあるすべてのデータが移行され、新しい 環境 B Ansible Automation Platform 2 の置き換え環境にアップグレードされます。

プラットフォーム移行プロセスのアプローチの概要:

  • 環境 A で Ansible Automation Platform インストーラーを使用して、Ansible Automation Platform 1.2 の完全なデータバックアップを作成します。
  • 完全な Ansible Automation Platform データバックアップを新しい空の代替 Ansible Automation Platform 1.2 環境コントロールプレーン (環境 B) にインポートします。
  • Ansible Automation Platform 2 インストーラーを使用して、環境 B をその Ansible Automation Platform 1.2 バージョンからアップグレードします。
  • 環境 B に自動化メッシュの実行ノードとホップノードをデプロイします。

インフラストラクチャーが正常に移行されると、Ansible Automation Platform 1.2 環境の Python 仮想環境を 環境 A から、環境 B の新しく利用可能な Ansible Automation Platform 2 環境内で使用される自動化実行環境に移行することに焦点が移ります。この 1 回限りの作業により、最新の Ansible Automation Platform 2 機能を活用し、運用のオーバーヘッドを削減して複数のプラットフォーム間で一貫性のある自動化を実行することができるようになります。

実行環境の導入プロセスは、以下で構成されます。

  • 環境 A の Ansible Automation Platform 1.2 からカスタム仮想環境をエクスポートする
  • エクスポートされた各仮想環境を 環境 A の Ansible 2.9 ベース実行環境と比較する
  • Ansible 2.9 実行環境に加えて、仮想環境によってエクスポートされた、含まれていない追加の依存関係を使用して、新しい実行環境を作成する
  • 新しい実行環境を 環境 B の対応するジョブテンプレートにアタッチする
注記

このドキュメントでは、お客様が複雑なアーキテクチャー内の 2 つのクラスター間でジョブの実行履歴とプラットフォームオブジェクトを保持する方法を理解できるように、全体的な移行アプローチを示すため、独自のリファレンス環境を紹介します。既存のアーキテクチャーおよび要件に基づいて、移行プロセスをさらに簡素化できます。多くの場合、Ansible Automation Platform インストーラーのデフォルト値だけで十分です。ここに記載されている移行プロセスは、単純な環境と複雑な環境の両方が対象となっています。

注記

Ansible Automation Platform 1.2 からバージョン 2 に移行するお客様は、マネージドノードのインベントリーが両方のクラスター/インスタンスで同じである限り、両方のクラスター/インスタンスで同じマニフェストを使用してアップグレードできます。移行期間は、Red Hat アカウント担当者からの正式な BU ガイダンス要求を行うことで Ansible ビジネスユニットから例外として承認されない限り、6 か月を超えることはできません。

1.1. アーキテクチャーの概要
リンクのコピー

本セクションでは、サイドバイサイドの移行プロセスを実行するのに、2 つの環境に関するアーキテクチャーの詳細に重点を置いています。

最初の環境である 環境 A は、以下で構成されます。

  • ラーレーの NC データセンターにある Red Hat Enterprise Linux 7 を実行する Ansible Tower 3.8.5 ノード 3 つ
  • Red Hat Enterprise Linux 7 データベースノード 1 つ
  • bastion ホスト (対応する分離ノードにアクセスするためジャンプホスト) 2 つ
  • 分離ノード (サクラメントの CA データセンター) 2 つ
  • 分離ノード (インド、ニューデリーのデータセンター) 2 つ

以下に、この環境を図で表します。

図1.1 環境 A アーキテクチャーの概要

enva
View larger image
enva

2 番目の環境である 環境 B は、新しい空の Ansible Automation Platform 1.2 環境で、Ansible Automation Platform 2 にアップグレードする前に、環境 B から Ansible Automation Platform 1.2 インストーラーを使用して 環境 A からすべてのデータをインポートするために使用されます。

まず、環境 B は以下で構成されます。

  • Red Hat Enterprise Linux 8 を実行する Ansible Tower 3.8.5 ノード 3 つ
  • Red Hat Enterprise Linux 8 データベースノード 1 つ
警告

Ansible Automation Platform 2 は Red Hat Enterprise Linux 7 をサポートしません。Ansible Automation Platform 2 にアップグレードする前に、Red Hat Enterprise Linux 8 を Ansible Automation Platform 1.2 環境 B のベース OS として使用することが重要です。

注記

このリファレンス全体で、多数の Ansible Automation Platform 2.1 への参照があります。しかし、このドキュメントに記載されている Ansible Automation Platform の移行プロセスはバージョン 2.1 以降に適用されます。

以下に、初期の 環境 B のフットプリントを図で表します。

図1.2 初期環境 B アーキテクチャーの概要

initial envb
View larger image
initial envb

環境 A から 環境 B へのデータ移行に成功すると、以下の項目を追加して、アップグレードプロセス時に 環境 B のアーキテクチャーを拡張します。

  • Ansible コントローラーから直接アクセスできる実行ノード 2 つ
  • ホップノード 3 つ (sacramento-hop、dublin-hop new-delhi-hop)
  • ホップノード sacramento-hop 経由でのみアクセス可能な実行ノード 2 つ
  • ホップノード dublin-hop および new-delhi-hop を介してアクセス可能な実行ノード 2 つ
注記

dublin-hop は、 インドのニューデリーにある実行ノードにアクセスするために使用できる自動化メッシュを介して別のルートを提供します。

拡張された Ansible Automation Platform 2 環境 B の世界ビューを以下に示します。

図1.3 環境 B の俯瞰図

俯瞰図
View larger image
俯瞰図

拡張された Ansible Automation Platform 2 環境 B アーキテクチャーのフットプリントの詳細を以下に示します。

図1.4 拡張された環境 B アーキテクチャーの概要

拡張された環境 b
View larger image
拡張された環境 b
注記

ジョブテンプレートからスケジュールを無効にするプロセスは、このリファレンスアーキテクチャーでは対応していません。移行が正常に完了したら、環境 A のジョブテンプレートからのスケジューリングを無効にして、環境 A と 環境 B の両方で同じジョブを同時に実行しないようにすることが重要です。

第2章 移行に関する考慮事項
リンクのコピー

Ansible Automation Platform 2 の導入により、自動化の機能を拡張するようにアーキテクチャーが再考されて、作成されました。Ansible Automation Platform 2 は、オートメーションコントロールプレーンと実行プレーンを切り離し、より柔軟なアーキテクチャーを提供します。この新しい機能と自動化メッシュの導入により、組織は自動化を世界中に拡張し、自動化を可能な限りエンドポイントの近くで実行できるようになります。

このリファレンスアーキテクチャーで提供される段階的な移行アプローチの前に、例外なく移行を進めるための全体的な移行の準備状況を慎重に評価し、計画を立てることが重要です。

2.1. 技術的な考慮事項
リンクのコピー

Ansible Automation Platform 1.2 と Ansible Automation Platform 2 の間の主な変更点の 1 つは、自動化メッシュを使用するホップノードと実行ノードを優先して、分離されたノードを削除したことです。自動化メッシュは、多様なネットワークトポロジー、プラットフォーム、および地域にわたって大規模なインベントリーの自動化をスケーリングするための、シンプルで柔軟かつ信頼性の高い方法を提供するオーバーレイネットワークです。自動化メッシュは、IT 資産全体で自動化を標準化および正規化するための強化されたセキュリティーを提供しながら、柔軟な設計オプションを提供し、回復力のある耐障害性のアーキテクチャーを構築します。

このリファレンス環境では、隔離されたノードとサードパーティーツール (SSH プロキシーやジャンプホストなど) を使用する Ansible Automation Platform 1.2 を移行し、自動化メッシュホップと実行ノードを使用して Ansible Automation Platform 2 にアップグレードする手順をキャプチャーします。

自動化メッシュおよび実行ノードを使用するには、ファイアウォール内で追加のポートを開く必要があります。

Expand
プロトコルポート目的

SSH

22/TCP

Ansible Automation Platform のインストール

HTTPS

443/TCP

Web UI、API、実行環境 (EE) のプル

receptor

27199/TCP

自動化メッシュ

注記

receptor TCP ポートは、Ansible Automation Platform のアップグレードプロセス中にカスタマイズできます。

もう 1 つの重要な考慮事項は、データベースのサポートがあるかどうかです。Automation controller が導入され、Postgres 12 データベースの要件が追加されます。既存の Postgres 10 データベースが Ansible Automation Platform 1.2 でインストール/管理されている場合、Ansible Automation Platform 2 へのアップグレードプロセスは、Postgres データベースの新規バージョン 12 へのアップグレードを処理します。

注記

このリファレンスアーキテクチャーでは、Postgres データベースは Ansible Automation Platform で管理されます。

独自の Postgres 10 データベースを管理する場合は、以下を行う必要があります。

  • サイドバイサイド移行に含まれる新しい Postgres 10 データベースをインストールします。
  • 環境 A から、環境 B で使用される新しく作成された Postgres 10 データベースにデータをインポートします。
  • 環境 B で使用されるデータベースで、Postgres 10 から Postgres 12 にアップグレードします。
  • アップグレードされた Postgres 12 を使用して、環境 B で Ansible Automation Platform 1.2 を Ansible Automation Platform 2 にアップグレードします。
注記

独自の Postgres データベースの管理は、このリファレンスアーキテクチャーの範囲外です。

注記

データベースのサポート可能性の詳細は、Database Scope of Coverage の記事を参照してください。

分離ノードとデータベースのサポートの有無に関する重要な考慮事項とは別に、Ansible Automation Platform 2 で削除された機能のリストがあります。このリストには以下が含まれます。

  • ユーザーインターフェイスを介してデフォルトのインスタンスグループを削除する機能
  • CentOS (任意のバージョン) および RHEL 7 でのデプロイのサポート
  • Mercurial プロジェクトのサポート
  • コントローラーに保存されているカスタムインベントリースクリプトのサポート
  • リソースプロファイリングコード (AWX_RESOURCE_PROFILING_*)
  • 実行環境を優先するカスタム Python 仮想環境のサポート
  • 上位レベルの /api/v2/job_events/ API エンドポイント
  • ジョブの分離は実行環境を使用して行われ、Ansible Tower の機能ではなくなりました。
注記

カスタム Python 仮想環境をユーザーが作成した実行環境に置き換える方法については、後の章で、このリファレンスアーキテクチャーによって提供される Ansible Playbook を使用して説明し、実行します。

2.2. Ansible コンテンツの移行に関する考慮事項
リンクのコピー

お使いの環境を Ansible Automation Platform 1.2 から Ansible Automation Platform 2 に移行するプロセスを評価する際、Ansible コンテンツ (コレクション、モジュール、ロール、プラグインなど) に対応するための考慮事項が他にあります。

これらの考慮事項はこのリストに限定されませんが、次のものが含まれます。

  • 互換性のある実行環境で使用するには、Ansible Playbook を Ansible Engine 2.9.10 以降で実行する必要があります (必須)。
  • Playbook の Ansible コンテンツは、Ansible コレクションを利用する必要があります (必須ではありませんが、推奨されます)。
  • Playbook の Ansible コンテンツは、完全修飾コレクション名 (FQCN) を使用する必要があります (必須ではありませんが、推奨されます)。
  • Ansible Playbook は、localhost への参照に対応するように変更する必要があります。実行環境を使用する場合、これは Pod 自体を参照し、以前に行われたように基盤となるホストを参照するものではありません。
注記

Ansible コンテンツを正常に実行するために追加の依存関係が必要な場合は、ユーザーが作成した実行環境が必要になることがあります。

2.3. オペレーションモデルの考慮事項
リンクのコピー

新しい Ansible Automation Platform アーキテクチャーの導入に伴い、新たに設計された Ansible Automation Platform 環境を統合する方法について計画を立てることが重要です。

以下に挙げる主要な質問に対する回答を考慮します。

  • Ansible Automation Platform 2 を実行するには、組織でどのようなトレーニングとイネーブルメントが必要ですか?
  • 実行環境と Ansible コンテンツコレクションはどのように管理されますか?

  • 組織に最適な実行環境コンテナーのバージョン管理は何ですか?

    • 開発と実稼働環境に異なるモデルを使用しますか？
  • ユーザーが作成した実行環境が必要な場合、それらの環境をどのように管理および配布しますか?
  • 実行環境を中心に CI を構築する予定はありますか?
  • CVE にパッチを適用し、準拠を維持するためのセキュリティー対応計画はどのようなものですか?
  • Ansible Automation Platform クラスターはどのくらいの頻度でアップグレードしますか?

これらはほんの一例にすぎませんが、組織の戦略を確実に成功させるためには、このような質問に対する回答が極めて重要です。

第3章 前提条件
リンクのコピー

Ansible Automation Platform 2 へのサイドバイサイド移行およびアップグレードには、環境 A と 環境 B が必要です。環境 A は、図1.1「環境 A アーキテクチャーの概要」 に示されるように、メインのクラスターである必要があります。この環境は、以下で構成します。

  • ラーレーの NC データセンターにある Red Hat Enterprise Linux 7 を実行する Ansible Tower 3.8.5 ノード 3 つ
  • Red Hat Enterprise Linux 7 データベースノード 1 つ
  • bastion ホスト (対応する分離ノードにアクセスするためジャンプホスト) 2 つ
  • 分離ノード (サクラメントの CA データセンター) 2 つ
  • 分離ノード (インド、ニューデリーのデータセンター) 2 つ

まず、環境 B は、図1.2「初期環境 B アーキテクチャーの概要」 に示すように単純化された Ansible Automation Platform 1.2 アーキテクチャーです。Ansible Automation Platform 2 へのアップグレードプロセス中に、Red Hat Enterprise Linux 8.4 サーバーのプールでクラスターが拡張され、以下が含まれるようになります。

  • コントロールプレーンノードから直接アクセスできる実行ノード 2 つ
  • ホップノード 3 つ (sacramento-hop、dublin-hop new-delhi-hop)
  • ホップノード sacramento-hop 経由でのみアクセス可能な実行ノード 2 つ
  • ホップノード dublin-hop および new-delhi-hop を介してアクセス可能な実行ノード 2 つ

アップグレード後の最終的なクラスターのアーキテクチャーは、図1.4「拡張された環境 B アーキテクチャーの概要」 のようになります。

注記

これらのノードは、物理サーバーである必要はありません。

3.1. 環境仕様
リンクのコピー

Expand
表3.1 環境仕様

ノードタイプ

Control

実行

ホップ

Database

CPU

4

4

4

4

RAM

16

16

16

16

ディスク

40GB

40GB

40GB

150GB+

注記

  • イベントを処理し、プロジェクト更新およびクリーンアップジョブを含むクラスタージョブを実行します。CPU およびメモリーを増やすと、ジョブイベントの処理に役立ちます。
  • ファイルおよび作業ディレクトリーストレージボリュームの最小 20 GB を /var/' 専用にし、最低でも 1500 IOPS をベースラインとして調整する必要があります。
  • プロジェクトは、制御およびハイブリッドに保存され、ジョブの期間中も実行ノードに保存されます。クラスターに大規模なプロジェクトが多数ある場合は、ディスク領域のエラーを回避するために、/var/lib/awx/projects に 2 倍の GB を追加することを検討してください。
  • 自動化を実行します。メモリーと CPU を増やし、フォークを多く実行できるように容量を増加します。
  • Automation Mesh の別の部分にトラフィックをルーティングします (たとえば、bastion ホストを別のネットワークにすることもできます)。RAM はスループットに影響を与える可能性があり、CPU アクティビティーは低くなります。ネットワーク帯域幅およびレイテンシーは通常、RAM/CPU のいずれかよりも重要な要素です。
  • ストレージボリュームは、ベースライン IOPS を高くする (1500 以上) 必要があります。
  • /var/lib/pgsql ディレクトリーには追加のディスク容量が必要です。ベース OS パーティションを拡張できない場合は、ディスク容量エラーを回避するために、/var/lib/pgsql ディレクトリーに 150GB 以上を確保することを検討してください。
注記

すべての自動化コントローラーデータは PostgreSQL データベースに保存されます。データベースストレージは、マネージドホストの数、ジョブ実行数、ファクトキャッシュに保存されているファクトの数、および個別ジョブのタスク数と共に増加します。たとえば、ホスト 250 台で 1 時間ごと (1 日に 24 回) に 20 個のタスクの Playbook を実行する場合は、毎週 800,000 を超えるイベントを保存します。

データベースに十分な容量が確保されていない場合は、以前のジョブ実行やファクトを定期的に消去する必要があります。詳細は、Management Jobs を参照してください。

3.2. ネットワーク要件
リンクのコピー

Ansible Automation Platform 2 では、コントロールプレーンジョブを実行するために割り当てられた Automation controller インスタンスとメッシュワーカーノード間の直接ネットワーク接続が必要です。

注記

DMZ または分離されたネットワークの背後にある実行ノードにトラフィックをルーティングするホップノードの場合、Ansible Automation Platform クラスターは複数のネットワークにまたがることができます。ネットワーク管理者は、インストール目的ですべてのノードで ssh 接続が利用可能であることを確認する必要があります。このリファレンス環境では、ホップノードは ssh プロキシーとして機能し、それぞれの実行ノードに到達します。

Ansible Automation Platform ダッシュボードにアクセスするには、コントロールプレーンノードが存在するネットワークにアクセスできるブラウザーが必要です。Ansible Automation Platform ダッシュボードに外部からアクセスする場合は、コントロールプレーンノードにパブリック IP アドレスを追加してください。

ネットワーク管理者は、すべてのノードに専用の IP アドレスと適切な DNS レコードを提供することを推奨します。ネットワーク管理者は、静的 IP アドレスをノードに割り当て、DHCP サーバーを設定して、IP を無限リースで予約するか、割り当てられた IP アドレスが除外範囲の一部であることを確認する必要があります。これにより、DHCP サーバーがない場合でも、各ノードの IP アドレスが一定に保たれます。注記: このリファレンスアーキテクチャーの目的上、DHCP サーバーの設定、DNS レコードの設定、およびロードバランサーの設定は範囲外です。

注記

このリファレンスアーキテクチャーの目的上、DHCP サーバーの設定、DNS レコードの設定、およびロードバランサーの設定は範囲外です。

ネットワーク管理者は、少なくとも次の数の IP アドレスを予約する必要があります。

  1. コントロールプレーンノードごとに 1 つの IP アドレス。
  2. 実行ノードごとに 1 つの IP アドレス。
  3. ホップノードごとに 1 つの IP アドレス
  4. データベースノードに 1 つの IP アドレス

このリファレンス環境は、サイトごとに 13 の IP アドレスを予約します。

次の表に、リファレンス環境の 環境 B の例を示します。

Expand

使用方法

ホスト名

IP

Automation Controller 1

envb_controller1.example.com

192.168.0.10

Automation Controller 2

envb_controller2.example.com

192.168.0.11

Automation Controller 3

envb_controller3.example.com

192.168.0.12

コントロールプレーンデータベース

envb_database.example.com

192.168.0.13

実行ノード 1

envb_executionnode-1.example.com

192.168.0.14

実行ノード 2

envb_executionnode-2.example.com

192.168.0.15

ホップノード 1

envb_hopnode-sacramento.example.com

192.168.0.16

ホップノード 2

envb_hopnode-new-delhi.example.com

192.168.0.17

ホップノード 3

envb_hopnode-dublin.example.com

192.168.0.18

実行ノード 3

envb_executionnode-3.example.com

10.14.1.11

実行ノード 4

envb_executionnode-4.example.com

10.14.1.12

実行ノード 5

envb_executionnode-5.example.com

10.15.1.11

実行ノード 6

envb_executionnode-6.example.com

10.15.1.12

3.3. ノードの検証チェックリスト
リンクのコピー

以下は、すべての要件の要約です。

  • ❏ コントローラーノード、データベースノード、実行ノード、およびホップノード用に 16 GB のメモリー
  • ❏ コントローラーノード、データベースノード、実行ノード、およびホップノード用の 4 つの CPU
  • ❏ データベースノード用に 150 GB 以上のディスク容量
  • ❏ データベースノード以外のノード用に 40 GB 以上のディスク容量
  • ❏ DHCP 予約では、無限リースを使用して、静的 IP アドレスを持つクラスターをデプロイメント。
  • ❏ すべてのノードの DNS レコード
  • ❏ すべてのノードで Red Hat Enterprise Linux {rhel_version} 以降 64 ビット (x86) がインストール済み
  • ❏ すべてのノードに Chrony を設定済み
注記

ノード要件の詳細は、「環境仕様」 を参照してください。

3.4. Automation Controller 設定の詳細
リンクのコピー

このリファレンスアーキテクチャーは、Ansible Automation Platform 1.2 から Ansible Automation Platform 2 への移行およびアップグレードに重点を置いています。この設定は、包括的な Ansible Automation Platform ソリューションを提供してサイドバイサイド移行シナリオを説明することを目的としています。このリファレンスアーキテクチャーでカバーされている主要なソリューションコンポーネントには、以下が含まれます。

  • Ansible Automation Platform 1.2
  • Ansible Automation Platform 2
  • Ansible Automation Platform インストーラー
  • カスタム Python 仮想環境移行用の Ansible Playbook

3.4.1. OS 設定
リンクのコピー

3.4.1.1. Chrony 設定
リンクのコピー

クラスター内の各 Ansible Automation Platform ノードは NTP サーバーにアクセスできる必要があります。chronyd は、システムクロックを同期するためのデーモンです。クロックを NTP サーバーと同期できます。これにより、クラスターノードが検証を必要とする SSL 証明書を使用する場合、ノード間の日付と時刻が同期していなくても失敗しません。

Ansible Automation Platform クラスターの拡張に使用される 環境 B のすべてのノードで以下を実行します。

  1. インストールされていない場合は、次のように chrony をインストールします。 

    # dnf install chrony --assumeyes
    Copy to Clipboard Toggle word wrap

  2. vi などのテキストエディターで /etc/chrony.conf ファイルを編集します。 

    # vi /etc/chrony.conf
    Copy to Clipboard Toggle word wrap

  3. 次のパブリックサーバープールセクションを見つけ、適切なサーバーを含めるように変更します。必要なサーバーは 1 つだけですが、3 つを推奨します。サーバーと適切に同期するのにかかる時間を短縮するために、iburst オプションが追加されました。 

    # Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server <ntp-server-address> iburst
    Copy to Clipboard Toggle word wrap
  4. /etc/chrony.conf ファイル内にすべての変更を保存します。

  5. ホストの起動時に chronyd デーモンが起動するように起動して有効にします。 

    # systemctl --now enable chronyd.service
    Copy to Clipboard Toggle word wrap

  6. chronyd デーモンのステータスを確認します。 

    # systemctl status chronyd.service
    Copy to Clipboard Toggle word wrap
3.4.1.2. Red Hat Subscription Manager
リンクのコピー

subscription-manager コマンドは、システムを Red Hat Network (RHN) に登録し、システムのサブスクリプションエンタイトルメントを管理します。--help オプションは、コマンドラインで使用可能なオプションをコマンドにクエリーするように指定します。--help オプションがコマンドディレクティブとともに発行された場合、特定のコマンドディレクティブで使用可能なオプションがリスト表示されます。

Red Hat Subscription Management を使用してシステムにパッケージを提供するには、最初にシステムをサービスに登録する必要があります。システムを登録するには、subscription-manager コマンドを使用して、register コマンドディレクティブを渡します。--username および --password オプションが指定されている場合、コマンドは RHN ネットワーク認証情報の入力を求めません。

以下に、subscription-manager を使用してシステムを登録する例を示します。

注記

Ansible Automation Platform クラスターの拡張に使用するノードを含め、環境 B 内のすべてのノードで以下を実行する必要があります。 

# subscription-manager register --username [User] --password '[Password]'
The system has been registered with id: abcd1234-ab12-ab12-ab12-481ba8187f60
Copy to Clipboard Toggle word wrap

システムを登録したら、エンタイトルメントプールに接続する必要があります。このリファレンス環境の目的上、Red Hat Ansible Automation Platform は選択されたプールになります。Red Hat Ansible Automation Platform エンタイトルメントプールを特定してサブスクライブします。次のコマンドディレクティブが必要です。 

# subscription-manager list --available | grep -A8 "Red Hat Ansible Automation Platform"
---
Subscription Name:   Red Hat Ansible Automation Platform, Premium (5000 Managed Nodes)
Provides:            Red Hat Ansible Engine
                     Red Hat Single Sign-On
                     Red Hat Ansible Automation Platform
SKU:                 MCT3695
Contract:            <contract>
Pool ID:             <pool_id>
Provides Management: No
Available:           9990
Suggested:           1
Service Type:        L1-L3
Roles:
Copy to Clipboard Toggle word wrap 
# subscription-manager attach --pool <pool_id>
Successfully attached a subscription for: Red Hat Ansible Automation Platform, Premium (5000 Managed Nodes)
Copy to Clipboard Toggle word wrap 
# subscription-manager repos --enable=ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms
Copy to Clipboard Toggle word wrap
注記

Ansible Automation Platform サブスクリプションの一部として、Automation controller、Private Automation Hub、およびその他の Ansible Automation Platform コンポーネントに RHEL を利用するために、10 個の Red Hat Enterprise Linux (RHEL) サブスクリプションを利用できます。

3.4.1.3. ユーザーアカウント
リンクのコピー

Ansible Automation Platform 2 をインストールする前に、デプロイメントプロセスの sudo 権限を持つ非 root ユーザーを作成することを推奨します。このユーザーは以下で使用されます。

  • SSH 接続
  • インストール時中のパスワードレス認証
  • 特権昇格 (sudo) 権限

このリファレンス環境の目的上、ユーザー ansible が選択されていますが、任意のユーザー名を使用できます。

Ansible Automation Platform クラスター拡張に使用するノードなど、環境 B の すべて のノードで、ansible という名前のユーザーを作成し、ssh キーを生成します。

  1. 非 root ユーザーを作成します。 

    # useradd ansible
    Copy to Clipboard Toggle word wrap

  2. ansible ユーザーのパスワードを設定します。 

    # passwd ansible
    Copy to Clipboard Toggle word wrap

  3. ansible ユーザーとして ssh キーを生成します。 

    $ ssh-keygen -t rsa
    Copy to Clipboard Toggle word wrap

  4. ansible ユーザーとして sudo を使用する場合は、パスワード要件を無効にします。 

    # echo "ansible ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/ansible
    Copy to Clipboard Toggle word wrap
3.4.1.4. SSH キーをすべてのノードにコピー
リンクのコピー

ansible ユーザーを作成したら、ansible ユーザーとして、Ansible Automation Platform クラスターの拡張に使用するノードを含む 環境 B のすべてのノードに ssh キーをコピーします。これにより、Ansible Automation Platform のインストールが実行されたときに、パスワードなしですべてのノードへの ssh が可能になります。

これは、次のように ssh-copy-id コマンドを使用して実行できます。 

$ ssh-copy-id ansible@hostname.example.com
Copy to Clipboard Toggle word wrap
注記

クラウドプロバイダー内で実行している場合は、代わりに、すべてのノードに ansible ユーザーの公開鍵を含む ~/.ssh/authorized_keys ファイルを作成し、authorized_keys ファイルへのパーミッションとして、所有者 (ansible) だけに読み取りおよび書き込みの権限 (パーミッション 600) を設定する必要があります。

3.4.1.5. ファイアウォールの設定
リンクのコピー

ファイアウォールへのアクセスと制限は、Ansible Automation Platform 2 環境のセキュリティーを保護する上で重要な役割を果たします。Red Hat Enterprise Linux {rhel_version} を使用すると、デフォルトで動的ファイアウォールデーモンである firewalld が使用されます。firewalld は、ネットワークゾーンを割り当てて、ネットワークとそれに関連する接続およびインターフェイスに信頼レベルを割り当てることによって機能します。

Ansible Automation Platform 2 のインストールを成功させるために、適切なサービスとポートへのアクセスを許可するようにファイアウォール設定を設定することを推奨します。

Ansible Automation Platform クラスター拡張に使用されるノードを含む、環境 B 内の すべて のノードで、firewalld がインストールされ、起動され、有効になっていることを確認します。

  1. firewalld パッケージをインストールします。 

    # dnf install firewalld --assumeyes
    Copy to Clipboard Toggle word wrap

  2. firewalld サービスを開始します。 

    # systemctl start firewalld
    Copy to Clipboard Toggle word wrap

  3. Firewalld サービスを有効にします。 

    # systemctl enable firewalld
    Copy to Clipboard Toggle word wrap

3.5. Ansible Automation Platform 設定の詳細
リンクのコピー

3.5.1. 実行ノードとホップノードのファイアウォール設定
リンクのコピー

Ansible Automation Platform を 2 に正常にアップグレードするための前提条件の 1 つとして、メッシュノード (実行およびホップノード) で自動化メッシュポートを有効にすることが挙げられます。すべてのノードのメッシュネットワークに使用されるデフォルトポートは 27199/tcp に設定されていますが、インベントリーファイル 内の各ノードの変数として receptor_listener_port を指定することで、別のポートを使用するように設定することもできます。インベントリーファイルの変更に関する詳細は、「環境 B の Ansible Automation Platform 2 へのアップグレード」 を参照してください。

注記

このリファレンス環境では、すべての Ansible Automation Platform 2 コントローラーノードはノードタイプの制御として指定されます。コントロールノードがハイブリッドノード (デフォルトのノードタイプ) として指定されている場合、メッシュポート (デフォルト: 27199/tcp) を有効にする必要があります。

ホップおよび実行ノード内で、ansible ユーザーとして、インストールに使用する firewalld ポートを設定します。

  1. firewalld が実行されていることを確認します。 

    $ sudo systemctl status firewalld
    Copy to Clipboard Toggle word wrap

  2. コントローラーデータベースノードに firewalld ポートを追加します (例: ポート 27199)。 

    $ sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp
    Copy to Clipboard Toggle word wrap

  3. firewalld をリロードします。 

    $ sudo firewall-cmd --reload
    Copy to Clipboard Toggle word wrap

  4. ポートが開いていることを確認します。 

    $ sudo firewall-cmd --list-ports
    Copy to Clipboard Toggle word wrap

第4章 インフラストラクチャーの移行
リンクのコピー

Ansible Automation Platform 1.2 から Ansible Automation Platform 2 への移行を成功させるために、このリファレンス環境は Ansible Automation Platform インストーラーの機能を利用します。

Ansible Automation Platform インストーラーを使用すると、簡単なコマンドをいくつか使用して、最新の Ansible Automation Platform 2 にバックアップ、インポート、およびアップグレードできるようになります。

以下のセクションでは、そのプロセスのステップを説明します。

4.1. 環境 Aでの Ansible Automation Platform 1.2 のバックアップ
リンクのコピー

環境 A の Ansible Automation Platform 1.2 環境にはすべてのデータが含まれているため、以下は 環境 A の Ansible Automation Platform インストーラーを使用してバックアップを作成します。

警告

バックアップを作成する前に、現在実行中のジョブや実行予定のジョブがないことを確認してください。バックアップ後に収集されたデータはすべて 失われます。

環境 A 内で、以下を実行します。

  1. ansible ユーザーとしてログインします。 

    $ ssh ansible@enva_controller1.example.com
    Copy to Clipboard Toggle word wrap
    注記

    このリファレンス環境では、Ansible Automation Platform インストーラーディレクトリーおよびバイナリーを含むホストとして enva_controller1 を使用します。

  2. ansible-tower-setup-3.8.5-X ディレクトリーに移動します。 

    $ cd /path/to/ansible-tower-setup-3.8.5-X
    Copy to Clipboard Toggle word wrap

  3. Ansible Automation Platform インストーラーを実行してバックアップを作成します。

    1. backup_dest は、Ansible Automation Platform データベースのバックアップを保存する場所を提供します。
    2. use_compression は、Ansible Automation Platform データベースバックアップのサイズを縮小します。
    3. @credentials.yml は、ansible-vaultで暗号化されたパスワード変数とそれらの値を渡します。
    4. --ask-vault-pass は、暗号化された credentials.yml ファイルへのアクセスに使用されるパスワードを要求します。

    5. -b は、バックアップ作成オプションを True に設定します。 

      $ ./setup.sh -e 'backup_dest=<mount_point>' -e 'use_compression=True' -e @credentials.yml -b
      Copy to Clipboard Toggle word wrap
注記

この参照環境は、暗号化された認証情報を利用しており、プレーンテキストのパスワードは含まれていません。詳細は、付録C 暗号化された credentials.yml ファイルの作成ansible-vault を使用して認証情報を暗号化する方法について説明しています。

注記

バックアッププロセスが完了するまでに時間がかかる場合があります。

4.2. 環境 Bへの Ansible Automation Platform 1.2 データベースのインポート
リンクのコピー

環境 A からのバックアップが作成されて利用可能になったら、以下は、環境 B の Ansible Automation Platform インストーラーを使用して、バックアップされた Ansible Automation Platform データベースをインポートします。

環境 B 内で、以下を実行します。

  1. ansible ユーザーとしてログインします。 

    $ ssh ansible@envb_controller1.example.com
    Copy to Clipboard Toggle word wrap
    注記

    このリファレンス環境では、Ansible Automation Platform インストーラーディレクトリーおよびバイナリーを含むホストとして envb_controller1 を使用します。

  2. ansible-tower-setup-3.8.5-X ディレクトリーに移動します。 

    $ cd /path/to/ansible-tower-setup-3.8.5-X
    Copy to Clipboard Toggle word wrap

  3. Ansible Automation Platform インストーラーを実行して Ansible Automation Platform データベースをインポートします。

    1. restore_backup_file は、バックアップされた Ansible Automation Platform データベースの場所を指定します。
    2. バックアッププロセス中に圧縮が使用されているため、use_compression は True に設定されています

    3. -r は復元データベースのオプションを True に設定します。 

      $ ./setup.sh -e ‘restore_backup_file=<mount_point>/tower-backup-latest.tar.gz -e ‘use_compression=True’ -e @credentials.yml -r -- --ask-vault-pass
      Copy to Clipboard Toggle word wrap
注記

この参照環境は、暗号化された認証情報を利用しており、プレーンテキストのパスワードは含まれていません。詳細は、付録C 暗号化された credentials.yml ファイルの作成ansible-vault を使用して認証情報を暗号化する方法について説明しています。

注記

インポートプロセスの完了には時間がかかる場合があります。

4.3. 環境 B の Ansible Automation Platform 2 へのアップグレード
リンクのコピー

Ansible Automation Platform データベースのインポートに成功すると、移行プロセスの最終ステップとして、環境 B Ansible Automation Platform 1.2 環境を Ansible Automation Platform 2 にアップグレードし、図1.4「拡張された環境 B アーキテクチャーの概要」 に示されるように 環境 B のアーキテクチャーを展開します。

環境 B 内で、以下を実行します。

  1. ansible ユーザーとしてログインします。 

    $ ssh ansible@envb_controller1.example.com
    Copy to Clipboard Toggle word wrap
    注記

    このリファレンス環境では、Ansible Automation Platform インストーラーディレクトリーおよびバイナリーを含むホストとして envb_controller1 を使用します。

  2. Ansible Automation Platform 2.1.1 セットアップ tar ansible-automation-platform-setup-2.1.1-1.tar.gz をダウンロードします。

    注記

    非接続インストールの場合は、Ansible Automation Platform 2.1.1 Setup Bundle をダウンロードします。

  3. ansible-automation-platform-setup-2.1.1-1.tar.gz を展開します。 

    $ tar zxvf ansible-automation-platform-setup-2.1.1-1.tar.gz
    Copy to Clipboard Toggle word wrap

  4. ansible-automation-platform-setup-2.1.1-1 のディレクトリーに移動します。 

    $ cd ansible-automation-platform-setup-2.1.1-1/
    Copy to Clipboard Toggle word wrap

  5. Ansible Automation Platform 1.2 インベントリーファイルを ansible-automation-platform-setup-2.1.1-1 ディレクトリーにコピーします。 

    $ cp /path/to/ansible-tower-setup-3.8.5-X/inventory .
    Copy to Clipboard Toggle word wrap

  6. Ansible Automation Platform インストーラーを使用してコピーされた Ansible Automation Platform 1.2 インベントリーファイルで Ansible Automation Platform 2 インストールインベントリー案を生成します。 

    $ ./setup.sh
    Copy to Clipboard Toggle word wrap
    注記

    ansible-core がまだインストールされていない場合は、このプロセス中にインストールされます。

    警告

    inventory.new.ini 案を作成すると、Ansible Automation Platform インストーラーがプロセスの初期段階で失敗することが予想されます。

    想定されるエラータスクは以下のようになります。 

    TASK [ansible.automation_platform_installer.check_config_static : Detect pre-2.x inventory and offer a migration] ***
fatal: [172.16.58.48 -> localhost]: FAILED! => {"changed": false, "msg": "The installer has detected that you are using an inventory format from a version prior to 4.0. We have created an example inventory based on your old style inventory. Please check the file `/home/ansible/aap_install-2.1.1/ansible-automation-platform-setup-bundle-2.1.1-2/inventory.new.ini` and make necessary adjustments so that the file can be used by the installer."}
    Copy to Clipboard Toggle word wrap

    inventory.new.ini

    [all:vars]
pg_host='10.0.188.133'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_sslmode='prefer'
ansible_become='true'
ansible_user='ansible'
tower_package_name='automation-controller'
tower_package_version='4.1.1'
automationhub_package_name='automation-hub'
automationhub_package_version='4.4.1'
automation_platform_version='2.1.1'
automation_platform_channel='ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms'
minimum_ansible_version='2.11'

# In AAP 2.X [tower] has been renamed to [automationcontroller]
# Nodes in [automationcontroller] will be hybrid by default, capable of executing user jobs.
# To specify that any of these nodes should be control-only instead, give them a host var of `node_type=control`

[automationcontroller]
envb_controller1.example.com
envb_controller2.example.com
envb_controller3.example.com

[database]
envb_database.example.com
    Copy to Clipboard Toggle word wrap

    注記

    パスワードをプレーンテキストで保存することは推奨されないため、変数 admin_password、pg_password、および registry_password は inventory.new.ini ファイルの一部ではありません。代わりに、暗号化された credentials.yml ファイルが使用されます。

  7. inventory.new.ini が作成されたら、ファイルを変更して、ホップノードと実行ノードを含む 環境 B の拡張アーキテクチャーを含めます。

    拡張れた 環境 B の inventory.new.ini

    [all:vars]
pg_host='envb_database.example.com'
pg_port='5432'
pg_database='awx'
pg_username='awx'
pg_sslmode='prefer'
ansible_become='true'
ansible_user='ansible'
tower_package_name='automation-controller'
tower_package_version='4.1.1'
automationhub_package_name='automation-hub'
automationhub_package_version='4.4.1'
automation_platform_version='2.1.1'
automation_platform_channel='ansible-automation-platform-2.1-for-rhel-8-x86_64-rpms'
minimum_ansible_version='2.11'
registry_url='registry.redhat.io'
    1 
    
registry_username='myusername'
    2 
    

# In AAP 2.X [tower] has been renamed to [automationcontroller]
# Nodes in [automationcontroller] will be hybrid by default, capable of executing user jobs.
# To specify that any of these nodes should be control-only instead, give them a host var of `node_type=control`

[automationcontroller]
envb_controller1.example.com
envb_controller2.example.com
envb_controller3.example.com

[database]
envb_database.example.com

[automationcontroller:vars]
node_type=control
    3 
    
peers=envb_datacenter_execution_nodes,envb_datacenter_hop_nodes
    4 
    

[execution_nodes]
envb_executionnode-1.example.com
envb_executionnode-2.example.com
envb_hopnnode-sacramento.example.com node_type=hop peers=sacramento_execution_nodes
    5 
    
envb_hopnode-new-delhi.example.com node_type=hop peers=new-delhi_execution_nodes
envb_hopnode-dublin.example.com node_type=hop peers=env_hopnode-new-delhi.example.com
envb_executionnode-3.example.com
envb_executionnode-4.example.com
envb_executionnode-5.example.com
envb_executionnode-6.example.com

[envb_datacenter_execution_nodes]
    6 
    
envb_executionnode-1.example.com
envb_executionnode-2.example.com

[envb_datacenter_hop_nodes]
    7 
    
envb_hopnnode-sacramento.example.com
envb_hopnode-new-delhi.example.com
envb_hopnode-dublin.example.com

[sacramento_execution_nodes]
    8 
    
envb_executionnode-3.example.com
envb_executionnode-4.example.com

[new-delhi_execution_nodes]
    9 
    
envb_executionnode-5.example.com
envb_executionnode-6.example.com
    Copy to Clipboard Toggle word wrap

    1
    実行環境イメージがダウンロードされ、インストールに含まれます。イメージをダウンロードするには適切な認証情報が必要です。
    2
    registry_url にアクセスするためのユーザー認証情報。
    3
    コントロールノードは、プロジェクトおよびインベントリーの更新およびシステムジョブを実行しますが、実行ジョブは実行しません。これらのノードでは実行機能は無効になります。
    4
    実行ノード間のピア関係の設定。
    5
    ホップノードと実行ノード間のノードタイプとピア関係の設定
    6
    自動化コントローラーノードへの直接接続アクセスのある実行ノードのグループ。
    7
    対応する実行ノードにトラフィックをルーティングするホップノードのグループ。
    8
    envb_hopnode-sacramento.example.com 経由でアクセス可能な実行ノードのグループ。
    9
    envb_hopnode-new-delhi.example.com 経由でアクセス可能な実行ノードのグループ。

  8. 次のオプションを指定して setup.sh を実行し、Ansible Automation Platform 2 にアップグレードします。 

    $ ./setup.sh -i inventory.new.ini -e @credentials.yml -- --ask-vault-pass
    Copy to Clipboard Toggle word wrap

  9. Ansible Automation Platform ダッシュボード UI がすべての Automation Controller ノードからアクセスできることを確認します。

    注記

    Automation controller のいずれかを介して Ansible Automation Platform ダッシュボードにアクセスするときに 502 エラーまたはセキュア接続に失敗した場合は、次のいずれかまたは両方の問題が原因である可能性があります。

    • 証明書の不一致
    • nginxの SELinux コンテキストが誤っている

    付録D アップグレード後の Playbook では、これらの問題を修正するための回避策を説明します。現在、修正が実装されており、今後のドットリリースで修正される予定です。

    証明書の不一致についての問題は、Ansible Automation Platform のバージョン 2.1.2 以降で修正されています。nginx の SELinux コンテキストが正しくない場合は、回避策の Ansible Playbook が必要です。詳細は、付録D アップグレード後の Playbook を参照してください。

このリファレンス環境は、* admin_password * registry_password * pg_password の変数に credentials.yml を使用します。

インベントリーファイルに設定できるさまざまな値の詳細は、インベントリーファイルの設定 を参照してください。

4.4. インスタンスおよびインスタンスグループの設定
リンクのコピー

アップグレードプロセスが完了したら、対応するインスタンスグループ (sacramento や new-delhi など) に、インスタンスを関連付ける必要があります。

  1. Administration→Instance Groupsを選択します。
  2. sacramento インスタンスグループをクリックします。
  3. Instances タブを選択します。
  4. 青い 割り当て ボタンをクリックします

  5. インスタンスの 選択 ウィンドウで、以下を選択します。

    1. envb_executionnode-3.example.com
    2. envb_executionnode-4.example.com
  6. Save をクリックします。

new-delhi インスタンスグループのプロセスを繰り返し、以下のインスタンスを new-delhi インスタンスグループに関連付けます。

  • envb_executionnode-5.example.com
  • envb_executionnode-6.example.com

完了したら、default グループ内のインスタンスの関連付けを解除します。

  1. Administration→Instance Groupsを選択します。
  2. default インスタンスグループをクリックします。
  3. Instances タブを選択します。

  4. 以下のインスタンスのチェックボックスを選択します。

    1. envb_executionnode-3.example.com
    2. envb_executionnode-4.example.com
    3. envb_executionnode-5.example.com
    4. envb_executionnode-6.example.com
  5. Disassociateというラベルの付いた青いボタンをクリックします。
  6. 赤い Disassociate ボタンで、関連付けが解除されていることを確認します。

default インスタンスグループには、以下のインスタンスだけを含める必要があります。

  • envb_executionnode-1.example.com
  • envb_executionnode-2.example.com

インフラストラクチャーの移行が完了すると、Python 仮想環境をユーザーが構築した実行環境に移行することに焦点が切り替わります。

第5章 仮想環境の実行環境への移行
リンクのコピー

Ansible Automation Platform 2 には、自動化コントロールプレーンと実行プレーンを完全に分離する、再考されたアーキテクチャーが付属しています。この新機能を使用すると、globe 全体で自動化を簡単にスケーリングでき、単一のデータセンターで自動化の実行にバインドされずに、できるだけソースに近いように自動化を実行できます。Ansible Automation Platform 1.2 と比較して、より動的、スケーラビリティー、回復性があり、柔軟性があります。

自動化実行環境の導入により、これらのコンテナーイメージは、Ansible Core、Ansible Content Collections、Python 依存関係、Red Hat Enterprise Linux UBI 8、および追加のパッケージ依存関係などの主要コンポーネントを含め、パッケージ化して実行するために必要なすべての自動化を可能にします。

この章では、Ansible Automation Platform 1.2 クラスター内のカスタム Python 仮想環境を、ユーザーが構築した自動化実行環境に移行することに焦点を当てます。

この 1 回限りの作業により、最新の Ansible Automation Platform 2 機能と、より少ない長期メンテナンスで複数のプラットフォームにわたって一貫した自動化を実行する機能を活用するための扉が開かれます。

警告

ユーザーが構築した実行環境にアクセスするには、それらが Private Automation Hub またはコンテナーレジストリー内でホストされている必要があります。Private Automation Hub のインストール方法の詳細については Ansible Automation Platform 2.1 リファレンスアーキテクチャーのデプロイ を参照してください。

5.1. 仮想環境から実行環境への移行の自動化
リンクのコピー

Ansible コマンドを実行するだけでプロセスを自動化する補助的な Ansible Playbook を含めることで、簡素化しています。

すべてを行うには、以下の手動のプロセスを実行します。

  1. Ansible Automation Platform 1.2 環境にカスタム Python 仮想環境を備える
  2. Python 仮想環境のカスタムリストを取得するための awx-manage コマンドラインユーティリティーを使用する
  3. 各 Python 仮想環境で awx-manage export_custom_venv コマンドを実行して、インストールされている Python パッケージのリストを取得する
  4. awx-manage custom_venv_associations コマンドを使用して Python 仮想環境の関連付けを確認する
  5. ansible-builder ツールを使用して上記の情報をフィルタリングして実行環境を作成する

自動プロセスは、以下で構成されます。

  1. Ansible Automation Platform 1.2 環境にある各カスタム Python 仮想環境からパッケージの一覧を取得する
  2. 前のステップのパッケージリストを Ansible-2.9 のパッケージリストと比較する。[1] ベースの Ansible-2.9 実行環境に存在しないパッケージを見つける
  3. Ansible-2.9 実行環境をベースとして使用し、前のステップのリストから不足している依存関係を含む新しいカスタム実行環境を作成する

シナリオがどのように実行されるかを確認するには、以下の例を試してみます。

既存の Ansible Automation Platform 1.2 には、custom-venv1 および custom-venv2 という ラベルの付いた 2 つのカスタム Python 仮想環境があります。

redhat_cop.ee_utilities コレクション にパッケージ化されたロール virtualenv_migrate を使用して、Ansible Tower ノードへの ssh アクセスを介して Ansible Automation Platform 1.2 環境に対して実行し、(Ansible 2.9 実行環境) と比較する現在のベース実行環境の一部ではないパッケージとそのバージョンを抽出します。

注記

redhat_cop.ee_utilities コレクションはコミュニティープロジェクトで、Red Hat では正式にサポートされていません。

それぞれの環境の Playbook およびインベントリーファイルのサンプルを以下に示します。

playbook.yml

---
- name: Review custom virtualenvs and pull requirements
  hosts: enva_tower
  become: true
  tasks:
    - name: Include venv role
      include_role:
        name: redhat_cop.ee_utilities.virtualenv_migrate
Copy to Clipboard Toggle word wrap

Inventory

[tower]
ansibletower.example.com
ansible_ssh_private_key_file=/path/to/example.pem


[all:vars]
###############################################################################
# Required configuration variables for migration from venv -> EE              #
###############################################################################

# The default URL location to the execution environment (Default Ansible 2.9)
# If you want to use the newest Ansible base, change to: ee-minimal-rhel8:latest
venv_migrate_default_ee_url="registry.redhat.io/ansible-automation-platform-21/ee-29-rhel8:latest"

# User credential for access to venv_migrate_default_ee_url
registry_username='myusername'
Copy to Clipboard Toggle word wrap

注記
  • ssh に必要なユーザーをもとに ansible_user=<ANSIBLE_USER> を Ansible Tower ノードに追加します。
  • この参照環境は、暗号化された認証情報を利用しており、プレーンテキストのパスワードは含まれていません。付録C 暗号化された credentials.yml ファイルの作成 の詳細は、ansible-vault を使用してレジストリーの認証情報を暗号化する方法を参照してください。暗号化された credentials.yml ファイルは、registry_passwordを指定するために使用されます。
警告

このロールには、podman コマンドを実行するために sudo 権限が必要です。

Ansible Playbook のサンプル出力は、各カスタム Python 仮想環境に必要な追加パッケージのリストを示しています。この場合、custom-venv1 Python 仮想環境には、Ansible 2.9 実行環境にすでに含まれているものに加えて、次のパッケージが必要であることがわかります。

  • certifi
  • charset-normalizer
  • enum34
  • future
  • solidfire-sdk-python

custom-venv2 Python 仮想環境には、標準の Ansible-2.9 実行環境に含まれるものに加えて、zabbix-api のみが必要でした。

注記

Ansible 2.9 実行環境は、ほとんどの Ansible Automation Platform 1.2 環境が Ansible 2.9 を使用しているため、カスタム Python 仮想環境との比較に使用されます。こうすることで、後方互換性があるので移行が容易になります。 

TASK [redhat_cop.tower_utilities.virtualenv_migrate : diff | Show the packages that are extra from default EEs in custom venvs.] ******************************************************************************
ok: [3.228.23.40 -> localhost] => {
    "msg": [
        {
            "/opt/my-envs/custom-venv1/": [
                "certifi",
                "charset-normalizer",
                "enum34",
                "future",
                "solidfire-sdk-python"
            ]
        },
        {
            "/opt/my-envs/custom-venv2/": [
                "zabbix-api"
            ]
        }
    ]
}
Copy to Clipboard Toggle word wrap

カスタム Python 仮想環境ごとにパッケージがキャプチャーされると、Ansible Playbook は、ローカルユーザー環境での実行環境の作成を自動化する redhat_cop.ee_utilities コレクション の一部である ee_builder ロールを使用します。

提供された Ansible Playbook を実行する前に、ローカルホストマシンに ansible-builder をインストールします。Playbook の実行により、カスタム Python 仮想環境と提供されたベース実行環境の間のパッケージの差異をもとに、ローカルマシン上に実行環境が作成されます。 

$ podman images

REPOSITORY                           TAG                IMAGE ID
localhost/custom-venv2               latest             c017418d1919
localhost/custom-venv1               latest             7cbe3b49974d
localhost/custom-venv                latest             9d5d809f38b0
Copy to Clipboard Toggle word wrap

5.1.1. Private Automation Hub へのプッシュ
リンクのコピー

ローカル実行環境が整ったら、次の方法でそれらを Private Automation Hub にプッシュできます。

注記

この参照アーキテクチャーでは、自動化実行環境の名前をカスタム Python 仮想環境の名前のままにし、簡素化しています。名前に変更が必要な場合は、実行環境を Private Automation Hub または選択したコンテナーレジストリーにプッシュする前に podman tag コマンドを使用します。 

$ podman login [automation-hub-url]
# Enter the username and password to access Private Automation Hub.
$ podman tag [image-id] [automation-hub-url]/[container image name]
$ podman push [automation-hub-url]/[container image name]
Copy to Clipboard Toggle word wrap
ヒント

詳細は、Private Automation Hub でのコンテナーの管理 を参照してください。

この作業が完了したら、コントローラーユーザーインターフェース内に Private Automation Hub のレジストリー認証情報を作成して、実行環境を Automation Controller に同期します。

Automation controller 内でレジストリー認証情報を作成するには、次のようにします。

  1. Resources→Credentials を選択します。
  2. Credentials 内で青い Add ボタンを選択します。

  3. Create New Credentials ウィンドウで、以下を実行します。

    1. Name を指定します(例: My private automation hub credentials)。
    2. Credential Type でドロップダウンを選択し、Container Registry を選択します。

    3. Type Details で以下を実行します。

      1. 認証 URL (例: pah.example.com) を指定します。
      2. Username フィールドに Private Automation Hub のユーザー名を入力します
      3. パスワードまたは トークン フィールドに Private Automation Hub のパスワードまたはトークンを入力します。
      4. Private Automation Hub 環境が SSL に対応している場合は、Verify SSL を選択します。
  4. Save をクリックします。

Automation controller 内で実行環境を使用できるようにするには、Private Automation Hub からイメージをプルする新しい実行環境を作成します。

Automation Controller 内で以下を実行します。

  1. Administration →Execution Environments を選択します。
  2. Execution Environments 内で、青色の Add ボタンを選択します

  3. Create new execution environment ウィンドウで、以下を実行します。

    1. Name (例: my execution environment) を指定します。
    2. 実行環境のイメージの場所 (例: repo/project/image-name:tag) を指定します。

    3. Registry credential の虫眼鏡を選択します。

      1. Private Automation Hub 認証情報など、Private Automation Hub の認証情報のラジオボタンをクリックします。

Automation controller 内で実行環境が使用可能になったため、既存のジョブテンプレートまたは新しく作成されたジョブテンプレートに対して使用できます。

ヒント

後方互換性を確保する必要がないユーザーが構築する実行環境を新たに作成する場合には、ee-minimal の実行環境を、基盤の実行環境として使用し、新しいイメージを構築することを推奨します。


[1] この参照アーキテクチャーは、Ansible Automation Platform 1.2 の実行プレーン環境とよく似た環境を作成するためにansible-2.9 実行環境を使用しています。

付録A 著者について
リンクのコピー

anshul
View larger image
anshul
roger
View larger image
roger

付録B コントリビューター
リンクのコピー

多くの時間を割いて、忍耐強くこのプロセスに協力してくださった次の方々に感謝申し上げます。その多大な貢献なしに、このドキュメントは実現しませんでした。

Expand
コントリビューター役職貢献内容

Julen Landa Alustiza

シニアソフトウェア品質エンジニア

テクニカルレビュー

Craig Brandt

プリンシパルテクニカルマーケティングマネージャー

コンテンツレビュー

付録C 暗号化された credentials.yml ファイルの作成
リンクのコピー

このセクションでは、Ansible Automation Platform インストーラーに渡される、暗号化された credentials.yml ファイルを作成する方法について説明します。

警告

使用するパスワードは、環境 A と 環境 B で同じでなければなりません。

最初の 環境 B Ansible Automation Platform 環境内で、以下を実行します。

  1. credentials.yml ファイルを作成し、暗号化された認証情報を保存します。 

    $ cat credentials.yml
    Copy to Clipboard Toggle word wrap 
    admin_password: my_long_admin_password
pg_password: my_long_pg_password
registry_password: my_long_registry_password
    Copy to Clipboard Toggle word wrap

  2. ansible-vaultを使用した credentials.yml ファイルの暗号化 

    $ ansible-vault encrypt credentials.yml
    Copy to Clipboard Toggle word wrap 
    New Vault password:
Confirm New Vault password:
Encryption successful
    Copy to Clipboard Toggle word wrap
    警告

    admin_password および pg_password 認証情報は、Ansible Automation Platform 1.2 環境 A で使用される値と一致する必要があります。

    警告

    暗号化された vault パスワードを安全な場所に保管します。

  3. credentials.yml ファイルが暗号化されていることを確認します。 

    $ cat credentials.yml
    Copy to Clipboard Toggle word wrap 
    $ANSIBLE_VAULT;1.1;AES256
36383639653562386534316333333961383336306465336465613831353435313530376464616539
3765393063303065323466663330646232363065316666310a373062303133376339633831303033
34313534383962613632303761636632623932653062343839613639653635643365616233313365
3636616639313864300a353239373433313339613465326339313035633565353464356538653631
63346434383534643237663862353361366632613634333231316334363939396461326561643336
3430633534303935646264633034383966336232303365383763
    Copy to Clipboard Toggle word wrap
注記

暗号化された認証情報の作成はオプションですが、インベントリーファイル内にパスワードをプレーンテキストで保存しないことを推奨します。

暗号化された認証情報をすでに使用している場合は、新規に作成する代わりに credentials.yml ファイルを使用します。

付録D アップグレード後の Playbook
リンクのコピー

このセクションでは、移行後にすべての Automation controller ノードで Automation controller UI にアクセスできない場合に、実行する必要がある Ansible Playbook を紹介します。この Playbook は、4章インフラストラクチャーの移行 セクションで説明されている SELinux コンテキストおよび証明書の不一致の問題に対応します。

以下の Ansible Playbook のコンテンツをコピーし、圧縮されていないインストーラーディレクトリー内の post_upgrade_playbook.yml というファイルに配置します。

注記

このディレクトリーはインストーラーインベントリーファイルで設定され、この Playbook はインストーラーインベントリーを使用して Automation controller ノードにいくつかの変更を加えます。

post_upgrade_playbook.yml

---
- name: Play to apply workaround to known issues in upgrade
  hosts: automationcontroller
  become: true
  tasks:
    - block:
      - name: Remove certs from all the controllers
        file:
          name: "{{ item }}"
          state: absent
        loop:
          - /etc/tower/tower.cert
          - /etc/tower/tower.key
      - name: Role to create new certs and copy to all controllers
        include_role:
          name: ansible.automation_platform_installer.nginx
      when:
        - automation_platform_version is version('2.1.1', '<=')
    - name: Add to targeted policy and apply selinux policy to controller dirs
      ansible.builtin.command: "{{ item }}"
      loop:
        - semodule -s targeted -i /usr/share/selinux/targeted/automation-controller.pp
        - /sbin/restorecon -R /var/lib/awx/venv /var/lib/awx/job_status /var/run/tower
    - name: Restart the controller service
      service:
        name: automation-controller
        state: restarted
Copy to Clipboard Toggle word wrap

コマンドを実行して、コントローラーノードで Playbook を実行します。 

$ ansible-playbook -i inventory.new.ini post_upgrade_playbook.yml
Copy to Clipboard Toggle word wrap

付録E Revision History
リンクのコピー

改訂履歴
改訂 1.1-02022-04-29Roger Lopez
  • Added NOTE within Overview regarding using same subscription manifest when migrating between versions of Ansible Automation Platform
改訂 1.0-02022-03-31Anshul Behl and Roger Lopez
  • Initial Release

法律上の通知
リンクのコピー

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る