バックアップおよび復元


Red Hat build of MicroShift 4.18

Red Hat build of MicroShift データベースのバックアップと復元

Red Hat OpenShift Documentation Team

概要

Red Hat build of MicroShift データベースをバックアップおよび復元する方法を説明します。

第1章 MicroShift データのバックアップと復元

サポート対象のすべてのシステムで、MicroShift データベースを手動でバックアップおよび復元できます。Greenboot ヘルスチェックを完了する必要があり、バックアップの前に MicroShift サービスを停止する必要があります。

注記

次の手順では、MicroShift データのみがバックアップされます。アプリケーションデータは付属しません。

  • rpm-ostree システムでは、MicroShift は起動するたびに自動的にバックアップを作成します。これらの自動バックアップは、システムが再起動されるたびに削除され、最新のバックアップに置き換えられます。
  • rpm-ostree システムを使用している場合は、Greenboot がシステムをロールバックした後、データは自動的に復元されます。このデータ復元により、ロールバックが完了した後のデータベースは、ホスト上で実行されているソフトウェアと必ず一致します。
  • 他のタイプのシステムでは、手動でデータをバックアップおよび復元する必要があります。

1.1. MicroShift サービスの停止

次の手順を使用して、MicroShift サービスを停止します。

前提条件

  • MicroShift サービスが実行されている。

手順

  1. 次のコマンドを入力して、MicroShift サービスを停止します。

    $ sudo systemctl stop microshift
  2. MicroShift にデプロイされたワークロードは、MicroShift サービスが停止した後も引き続き実行されます。次のコマンドを入力して、実行中のワークロードを表示します。

    $ sudo crictl ps -a
  3. 次のコマンドを入力して、デプロイされたワークロードを停止します。

    $ sudo systemctl stop kubepods.slice

1.2. MicroShift データを手動でバックアップする

MicroShift データは、いつでも手動でバックアップできます。システムを更新する前にデータをバックアップし、更新が失敗した場合やその他のシステムトラブルに備えてデータを保存してください。自動バックアップは、/var/lib/microshift-backups ディレクトリーに作成されます。このディレクトリーを各コマンドで指定すると、手動でデータをバックアップおよび復元するために使用できます。バックアップを作成する際は、出力ファイルのファイルパス全体を使用する必要があります。

前提条件

  • ホストへの root アクセス権限がある。
  • MicroShift が停止している。

手順

  1. 次のコマンドを実行して、親ディレクトリーを使用し、/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"

  2. オプション: 次のコマンドを実行し、カスタム名を使用して特定の親ディレクトリーにバックアップを手動で作成します。

    $ 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 サービスを停止している。

手順

  1. 次のコマンドを実行して、復元するバックアップの完全なファイルパスを使用して 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"

  2. オプション: バックアップの完全なファイルパスを使用して、カスタマイズされたディレクトリーからデータを手動で復元します。以下のコマンドを実行します。

    $ sudo microshift restore /<mnt>/<other_backups_location>/<another_manual_backup>

    <other_backups_location> を使用したディレクトリーに置き換え、<my_manual_backup> を復元するバックアップを作成する際に使用したバックアップ名に置き換えます。

  3. ホストを再起動します。ホストを再起動すると、すべてのワークロードと 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 を停止している。

手順

  1. 次のコマンドを実行して、バックアップディレクトリーから最新のバックアップを復元します。

    $ 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 サービスに追加したり、定期的に実行する別のサービスを追加したりできます。
  2. 次のコマンドを実行して 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 システムの自動復旧プロセスを自動化する次の例を考えてみましょう。

手順

  1. 次のコマンドを実行して、microshift.service のディレクトリーを作成します。

    $ sudo mkdir -p /usr/lib/systemd/system/microshift.service.d
  2. microshift.service が失敗したときに systemdmicroshift-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= サービスはトリガーされません。
  3. 次のコマンドを実行して、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
  4. 次のコマンドを実行して、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
  5. 次のコマンドを実行してスクリプトを実行可能にします。

    $ sudo chmod +x /usr/bin/microshift-auto-recovery
  6. 次のコマンドを実行してシステム設定を再ロードします。

    $ 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 ツールをインストールしている。

手順

  1. オプション: composer-cli/etc ディレクトリーにのみファイルを作成できるため、ブループリントを含む RPM にファイルをパッケージ化します。
  2. ブループリントファイルを作成するには、次の例を使用します。

    [[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"
    """
  3. 次の手順は、イメージのビルドの準備 を参照してください。

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 および 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 システムでの自動リカバリーの使用セクションで説明したように、microshift-auto-recovery スクリプトを作成している。

手順

  1. 以下のスニペット例を使用して、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 リポジトリーがホスト上で利用できないと、ビルドは失敗します。

  2. 次のイメージビルドコマンドを実行して、ローカル 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

法律上の通知

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.