バックアップおよび復元
Red Hat build of MicroShift データベースのバックアップと復元
概要
第1章 MicroShift データのバックアップと復元 リンクのコピーリンクがクリップボードにコピーされました!
サポート対象のすべてのシステムで、MicroShift データベースを手動でバックアップおよび復元できます。Greenboot ヘルスチェックを完了する必要があり、バックアップの前に MicroShift サービスを停止する必要があります。
次の手順では、MicroShift データのみがバックアップされます。アプリケーションデータは付属しません。
-
rpm-ostreeシステムでは、MicroShift は起動するたびに自動的にバックアップを作成します。これらの自動バックアップは、システムが再起動されるたびに削除され、最新のバックアップに置き換えられます。 -
rpm-ostreeシステムを使用している場合は、Greenboot がシステムをロールバックした後、データは自動的に復元されます。このデータ復元により、ロールバックが完了した後のデータベースは、ホスト上で実行されているソフトウェアと必ず一致します。 - 他のタイプのシステムでは、手動でデータをバックアップおよび復元する必要があります。
1.1. MicroShift サービスの停止 リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、MicroShift サービスを停止します。
前提条件
- MicroShift サービスが実行されている。
手順
次のコマンドを入力して、MicroShift サービスを停止します。
$ sudo systemctl stop microshiftMicroShift にデプロイされたワークロードは、MicroShift サービスが停止した後も引き続き実行されます。次のコマンドを入力して、実行中のワークロードを表示します。
$ sudo crictl ps -a次のコマンドを入力して、デプロイされたワークロードを停止します。
$ sudo systemctl stop kubepods.slice
1.2. MicroShift データを手動でバックアップする リンクのコピーリンクがクリップボードにコピーされました!
MicroShift データは、いつでも手動でバックアップできます。システムを更新する前にデータをバックアップし、更新が失敗した場合やその他のシステムトラブルに備えてデータを保存してください。自動バックアップは、/var/lib/microshift-backups ディレクトリーに作成されます。このディレクトリーを各コマンドで指定すると、手動でデータをバックアップおよび復元するために使用できます。バックアップを作成する際は、出力ファイルのファイルパス全体を使用する必要があります。
前提条件
- ホストへの root アクセス権限がある。
- MicroShift が停止している。
手順
次のコマンドを実行して、親ディレクトリーを使用し、
/var/lib/microshift-backups/<my_manual_backup>などの名前を指定してバックアップを手動で作成します。$ sudo microshift backup /var/lib/microshift-backups/<my_manual_backup><my_manual_backup>を、使用するバックアップ名に置き換えます。出力例
??? I1017 07:38:16.770506 5900 data_manager.go:92] "Copying data to backup directory" storage="/var/lib/microshift-backups" name="test" data="/var/lib/microshift" ??? I1017 07:38:16.770713 5900 data_manager.go:227] "Starting copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift /var/lib/microshift-backups/test" ??? I1017 07:38:16.776162 5900 data_manager.go:241] "Finished copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift /var/lib/microshift-backups/test" ??? I1017 07:38:16.776256 5900 data_manager.go:125] "Copied data to backup directory" backup="/var/lib/microshift-backups/test" data="/var/lib/microshift"オプション: 次のコマンドを実行し、カスタム名を使用して特定の親ディレクトリーにバックアップを手動で作成します。
$ sudo microshift backup /mnt/<other_backups_location>/<another_manual_backup><other_backups_location>を使用するディレクトリーに置き換え、<my_manual_backup>を使用するバックアップ名に置き換えます。
検証
-
選択したディレクトリー内のデータを表示して、バックアップが存在することを確認できます。たとえば、
/var/lib/microshift-backups/<my_manual_backup>/または/mnt/<other_backups_location>/<another_manual_backup>などです。
1.3. MicroShift データのバックアップを手動で復元する リンクのコピーリンクがクリップボードにコピーされました!
MicroShift データをバックアップから手動で復元できます。更新後や、必要なデータを削除したり破損させたりするシステムのイベントの発生後にバックアップを復元できます。自動バックアップは、デフォルトで /var/lib/microshift-backups ディレクトリーにあります。このディレクトリーを各コマンドで指定すると、手動でデータをバックアップおよび復元するために使用できます。バックアップを復元する場合は、ファイルパス全体を使用する必要があります。
rpm-ostree システムの場合、MicroShift はデータを自動的にバックアップおよび復元します。
前提条件
- ホストへの root アクセス。
- データのバックアップファイルに対する完全パス。
- MicroShift サービスを停止している。
手順
次のコマンドを実行して、復元するバックアップの完全なファイルパスを使用して MicroShift データを手動で復元します。
$ sudo microshift restore /var/lib/microshift-backups/<my_manual_backup><my_manual_backup>を、使用したバックアップ名に置き換えます。オプション: 完全なファイルパスを使用して、自動ostreeバックアップを復元することもできます。出力例
??? I1017 07:39:52.055165 6007 data_manager.go:131] "Copying backup to data directory" storage="/var/lib/microshift-backups" name="test" data="/var/lib/microshift" ??? I1017 07:39:52.055243 6007 data_manager.go:154] "Renaming existing data dir" data="/var/lib/microshift" renamedTo="/var/lib/microshift.saved" ??? I1017 07:39:52.055326 6007 data_manager.go:227] "Starting copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift-backups/test /var/lib/microshift" ??? I1017 07:39:52.061363 6007 data_manager.go:241] "Finished copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift-backups/test /var/lib/microshift" ??? I1017 07:39:52.061404 6007 data_manager.go:175] "Removing temporary data directory" path="/var/lib/microshift.saved" ??? I1017 07:39:52.063745 6007 data_manager.go:180] "Copied backup to data directory" name="test" data="/var/lib/microshift"オプション: バックアップの完全なファイルパスを使用して、カスタマイズされたディレクトリーからデータを手動で復元します。以下のコマンドを実行します。
$ sudo microshift restore /<mnt>/<other_backups_location>/<another_manual_backup><other_backups_location>を使用したディレクトリーに置き換え、<my_manual_backup>を復元するバックアップを作成する際に使用したバックアップ名に置き換えます。- ホストを再起動します。ホストを再起動すると、すべてのワークロードと Pod が再起動できるようになります。
検証
-
oc get pods -Aコマンドを使用してクラスターが実行中であることを確認してから、復元されたデータを確認します。
第2章 手動バックアップからの自動リカバリー リンクのコピーリンクがクリップボードにコピーされました!
自動リカバリーを設定すると、MicroShift の起動に失敗した場合、手動バックアップからデータを自動的に復元できます。
2.1. バックアップおよび復元コマンドを変更してデータ復旧を自動化する リンクのコピーリンクがクリップボードにコピーされました!
自動リカバリーオプションを使用して、すべてのバックアップを 1 つのディレクトリーに保存し、復元する最新のバックアップを自動的に選択します。既存の backup および restore コマンドを変更すると、自動リカバリーを設定できます。
--auto-recovery オプションは、PATH 引数を、特定のバックアップファイルへのパスとしてではなく、自動リカバリーのすべてのバックアップを保持するディレクトリーへのパスとして扱います。--auto-recovery オプションは、backup と restore コマンドの両方で使用できます。
-
たとえば、
microshift restore --auto-recovery PATHなど、restoreで自動リカバリーオプションを使用する場合は、変更されたコマンドを実行すると、最新のバックアップが自動的に選択および復元されます。 -
microshift backup --auto-recovery PATHなど、microshift backupコマンドで同じオプションを使用すると、新しいバックアップが PATH に作成されます。 -
デフォルトでは、
microshift restore --auto-recovery PATHは、失敗した MicroShift データをPATH/failedに作成します。失敗したバックアップデータの作成を無効にする場合は、--dont-save-failedオプションを追加できます。
restore コマンドでは、--dont-save-failed オプションのみを使用できます。
2.2. 自動回復機能を使用したバックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
自動リカバリーオプションを使用してバックアップを作成するには、次の手順を実行します。
バックアップを作成するには MicroShift を停止する必要があるため、MicroShift を停止する最適なタイミングを決定する必要があります。
前提条件
- MicroShift を停止した。
手順
次のコマンドを実行して、バックアップを作成して選択したディレクトリーに保存します。
$ sudo microshift backup --auto-recovery <path_of_directory>1 - 1
<path_of_directory>を、バックアップを保存するディレクトリーのパスに置き換えます。たとえば、/var/lib/microshift-auto-recoveryです。
注記--auto-recoveryオプションは、PATH引数の解釈を、最終バックアップパスから、自動リカバリーの全バックアップを格納するディレクトリーに変更します。出力例
??? I1104 09:18:52.100725 8906 system.go:58] "OSTree deployments" deployments=[{"id":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","booted":true,"staged":false,"pinned":false},{"id":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","booted":false,"staged":false,"pinned":false}] ??? I1104 09:18:52.100895 8906 data_manager.go:83] "Copying data to backup directory" storage="/var/lib/microshift-auto-recovery" name="20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1" data="/var/lib/microshift" ??? I1104 09:18:52.102296 8906 disk_space.go:33] Calculated size of "/var/lib/microshift": 261M - increasing by 10% for safety: 287M ??? I1104 09:18:52.102321 8906 disk_space.go:44] Calculated available disk space for "/var/lib/microshift-auto-recovery": 1658M ??? I1104 09:18:52.105700 8906 atomic_dir_copy.go:66] "Made an intermediate copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift /var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1.tmp.99142" ??? I1104 09:18:52.105732 8906 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1.tmp.99142" dest="/var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1" ??? I1104 09:18:52.105749 8906 data_manager.go:120] "Copied data to backup directory" backup="/var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1" data="/var/lib/microshift" /var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1
検証
次のコマンドを実行して、作成したバックアップがカスタマイズされたストレージディレクトリーに存在することを確認します。
$ sudo ls -la <path_of_directory>1 - 1
<path_of_directory>を、バックアップを保存するディレクトリーのパスに置き換えます。たとえば、/var/lib/microshift-auto-recoveryです。
2.3. 自動回復機能を使用したバックアップの復元 リンクのコピーリンクがクリップボードにコピーされました!
必要なデータが削除または破損するシステムイベントが発生した後でも、バックアップを復元できます。自動リカバリーを使用してバックアップを復元するには、次の手順を実行します。自動リカバリーは最新のバックアップを選択して復元します。これまでに自動リカバリーを使用して復元されたバックアップは、PATH/restored ディレクトリーに移動されます。
前提条件
- MicroShift を停止している。
手順
次のコマンドを実行して、バックアップディレクトリーから最新のバックアップを復元します。
$ sudo microshift restore --auto-recovery <path_of_directory>1 - 1
<path_of_directory>を、バックアップを保存するディレクトリーのパスに置き換えます。たとえば、/var/lib/microshift-auto-recoveryです。
注記-
--auto-recoveryオプションは、後で調査できるように MicroShift データを/var/lib/microshift-auto-recovery/failed/にコピーし、最新のバックアップを選択して復元します。 -
--dont-save-failedオプションは、失敗した MicroShift データのバックアップを無効にします。
出力例
??? I1104 09:19:28.617225 8950 state.go:80] "Read state from the disk" state={"LastBackup":"20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"} ??? I1104 09:19:28.617323 8950 storage.go:78] "Auto-recovery backup storage read and parsed" dirs=["20241022101255_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","20241022101520_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","restored"] backups=[{"CreationTime":"2024-10-22T10:12:55Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-10-22T10:15:20Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-10-22T10:15:28Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}] ??? I1104 09:19:28.617350 8950 storage.go:40] "Filtered list of backups - removed previously restored backup" removed="20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0" newList=[{"CreationTime":"2024-10-22T10:12:55Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-10-22T10:15:20Z","Version":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0"},{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}] ??? I1104 09:19:28.633237 8950 system.go:58] "OSTree deployments" deployments=[{"id":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","booted":true,"staged":false,"pinned":false},{"id":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","booted":false,"staged":false,"pinned":false}] ??? I1104 09:19:28.633258 8950 storage.go:49] "Filtered list of backups by version" version="default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1" newList=[{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}] ??? I1104 09:19:28.633268 8950 restore.go:170] "Potential backups" bz=[{"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"}] ??? I1104 09:19:28.633277 8950 restore.go:173] "Candidate backup for restore" b={"CreationTime":"2024-11-04T09:18:52Z","Version":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1"} ??? I1104 09:19:28.634007 8950 disk_space.go:33] Calculated size of "/var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1": 261M - increasing by 10% for safety: 287M ??? I1104 09:19:28.634096 8950 disk_space.go:44] Calculated available disk space for "/var/lib": 1658M ??? I1104 09:19:28.634507 8950 disk_space.go:33] Calculated size of "/var/lib/microshift": 261M - increasing by 10% for safety: 287M ??? I1104 09:19:28.634522 8950 disk_space.go:44] Calculated available disk space for "/var/lib/microshift-auto-recovery": 1658M ??? I1104 09:19:28.649719 8950 system.go:58] "OSTree deployments" deployments=[{"id":"default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1","booted":true,"staged":false,"pinned":false},{"id":"default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0","booted":false,"staged":false,"pinned":false}] ??? I1104 09:19:28.653880 8950 atomic_dir_copy.go:66] "Made an intermediate copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift /var/lib/microshift-auto-recovery/failed/20241104091928_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1.tmp.22742" ??? I1104 09:19:28.657362 8950 atomic_dir_copy.go:66] "Made an intermediate copy" cmd="/bin/cp --verbose --recursive --preserve --reflink=auto /var/lib/microshift-auto-recovery/20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1 /var/lib/microshift.tmp.482" ??? I1104 09:19:28.657385 8950 state.go:40] "Saving intermediate state" state="{\"LastBackup\":\"20241104091852_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1\"}" path="/var/lib/microshift-auto-recovery/state.json.tmp.41544" ??? I1104 09:19:28.662438 8950 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift.tmp.482" dest="/var/lib/microshift" ??? I1104 09:19:28.662451 8950 state.go:46] "Moving state file to final path" intermediatePath="/var/lib/microshift-auto-recovery/state.json.tmp.41544" finalPath="/var/lib/microshift-auto-recovery/state.json" ??? I1104 09:19:28.662521 8950 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift-auto-recovery/failed/20241104091928_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1.tmp.22742" dest="/var/lib/microshift-auto-recovery/failed/20241104091928_default-b3442053c9ce69310cd54140d8d592234c5306e4c5132de6efe615f79c84300a.1" ??? I1104 09:19:28.662969 8950 atomic_dir_copy.go:115] "Renamed to final destination" src="/var/lib/microshift-auto-recovery/20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0" dest="/var/lib/microshift-auto-recovery/restored/20241022101528_default-a129624b9233fa54fe3574f1aa211bc2d85e1052b52245fe7d83f10c2f6d28e3.0" ??? I1104 09:19:28.662983 8950 restore.go:141] "Auto-recovery restore completed".重要-
restoreコマンドは復元後に MicroShift を再起動しません。このコマンドを実行した時点で、MicroShift サービスはすでに障害で停止しているか、ユーザーによって停止されています。 - MicroShift は、どのファイルシステムのディスク領域も監視しません。自動化によって古いバックアップの削除が処理されるようにする必要があります。たとえば、このプロセスを auto-recovery サービスに追加したり、定期的に実行する別のサービスを追加したりできます。
次のコマンドを実行して MicroShift を再起動します。
$ sudo systemctl restart microshift
検証
次のコマンドを実行して、MicroShift が正常に開始されたことを確認します。
$ oc get pods -A出力例
NAMESPACE NAME READY STATUS RESTARTS AGE default i-06166fbb376f14a8bus-west-2computeinternal-debug-qtwcr 1/1 Running 0 46m kube-system csi-snapshot-controller-5c6586d546-lprv4 1/1 Running 0 51m openshift-dns dns-default-45jl7 2/2 Running 0 50m openshift-dns node-resolver-7wmzf 1/1 Running 0 51m openshift-ingress router-default-78b86fbf9d-qvj9s 1/1 Running 0 51m openshift-ovn-kubernetes ovnkube-master-5rfhh 4/4 Running 0 51m openshift-ovn-kubernetes ovnkube-node-gcnt6 1/1 Running 0 51m openshift-service-ca service-ca-bf5b7c9f8-pn6rk 1/1 Running 0 51m openshift-storage topolvm-controller-549f7fbdd5-7vrmv 5/5 Running 0 51m openshift-storage topolvm-node-rht2m 3/3 Running 0 50m注記この出力例は、基本的な MicroShift を示しています。オプションの RPM をインストールしている場合は、それらのサービスを実行している Pod のステータスも出力に表示されるはずです。
2.3.1. RPM システムでの自動リカバリーの使用 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift が failed 状態になると、systemd サービスは microshift-auto-recovery.service ユニットを開始します。このユニットは auto-recovery の復元プロセスを実行します。
ユースケースとして、systemd サービスを使用する RPM システムの自動リカバリープロセスを自動化する次の例を考えてみましょう。
手順
次のコマンドを実行して、
microshiftのディレクトリーを作成します。$ sudo mkdir -p /usr/lib/systemd/system/microshift.service.dmicroshift.serviceが失敗したときにsystemdにmicroshift-auto-recovery.serviceを実行するように指示するには、次のコマンドを実行して10-auto-recovery.confファイルを作成します。$ sudo tee /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf > /dev/null <<'EOF' [Unit] OnFailure=microshift-auto-recovery.service StartLimitIntervalSec=25s1 EOF- 1
- 低速なシステムの場合は、
StartLimitInterval値をデフォルトの10sからより大きな値に増やします。値が低すぎると、systemd がmicroshiftsystemd サービスを失敗としてマークしなくなり、OnFailure=サービスがトリガーされなくなります。
次のコマンドを実行して、
microshift-auto-recovery.serviceファイルを作成します。$ sudo tee /usr/lib/systemd/system/microshift-auto-recovery.service > /dev/null <<'EOF' [Unit] Description=MicroShift auto-recovery [Service] Type=oneshot ExecStart=/usr/bin/microshift-auto-recovery [Install] WantedBy=multi-user.target EOF次のコマンドを実行して、
microshift-auto-recoveryスクリプトを作成します。$ sudo tee /usr/bin/microshift-auto-recovery > /dev/null <<'EOF' #!/usr/bin/env bash set -xeuo pipefail # If greenboot uses a non-default file for clearing boot_counter, use boot_success instead. if grep -q "/boot/grubenv" /usr/libexec/greenboot/greenboot-grub2-set-success; then if grub2-editenv - list | grep -q ^boot_success=0; then echo "Greenboot didn't decide the system is healthy after staging new deployment." echo "Quitting to not interfere with the process" exit 0 fi else if grub2-editenv - list | grep -q ^boot_counter=; then echo "Greenboot didn't decide the system is healthy after staging a new deployment." echo "Quitting to not interfere with the process" exit 0 fi fi /usr/bin/microshift restore --auto-recovery /var/lib/microshift-auto-recovery /usr/bin/systemctl reset-failed microshift /usr/bin/systemctl start microshift echo "DONE" EOF次のコマンドを実行してスクリプトを実行可能にします。
$ sudo chmod +x /usr/bin/microshift-auto-recovery次のコマンドを実行してシステム設定を再ロードします。
$ sudo systemctl daemon-reload
2.3.2. RHEL for Edge での自動リカバリーの使用 リンクのコピーリンクがクリップボードにコピーされました!
ユースケースとして、ブループリントファイルで systemd を使用する Red Hat Enterprise Linux for Edge (RHEL for Edge) システムの auto-recovery プロセスを自動化する次の例を検討してください。
systemd を使用する RHEL for Edge システムの auto-recovery プロセス全体をブループリントファイルに含める必要があります。
前提条件
- Podman がインストールされている。
-
コマンドラインの
composer-cliツールがインストールされている。
手順
-
オプション:
composer-cliは/etcディレクトリーにのみファイルを作成できるため、ブループリントが含まれる RPM にファイルをパッケージ化します。 ブループリントファイルを作成するには、次の例を使用します。
[[customizations.directories]] path = "/etc/systemd/system/microshift.service.d" [[customizations.directories]] path = "/etc/bin" [[customizations.files]] path = "/etc/systemd/system/microshift.service.d/10-auto-recovery.conf" data = """ [Unit] OnFailure=microshift-auto-recovery.service """ [[customizations.files]] path = "/etc/systemd/system/microshift-auto-recovery.service" data = """ [Unit] Description=MicroShift auto-recovery [Service] Type=oneshot ExecStart=/etc/bin/microshift-auto-recovery [Install] WantedBy=multi-user.target """ [[customizations.files]] path = "/etc/bin/microshift-auto-recovery" mode = "0755" data = """ #!/usr/bin/env bash set -xeuo pipefail # If greenboot uses a non-default file for clearing boot_counter, use boot_success instead. if grep -q "/boot/grubenv" /usr/libexec/greenboot/greenboot-grub2-set-success; then if grub2-editenv - list | grep -q ^boot_success=0; then echo "Greenboot didn't decide the system is healthy after staging a new deployment." echo "Quitting to not interfere with the process" exit 0 fi else if grub2-editenv - list | grep -q ^boot_counter=; then echo "Greenboot didn't decide the system is healthy after staging a new deployment." echo "Quitting to not interfere with the process" exit 0 fi fi /usr/bin/microshift restore --auto-recovery /var/lib/microshift-auto-recovery /usr/bin/systemctl reset-failed microshift /usr/bin/systemctl start microshift echo "DONE" """- 次の手順は、イメージのビルドの準備 を参照してください。
2.3.3. Image Mode for RHEL での自動リカバリーの使用 リンクのコピーリンクがクリップボードにコピーされました!
Image Mode for RHEL はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ユースケースとして、systemd サービスを使用する Image Mode for Red Hat Enterprise Linux (RHEL) システムの auto-recovery プロセスを自動化する次の例を検討してください。
コンテナーファイルで systemd を使用する image mode for RHEL の auto-recovery プロセス全体を含める必要があります。
前提条件
- bootc イメージの構築 の手順に従って、Containerfile を作成している。
「RPM システムでの auto-recovery の使用」セクションで説明されているように
10-auto-recovery.confファイルとmicroshift-auto-recovery.serviceファイルを作成した。重要10-auto-recovery.confおよびmicroshift-auto-recovery.serviceの場所は、Containerfile を起点にする必要があります。たとえば、Containerfile へのパスが
/home/microshift/my-build/Containerfileの場合、適切に埋め込むには systemd ファイルが隣接している必要があります。この例では、正しいパスは以下のとおりです。-
/home/microshift/my-build/auto-rec/10-auto-recovery.conf -
/home/microshift/my-build/auto-rec/microshift-auto-recovery.service -
/home/microshift/my-build/auto-rec/microshift-auto-recovery
-
-
「RPM システムでの auto-recovery の使用」セクションで説明されているように
microshift-auto-recoveryスクリプトを作成した。
手順
以下のスニペット例を使用して、image mode for RHEL イメージを準備するために使用するコンテナーファイルを更新します。
RUN mkdir -p /usr/lib/systemd/system/microshift.service.d COPY ./auto-rec/10-auto-recovery.conf /usr/lib/systemd/system/microshift.service.d/10-auto-recovery.conf COPY ./auto-rec/microshift-auto-recovery.service /usr/lib/systemd/system/ COPY ./auto-rec/microshift-auto-recovery /usr/bin/ RUN chmod +x /usr/bin/microshift-auto-recovery重要Podman は、コンテナーイメージをビルドするときに、コンテナー内のホストのサブスクリプション情報とリポジトリーを使用します。
rhocpおよびfast-datapathリポジトリーがホスト上で利用できないと、ビルドは失敗します。次のイメージビルドコマンドを実行して、ローカル bootc イメージを再構築します。
PULL_SECRET=~/.pull-secret.json USER_PASSWD=<your_redhat_user_password> IMAGE_NAME=microshift-4.18-bootc sudo podman build --authfile "${PULL_SECRET}" -t "${IMAGE_NAME}" \ --build-arg USER_PASSWD="${USER_PASSWD}" \ -f Containerfile注記シークレットは、イメージのビルド中に次のように使用されます。
-
registry.redhat.ioレジストリーからベースrhel-bootc:9.4イメージをプルするには、podman--authfile引数が必要です。 -
ビルド
USER_PASSWD引数は、redhatユーザーのパスワードを設定するために使用されます。
-
検証
次のコマンドを実行して、ローカル bootc イメージが作成されたことを確認します。
$ sudo podman images "${IMAGE_NAME}"出力例
REPOSITORY TAG IMAGE ID CREATED SIZE localhost/microshift-4.18-bootc latest 193425283c00 2 minutes ago 2.31 GB