6.2. 移行の準備
現在の Ansible Automation Platform デプロイメントを Ansible Automation Platform Operator に移行する前に、既存のデータをバックアップし、秘密鍵および postgresql 設定用の Kubernetes シークレットを作成する必要があります。
Automation Controller インスタンスと Automation Hub インスタンスの両方を移行する場合は、両方の 秘密鍵のシークレットの作成 と postgresql 設定シークレットの作成 の手順を繰り返してから、Ansible Automation Platform Operator へのデータの移行 に進んでください。
6.2.1. Ansible Automation Platform Operator への移行
前提条件
Ansible Automation Platform デプロイメントを Ansible Automation Platform Operator に移行するには、以下が必要です。
- 秘密鍵のシークレット
- Postgresql の設定
- 新しい OpenShift クラスターの namespace のロールベースアクセス制御
- 新しい OpenShift クラスターは、以前の PostgreSQL データベースに接続可能である必要があります。
Red Hat Ansible Automation Platform の初期インストールの前に、秘密鍵情報をインベントリーファイルに保存できます。秘密鍵を覚えていない場合や、インベントリーファイルを見つけられない場合は、Red Hat カスタマーポータルから Ansible サポート にお問い合わせください。
Ansible Automation Platform 2.4 からデータを移行する前に、損失防止のためにデータをバックアップする必要があります。
手順
- 現在のデプロイメントプロジェクトにログインします。
-
$ ./setup.sh -b
を実行して、現在のデータまたはデプロイメントのバックアップを作成します。
6.2.2. 秘密鍵のシークレットの作成
OpenShift Container Platform 上の Ansible Automation Platform Operator にデータを移行するには、秘密鍵を作成する必要があります。Automation Controller、Automation Hub、および Event-Driven Ansible を移行する場合は、初期インストール時にインベントリーファイルで定義された秘密鍵と一致する秘密鍵がそれぞれに必要です。そうしないと、移行されたデータが暗号化されたままになり、移行後に使用できなくなります。
カスタムリソースで対称暗号化秘密鍵を指定する際は、Automation Controller の場合、フィールドの名前は secret_key_name
であることに注意してください。Automation Hub および Event-Driven Ansible の場合、フィールドの名前は db_fields_encryption_secret
です。
Kubernetes シークレットでは、Automation Controller と Event-Driven Ansible は同じ stringData キー (secret_key
) を使用しますが、Automation Hub は異なるキー (database_fields.symmetric.key
) を使用します。
手順
- 以前のインストールで Ansible Automation Platform をデプロイするのに使用したインベントリーファイルで古い秘密鍵を見つけます。
秘密鍵の YAML ファイルを作成します。
--- apiVersion: v1 kind: Secret metadata: name: <controller-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: <content of /etc/tower/SECRET_KEY from old controller> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <eda-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: </etc/ansible-automation-platform/eda/SECRET_KEY> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <hub-resourcename>-secret-key namespace: <target-namespace> stringData: database_fields.symmetric.key: </etc/pulp/certs/database_fields.symmetric.key> type: Opaque
--- apiVersion: v1 kind: Secret metadata: name: <controller-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: <content of /etc/tower/SECRET_KEY from old controller> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <eda-resourcename>-secret-key namespace: <target-namespace> stringData: secret_key: </etc/ansible-automation-platform/eda/SECRET_KEY> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: <hub-resourcename>-secret-key namespace: <target-namespace> stringData: database_fields.symmetric.key: </etc/pulp/certs/database_fields.symmetric.key> type: Opaque
Copy to Clipboard Copied! 注記admin_password_secret
が指定されていない場合、Operator が<resourcename>-admin-password
という名前のシークレットで管理者パスワードを検索します。存在しない場合、Operator はパスワードを生成し、そのパスワードから<resourcename>-admin-password
という名前のシークレットを作成します。秘密鍵の YAML をクラスターに適用します。
oc apply -f <yaml-file>
oc apply -f <yaml-file>
Copy to Clipboard Copied!
6.2.3. postgresql 設定シークレットの作成
移行を成功させるには、既存のデプロイメントのデータベースへのアクセスを提供する必要があります。
手順
postgresql 設定シークレットの YAML ファイルを作成します。
apiVersion: v1 kind: Secret metadata: name: <resourcename>-old-postgres-configuration namespace: <target namespace> stringData: host: "<external ip or url resolvable by the cluster>" port: "<external port, this usually defaults to 5432>" database: "<desired database name>" username: "<username to connect as>" password: "<password to connect with>" type: Opaque
apiVersion: v1 kind: Secret metadata: name: <resourcename>-old-postgres-configuration namespace: <target namespace> stringData: host: "<external ip or url resolvable by the cluster>" port: "<external port, this usually defaults to 5432>" database: "<desired database name>" username: "<username to connect as>" password: "<password to connect with>" type: Opaque
Copy to Clipboard Copied! - postgresql 設定の yaml をクラスターに適用します。
oc apply -f <old-postgres-configuration.yml>
oc apply -f <old-postgres-configuration.yml>
6.2.4. ネットワーク接続の確認
データの移行を成功させるには、新しい Operator デプロイメントから以前のデプロイメントデータベースへのネットワーク接続があることを確認します。
前提条件
既存のデプロイメントのホストおよびポート情報を書き留めておきます。この情報は、conf.d ディレクトリーにある postgres.py ファイルにあります。
手順
新しいデプロイメントと古いデプロイメントのデータベース間の接続を確認するための YAML ファイルを作成します。
apiVersion: v1 kind: Pod metadata: name: dbchecker spec: containers: - name: dbchecker image: registry.redhat.io/rhel8/postgresql-13:latest command: ["sleep"] args: ["600"]
apiVersion: v1 kind: Pod metadata: name: dbchecker spec: containers: - name: dbchecker image: registry.redhat.io/rhel8/postgresql-13:latest command: ["sleep"] args: ["600"]
Copy to Clipboard Copied! 接続チェッカーの yaml ファイルを新規プロジェクトのデプロイメントに適用します。
oc project ansible-automation-platform oc apply -f connection_checker.yaml
oc project ansible-automation-platform oc apply -f connection_checker.yaml
Copy to Clipboard Copied! 接続チェッカー Pod が実行されていることを確認します。
oc get pods
oc get pods
Copy to Clipboard Copied! Pod シェルに接続します。
oc rsh dbchecker
oc rsh dbchecker
Copy to Clipboard Copied! Pod でシェルセッションが開いたら、新規プロジェクトが古いプロジェクトクラスターに接続できることを確認します。
pg_isready -h <old-host-address> -p <old-port-number> -U AutomationContoller
pg_isready -h <old-host-address> -p <old-port-number> -U AutomationContoller
Copy to Clipboard Copied! 例
<old-host-address>:<old-port-number> - accepting connections
<old-host-address>:<old-port-number> - accepting connections
Copy to Clipboard Copied!