バックアップおよび復元
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 microshift
MicroShift にデプロイされたワークロードは、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 つのディレクトリーに保存し、復元する最新のバックアップを自動的に選択します。既存の バックアップ
および 復元
コマンドを変更すると、自動回復を設定できます。
このオプションは、PATH
引数を、特定のバックアップファイルへのパスとしてではなく、自動回復用のすべてのバックアップを保持するディレクトリーへのパスとして扱います。--auto-recovery オプションは、backup コマンドと restore
コマンドの両方で使用できます。
-
たとえば、
microshift restore --auto-recovery PATH
など、復元
で自動リカバリーオプションを使用する場合は、変更されたコマンドを実行すると、最新のバックアップが自動的に選択および復元されます。 -
microshift backup --auto-recovery PATH
など、microshift バックアップ
コマンドで同じオプションを使用すると、新しいバックアップが 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
ユニットを開始します。このユニットは 自動リカバリー
の復元プロセスを実行します。
ユースケースとして、systemd サービスを使用する RPM システムの自動復旧プロセスを自動化する次の例を考えてみましょう。
手順
次のコマンドを実行して、
microshift.service
のディレクトリーを作成します。$ sudo mkdir -p /usr/lib/systemd/system/microshift.service.d
microshift.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=25s 1 EOF
- 1
StartLimitInterval
の値を、デフォルトの10s
から低速なシステムの大きな値に増やします。値が低すぎると、microshift
systemd サービスが失敗したとマークされない可能性があります。つまり、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 での自動リカバリーの使用
ユースケースとして、Blueprint ファイルで systemd を使用する Red Hat Enterprise Linux for Edge (RHEL for Edge)システムの 自動リカバリー
プロセスを自動化する次の例を考えてみましょう。
systemd
を使用する OSTree システムの 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. RHEL システム用のイメージモードでの自動復旧の使用
Image Mode for RHEL はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ユースケースとして、systemd サービスを使用する Red Hat Enterprise Linux (RHEL)システムの 自動回復
プロセスを自動化する状況の例を以下に示します。
コンテナーファイルで systemd
を使用する RHEL システムのイメージモードの 自動リカバリー
プロセス全体を含める必要があります。
前提条件
- bootc イメージの構築 の手順に従って、Containerfile を 作成している。
「RPM システムで
の自動リカバリーの使用」セクションで説明されているように、10.auto-recovery.conf
およびmicroshift-auto-recovery.service
ファイルを作成している。重要10-auto-recovery.conf および
の場所は、Containerfile と相対的である必要があります。microshift-auto-recovery.
serviceたとえば、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 システムでの自動リカバリーの使用セクションで説明したように、
microshift-auto-recovery
スクリプトを作成している。
手順
以下のスニペット例を使用して、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