日々の基本的な操作の有効化

OpenShift Console と Ansible Automation Platform の認証情報

OpenShift クラスターコンソールは {openshift_cluster_console_url}[こちら^] から利用できます。 ローカル管理者ログインには、以下の認証情報が利用できます:

  • ユーザー: {openshift_cluster_admin_username}

  • パスワード: {openshift_cluster_admin_password}

最初に認証プロバイダーを選択する画面が表示されますので、htpasswd_provider をクリックしてください。

00 htpasswd login
Figure 1. OpenShift Authentication

その後、認証情報をコピー&ペーストできるログイン画面が表示されます。

01 openshift login
Figure 2. OpenShift Login

Ansible Automation Platform コンソールは {aap_controller_web_url}[こちら^] から利用できます。 管理者ログインには、以下の認証情報が利用できます:

  • ユーザー: {aap_controller_admin_user}

  • パスワード {aap_controller_admin_password}

02 aap login
Figure 3. AAP Login

この機会に両方のコンソールを開いてログインし、ラボの準備をしてください。

OpenShift 上の仮想マシン向けの動的インベントリーの作成

目的:

動的インベントリーを使用すると、Ansible Automation Platform (AAP) は外部ソースからシステムインベントリーを自動的に取得・更新できるため、手動でのインベントリー管理が不要になります。

このラボでは、OpenShift Virtualization からデータを取得するための動的インベントリーを設定します。 これにより、AAP は OCP クラスターの vms-aap-day2 名前空間に存在する OpenShift VM を管理できるようになります。

インベントリーの作成

  1. 左側のメニューで、Automation Execution のメニューをクリックして展開し、次に Infrastructure をクリックし、続けて Inventories をクリックします。

    03 auto infra inv
    Figure 4. Automation Execution, Infrastucture, Inventories
  2. Create inventory ドロップダウンボックスをクリックし、Create inventory オプションを選択します。

    04 create inventory dropdown
    Figure 5. Create Inventory Dropdown
  3. Create Inventory フォームで、以下のフィールドに適切な値を入力するか、ドロップダウンメニューから選択します:

    • Name: OpenShift Virtual Machines

    • Organization: Default

  4. 下部にある Create inventory ボタンをクリックします。

    05 create inventory
    Figure 6. Create Inventory

インベントリーへのソースの追加

  1. インベントリーを作成した後、Sources タブに切り替えます。

  2. Create source ボタンを選択します。

    06 sources tab
    Figure 7. Sources Tab
  3. Create Source フォームで、以下のフィールドに適切な値を入力するか、ドロップダウンメニューから選択します:

    • Name: OpenShift Virtual Machines Source

    • Execution environment: Day 2 EE

    • Source: OpenShift Virtualization

    • Credential: OpenShift Credential

    • Update on launch チェックボックス: Checked

    • Cache timeout (seconds): 0

  4. 以下の YAML スニペットをコピーして、フォームの Source variables フィールドに貼り付けます。

    namespaces:
      - vms-aap-day2
  5. Create source ボタンをクリックして設定を保存します。

    07 create inventory source
    Figure 8. Create Inventory Source

インベントリーの更新

  1. 右上隅にある Launch Inventory Update ボタンをクリックして、インベントリー収集を開始します。

    08 update inventory
    Figure 9. Update Inventory
  2. Last Job StatusSuccess と表示されるまで待ちます。

    09 job status success
    Figure 10. Job Status Success
  3. Back to Inventory Sources のタブをクリックします。

    10 back to inventory sources
    Figure 11. Back to Inventory Sources
  4. 画面上部の Hosts タブに切り替えます。

  5. OpenShift クラスターの vms-app-day2 名前空間からの仮想マシンがインベントリーホストとしてリストされていることを確認します。

    11 verify hosts
    Figure 12. Verify Hosts
  6. マシンが動作していることを確認するため、検出された 3 つの VM を選択し、Run command ボタンをクリックして自動化された ping ジョブを実行できます。

    12 run command
    Figure 13. Run Command
  7. Run command ウィザードが表示され、いくつかのページがあります:

    • Details ページで、Module ドロップダウンメニューから ping を選択し、Next をクリックします。

    • Execution Environment ページで、Execution Environment ドロップダウンから Day2 EE を選択し、Next をクリックします。

    • Credential ページで、Credential ドロップダウンから Workshop Credential を選択し、Next をクリックします。

    • Review ページで、選択したオプションを確認し、準備ができたら Finish ボタンをクリックします。

      13 review run command
      Figure 14. Review Run Command
  8. コマンド実行の出力は、各 VM の名前とそのステータスを含む、以下の出力に類似しているはずです:

    vms-aap-day2-rhel9-vm1 |
    SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python3"
        },
        "changed": false,
        "ping": "pong"
    }
    vms-aap-day2-rhel9-vm2 |
    SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python3"
        },
        "changed": false,
        "ping": "pong"
    }
    vms-aap-day2-rhel9-vm3 |
    SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python3"
        },
        "changed": false,
        "ping": "pong"
    }
    14 ping success
    Figure 15. Ping Success
    OpenShift コンソールにログインし、仮想マシンを手動で確認することで、VM が実行されていることを手動で確認することもできます。

OpenShift コンソールでの VM インベントリーの確認

  1. OpenShift 管理コンソールウィンドウに切り替えます。

  2. 左側のナビゲーションメニューで、Virtualization をクリックし、次に VirtualMachines をクリックします。

  3. 中央のナビゲーション列で vms-aap-day2 プロジェクトをハイライトします。

  4. 仮想マシンが実行中であることを確認します。

    15 vm inventory openshift
    Figure 16. Virtual Machines Running on OpenShift

OpenShift Compliance Operator を使用したセキュリティとコンプライアンス

このラボのセクションでは、OpenShift Compliance Operator を使用して、OpenShift クラスターにセキュリティスキャンを設定する方法に焦点を当てます。 コンプライアンスオペレーターは、OpenShift 環境内のホストが特定のセキュリティ標準を満たし、それらの標準を満たすようにデプロイされていることを保証するのに役立ちます。

