日々の基本的な操作の有効化
OpenShift Console と Ansible Automation Platform の認証情報
OpenShift クラスターコンソールは {openshift_cluster_console_url}[こちら^] から利用できます。 ローカル管理者ログインには、以下の認証情報が利用できます:
-
ユーザー:
{openshift_cluster_admin_username}
-
パスワード:
{openshift_cluster_admin_password}
最初に認証プロバイダーを選択する画面が表示されますので、htpasswd_provider をクリックしてください。
その後、認証情報をコピー&ペーストできるログイン画面が表示されます。
Ansible Automation Platform コンソールは {aap_controller_web_url}[こちら^] から利用できます。 管理者ログインには、以下の認証情報が利用できます:
-
ユーザー:
{aap_controller_admin_user}
-
パスワード
{aap_controller_admin_password}
この機会に両方のコンソールを開いてログインし、ラボの準備をしてください。
OpenShift 上の仮想マシン向けの動的インベントリーの作成
目的:
動的インベントリーを使用すると、Ansible Automation Platform (AAP) は外部ソースからシステムインベントリーを自動的に取得・更新できるため、手動でのインベントリー管理が不要になります。
このラボでは、OpenShift Virtualization からデータを取得するための動的インベントリーを設定します。 これにより、AAP は OCP クラスターの vms-aap-day2 名前空間に存在する OpenShift VM を管理できるようになります。
インベントリーの作成
-
左側のメニューで、Automation Execution のメニューをクリックして展開し、次に Infrastructure をクリックし、続けて Inventories をクリックします。
-
Create inventory ドロップダウンボックスをクリックし、Create inventory オプションを選択します。
-
Create Inventory フォームで、以下のフィールドに適切な値を入力するか、ドロップダウンメニューから選択します:
-
Name:
OpenShift Virtual Machines
-
Organization: Default
-
-
下部にある Create inventory ボタンをクリックします。
インベントリーへのソースの追加
-
インベントリーを作成した後、Sources タブに切り替えます。
-
Create source ボタンを選択します。
-
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
-
-
以下の YAML スニペットをコピーして、フォームの Source variables フィールドに貼り付けます。
namespaces: - vms-aap-day2
-
Create source ボタンをクリックして設定を保存します。
インベントリーの更新
-
右上隅にある Launch Inventory Update ボタンをクリックして、インベントリー収集を開始します。
-
Last Job Status が Success と表示されるまで待ちます。
-
Back to Inventory Sources のタブをクリックします。
-
画面上部の Hosts タブに切り替えます。
-
OpenShift クラスターの vms-app-day2 名前空間からの仮想マシンがインベントリーホストとしてリストされていることを確認します。
-
マシンが動作していることを確認するため、検出された 3 つの VM を選択し、Run command ボタンをクリックして自動化された ping ジョブを実行できます。
-
Run command ウィザードが表示され、いくつかのページがあります:
-
Details ページで、Module ドロップダウンメニューから ping を選択し、Next をクリックします。
-
Execution Environment ページで、Execution Environment ドロップダウンから Day2 EE を選択し、Next をクリックします。
-
Credential ページで、Credential ドロップダウンから Workshop Credential を選択し、Next をクリックします。
-
Review ページで、選択したオプションを確認し、準備ができたら Finish ボタンをクリックします。
-
-
コマンド実行の出力は、各 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" }
OpenShift コンソールにログインし、仮想マシンを手動で確認することで、VM が実行されていることを手動で確認することもできます。
OpenShift Compliance Operator を使用したセキュリティとコンプライアンス
このラボのセクションでは、OpenShift Compliance Operator を使用して、OpenShift クラスターにセキュリティスキャンを設定する方法に焦点を当てます。 コンプライアンスオペレーターは、OpenShift 環境内のホストが特定のセキュリティ標準を満たし、それらの標準を満たすようにデプロイされていることを保証するのに役立ちます。
-
左側のナビゲーションメニューから Operators、次に Installed Operators を選択し、All Projects が選択されていることを確認して Compliance Operator を選択します。
-
これにより Operator details ページに移動しますので、横スクロールバーを使用して移動し、ScanSetting タブを見つけます。
-
Create ScanSetting ボタンをクリックします。
-
Create ScanSetting ページで、スキャンの名前を
scan01
に設定します。 次に、YAML view ラジオボタンをクリックします。 -
ScanSetting YAML の詳細で、デフォルトで設定されている以下の値に注意してください:
-
autoApplyRemediations フィールドは false に設定されています。
-
デフォルトでスキャンされる roles には、worker ノードと master ノードの両方が含まれています。
-
name フィールドは、フォームビューで入力した scan01 に設定されています。
-
-
Create ボタンをクリックして、このシンプルな scansetting 定義を作成します。
-
次に、多数の事前定義されたスキャンプロファイルがある Profile タブをクリックします。
-
検索ボックスに
rhcos4
と入力し、リスト内の FedRamp moderate プロファイル rhcos4-moderate を見つけます。 -
rhcos4-moderate をクリックし、次に YAML をクリックします。 出力を下にスクロールして、このスキャンの一部として適用されるルールを閲覧します。 サイドパネルをちらっと見ると、かなりの数のルールがあることがわかります。
-
ルールの確認が終わったら、ブラウザの back button を 2 回クリックして Operator details ページに戻ります。
利用可能なプロファイルに関する追加の詳細は、 こちら で確認できます。 -
次に、作成した ScanSetting 定義と Profile をペアリングする ScanSettingBinding を作成します。 これを行うには、Scan Setting Binding タブに移動し、Create ScanSettingBinding ボタンをクリックします。
-
ScanSettingBinding YAMLの詳細にて、以下の変更を行います:
-
metadata/name の値を
fedramp01
に設定します。 -
settingsRef/name フィールドを、以前に作成した
scan01
に設定します。
-
-
Create ボタンをクリックします。
プロファイルはデフォルトで rhcos4-moderate (fedramp moderate プロファイル) に設定されています。 -
ScanSettingBinding が作成されると、
fedramp01
スキャンが自動的に実行されます。 これは Compliance Suite タブで確認できます。 -
この Compliance Suite は、定義されたスキャンを、今回のケースでは scan01 で定義されたマスターノードとワーカーノードに対して実行します。
-
Compliance Scan タブをクリックすることで、スキャンが RUNNING, AGGREGATING, DONE のステップを経て進行するのを監視できます。
-
スキャンが完了したら (平均 3~4 分)、ComplianceCheckResult タブをクリックして結果を確認できます。
-
検索バーを Label に変更し、以下のラベルを適用します:
-
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 では、管理者はネットワークポリシーを設定して、環境、およびそこで実行される仮想ゲストをさらに保護できます。 このラボのこの部分では、仮想マシンを設定し、そのマシンから外部へのエグレスを禁止するネットワークポリシーを適用します。
仮想マシンでのネットワークエグレスの確認
-
左側のナビゲーションメニューで、Virtualization、次に VirtualMachines をクリックし、中央の列で vms-aap-day2 プロジェクトの下にある rhel9-vm1 仮想マシンを選択します。
-
Console タブをクリックし、提供された認証情報と組み込みのコピー/ペースト機能を使用して VM に認証します。
コピー/ペースト機能を有効にするように求めるポップアップが表示される場合があります。 プロンプトが表示されたら Allow をクリックします。 -
ログインしたら、以下のコマンドを実行して Google へのアウトバウンド ping を開始します:
ping www.google.com
-
Control+C を押して ping を停止します。
-
左側のナビゲーションメニューから Workloads、次に Pods をクリックし、VM rhel9-vm1 を表す
virt-launcher
Pod をクリックして Pod の詳細を表示します。Pod 名はランダムに生成されるため、ご自身の Pod 名は上記のスクリーンショットと一致しない可能性が高いです。 -
Pod details ページで、Labels セクションの Edit オプションをクリックします。
-
Edit labels ウィンドウが表示されます。中央のボックスをクリックし、
app=network-policy-deny
のラベルを追加し、Enter キーを押してコミットしてから、Save ボタンをクリックします。 -
rhel9-vm2 仮想マシンについても同じプロセスを繰り返します。
ネットワークポリシーの作成
-
左側のナビゲーションメニューから Networking、次に NetworkPolicies をクリックし、画面中央の Create NetworkPolicy ボタンをクリックします。
-
NetworkPolicies で、以下のフィールドに入力します:
-
値が入力されたら、Pod selector セクションの下にある affected pods リンクをクリックして、このポリシーの影響を受ける Pod を表示できます。 設定に問題がなければ、Create ボタンをクリックします。
-
ポリシーが作成されたので、テストしてみましょう。
VM でのネットワークポリシーの効果の確認
-
rhel9-vm1 仮想マシンのコンソールに戻って、ポリシーをテストします。
-
左側のナビゲーションメニューを使用して、Virtualization、次に VirtualMachines をクリックし、中央の列から rhel9-vm1 を選択します。
-
VM の Console タブをクリックします。まだログインしているはずです。
-
以下の構文をコピー&ペーストして、新しいネットワークポリシーをテストします:
ping www.google.com
-
DNS ルックアップを含め、クラスターからのエグレスが完全にブロックされました。
-
この演習を完了したら、Networking と NetworkPolicies に戻り、右側の 3 点メニューを使用して ping-egress-deny ポリシーを削除し、ポップアップボックスで確認します。
このセクションでは、仮想マシンからパブリック Web サイトへのエグレストラフィックをブロックするシンプルなネットワークポリシーを適用する方法を学びました。 これは非常にシンプルな例とこの機能の適用ですが、ネットワークポリシーは非常に機能が豊富で調整可能です。 より高度な例では、マイクロセグメンテーションポリシーを実装して、クラスターの内部と外部、異なる OpenShift プロジェクトまたは同じ OpenShift プロジェクト内の仮想ゲスト間のトラフィックフローを形成するのに役立ちます。
アラート、グラフ、ログの有効化と探索
管理者にとってのもう一つの重要なタスクは、多くの場合、クラスターのパフォーマンスを評価できることです。 これらのパフォーマンスメトリックは、ノード自体、またはクラスター内で実行されているワークロードから収集できます。 OpenShift には、アラートの生成、ログの集約、および管理者がクラスターのパフォーマンスを視覚化するのに役立つグラフの生成を支援する組み込みツールが多数あります。
ノードのアラートとグラフ
まず、クラスターを構成するノードのメトリックを見てみましょう。
-
左側のナビゲーションメニューで Compute、次に Nodes をクリックします。
-
Nodes ページから、クラスター内の各ノード、そのステータス、ロール、現在ホストしている Pod の数、およびメモリと CPU の使用率などの物理属性を確認できます。
-
クラスター内のワーカーノード 4 をクリックします。 Node details ページが表示され、ノードに関するより詳細な情報が表示されます。
-
このページには、画面上部中央にノードによって生成されているアラートが表示され、画面下部中央に CPU、メモリ、ストレージ、ネットワークスループットのグラフを表示することで、ノードの使用率を視覚化するのに役立つグラフが提供されます。
-
利用率パネルの右上隅にあるドロップダウンをクリックすることで、これらのグラフのレビュー期間を 1、6、または 24 時間に変更できます。
仮想マシンのグラフ
物理クラスターリソース以外に、アプリケーションや仮想マシンなどのワークロードで何が起こっているかを視覚化できることも非常に重要です。 それらについて見つけることができる情報を調べてみましょう。
このラボのこの部分では、グラフがどのように生成されるかを確認できるように、仮想マシンの一部に追加の負荷を生成するためにアプリケーションを使用します。 |
-
左側のナビゲーションメニューを使用して Workloads、次に Deployments をクリックします。
-
プロジェクト: windows-vms にいることを確認してください。
-
ここにデプロイされた Pod が 1 つ表示されるはずです。これは loadmaker と呼ばれます。
-
loadmaker をクリックすると、Deployment details ページが表示されます。
-
Environment をクリックすると、REQUESTS_PER_SECOND のフィールドが表示されます。このフィールドの値を
75
に変更し、下部の Save ボタンをクリックします。 -
さて、負荷を生成している VM を確認しに行きましょう。
-
左側のナビゲーションメニューで Virtualization、次に VirtualMachines をクリックします。中央の列で windows-vms プロジェクトを選択します。 3 つの仮想マシンが表示されるはずです: winweb01、winweb02、および database。
このラボの時点では、database と winweb01 のみが電源オンになっているはずです。 もしオフになっている場合は、今すぐ電源をオンにしてください。winweb02 は当面電源をオンにしないでください。 -
仮想マシンが実行されたら、winweb01 をクリックします。これにより VirtualMachine details ページが表示されます。
-
このページには Utilization セクションがあり、以下の情報が表示されます:
-
Breakdown by network をクリックして Network Transfer を詳しく見ると、仮想マシンに割り当てられた各ネットワークアダプターを通過しているネットワークトラフィックの量を確認できます。 この場合、1 つの default ネットワークアダプターです。
-
ネットワークアダプターの確認が終わったら、CPU 使用率を示すグラフをクリックします。
-
これにより Metrics ウィンドウが起動し、CPU 使用率に関する詳細を確認できます。 デフォルトでは 30 分に設定されていますが、ドロップダウンをクリックして 1 時間に変更すると、ロードジェネレーターをオンにした後のグラフのスパイクを確認できます。
-
右上隅で更新タイミングを変更することもできます。
-
また、このグラフを生成するために VM に対して実行されているクエリを確認したり、Add Query ボタンを使用して独自のクエリを作成したりすることもできます。
-
演習として、IO/wait ステータスで費やされた vCPU 時間の量を示すカスタムクエリを追加してみましょう。
-
Add Query ボタンをクリックし、表示された新しい行に以下のクエリを貼り付けます:
sum(rate(kubevirt_vmi_vcpu_wait_seconds_total{name='winweb01',namespace='windows-vms'}[5m])) BY (name, namespace)
-
Run queries ボタンをクリックして、グラフがどのように更新されるかを確認します。 ゲスト上の vCPU が常に負荷がかかっていることを示す新しい折れ線グラフが表示されます。
ダッシュボードの確認
OpenShift のもう 1 つの強力な機能は、Cluster Observability Operator を使用して、クラスターのパフォーマンスの詳細なダッシュボードを表示できることです。 それらのいくつかを見てみましょう。
-
左側のナビゲーションメニューから Observe (日本語UIでは モニタリング )、次に Dashboards をクリックします。
-
API Performance をクリックし、KubeVirt/Infrastructure Resources/Top Consumers を検索します。
-
このダッシュボードには、クラスターで実行されているすべての仮想マシンのトップコンシューマーが表示されます。 Top Consumers of CPU by virt-launcher Pods パネルを見て、右上隅の Inspect リンクをクリックします。
-
表示されている各 VM の横にあるチェックボックスをオンにすることで、グラフで表示したい VM を選択できます。
-
今すぐ試して、いくつかの線をオフにしてみてください。 無効にすると、関連する色付きの線がグラフから消えます。
これで、ノードとワークロードに関するアラート、パフォーマンスメトリック、およびグラフを見つけて表示する方法を決定するこのセクションを完了しました。将来的には、これらのスキルを活用して、独自の 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.yml、start_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 コンソールに戻って確認することで、自動化ジョブの効果を確認できます。
-
OpenShift コンソールで、左側のナビゲーションメニューを使用して Virtualization、次に VirtualMachines をクリックします。 中央の列で vms-aap-day2 プロジェクトをクリックし、3 つすべての VM が現在実行中であることを確認します。
-
Ansible Automation Platform を開いているタブに戻ります。 以前のログインがタイムアウトした場合、または誤ってウィンドウを閉じた場合は、再度ログインするための情報がここにあります:
Ansible Automation Platform コンソールはこちら {aap_controller_web_url}[here^] から利用できます。 管理者ログインには、以下の認証情報が利用できます:
-
ユーザー:
{aap_controller_admin_user}
-
パスワード
{aap_controller_admin_password}
-
-
AAP UI ダッシュボード内で、左側のメニューを使用して Automation Execution に移動し、次に Templates をクリックします。 テンプレート画面で、Create template ボタンをクリックし、ドロップダウンメニューから Create job template を選択します。
-
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
-
入力が完了したら、Create job template ボタンをクリックします。
-
Stop VMs ジョブテンプレートが作成されたら、右上隅の Launch template ボタンを選択してジョブを実行します。
-
ジョブが実行を開始し、成功すると変更が黄色で表示されます。
-
OpenShift コンソールに戻って、vms-aap-day2 プロジェクト内の仮想マシンがすべて停止していることを確認します。
-
AAP ダッシュボードに戻り、このプロセスを繰り返して Start VMs および Restart VMs Ansible ジョブテンプレートを作成します。 それぞれの詳細は以下に示します。
-
以下の詳細を使用して 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
-
以下の詳細を使用して 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
-
これらのジョブテンプレートを作成したら、右上隅の 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 インターフェイスを介してすべての部分を接続し、ジョブテンプレートを使用して自動化を実行します。
-
左側のナビゲーションバーを使用して、Automation Execution、次に Templates をクリックします。
-
Create template ボタンをクリックし、ドロップダウンメニューから Create job template を選択します。
-
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 つの認証情報が添付されており、特権昇格が有効になっていることに注意してください。 -
フォームに記入したら、Create job template ボタンをクリックします。
-
作成後、右上隅の Launch Template ボタンをクリックしてジョブを開始します。
-
Patch VMs ジョブが正常に完了すると、次のような出力が表示されるはずです:
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 種類のインスタンスタイプを提供します:
-
VirtualMachineInstancetype: 特定の名前空間に限定されたインスタンスタイプの名前空間スコープオブジェクト。
-
VirtualMachineClusterInstancetype: すべての名前空間で利用可能なインスタンスタイプのクラスターワイドオブジェクト。 どちらのタイプも同じ VirtualMachineInstancetypeSpec を共有しており、これによりカスタム構成を定義したり、OpenShift Virtualization がインストールされたときにデフォルトで含まれるさまざまなインスタンスタイプを使用したりできます。 インスタンスタイプを使用することで、VM 構成管理を簡素化し、すべてのデプロイメント全体で一貫性を確保できるため、リソースのホットプラグに 推奨されるアプローチ となります。 このラボでは、主にインスタンスタイプの方法に焦点を当てますが、コンテキストのために VM 仕様を直接変更する従来のアプローチについても学びます。
従来の方法は、インスタンスタイプを使用しない VM を作成する場合にのみ機能します。 |
VM がインスタンスタイプを使用しているかどうかを識別する方法
VM がインスタンスタイプで作成されているかどうかを判断するには、次の手順に従います:
-
OpenShift Virtualization コンソールで rhel9-vm1 の Overview タブに移動します。
-
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 つは、信頼性の高いバックアップおよびリストア機能を通じてビジネス継続性を確保することです。 実行中の 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 つのタスクがあります:
-
ansible.builtin.assert
を使用して、vm_to_snapshot
という変数が提供されていることを検証します。 -
kubevirt_vm_info
を使用してVirtualMachine
リソースの定義を取得し、vm_info
に格納します。 -
redhat.openshift.k8s
モジュールを使用して新しいVirtualMachineSnapshot
リソースを作成します。
スナップショット作成の主な詳細:
-
generateName:
name
が提供されていない場合に一意の名前を生成する OpenShift の機能。 -
ownerReferences:
VirtualMachineSnapshot
とVirtualMachine
の間にリレーションシップを作成し、VM が削除された場合に OpenShift のガベージコレクターがスナップショットを自動的に削除するようにします。 -
wait/wait_condition: スナップショットが正常に完了するまで実行を一時停止します (条件 タイプ
Ready
がtrue
に設定されている)。 -
when: ちょうど 1 つの VM リソースが見つかった場合にのみスナップショットが作成されることを保証します。
Snapshot VMs ジョブテンプレートの作成と実行
次に、AAP Web インターフェイスを介してすべての部分を接続し、ジョブテンプレートを使用してスナップショット自動化を実行します。
-
AAP UI ダッシュボードにアクセスし、Automation Execution → Templates に移動します。
-
Create Template をクリックし、Create job template を選択します。
-
以下の詳細を入力します:
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
-
Create Job Template をクリックします。
-
右上隅から Launch Template を選択してジョブを起動します。
提供されているリストアタスクファイルの理解
リストア自動化は、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
このインクルードされたタスクファイルは、次の手順に従って完全なリストアワークフローを管理します:
-
提供されたスナップショット名に基づいて
VirtualMachineSnapshot
を取得します。 -
仮想マシンを停止します。
-
VirtualMachineRestore
リソースを作成し、リストアが完了するまで待ちます。 -
仮想マシンを起動します。
---
- 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 ジョブテンプレートの作成と実行
-
AAP UI ダッシュボードにアクセスし、Automation Execution → Templates に移動します。
-
Create Template をクリックし、Create job template を選択します。
-
以下の詳細を入力します。以前に作成したスナップショットの名前を含めるように注意してください:
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>
を以前に作成したスナップショットの実際の名前 に置き換えてください。 -
Create Job Template をクリックします。
-
Launch Template をクリックしてテンプレートを起動します。