15a compliance overview
Figure 17. Compliance Overview
  1. 左側のナビゲーションメニューから Operators、次に Installed Operators を選択し、All Projects が選択されていることを確認して Compliance Operator を選択します。

    16 compliance operator
    Figure 18. Compliance Operator
  2. これにより Operator details ページに移動しますので、横スクロールバーを使用して移動し、ScanSetting タブを見つけます。

    17 compliance details
    Figure 19. Compliance Details
  3. Create ScanSetting ボタンをクリックします。

    18 scansetting button
    Figure 20. Create ScanSetting Button
  4. Create ScanSetting ページで、スキャンの名前を scan01 に設定します。 次に、YAML view ラジオボタンをクリックします。

    19 create scansetting
    Figure 21. Create Scansetting
  5. ScanSetting YAML の詳細で、デフォルトで設定されている以下の値に注意してください:

    • autoApplyRemediations フィールドは false に設定されています。

    • デフォルトでスキャンされる roles には、worker ノードと master ノードの両方が含まれています。

    • name フィールドは、フォームビューで入力した scan01 に設定されています。

  6. Create ボタンをクリックして、このシンプルな scansetting 定義を作成します。

    20 scansetting details
    Figure 22. ScanSetting Details
  7. 次に、多数の事前定義されたスキャンプロファイルがある Profile タブをクリックします。

  8. 検索ボックスに rhcos4 と入力し、リスト内の FedRamp moderate プロファイル rhcos4-moderate を見つけます。

    21 profiles detail
    Figure 23. Profiles Detail
  9. rhcos4-moderate をクリックし、次に YAML をクリックします。 出力を下にスクロールして、このスキャンの一部として適用されるルールを閲覧します。 サイドパネルをちらっと見ると、かなりの数のルールがあることがわかります。

    22 rhcos4 mod rules
    Figure 24. RHCOS4-Moderate Rules
  10. ルールの確認が終わったら、ブラウザの back button を 2 回クリックして Operator details ページに戻ります。

    利用可能なプロファイルに関する追加の詳細は、 こちら で確認できます。
  11. 次に、作成した ScanSetting 定義と Profile をペアリングする ScanSettingBinding を作成します。 これを行うには、Scan Setting Binding タブに移動し、Create ScanSettingBinding ボタンをクリックします。

    23 create scansettingbinding
    Figure 25. Create ScanSettingBinding
  12. ScanSettingBinding YAMLの詳細にて、以下の変更を行います:

    • metadata/name の値を fedramp01 に設定します。

    • settingsRef/name フィールドを、以前に作成した scan01 に設定します。

  13. Create ボタンをクリックします。

    プロファイルはデフォルトで rhcos4-moderate (fedramp moderate プロファイル) に設定されています。
    24 scansettingbinding details
    Figure 26. ScanSettingBinding Details
  14. ScanSettingBinding が作成されると、fedramp01 スキャンが自動的に実行されます。 これは Compliance Suite タブで確認できます。

    25 compliance suite
    Figure 27. Compliance Suite
  15. この Compliance Suite は、定義されたスキャンを、今回のケースでは scan01 で定義されたマスターノードとワーカーノードに対して実行します。

  16. Compliance Scan タブをクリックすることで、スキャンが RUNNING, AGGREGATING, DONE のステップを経て進行するのを監視できます。

    26 compliance scan
    Figure 28. Compliance Scan
  17. スキャンが完了したら (平均 3~4 分)、ComplianceCheckResult タブをクリックして結果を確認できます。

  18. 検索バーを Label に変更し、以下のラベルを適用します:

    • compliance.openshift.io/check-status=FAIL

    • compliance.openshift.io/check-severity=high

      27 compliance check results
      Figure 29. Compliance Check Results
  19. 12 個の高 severity のチェックが Failed ステータスになっています:

ComplianceCheckResult

Check-Severity

Check-Status

rhcos4-moderate-master-configure-crypto-policy

high

FAIL

rhcos4-moderate-master-coreos-pti-kernel-argument

high

FAIL

rhcos4-moderate-master-disable-ctrlaltdel-burstaction

high

FAIL

rhcos4-moderate-master-disable-ctrlaltdel-reboot

high

FAIL

rhcos4-moderate-master-enable-fips-mode

high

FAIL

rhcos4-moderate-master-no-empty-passwords

high

FAIL

rhcos4-moderate-worker-configure-crypto-policy

high

FAIL

rhcos4-moderate-worker-coreos-pti-kernel-argument

high

FAIL

rhcos4-moderate-worker-disable-ctrlaltdel-burstaction

high

FAIL

rhcos4-moderate-worker-disable-ctrlaltdel-reboot

high

FAIL

rhcos4-moderate-worker-enable-fips-mode

high

FAIL

rhcos4-moderate-worker-no-empty-passwords

high

FAIL

これで、OpenShift クラスターに対してコンプライアンススキャンを設定および実行するこのセクションを完了しました。

VM トラフィックを管理するためのネットワークポリシーの設定

Red Hat OpenShift では、管理者はネットワークポリシーを設定して、環境、およびそこで実行される仮想ゲストをさらに保護できます。 このラボのこの部分では、仮想マシンを設定し、そのマシンから外部へのエグレスを禁止するネットワークポリシーを適用します。

仮想マシンでのネットワークエグレスの確認

  1. 左側のナビゲーションメニューで、Virtualization、次に VirtualMachines をクリックし、中央の列で vms-aap-day2 プロジェクトの下にある rhel9-vm1 仮想マシンを選択します。

    28 view vm
    Figure 30. View VM
  2. Console タブをクリックし、提供された認証情報と組み込みのコピー/ペースト機能を使用して VM に認証します。

    29 login vm
    Figure 31. Login to VM
    コピー/ペースト機能を有効にするように求めるポップアップが表示される場合があります。 プロンプトが表示されたら Allow をクリックします。
  3. ログインしたら、以下のコマンドを実行して Google へのアウトバウンド ping を開始します:

    ping www.google.com
    30 ping site
    Figure 32. Ping Google
  4. Control+C を押して ping を停止します。

  5. 左側のナビゲーションメニューから Workloads、次に Pods をクリックし、VM rhel9-vm1 を表す virt-launcher Pod をクリックして Pod の詳細を表示します。

    31 select pod
    Figure 33. Select Pod
    Pod 名はランダムに生成されるため、ご自身の Pod 名は上記のスクリーンショットと一致しない可能性が高いです。
  6. Pod details ページで、Labels セクションの Edit オプションをクリックします。

    32 pod details
    Figure 34. Edit Pod Details
  7. Edit labels ウィンドウが表示されます。中央のボックスをクリックし、app=network-policy-deny のラベルを追加し、Enter キーを押してコミットしてから、Save ボタンをクリックします。

    33 pod labels
    Figure 35. Edit Pod Labels
  8. rhel9-vm2 仮想マシンについても同じプロセスを繰り返します。

ネットワークポリシーの作成

  1. 左側のナビゲーションメニューから Networking、次に NetworkPolicies をクリックし、画面中央の Create NetworkPolicy ボタンをクリックします。

    34 network policy
    Figure 36. Network Policy
  2. NetworkPolicies で、以下のフィールドに入力します:

    • Policy name: ping-egress-deny

    • Key: app

    • Value: network-policy-deny

    • Deny all egress traffic チェックボックス: チェック

      35 network policy configure
      Figure 37. Configure Network Policy
  3. 値が入力されたら、Pod selector セクションの下にある affected pods リンクをクリックして、このポリシーの影響を受ける Pod を表示できます。 設定に問題がなければ、Create ボタンをクリックします。

    36 affected pods
    Figure 38. Affected Pods
  4. ポリシーが作成されたので、テストしてみましょう。

VM でのネットワークポリシーの効果の確認

  1. rhel9-vm1 仮想マシンのコンソールに戻って、ポリシーをテストします。

  2. 左側のナビゲーションメニューを使用して、Virtualization、次に VirtualMachines をクリックし、中央の列から rhel9-vm1 を選択します。

  3. VM の Console タブをクリックします。まだログインしているはずです。

  4. 以下の構文をコピー&ペーストして、新しいネットワークポリシーをテストします:

    ping www.google.com
    37 ping site deny
    Figure 39. Egress Blocked
  5. DNS ルックアップを含め、クラスターからのエグレスが完全にブロックされました。

  6. この演習を完了したら、NetworkingNetworkPolicies に戻り、右側の 3 点メニューを使用して ping-egress-deny ポリシーを削除し、ポップアップボックスで確認します。

    38 delete policy
    Figure 40. Delete Policy

このセクションでは、仮想マシンからパブリック Web サイトへのエグレストラフィックをブロックするシンプルなネットワークポリシーを適用する方法を学びました。 これは非常にシンプルな例とこの機能の適用ですが、ネットワークポリシーは非常に機能が豊富で調整可能です。 より高度な例では、マイクロセグメンテーションポリシーを実装して、クラスターの内部と外部、異なる OpenShift プロジェクトまたは同じ OpenShift プロジェクト内の仮想ゲスト間のトラフィックフローを形成するのに役立ちます。

アラート、グラフ、ログの有効化と探索

管理者にとってのもう一つの重要なタスクは、多くの場合、クラスターのパフォーマンスを評価できることです。 これらのパフォーマンスメトリックは、ノード自体、またはクラスター内で実行されているワークロードから収集できます。 OpenShift には、アラートの生成、ログの集約、および管理者がクラスターのパフォーマンスを視覚化するのに役立つグラフの生成を支援する組み込みツールが多数あります。

ノードのアラートとグラフ

まず、クラスターを構成するノードのメトリックを見てみましょう。

  1. 左側のナビゲーションメニューで Compute、次に Nodes をクリックします。

  2. Nodes ページから、クラスター内の各ノード、そのステータス、ロール、現在ホストしている Pod の数、およびメモリと CPU の使用率などの物理属性を確認できます。

    39 node list
    Figure 41. Nodes
  3. クラスター内のワーカーノード 4 をクリックします。 Node details ページが表示され、ノードに関するより詳細な情報が表示されます。

  4. このページには、画面上部中央にノードによって生成されているアラートが表示され、画面下部中央に CPU、メモリ、ストレージ、ネットワークスループットのグラフを表示することで、ノードの使用率を視覚化するのに役立つグラフが提供されます。

  5. 利用率パネルの右上隅にあるドロップダウンをクリックすることで、これらのグラフのレビュー期間を 1、6、または 24 時間に変更できます。

    40 node example
    Figure 42. Node Details

仮想マシンのグラフ

物理クラスターリソース以外に、アプリケーションや仮想マシンなどのワークロードで何が起こっているかを視覚化できることも非常に重要です。 それらについて見つけることができる情報を調べてみましょう。

このラボのこの部分では、グラフがどのように生成されるかを確認できるように、仮想マシンの一部に追加の負荷を生成するためにアプリケーションを使用します。
  1. 左側のナビゲーションメニューを使用して Workloads、次に Deployments をクリックします。

  2. プロジェクト: windows-vms にいることを確認してください。

  3. ここにデプロイされた Pod が 1 つ表示されるはずです。これは loadmaker と呼ばれます。

    41 select loadmaker
    Figure 43. Loadmaker Deployment
  4. loadmaker をクリックすると、Deployment details ページが表示されます。

    42 deploy details
    Figure 44. Deployment Details
  5. Environment をクリックすると、REQUESTS_PER_SECOND のフィールドが表示されます。このフィールドの値を 75 に変更し、下部の Save ボタンをクリックします。

    43 lm pod config
    Figure 45. LM Pod Config
  6. さて、負荷を生成している VM を確認しに行きましょう。

  7. 左側のナビゲーションメニューで Virtualization、次に VirtualMachines をクリックします。中央の列で windows-vms プロジェクトを選択します。 3 つの仮想マシンが表示されるはずです: winweb01winweb02、および database

    44 windows vms
    Figure 46. Windows VMs
    このラボの時点では、databasewinweb01 のみが電源オンになっているはずです。 もしオフになっている場合は、今すぐ電源をオンにしてください。winweb02 は当面電源をオンにしないでください。
  8. 仮想マシンが実行されたら、winweb01 をクリックします。これにより VirtualMachine details ページが表示されます。

  9. このページには Utilization セクションがあり、以下の情報が表示されます:

    • VM リソース (CPU、メモリ、ストレージ、ネットワーク転送) の基本的なステータス。これは 15 秒ごとに更新されます。

    • 最近の期間の VM パフォーマンスを詳述するいくつかの小さなグラフ。デフォルトでは過去 5 分ですが、ドロップダウンメニューから最大 1 週間までの値を選択できます。

      45 vm details
      Figure 47. VM Details
  10. Breakdown by network をクリックして Network Transfer を詳しく見ると、仮想マシンに割り当てられた各ネットワークアダプターを通過しているネットワークトラフィックの量を確認できます。 この場合、1 つの default ネットワークアダプターです。

    46 select network
    Figure 48. Select Network
  11. ネットワークアダプターの確認が終わったら、CPU 使用率を示すグラフをクリックします。

    47 select cpu
    Figure 49. Select CPU
  12. これにより Metrics ウィンドウが起動し、CPU 使用率に関する詳細を確認できます。 デフォルトでは 30 分に設定されていますが、ドロップダウンをクリックして 1 時間に変更すると、ロードジェネレーターをオンにした後のグラフのスパイクを確認できます。

    48 cpu metrics
    Figure 50. CPU Metrics
  13. 右上隅で更新タイミングを変更することもできます。

    49 change refresh
    Figure 51. Change Refresh Interval
  14. また、このグラフを生成するために VM に対して実行されているクエリを確認したり、Add Query ボタンを使用して独自のクエリを作成したりすることもできます。

    50 add query
    Figure 52. Add_Query
  15. 演習として、IO/wait ステータスで費やされた vCPU 時間の量を示すカスタムクエリを追加してみましょう。

  16. Add Query ボタンをクリックし、表示された新しい行に以下のクエリを貼り付けます:

    sum(rate(kubevirt_vmi_vcpu_wait_seconds_total{name='winweb01',namespace='windows-vms'}[5m])) BY (name, namespace)
  17. Run queries ボタンをクリックして、グラフがどのように更新されるかを確認します。 ゲスト上の vCPU が常に負荷がかかっていることを示す新しい折れ線グラフが表示されます。

    51 example query
    Figure 53. Sample Custom Query

ダッシュボードの確認

OpenShift のもう 1 つの強力な機能は、Cluster Observability Operator を使用して、クラスターのパフォーマンスの詳細なダッシュボードを表示できることです。 それらのいくつかを見てみましょう。

  1. 左側のナビゲーションメニューから Observe (日本語UIでは モニタリング )、次に Dashboards をクリックします。

    52 dashboards
    Figure 54. Dashboards
  2. API Performance をクリックし、KubeVirt/Infrastructure Resources/Top Consumers を検索します。

    53 kubevirt dashboard
    Figure 55. KubeVirt Dashboard
  3. このダッシュボードには、クラスターで実行されているすべての仮想マシンのトップコンシューマーが表示されます。 Top Consumers of CPU by virt-launcher Pods パネルを見て、右上隅の Inspect リンクをクリックします。

    54 cpu inspect
    Figure 56. CPU Inspect
  4. 表示されている各 VM の横にあるチェックボックスをオンにすることで、グラフで表示したい VM を選択できます。

  5. 今すぐ試して、いくつかの線をオフにしてみてください。 無効にすると、関連する色付きの線がグラフから消えます。

    55 metrics select
    Figure 57. Select Metrics

これで、ノードとワークロードに関するアラート、パフォーマンスメトリック、およびグラフを見つけて表示する方法を決定するこのセクションを完了しました。将来的には、これらのスキルを活用して、独自の OpenShift Virtualization 環境をトラブルシューティングできます。

仮想マシンの自動化された管理

ゲスト VM の停止、起動、再起動

OpenShift コンソールでの作業に時間を費やしたので、管理作業を容易にするためにどのような種類のアクティビティを自動化できるかを見てみましょう。 このセクションでは、Ansible Automation Platform (AAP) を使用して、Red Hat OpenShift Virtualization で実行されているゲスト VM のライフサイクルを管理する方法を学びます。 プレイブックや VM タスクファイルの作成などの多くの準備作業はすでに完了していますが、このラボのセクションでは、各部分がどのように連携するか、および AAP 経由で自動化を実行する方法を理解することに焦点を当てます。 まず、特定の名前空間内のすべての VM の停止、起動、再起動など、一般的な VM ライフサイクルアクションを実行します。 これらのタスクは、これらのアクションの背後にある自動化がどのように構造化されているかを示すように設計されています。

既存のセットアップ

エクスペリエンスを支援するために、以下のコンテンツがすでに作成および設定されています:

  • tasks/main.yml ファイルには、動的なタスクインクルージョンロジックが事前に入力されています。

  • 入力変数に基づいて適切なタスクを呼び出す Ansible プレイブック (manage_vm_playbook.yml) がすでに配置されています。

  • VM を停止、起動、再起動するための個々のタスクファイル (stop_vm.ymlstart_vm.yml、および restart_vm.yml) が事前に作成されています。 これらのファイルを作成または変更する必要はありませんが、Ansible Automation Platform でジョブテンプレートを作成するときに参照するため、それらがどのように機能するかを理解することが重要です。

タスクファイルの理解

各タスクファイルは、特定の名前空間 (今回のケースでは vms-aap-day2) 内のすべての仮想マシンを取得し、現在のステータスに基づいてアクション (停止、起動、再起動) を実行することで機能します。 ansible.builtin.debug タスクは、動的な Ansible タスクを作成するために必要な主要なフィールドを特定するために、VM リソース vm_info の構造を理解するための洞察を提供します。

stop_vm.yml

このタスクファイルは、特定の名前空間内で現在実行中の VM を停止します。

---
- name: Get all VirtualMachines in the namespace
  redhat.openshift_virtualization.kubevirt_vm_info:
    namespace: "{{ vm_namespace }}"
  register: vm_info

- name: Debug the vm_info variable
  ansible.builtin.debug:
    var: vm_info

- name: Stop VM using OpenShift API
  ansible.builtin.uri:
    url: "{{ OCP_HOST }}/apis/subresources.kubevirt.io/v1/namespaces/{{ vm_namespace }}/virtualmachines/{{ item.metadata.name }}/stop"
    method: PUT
    headers:
      Authorization: "Bearer {{ OCP_BEARER_TOKEN }}"
    validate_certs: false
    status_code:
      - 202
  loop: "{{ vm_info.resources }}"
  loop_control:
    label: "{{ item.metadata.name }}"

  changed_when: item.status.printableStatus != "Stopped"

start_vm.yml

このタスクファイルは、特定の名前空間内で現在停止している VM を起動します。

---
- name: Get all VirtualMachines in the namespace
  redhat.openshift_virtualization.kubevirt_vm_info:
    namespace: "{{ vm_namespace }}"
  register: vm_info

- name: Debug the vm_info variable
  ansible.builtin.debug:
    var: vm_info

- name: Start VM using OpenShift API
  ansible.builtin.uri:
    url: "{{ OCP_HOST }}/apis/subresources.kubevirt.io/v1/namespaces/{{ vm_namespace }}/virtualmachines/{{ item.metadata.name }}/start"
    method: PUT
    headers:
      Authorization: "Bearer {{ OCP_BEARER_TOKEN }}"
    validate_certs: false
    status_code:
      - 202
  loop: "{{ vm_info.resources }}"
  loop_control:
    label: "{{ item.metadata.name }}"

  changed_when: item.status.printableStatus != "Running"

restart_vm.yml

このタスクファイルは、特定の名前空間内で現在実行中の VM を再起動します。

---
- name: Get all VirtualMachines in the namespace
  redhat.openshift_virtualization.kubevirt_vm_info:
    namespace: "{{ vm_namespace }}"
  register: vm_info

- name: Debug the vm_info variable
  ansible.builtin.debug:
    var: vm_info

- name: Restart VM using OpenShift API
  ansible.builtin.uri:
    url: "{{ OCP_HOST }}/apis/subresources.kubevirt.io/v1/namespaces/{{ vm_namespace }}/virtualmachines/{{ item.metadata.name }}/restart"
    method: PUT
    headers:
      Authorization: "Bearer {{ OCP_BEARER_TOKEN }}"
    validate_certs: false
    status_code:
      - 202
  loop: "{{ vm_info.resources }}"
  loop_control:
    label: "{{ item.metadata.name }}"

  changed_when: item.status.printableStatus != "Running"

これらのタスクファイルは、ansible.builtin.uri モジュールを使用して OpenShift REST API と直接対話し、仮想マシンの停止、起動、または再起動の適切なライフサイクルアクションを呼び出します。 さらに、デバッグタスクは、kubevirt_vm_info モジュールによって返される VM データの構造を視覚化するのに役立ち、次のように内訳されます:

  • kubevirt_vm_info モジュールは、名前空間内のすべての VM を取得します。

  • metadata.name: VirtualMachine の名前。

  • metadata.namespace: VM が属する名前空間。

  • loop_control オプションは、各タスクの反復にラベルを設定し、出力に VM 名 (item.metadata.name) を表示します。 これにより、プレイブックの出力が読みやすく、デバッグしやすくなります。

  • status.printableStatus: VM の現在のステータス (例: Stop、Start、Restart)。

ansible.builtin.debug モジュールのスニペット例を以下に示します。

changed: true
result:
  apiVersion: kubevirt.io/v1
  kind: VirtualMachine
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: >
        ...
    ...
    name: rhel9-vm1
    namespace: vms-aap-day2
  spec:
    ...
  status:
    ...
    printableStatus: Stopped
  ...

Ansible Automation Platform を使用した VM ジョブテンプレートの作成と実行

作成する各 VM ライフサイクルテンプレートは、manage_vm_playbook.yml を利用します。 このセクションでは、Ansible Automation Platform (AAP) ダッシュボードを使用してVM の起動、VM の停止、VM の再起動のシナリオごとに VM ジョブテンプレートを作成します:。 OpenShift コンソールに戻って確認することで、自動化ジョブの効果を確認できます。

  1. OpenShift コンソールで、左側のナビゲーションメニューを使用して Virtualization、次に VirtualMachines をクリックします。 中央の列で vms-aap-day2 プロジェクトをクリックし、3 つすべての VM が現在実行中であることを確認します。

    55a running vms
    Figure 58. Running AAP VMs
  2. Ansible Automation Platform を開いているタブに戻ります。 以前のログインがタイムアウトした場合、または誤ってウィンドウを閉じた場合は、再度ログインするための情報がここにあります:

    Ansible Automation Platform コンソールはこちら {aap_controller_web_url}[here^] から利用できます。 管理者ログインには、以下の認証情報が利用できます:

    • ユーザー: {aap_controller_admin_user}

    • パスワード {aap_controller_admin_password}

  3. AAP UI ダッシュボード内で、左側のメニューを使用して Automation Execution に移動し、次に Templates をクリックします。 テンプレート画面で、Create template ボタンをクリックし、ドロップダウンメニューから Create job template を選択します。

    56 create job template
    Figure 59. Create Job Template
  4. Create job template ページで、以下の詳細を入力します:

    Parameter Value

    Name

    Stop VMs

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/manage_vm_playbook.yml

    Execution Environment

    Day2 EE

    Credentials

    OpenShift Credential

    Extra variables

    vm_namespace: vms-aap-day2
    task_file: stop_vm.yml

  5. 入力が完了したら、Create job template ボタンをクリックします。

    57 stop vms template
    Figure 60. Stop VMs Template
  6. Stop VMs ジョブテンプレートが作成されたら、右上隅の Launch template ボタンを選択してジョブを実行します。

    58 launch stop vms
    Figure 61. Launch Stop VMs Template
  7. ジョブが実行を開始し、成功すると変更が黄色で表示されます。

    59 successful job
    Figure 62. Successful Job
  8. OpenShift コンソールに戻って、vms-aap-day2 プロジェクト内の仮想マシンがすべて停止していることを確認します。

    60 stopped vms
    Figure 63. Stopped VMs
  9. AAP ダッシュボードに戻り、このプロセスを繰り返して Start VMs および Restart VMs Ansible ジョブテンプレートを作成します。 それぞれの詳細は以下に示します。

  10. 以下の詳細を使用して Start VMs ジョブテンプレートを作成します:

    Parameter Value

    Name

    Start VMs

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/manage_vm_playbook.yml

    Execution Environment

    Day2 EE

    Credentials

    OpenShift Credential

    Extra variables

    vm_namespace: vms-aap-day2
    task_file: start_vm.yml

  11. 以下の詳細を使用して Restart VMs ジョブテンプレートを作成します:

    Parameter Value

    Name

    Restart VMs

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/manage_vm_playbook.yml

    Execution Environment

    Day2 EE

    Credentials

    OpenShift Credential

    Extra variables

    vm_namespace: vms-aap-day2
    task_file: restart_vm.yml

  12. これらのジョブテンプレートを作成したら、右上隅の Launch template ボタンを選択してジョブを実行し、OpenShift コンソール内でこれらの VM の変更を確認します。 Start VMs テンプレートを実行することで各VMは起動し、次に Restrat VMs テンプレートの実行することで各マシンは再起動するはずです。

VM のパッチ適用

この演習では、Ansible Automation Platform を使用して、セキュリティ関連の更新のみを適用することで、RHEL 仮想マシンのパッチ適用を自動化します。 ターゲットとする仮想マシンは、前の手順でセットアップした動的インベントリー ( OpenShift Virtual Machines インベントリー) の一部です。 プレイブックやタスクを一から記述する代わりに、提供されている自動化コンテンツを使用します。これには以下が含まれます:

  • dnf モジュールを使用してセキュリティ更新を実行するタスクファイル。

  • システム登録とパッチ適用を担当するロールを実行するプレイブック。 目標は、このコンテンツが何をするかを理解し、Ansible Automation Platform の Web UI を使用して自動化を実行するためのジョブテンプレートを作成することです。

このラボでは、Vault 認証情報を使用して機密性の高い認証データを安全に処理し、サブスクリプション管理ロールを使用して RHEL システムを Red Hat に登録します。 これにより、VM が更新に必要な正しいリポジトリーにアクセスできるようになり、安全な自動化プラクティスが実証されます。

提供されているタスクファイル: update_security_packages.yml の理解

このタスクファイルは、redhatone.vm_management.vm_management ロールの tasks/ ディレクトリ内にあります。 これは、ansible.builtin.dnf モジュールを使用して、インベントリー内のすべてのホストで最新のセキュリティ関連の更新をスキャンしてインストールします。

- name: Update security-related packages on all hosts
  ansible.builtin.dnf:
    name: "*" (1)
    security: true (2)
    state: latest (3)
1 name: "*" — すべての利用可能なパッケージをターゲットにします。
2 security: true — セキュリティ関連の更新のみにフィルターをかけます。
3 state: latest — 最新の利用可能なセキュリティ更新がインストールされていることを保証します。 このタスクはモジュール化されるように設計されています。 これはロールに含まれており、まもなく使用される task_file のような変数を使用して、任意のプレイブックからトリガーできます。

提供されているプレイブック: patch_vm_playbook.yml の理解

このプレイブックは、システム登録とパッチ適用の両方を処理するロジックを実行する責任があります。 これはすでにプロジェクトディレクトリに存在しています。

- name: Patch Virtual Machines
  hosts: all
  roles:
    - redhatone.vm_management.rhsm_subscription (1)
    - redhatone.vm_management.vm_management (2)
1 redhatone.vm_management.rhsm_subscription: Vault 経由で提供される認証情報を使用して、RHEL VM を Red Hat に登録します。 このステップにより、システムが更新を受信するために必要なリポジトリーにアクセスできるようになります。
2 redhatone.vm_management.vm_management: task_file 変数を介して参照されるセキュリティ更新タスク (update_security_packages.yml) を含むロールを呼び出します。 このプレイブックは、すべてのターゲットホストが登録とパッチ適用の両方を正しい順序で実行することを保証します。

Ansible Automation Platform での Patch VMs ジョブテンプレートの作成

次に、AAP Web インターフェイスを介してすべての部分を接続し、ジョブテンプレートを使用して自動化を実行します。

  1. 左側のナビゲーションバーを使用して、Automation Execution、次に Templates をクリックします。

  2. Create template ボタンをクリックし、ドロップダウンメニューから Create job template を選択します。

    61 create job template
    Figure 64. Stop VMs Template
  3. Create job template ページで、以下のフィールドに入力します:

    Parameter Value

    Name

    Patch VMs

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/patch_playbook.yml

    Execution Environment

    Day2 EE

    Credentials

    Workshop Credential, Vault Credential

    Extra Variables

    task_file: update_security_packages.yml

    Privilege Escalation

    Enabled

    2 つの認証情報が添付されており、特権昇格が有効になっていることに注意してください。
  4. フォームに記入したら、Create job template ボタンをクリックします。

    62 create patch template
    Figure 65. Create Patch Template
  5. 作成後、右上隅の Launch Template ボタンをクリックしてジョブを開始します。

  6. Patch VMs ジョブが正常に完了すると、次のような出力が表示されるはずです:

    63 patch vm
    Figure 66. Patch VM

ジョブ出力の確認

ジョブの実行後、以下を確認できます:

  • どの操作が実行されたかを示すタスクごとの内訳。

  • Update security-related packages on all hosts というタイトルのタスクの出力。

  • どのセキュリティ更新が適用されたかを示すホストごとの詳細。

    1. Update security-related packages on all hostsTASK の下で、vms-aap-day2-rhel9-vm1 をクリックします。

      64 patch complete
      Figure 67. Patching Complete
    2. タスクに関する追加の Details が表示され、Data タブをクリックすることで、システムが実際に自動化ジョブによってパッチ適用されたことを検証できます。

      65 patch details
      Figure 68. Patch Details

CPU およびメモリーリソースのホットプラグ

仮想ワークロードを持つことの大きな利点の 1 つは、ワークロードの需要を満たすために、実行中のワークロードが使用するリソースをその場で調整できることです。 物理的に RAM を追加したり、プロセッサーをアップグレードしたりするためにサーバーをシャットダウンしなければならなかった時代と比較して、追加のリソースをホットプラグすることで VM リソースを動的にスケーリングできる機能は、時間を大幅に節約できます。 また、ゲストから収集されたメトリックに基づいて、Ansible Automation Platform を使用してこれらのリクエストのスケールアップとスケールダウンを自動化できるため、リソース消費と物理的な管理時間の両方で効率が保証されます。

このセクションでは、Ansible Automation Platform と redhat.openshift_virtualization コレクションを使用して、実行中の仮想マシン (VM) に CPU およびメモリーリソースをホットプラグする方法を学びます。 ホットプラグとは、再起動を必要とせずに、実行中の VM に CPU やメモリーなどのハードウェアリソースを追加または削除できる機能です。 この機能は、動的なワークロードにとって非常に重要であり、ダウンタイムを最小限に抑えながら、需要に基づいてリソースをスケーリングできます。 この演習では、VM のリソースと特性を定義する OpenShift Virtualization の再利用可能なオブジェクトである インスタンスタイプ の使用に主に焦点を当てます。 インスタンスタイプは、VM 間で一貫した構成を可能にすることで、リソース管理を簡素化します。

インスタンスタイプとは何ですか?

インスタンスタイプは、新しい VM のリソース (CPU やメモリーなど) と特性を定義する再利用可能な構成オブジェクトです。 OpenShift Virtualization は、次の 2 種類のインスタンスタイプを提供します:

  1. VirtualMachineInstancetype: 特定の名前空間に限定されたインスタンスタイプの名前空間スコープオブジェクト。

  2. VirtualMachineClusterInstancetype: すべての名前空間で利用可能なインスタンスタイプのクラスターワイドオブジェクト。 どちらのタイプも同じ VirtualMachineInstancetypeSpec を共有しており、これによりカスタム構成を定義したり、OpenShift Virtualization がインストールされたときにデフォルトで含まれるさまざまなインスタンスタイプを使用したりできます。 インスタンスタイプを使用することで、VM 構成管理を簡素化し、すべてのデプロイメント全体で一貫性を確保できるため、リソースのホットプラグに 推奨されるアプローチ となります。 このラボでは、主にインスタンスタイプの方法に焦点を当てますが、コンテキストのために VM 仕様を直接変更する従来のアプローチについても学びます。

従来の方法は、インスタンスタイプを使用しない VM を作成する場合にのみ機能します。

VM がインスタンスタイプを使用しているかどうかを識別する方法

VM がインスタンスタイプで作成されているかどうかを判断するには、次の手順に従います:

  1. OpenShift Virtualization コンソールで rhel9-vm1Overview タブに移動します。

  2. Details セクションで、以下を探します:

    • Instance Type: VM がインスタンスタイプを使用している場合、このフィールドには VM に適用されたインスタンスタイプの名前が表示されます (例: u1.small)。

    • Template: インスタンスタイプが使用されていない場合、このフィールドには None または VM の作成に使用されたテンプレートの名前が表示されます。

      66 vm details
      Figure 69. VM Details

インスタンスタイプの方法は、VM にリソースをホットプラグするための推奨されるアプローチです。 これは、OpenShift Virtualization の強力な機能を活用しながら、複数の VM 間で一貫した再利用可能なリソース構成を保証します。

事前に作成された hot_plug.yml ファイルを使用したリソースの更新

hot_plug.yml ファイルは、新しいインスタンスタイプを適用することで実行中の VM を更新するタスクで構成されています。 このアプローチにより、VM を再作成したり電源を切ったりすることなく、CPU およびメモリーリソースを動的に追加できます。

- name: Swap Instance Type to add more Resources
  redhat.openshift_virtualization.kubevirt_vm: (1)
    name: "rhel9-vm1" (2)
    namespace: "{{ vm_namespace }}" (3)
    state: present (4)
    run_strategy: RestartOnError (5)
    instancetype: (6)
      name: "{{ instance_type }}" (7)
      revisionName: "" (8)
1 redhat.openshift_virtualization.kubevirt_vm: OpenShift Virtualization で VM を管理するために使用されるモジュールを指定します。
2 name: 新しいリソースが適用される VM の名前。
3 namespace: VM が存在する名前空間。
4 state: VM が存在し、利用可能であることを保証します。
5 run_strategy: エラーが発生した場合に VM を再起動しますが、手動で停止されたマシンは起動しません。
6 instancetype: VM のインスタンスタイプを定義し、事前設定されたリソース設定またはカスタムリソース設定の使用を可能にします。
7 instancetype.name: 適用されるインスタンスタイプの名前。
8 instancetype.revisionName: オプションでインスタンスタイプの正確なリビジョンを指定し、VM との互換性を保証します。 通常は自動生成されるため、空のままにします。
このタスクメソッドが機能するには、VM がインスタンスタイプを使用して作成されている必要があります。 そうでない場合は、従来の方法を使用する必要があります。

従来の方法: Spec を直接変更する (情報提供のみ)

従来の方法では、VM の spec ファイルを直接変更して、CPU およびメモリーリソースを更新します。 このアプローチは柔軟性がありますが、インスタンスタイプが提供する再利用性と一貫性が欠けているため、複数の VM 間でリソースを管理するには理想的ではありません。

- name: Modify CPU & Memory Resources
  redhat.openshift_virtualization.kubevirt_vm: (1)
    name: "rhel9-vm2" (2)
    namespace: "{{ vm_namespace }}" (3)
    state: present (4)
    spec: (5)
      domain: (6)
        cpu: (7)
          sockets: 2
        memory: (8)
          guest: 4Gi
1 redhat.openshift_virtualization.kubevirt_vm: OpenShift Virtualization で VM を管理するために使用されるモジュールを指定します。
2 name: 変更される VM の名前。
3 namespace: VM が存在する名前空間。
4 state: VM が目的のステータス、この場合は present であることを保証します。
5 spec: VM の仕様を直接変更します。
6 spec.domain: VM の仮想化環境に関連する設定が含まれます。
7 spec.domain.cpu: VM の CPU ソケットの数を指定します (例: 2)。
8 spec.domain.memory: VM に割り当てられたメモリーを定義します (例: 4Gi)。 NOTE: 従来型の VM はこのラボ演習の一部ではないため、従来の方法は情報提供のみを目的としています。 ==== ホットプラグジョブテンプレートの作成と実行
  1. AAP UI ダッシュボード内で、左側のメニューを使用して Automation Execution、次に Templates をクリックします。

  2. Create Template をクリックし、表示されたドロップダウンメニューから Create job template を選択します。

    67 create template
    Figure 70. Create Job Template
  3. 以下の詳細を入力してジョブテンプレートを作成します:

    Parameter Value

    Name

    Hot Plug VMs

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/manage_vm_playbook.yml

    Execution Environment

    Day 2 EE

    Credentials

    OpenShift Credential

    Extra variables

    vm_namespace: vms-aap-day2
    task_file: hot_plug.yml
    instance_type: u1.2xmedium

  4. 詳細を入力したら、Create Job Template をクリックします。

    68 create hotadd template
    Figure 71. Create HotAdd Template
  5. 右上隅の Launch Template ボタンを選択してジョブを起動します。 ジョブが完了すると、仮想マシンのインスタンスタイプを変更できたことを示す出力が表示されるはずです。

    69 hotadd template success
    Figure 72. HotAdd Template Success
  6. ジョブが完了したら、OpenShift コンソールに戻り、rhel9-vm1 仮想マシンの詳細をもう一度表示します。 InstanceType フィールドが変更され、u1.2xmedium に設定されていることが確認できるはずです。

    70 vm modified instancetype
    Figure 73. VM InstanceType Modified

仮想マシンのバックアップとリストア

仮想マシン管理の最も重要な側面の 1 つは、信頼性の高いバックアップおよびリストア機能を通じてビジネス継続性を確保することです。 実行中の VM の特定の時点のスナップショットをキャプチャし、災害、システム障害、または意図しない変更が発生した場合にそれらを迅速にリストアできる機能は、従来のバックアップ方法と比較して、組織の時間とリソースを大幅に節約できます。 この演習では、Ansible Automation Platform を使用した VM スナップショットによる仮想マシンのバックアップとリストアを自動化します。 この機能により、運用効率を維持しながら、仮想化されたワークロードを大規模に保護できます。 OpenShift Virtualization の仮想マシンスナップショットは、アタッチされたすべての Container Storage Interface (CSI) ボリュームと VM 構成メタデータを含む、特定の時点での VM の完全な状態とデータをキャプチャします。 実行中の VM の場合、QEMU ゲストエージェントは、ファイルシステムをフリーズし、スナップショットを取得し、次にファイルシステムを解凍することにより、スナップショット作成中の I/O 操作を調整し、データの一貫性を確保します。 スナップショットは、次の 3 つの OpenShift API を通じて管理されます:

  • VirtualMachineSnapshot: スナップショットを作成するためのユーザーリクエストを表し、VM の現在の状態に関する情報が含まれます

  • VirtualMachineSnapshotContent: VM スナップショットコントローラーによって作成された、クラスター上のプロビジョニングされたリソース (実際のスナップショット) を表します

  • VirtualMachineRestore: スナップショットから VM をリストアするためのユーザーリクエストを表します

既存のセットアップ

エクスペリエンスを支援するために、以下のコンテンツがすでに作成および設定されています:

  • スナップショット自動化タスク (snapshot_vms.yml および _snapshot_vm.yml) は、ループベースのアプローチを使用して VM スナップショットを処理するように事前に記述されています。

  • リストア自動化タスク (restore_vm_snapshots.yml および _restore_vm_snapshot.yml) は、VM の停止、リストア、再起動を含む完全なリストアワークフローを管理するために事前に作成されています。

  • manage_vm_playbook.yml プレイブックは、VM のスナップショットを取得するかリストアするかに基づく入力変数に基づいて、これらのタスクを実行するようにすでに設定されています。 これらのファイルを作成または変更する必要はありませんが、Ansible Automation Platform でジョブテンプレートを作成するときに参照するため、それらがどのように機能するかを理解することが重要です。

提供されているスナップショットタスクファイルの理解

スナップショット自動化では、1 つのタスクファイルがループを使用して複数のスナップショットを処理し、インクルードタスクファイルが個々の VM スナップショットを取得するという 2 層のアプローチを使用します。

snapshot_vms.yml

このメインのタスクファイルは、コンマ区切りの VM 名文字列を処理し、Ansible のループ機能を使用して VM ごとに個別のスナップショットタスクを作成します。

---
- name: Snapshot individual VM
  ansible.builtin.include_tasks:
    file: _snapshot_vm.yml
  loop_control:
    loop_var: vm_to_snapshot
  loop: "{{ vms_to_snapshot.replace(' ','').split(',') }}"
  when: vms_to_snapshot |
default('', True) | length > 0

タスクの説明:

  • when: vms_to_snapshot 変数がコンテンツを含んでいることを、フィルターを使用して変数状態をチェックして検証してから続行します

  • loop: コンマ区切りの VM 名を処理し、スペースを削除し、Jinja2 関数を使用してリストを作成します

  • loop_control/loop_var: ループの各反復の変数名 (vm_to_snapshot) を設定します

  • ansible.builtin.include_tasks: スナップショットプロセスを完了するために必要なステップ (タスク) をキャプチャする、インクルードされたタスクファイル _snapshot_vm.yml を VM ごとに呼び出します。

_snapshot_vm.yml

アンダースコア "_" で始まるタスクファイルは、別のタスクファイル内にインクルードされていることを示します。 このファイルは、OpenShift API を使用して単一の VM の実際のスナップショット作成を処理し、コアのスナップショットロジックを含んでいます。

---
- name: Verify VM to Snapshot Provided
  ansible.builtin.assert:
    that:
      - vm_to_snapshot |
default('', True) | length > 0
    quiet: True
    fail_msg: VM to Snapshot not specified

- name: Get VirtualMachine to snapshot
  redhat.openshift_virtualization.kubevirt_vm_info:
    namespace: "{{ vm_namespace }}"
    name: "{{ vm_to_snapshot }}"
  register: vm_info

- name: Create Snapshot
  redhat.openshift.k8s:
    state: present
    definition:
      apiVersion: snapshot.kubevirt.io/v1alpha1
      kind: VirtualMachineSnapshot
      metadata:
        generateName: "{{ vm_info.resources[0].metadata.name }}-"
        namespace: "{{ vm_info.resources[0].metadata.namespace }}"

        ownerReferences:
          - apiVersion: kubevirt.io/v1
            blockOwnerDeletion: false
            kind: VirtualMachine
            name: "{{ vm_info.resources[0].metadata.name }}"
            uid: "{{ vm_info.resources[0].metadata.uid }}"
      spec:
        source:
          apiGroup:
kubevirt.io
          kind: VirtualMachine
          name: "{{ vm_info.resources[0].metadata.name }}"
    wait: true
    wait_condition:
      type: Ready
  when: "'resources' in vm_info and vm_info.resources |
length == 1"

タスクの説明:

このインクルードされたタスクファイルには 3 つのタスクがあります:

  1. ansible.builtin.assert を使用して、vm_to_snapshot という変数が提供されていることを検証します。

  2. kubevirt_vm_info を使用して VirtualMachine リソースの定義を取得し、vm_info に格納します。

  3. redhat.openshift.k8s モジュールを使用して新しい VirtualMachineSnapshot リソースを作成します。

スナップショット作成の主な詳細:

  • generateName: name が提供されていない場合に一意の名前を生成する OpenShift の機能。

  • ownerReferences: VirtualMachineSnapshotVirtualMachine の間にリレーションシップを作成し、VM が削除された場合に OpenShift のガベージコレクターがスナップショットを自動的に削除するようにします。

  • wait/wait_condition: スナップショットが正常に完了するまで実行を一時停止します (条件 タイプ Readytrue に設定されている)。

  • when: ちょうど 1 つの VM リソースが見つかった場合にのみスナップショットが作成されることを保証します。

Snapshot VMs ジョブテンプレートの作成と実行

次に、AAP Web インターフェイスを介してすべての部分を接続し、ジョブテンプレートを使用してスナップショット自動化を実行します。

  1. AAP UI ダッシュボードにアクセスし、Automation Execution → Templates に移動します。

  2. Create Template をクリックし、Create job template を選択します。

  3. 以下の詳細を入力します:

    Parameter Value

    Name

    Snapshot VMs

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/manage_vm_playbook.yml

    Execution Environment

    Day2 EE

    Credentials

    OpenShift Credential

    Extra variables

    vm_namespace: vms-aap-day2
    task_file: snapshot_vms.yml
    vms_to_snapshot: rhel9-vm1

  4. Create Job Template をクリックします。

    71 create snapshot
    Figure 74. Create Snapshot Template
  5. 右上隅から Launch Template を選択してジョブを起動します。

スナップショット作成の確認

ジョブが正常に完了したら、新しいスナップショットが作成されたことを確認します。

  1. OpenShift コンソールに移動し、vms-aap-day2 プロジェクト内の Virtualization → VirtualMachines に移動します。

  2. rhel9-vm1 インスタンスを選択し、Snapshots タブをクリックします。

  3. スナップショットがリストに表示されていることを確認します。

    72 ocp snapshot details
    Figure 75. Snapshot Details

提供されているリストアタスクファイルの理解

リストア自動化は、VM の停止、スナップショットからのリストア、VM の再起動という完全なワークフローを処理します。 スナップショットの作成とは異なり、スナップショットからのリストアを開始する前に仮想マシンを電源オフにする必要があります。 この自動化は、スナップショットプロセスと同じ 2 層パターンに従います。

restore_vm_snapshots.yml

このメインのタスクファイルは、コンマ区切りのスナップショット名文字列を処理し、個別のリストアタスクを作成します。 スナップショットタスクとの主な違いは、VM 名ではなくスナップショット名を参照することです。

---
- name: Restore VM Snapshot
  ansible.builtin.include_tasks:
    file: _restore_vm_snapshot.yml
  loop_control:
    loop_var: vm_snapshot
  loop: "{{ vm_snapshots.replace(' ','').split(',') }}"
  when: vm_snapshots |
default('', True) | length > 0

このタスクは、リストアする VirtualMachineSnapshot リソース名のコンマ区切り文字列を含む vm_snapshots という変数に対して操作を行います。

_restore_vm_snapshot.yml

このインクルードされたタスクファイルは、次の手順に従って完全なリストアワークフローを管理します:

  1. 提供されたスナップショット名に基づいて VirtualMachineSnapshot を取得します。

  2. 仮想マシンを停止します。

  3. VirtualMachineRestore リソースを作成し、リストアが完了するまで待ちます。

  4. 仮想マシンを起動します。

---
- name: Verify VM Snapshot Provided
  ansible.builtin.assert:
    that:
      - vm_snapshot |
default('', True) | length > 0
    quiet: True
    fail_msg: VM Snapshot not specified

- name: Get VirtualMachine Snapshot
  kubernetes.core.k8s_info:
    api_version: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineSnapshot
    namespace: "{{ vm_namespace }}"
    name: "{{ vm_snapshot }}"
  register: vm_snapshot_instance

- name: Create Restore
  block:
    - name: Stop Virtual Machine
      redhat.openshift_virtualization.kubevirt_vm:
        name: "{{ vm_snapshot_instance.resources[0].metadata.ownerReferences[0].name }}"
        namespace: "{{ vm_snapshot_instance.resources[0].metadata.namespace }}"

run_strategy: Halted
        wait: true

    - name: Create Restore
      redhat.openshift.k8s:
        state: present
        definition:
          apiVersion: snapshot.kubevirt.io/v1alpha1
          kind: VirtualMachineRestore
          metadata:
            generateName: "{{ vm_snapshot_instance.resources[0].metadata.ownerReferences[0].name }}-"
            namespace:
"{{ vm_snapshot_instance.resources[0].metadata.namespace }}"
            ownerReferences:
              - apiVersion: kubevirt.io/v1
                blockOwnerDeletion: false
                kind: VirtualMachine
                name: "{{ vm_snapshot_instance.resources[0].metadata.ownerReferences[0].name }}"
                uid:
"{{ vm_snapshot_instance.resources[0].metadata.ownerReferences[0].uid }}"
          spec:
            target:
              apiGroup: kubevirt.io
              kind: VirtualMachine
              name: "{{ vm_snapshot_instance.resources[0].metadata.ownerReferences[0].name }}"
            virtualMachineSnapshotName: "{{ vm_snapshot_instance.resources[0].metadata.name }}"
        wait: true

    wait_timeout: 600
        wait_condition:
          type: Ready

    - name: Start Virtual Machine
      redhat.openshift_virtualization.kubevirt_vm:
        name: "{{ vm_snapshot_instance.resources[0].metadata.ownerReferences[0].name }}"
        namespace: "{{ vm_snapshot_instance.resources[0].metadata.namespace }}"
        run_strategy: Always
        wait: true
  when: "'resources' in vm_snapshot_instance and vm_snapshot_instance.resources |
length == 1"

タスクの説明:

  • kubernetes.core.k8s_info: スナップショットの詳細を取得して関連付けられた VM を識別します (kubevirt_vm_info は仮想マシンに固有ですが、これは任意の OpenShift リソースの取得を可能にします)。

  • block: リストア手順をグループ化し、最後に条件チェックを行います。

  • Stop Virtual Machine: リストアが始まる前に、run_strategy: Halted を使用して VM の電源をオフにします。

  • Create Restore: リストアがデフォルトの 120 秒よりも長くかかる可能性があるため、wait_timeout を 600 秒 (10 分) に設定して VirtualMachineRestore リソースを作成します。

  • Start Virtual Machine: リストア完了後、run_strategy: Always を使用して VM の電源をオンに戻します。

Restore VM Snapshots ジョブテンプレートの作成と実行

  1. AAP UI ダッシュボードにアクセスし、Automation Execution → Templates に移動します。

  2. Create Template をクリックし、Create job template を選択します。

  3. 以下の詳細を入力します。以前に作成したスナップショットの名前を含めるように注意してください:

    Parameter Value

    Name

    Restore VM Snapshots

    Job Type

    Run

    Inventory

    OpenShift Virtual Machines

    Project

    Workshop Project

    Playbook

    solutions/manage_vm_playbook.yml

    Execution Environment

    Day2 EE

    Credentials

    OpenShift Credential

    Extra variables

    vm_namespace: vms-aap-day2
    task_file: restore_vm_snapshots.yml
    vm_snapshots: <snapshot_name>

    <snapshot_name> を以前に作成したスナップショットの実際の名前 に置き換えてください。
  4. Create Job Template をクリックします。

    73 restore snapshot
    Figure 76. Restore Snapshot Template
  5. Launch Template をクリックしてテンプレートを起動します。

スナップショットリストアの確認

ジョブが正常に完了したら、リストアが適用されたことを確認します。

  1. OpenShift コンソールに移動し、vms-aap-day2 プロジェクト内の Virtualization → VirtualMachines に移動します。

  2. rhel9-vm1 インスタンスを選択し、Snapshots タブをクリックします。

  3. リストアしたスナップショットを見つけ、Last restored 列に最近のリストアタイムスタンプが表示されていることを確認します。

    74 ocp restore snapshot details
    Figure 77. Restore Snapshot Details

まとめ

このモジュールでは、OpenShift Virtualization 管理者としての 1 日を過ごし、Red Hat OpenShift のネイティブパフォーマンス評価ツールを探索し、Ansible Automation Platform を使用して、多くの VM が日常的に頻繁に経験する多くのタスクを自動化しました。