第4章 環境全体のバックアップの作成

環境全体のバックアップの作成には、インスタンスのクラッシュまたはデータの破損時の復元に役立つ重要なデータをコピーすることが必要になります。バックアップの作成後、それらは関連コンポーネントの新規バージョンに復元できます。

OpenShift Container Platform では、クラスター全体の バックアップ を作成できます。これにより、クラスターの現在の状態 (現在のクラスター設定) を別のストレージに保存できます。環境バックアップの状態には以下が含まれます。

  • クラスターデータファイル
  • 各マスターの etcd データ
  • API オブジェクト
  • レジストリーストレージ
  • ボリュームストレージ

バックアップは、データの損失を防ぐために定期的に実行します。

重要

以下のプロセスでは、アプリケーションおよび OpenShift Container Platform クラスターをバックアップするための通常の方法について説明しています。ここではカスタム要件は考慮されません。クラスターの完全バックアップおよび復元手順の基本として以下の手順を使用してください。また、データ損失を防ぐために必要なすべての措置を取る必要があります。

バックアップと復元は保証されるものではなく、独自のデータは各自でバックアップしておく必要があります。

4.1. マスターホストのバックアップの作成

バックアッププロセスは、システム更新やアップグレードまたはその他の大きな変更を含む変更を OpenShift Container Platform インフラストラクチャーに加える前に実行します。データのバックアップは、障害発生時に最新データが利用可能になるように定期的に実行します。

OpenShift Container Platform ファイル

マスターインスタンスは API、コントローラーなどの重要なサービスを実行します。/etc/origin/master ディレクトリーには、以下のような重要なファイルが数多く格納されています。

  • 設定、API コントローラー、サービスなど
  • インストールで生成される証明書
  • すべてのクラウドプロバイダー関連の設定
  • キーおよびその他の認証ファイル (htpasswd を使用する場合は htpasswd など)
  • その他

ログレベルの引き上げやプロキシーの使用などのカスタマイズを OpenShift Container Platform サービスに対して行うことができます。設定ファイルは /etc/sysconfig ディレクトリーに保存されます。

マスターはノードでもあるため、/etc/origin ディレクトリー全体のバックアップを作成します。

手順

重要

各マスターノードで以下の手順を実行する必要があります。

  1. Pod 定義のバックアップを作成します。ここに置かれます。
  2. マスターホストの設定ファイルのバックアップを作成します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/ ${MYBACKUPDIR}/etc/sysconfig/
    注記

    マスター設定ファイルは /etc/origin/master/master-config.yaml です。

    警告

    /etc/origin/master/ca.serial.txt ファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に /etc/origin/master/ca.serial.txt ファイルを残りのマスターホストにコピーします。

    重要

    複数のマスターを実行する OpenShift Container Platform 3.11 クラスターでは、マスターノードの 1 つの /etc/origin/master/etc/etcd/ca および /etc/etcd/generated_certs に追加の CA 証明書が含まれます。これらはアプリケーションノードおよび etcd ノードのスケールアップ操作に必要であり、元のマスターが永続的に利用不可になる場合に別のマスターで復元される必要があります。これらのディレクトリーは、ここで説明されているバックアップ手順にデフォルトで含まれています。

  3. バックアップの計画時に考慮する必要のある他の重要なファイルには以下が含まれます。

    ファイル

    説明

    /etc/cni/*

    コンテナーネットワークインターフェースの設定 (使用される場合)

    /etc/sysconfig/iptables

    iptables ルールが保存される場所

    /etc/sysconfig/docker-storage-setup

    container-storage-setup コマンドの入力ファイル

    /etc/sysconfig/docker

    docker 設定ファイル

    /etc/sysconfig/docker-network

    docker ネットワーク設定 (例: MTU)

    /etc/sysconfig/docker-storage

    docker ストレージ設定 (container-storage-setup で生成される)

    /etc/dnsmasq.conf

    dnsmasq の主要な設定ファイル

    /etc/dnsmasq.d/*

    異なる dnsmasq 設定ファイル

    /etc/sysconfig/flanneld

    flannel 設定ファイル (使用される場合)

    /etc/pki/ca-trust/source/anchors/

    システムに追加される証明書 (例: 外部レジストリー用)

    上記のファイルのバックアップを作成します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  4. パッケージが間違って削除されてしまう場合や、rpm パッケージに含まれるファイルを復元する必要がある場合に、システムにインストールされている rhel パッケージの一覧があると便利です。

    注記

    コンテンツビューやファクトストアなどの Red Hat Satellite 機能を使用する場合は、見つからないパッケージやシステムにインストールされているパッケージの履歴データを再インストールする適切なメカニズムを指定します。

    システムにインストールされている現在の rhel パッケージの一覧を作成するには、以下を実行します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  5. これまでの手順を実行している場合、以下のファイルがバックアップディレクトリーに置かれます。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/master/ca.crt
    etc/origin/master/ca.key
    etc/origin/master/ca.serial.txt
    etc/origin/master/ca-bundle.crt
    etc/origin/master/master.proxy-client.crt
    etc/origin/master/master.proxy-client.key
    etc/origin/master/service-signer.crt
    etc/origin/master/service-signer.key
    etc/origin/master/serviceaccounts.private.key
    etc/origin/master/serviceaccounts.public.key
    etc/origin/master/openshift-master.crt
    etc/origin/master/openshift-master.key
    etc/origin/master/openshift-master.kubeconfig
    etc/origin/master/master.server.crt
    etc/origin/master/master.server.key
    etc/origin/master/master.kubelet-client.crt
    etc/origin/master/master.kubelet-client.key
    etc/origin/master/admin.crt
    etc/origin/master/admin.key
    etc/origin/master/admin.kubeconfig
    etc/origin/master/etcd.server.crt
    etc/origin/master/etcd.server.key
    etc/origin/master/master.etcd-client.key
    etc/origin/master/master.etcd-client.csr
    etc/origin/master/master.etcd-client.crt
    etc/origin/master/master.etcd-ca.crt
    etc/origin/master/policy.json
    etc/origin/master/scheduler.json
    etc/origin/master/htpasswd
    etc/origin/master/session-secrets.yaml
    etc/origin/master/openshift-router.crt
    etc/origin/master/openshift-router.key
    etc/origin/master/registry.crt
    etc/origin/master/registry.key
    etc/origin/master/master-config.yaml
    etc/origin/generated-configs/master-master-1.example.com/master.server.crt
    ...[OUTPUT OMITTED]...
    etc/origin/cloudprovider/openstack.conf
    etc/origin/node/system:node:master-0.example.com.crt
    etc/origin/node/system:node:master-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:master-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    必要な場合は、ファイルを圧縮してスペースを節約することができます。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

これらのファイルのいずれかをゼロから作成するには、openshift-ansible-contrib リポジトリーに含まれる backup_master_node.sh スクリプトを使用します。このスクリプトは前述の手順を実行し、スクリプトが実行され、前述のすべてのファイルがコピーされるホスト上のディレクトリーを作成します。

注記

openshift-ansible-contrib スクリプトは Red Hat ではサポートされていませんが、リファレンスアーキテクチャーチームはコードが定義通りに動作し、安全であることを確認するテストを実施しています。

このスクリプトは、以下のコマンドを使用してすべてのマスターホストで実行することができます。

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

4.2. ノードホストのバックアップの作成

ノードホストのバックアップの作成は、マスターホストのバックアップとは異なるユースケースになります。マスターホストには数多くの重要なファイルが含まれるため、バックアップの作成は強く推奨されます。しかしノードの場合、その性質として特殊なものはフェイルオーバー時にノード全体で複製され、通常はそれらに環境の実行に必要なデータは含まれません。ノードのバックアップ作成は、環境の実行に必要なものが含まれる場合に実行することが推奨されます。

バックアッププロセスは、システム更新やアップグレードまたはその他の大きな変更を含む変更をインフラストラクチャーに加える前に実行します。バックアップは、障害の発生時に最新データが利用可能になるように定期的に実行する必要があります。

OpenShift Container Platform ファイル

ノードインスタンスはコンテナーをベースとする Pod の形式で実行されます。/etc/origin/ および /etc/origin/node ディレクトリーは以下のような重要なファイルを格納します。

  • ノードサービスの設定
  • インストールで生成される証明書
  • クラウドプロバイダー関連の設定
  • キーおよびその他の認証ファイル (dnsmasq 設定など)

OpenShift Container Platform サービスは、ログレベルの引き上げやプロキシーの使用などを実行するためにカスタマイズでき、設定ファイルは /etc/sysconfig ディレクトリーに保存されます。

手順

  1. ノード設定ファイルのバックアップを作成します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo cp -aR /etc/origin ${MYBACKUPDIR}/etc
    $ sudo cp -aR /etc/sysconfig/atomic-openshift-node ${MYBACKUPDIR}/etc/sysconfig/
  2. OpenShift Container Platform は、バックアップポリシーの計画時に考慮する必要のある特定のファイルを使用します。これには以下が含まれます。

    ファイル

    説明

    /etc/cni/*

    コンテナーネットワークインターフェースの設定 (使用される場合)

    /etc/sysconfig/iptables

    iptables ルールが保存される場所

    /etc/sysconfig/docker-storage-setup

    container-storage-setup コマンドの入力ファイル

    /etc/sysconfig/docker

    docker 設定ファイル

    /etc/sysconfig/docker-network

    docker ネットワーク設定 (例: MTU)

    /etc/sysconfig/docker-storage

    docker ストレージ設定 (container-storage-setup で生成される)

    /etc/dnsmasq.conf

    dnsmasq の主要な設定ファイル

    /etc/dnsmasq.d/*

    異なる dnsmasq 設定ファイル

    /etc/sysconfig/flanneld

    flannel 設定ファイル (使用される場合)

    /etc/pki/ca-trust/source/anchors/

    システムに追加される証明書 (例: 外部レジストリー用)

    これらのファイルを作成するには、以下を実行します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/sysconfig
    $ sudo mkdir -p ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors
    $ sudo cp -aR /etc/sysconfig/{iptables,docker-*,flanneld} \
        ${MYBACKUPDIR}/etc/sysconfig/
    $ sudo cp -aR /etc/dnsmasq* /etc/cni ${MYBACKUPDIR}/etc/
    $ sudo cp -aR /etc/pki/ca-trust/source/anchors/* \
        ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/
  3. パッケージが間違って削除されてしまう場合や、rpm パッケージに含まれるファイルを復元する必要がある場合に、システムにインストールされている rhel パッケージの一覧があると便利です。

    注記

    コンテンツビューやファクトストアなどの Red Hat Satellite 機能を使用する場合は、見つからないパッケージやシステムにインストールされているパッケージの履歴データを再インストールする適切なメカニズムを指定します。

    システムにインストールされている現在の rhel パッケージの一覧を作成するには、以下を実行します。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo mkdir -p ${MYBACKUPDIR}
    $ rpm -qa | sort | sudo tee $MYBACKUPDIR/packages.txt
  4. 以下のファイルがバックアップディレクトリーに置かれます。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n'
    etc/sysconfig/atomic-openshift-node
    etc/sysconfig/flanneld
    etc/sysconfig/iptables
    etc/sysconfig/docker-network
    etc/sysconfig/docker-storage
    etc/sysconfig/docker-storage-setup
    etc/sysconfig/docker-storage-setup.rpmnew
    etc/origin/node/system:node:app-node-0.example.com.crt
    etc/origin/node/system:node:app-node-0.example.com.key
    etc/origin/node/ca.crt
    etc/origin/node/system:node:app-node-0.example.com.kubeconfig
    etc/origin/node/server.crt
    etc/origin/node/server.key
    etc/origin/node/node-dnsmasq.conf
    etc/origin/node/resolv.conf
    etc/origin/node/node-config.yaml
    etc/origin/node/flannel.etcd-client.key
    etc/origin/node/flannel.etcd-client.csr
    etc/origin/node/flannel.etcd-client.crt
    etc/origin/node/flannel.etcd-ca.crt
    etc/origin/cloudprovider/openstack.conf
    etc/pki/ca-trust/source/anchors/openshift-ca.crt
    etc/pki/ca-trust/source/anchors/registry-ca.crt
    etc/dnsmasq.conf
    etc/dnsmasq.d/origin-dns.conf
    etc/dnsmasq.d/origin-upstream-dns.conf
    etc/dnsmasq.d/node-dnsmasq.conf
    packages.txt

    必要な場合は、ファイルを圧縮してスペースを節約することができます。

    $ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d)
    $ sudo tar -zcvf /backup/$(hostname)-$(date +%Y%m%d).tar.gz $MYBACKUPDIR
    $ sudo rm -Rf ${MYBACKUPDIR}

これらのファイルのいずれかをゼロから作成するには、openshift-ansible-contrib リポジトリーに含まれる backup_master_node.sh スクリプトを使用します。このスクリプトは前述の手順を実行し、スクリプトが実行され、前述のすべてのファイルがコピーされるホスト上のディレクトリーを作成します。

注記

openshift-ansible-contrib スクリプトは Red Hat ではサポートされていませんが、リファレンスアーキテクチャーチームはコードが定義通りに動作し、安全であることを確認するテストを実施しています。

このスクリプトは、以下を実行してすべてのマスターで実行することができます。

$ mkdir ~/git
$ cd ~/git
$ git clone https://github.com/openshift/openshift-ansible-contrib.git
$ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts
$ ./backup_master_node.sh -h

4.3. レジストリー証明書のバックアップ

外部のセキュリティー保護されたレジストリーを使用する場合、すべてのレジストリー証明書を保存する必要があります。デフォルトでレジストリーのセキュリティーは保護されます。

重要

各クラスターノードで以下の手順を実行する必要があります。

手順

  1. レジストリー証明書をバックアップします。

    # cd /etc/docker/certs.d/
    # tar cf /tmp/docker-registry-certs-$(hostname).tar *
  2. バックアップを外部の場所に移動します。
注記

1 つ以上の 外部のセキュリティー保護されたレジストリーを使用している場合、イメージのプルまたはプッシュを実行するホストは、Pod を実行するためにレジストリー証明書を信頼する必要があります。

4.4. 他のインストールファイルのバックアップ

OpenShift Container Platform をインストールするために使用したファイルをバックアップします。

手順

  1. 復元手順には完全な再インストールが必要になるため、初期インストールで使用されたすべてのファイルを保存します。これらのファイルには、以下が含まれる場合があります。

  2. インストール後のステップの手順をバックアップします。一部のインストールには、インストーラーに含まれないステップが必要になる場合があります。これには、OpenShift Container Platform の制御範囲外のサービスの変更やモニターエージェントなどの追加サービスのインストールが含まれる場合があります。複数の認証プロバイダーの使用など、通常インストーラー (Advanced Installer) でサポートされていない追加の設定も必要になる場合があります。

4.5. アプリケーションデータのバックアップ

rsync がコンテナーイメージ内にインストールされていることを前提とすると、多くの場合、アプリケーションデータは oc rsync コマンドを使用してバックアップできます。Red Hat rhel7 ベースイメージには rsync が含まれます。したがって、rhel7 をベースとするすべてのイメージにはこれが含まれることになります。「Troubleshooting and Debugging CLI Operations - rsync」を参照してください。

警告

これは、アプリケーションデータの 汎用的な バックアップについての説明であり、データベースシステムの特殊なエクスポート/インポートなどのアプリケーション固有のバックアップ手順については考慮に入れられていません。

使用する永続ボリュームのタイプ (Cinder、NFS、Gluster など) によっては、他のバックアップ手段を使用できる場合もあります。

バックアップのパスも アプリケーションに固有 のものです。deploymentconfig でボリュームの mountPath を参照してバックアップするパスを判別することができます。

注記

この種のアプリケーションデータのバックアップは、アプリケーション Pod が実行中の場合にのみ実行できます。

手順

Jenkins デプロイメントのアプリケーションデータのバックアップ例

  1. アプリケーションデータ mountPathdeploymentconfig から取得します。

    $ oc get dc/jenkins -o jsonpath='{ .spec.template.spec.containers[?(@.name=="jenkins")].volumeMounts[?(@.name=="jenkins-data")].mountPath }'
    /var/lib/jenkins
  2. 現在実行中の Pod の名前を取得します。

    $ oc get pod --selector=deploymentconfig=jenkins -o jsonpath='{ .metadata.name }'
    jenkins-1-37nux
  3. oc rsync コマンドを使用してアプリケーションデータをコピーします。

    $ oc rsync jenkins-1-37nux:/var/lib/jenkins /tmp/jenkins-backup/

4.6. etcd のバックアップ

etcd はすべてのオブジェクト定義、および永続マスターの状態を保存するキー値のストアです。他のコンポーネントは変更の有無を監視して、それぞれ必要な状態に切り替えます。

3.5 よりも前の OpenShift Container Platform バージョンは etcd バージョン 2 (v2) を使用し、3.5 以降ではバージョン 3 (v3) を使用します。etcd のデータモデルは、この 2 つのバージョン間で異なります。etcd v3 は v2 と v3 データモデルの両方を使用できますが、etcd v2 は v2 データモデルしか使用できません。etcd v3 サーバーでは、v2 および v3 データストアは並列して存在し、それぞれ独立しています。

v2 および v3 の両方の操作については、ETCDCTL_API 環境変数を使用して適切な API を使用できます。

$ etcdctl -v
etcdctl version: 3.2.28
API version: 2

$ ETCDCTL_API=3 etcdctl version
etcdctl version: 3.2.28
API version: 3.2

v3 への移行方法についての詳細は、OpenShift Container Platform 3.7 ドキュメントの「Migrating etcd Data (v2 to v3)」のセクションを参照してください。

OpenShift Container Platform バージョン 3.10 移行では、etcd を別のホストにインストールすることも、マスターホスト上の静的 Pod として実行することもできます。別個の etcd ホストを指定しない場合、etcd はマスターホストの静的 Pod として実行されます。この違いにより、静的 Pod を使用する場合はバックアッププロセスも異なります。

etcd のバックアッププロセスは 2 つの異なる手順で構成されています。

  • 設定のバックアップ: 必要な etcd 設定および証明書が含まれます。
  • データのバックアップ: v2 と v3 の両方のデータモデルが含まれます。

データのバックアッププロセスは、適切な証明書が提供され、etcdctl ツールがインストールされている etcd クラスターに接続できるホストで実行できます。

注記

バックアップファイルは可能な場合は OpenShift Container Platform 環境外の外部システムにコピーしてから暗号化する必要があります。

etcd のバックアップには現在のストレージボリュームへのすべての参照が含まれることに注意してください。etcd の復元時に、OpenShift Container Platform はノードでの以前の Pod の起動と同じストレージの再割り当てを開始します。このプロセスは、ノードをクラスターから削除し、新規ノードを代わりに追加するプロセスと変わりがありません。そのノードに割り当てられているすべてのものは、Pod のスケジュール先のノードに関係なく Pod に再び割り当てられます。

4.6.1. etcd のバックアップ

etcd のバックアップ時に、etcd 設定ファイルと etcd データの両方をバックアップする必要があります。

4.6.1.1. etcd 設定ファイルのバックアップ

保持する etcd 設定ファイルはすべて etcd が実行されているインスタンスの /etc/etcd ディレクトリーに保存されます。これには、etcd 設定ファイル (/etc/etcd/etcd.conf) およびクラスターの通信に必要な証明書が含まれます。それらすべてのファイルは Ansible インストーラーによってインストール時に生成されます。

手順

クラスターの各 etcd メンバーについての etcd 設定をバックアップします。

$ ssh master-0 1
# mkdir -p /backup/etcd-config-$(date +%Y%m%d)/
# cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
1
master-0 を etcd メンバーの名前に置き換えます。
注記

各 etcd クラスターメンバーの証明書および設定ファイルは一意のものです。

4.6.1.2. etcd データのバックアップ

前提条件
注記

OpenShift Container Platform インストーラーはエイリアスを作成するため、etcdctl2 (etcd v2 タスクの場合) と etcdctl3 (etcd v3 タスクの場合) という名前のすべてのフラグを入力しなくて済みます。

ただし、etcdctl3 エイリアスは etcdctl コマンドに詳細なエンドポイント一覧を提供しないため、--endpoints オプションを指定し、すべてのエンドポイントを一覧表示する必要があります。

etcd をバックアップする前に、以下を確認してください。

  • etcdctl バイナリーが利用可能であるか、またはコンテナー化インストールの場合は rhel7/etcd コンテナーが利用可能でなければなりません。
  • OpenShift Container Platform API サービスが実行中であることを確認します。
  • etcd クラスターとの接続を確認します (ポート 2379/tcp)。
  • etcd クラスターに接続するために使用する適切な証明書があることを確認します。
  • etcd クラスターについては、その正常性を確認して機能していることを確認します。

    • エンドポイントの正常性を確認します。

      # etcdctl3 --cert="/etc/etcd/peer.crt" \
                --key=/etc/etcd/peer.key \
                --cacert="/etc/etcd/ca.crt" \
                --endpoints="https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379" \1
                endpoint health
      1
      これらの値をクラスターのエンドポイントに置き換えます。

      出力例

      https://master-0.example.com:2379 is healthy: successfully committed proposal: took = 5.011358ms
      https://master-1.example.com:2379 is healthy: successfully committed proposal: took = 1.305173ms
      https://master-2.example.com:2379 is healthy: successfully committed proposal: took = 1.388772ms

    • メンバーの一覧を確認します。

      # etcdctl3 member list

      出力例

      2a371dd20f21ca8d, started, master-1.example.com, https://192.168.55.12:2380, https://192.168.55.12:2379
      40bef1f6c79b3163, started, master-0.example.com, https://192.168.55.8:2380, https://192.168.55.8:2379
      95dc17ffcce8ee29, started, master-2.example.com, https://192.168.55.13:2380, https://192.168.55.13:2379

手順
注記

etcdctl backup コマンドはバックアップを実行するために使用されますが、etcd v3 には バックアップ の概念がありません。代わりに etcdctl snapshot save コマンドを使用してライブメンバーの スナップショット を取るか、または etcd データディレクトリーの member/snap/db ファイルをコピーしてください。

etcdctl backup コマンドは、ノード ID やクラスター ID などのバックアップに含まれるメタデータの一部を書き換えるので、バックアップでは、ノードの以前のアイデンティティーが失われます。バックアップからクラスターを再作成するには、新規の単一ノードクラスターを作成してから、残りのノードをクラスターに追加します。メタデータは新規ノードが既存クラスターに加わらないように再作成されます。

etcd データをバックアップします。

重要

OpenShift Container Platform の以前のバージョンからアップグレードしたクラスターには、v2 データストアが含まれる可能性があります。すべての etcd データストアをバックアップしてください。

  1. 静的 Pod マニフェストから etcd エンドポイント IP アドレスを取得します。

    $ export ETCD_POD_MANIFEST="/etc/origin/node/pods/etcd.yaml"
    $ export ETCD_EP=$(grep https ${ETCD_POD_MANIFEST} | cut -d '/' -f3)
  2. 管理者としてログインします。

    $ oc login -u system:admin
  3. etcd Pod 名を取得します。

    $ export ETCD_POD=$(oc get pods -n kube-system | grep -o -m 1 '^master-etcd\S*')
  4. kube-system プロジェクトに変更します。

    $ oc project kube-system
  5. Pod の etcd データのスナップショットを作成し、これをローカルに保存します。

    $ oc exec ${ETCD_POD} -c etcd -- /bin/bash -c "ETCDCTL_API=3 etcdctl \
        --cert /etc/etcd/peer.crt \
        --key /etc/etcd/peer.key \
        --cacert /etc/etcd/ca.crt \
        --endpoints $ETCD_EP \
        snapshot save /var/lib/etcd/snapshot.db" 1
    1
    スナップショットを /var/lib/etcd/ の下のディレクトリーに書き込む必要があります。

4.7. プロジェクトのバックアップ

関連するすべてのデータのバックアップの作成には、すべての重要な情報をエクスポートし、新規プロジェクトに復元することが関係します。

重要

oc get all コマンドは特定のプロジェクトリソースのみを返すため、以下の手順にあるように PVC およびシークレットを含む他のリソースを個別にバックアップする必要があります。

手順

  1. バックアップするプロジェクトデータを一覧表示します。

    $ oc get all

    出力例

    NAME         TYPE      FROM      LATEST
    bc/ruby-ex   Source    Git       1
    
    NAME               TYPE      FROM          STATUS     STARTED         DURATION
    builds/ruby-ex-1   Source    Git@c457001   Complete   2 minutes ago   35s
    
    NAME                 DOCKER REPO                                     TAGS      UPDATED
    is/guestbook         10.111.255.221:5000/myproject/guestbook         latest    2 minutes ago
    is/hello-openshift   10.111.255.221:5000/myproject/hello-openshift   latest    2 minutes ago
    is/ruby-22-centos7   10.111.255.221:5000/myproject/ruby-22-centos7   latest    2 minutes ago
    is/ruby-ex           10.111.255.221:5000/myproject/ruby-ex           latest    2 minutes ago
    
    NAME                 REVISION   DESIRED   CURRENT   TRIGGERED BY
    dc/guestbook         1          1         1         config,image(guestbook:latest)
    dc/hello-openshift   1          1         1         config,image(hello-openshift:latest)
    dc/ruby-ex           1          1         1         config,image(ruby-ex:latest)
    
    NAME                   DESIRED   CURRENT   READY     AGE
    rc/guestbook-1         1         1         1         2m
    rc/hello-openshift-1   1         1         1         2m
    rc/ruby-ex-1           1         1         1         2m
    
    NAME                  CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
    svc/guestbook         10.111.105.84    <none>        3000/TCP            2m
    svc/hello-openshift   10.111.230.24    <none>        8080/TCP,8888/TCP   2m
    svc/ruby-ex           10.111.232.117   <none>        8080/TCP            2m
    
    NAME                         READY     STATUS      RESTARTS   AGE
    po/guestbook-1-c010g         1/1       Running     0          2m
    po/hello-openshift-1-4zw2q   1/1       Running     0          2m
    po/ruby-ex-1-build           0/1       Completed   0          2m
    po/ruby-ex-1-rxc74           1/1       Running     0          2m

  2. プロジェクトオブジェクトを project.yaml ファイルにエクスポートします。

    $ oc get -o yaml --export all > project.yaml
  3. ロールバインディング、シークレット、サービスアカウント、Persistent Volume Claim (永続ボリューム要求、PVC) など、プロジェクト内の他のオブジェクトをエクスポートします。

    以下のコマンドを使用して、プロジェクト内のすべての namespace オブジェクトをエクスポートできます。

    $ for object in $(oc api-resources --namespaced=true -o name)
    do
      oc get -o yaml --export $object > $object.yaml
    done

    一部のリソースはエクスポートできず、MethodNotAllowed エラーが表示されることに注意してください。

  4. 一部のエクスポートされたオブジェクトはプロジェクト内の特定のメタデータまたは固有の ID への参照に依存する場合があります。これは、再作成されるオブジェクトのユーザビリティーにおける制限になります。

    imagestreams の使用時に、deploymentconfigimage パラメーターは、復元される環境に存在しない内部レジストリー内のイメージの特定の sha チェックサムをポイントする場合があります。たとえば、サンプル "ruby-ex" を oc new-app centos/ruby-22-centos7~https://github.com/sclorg/ruby-ex.git として実行すると、イメージをホストするための内部レジストリーを使用する imagestream ruby-ex が作成されます。

    $ oc get dc ruby-ex -o jsonpath="{.spec.template.spec.containers[].image}"
    10.111.255.221:5000/myproject/ruby-ex@sha256:880c720b23c8d15a53b01db52f7abdcbb2280e03f686a5c8edfef1a2a7b21cee

    oc get --export でのエクスポートと同じ方法で、deploymentconfig をインポートすると、イメージが存在しない場合には失敗します。

4.8. Persistent Volume Claim (永続ボリューム要求) のバックアップ

コンテナー内の永続データをサーバーと同期できます。

重要

OpenShift Container Platform 環境をホストする一部のプロバイダーでは、バックアップおよび復元目的でサードパーティーのスナップショットサービスを起動する機能がある場合があります。ただし、OpenShift Container Platform ではこれらのサービスを起動する機能を提供していないため、本書ではこれらの手順については説明しません。

特定アプリケーションの適切なバックアップ手順については、製品のドキュメントを参照してください。たとえば、mysql データディレクトリー自体をコピーしても使用可能なバックアップは作成されません。その代わりに、関連付けられたアプリケーションの特定のバックアップ手順を実行してから、データを同期することができます。この特定の手順には、OpenShift Container Platform をホストするプラットフォームで提供されるスナップショットソリューションの使用も含まれます。

手順

  1. プロジェクトおよび Pod を表示します。

    $ oc get pods
    NAME           READY     STATUS      RESTARTS   AGE
    demo-1-build   0/1       Completed   0          2h
    demo-2-fxx6d   1/1       Running     0          1h
  2. 永続ボリュームで使用されているボリュームを検索できるように必要な Pod の情報を記述します。

    $ oc describe pod demo-2-fxx6d
    Name:			demo-2-fxx6d
    Namespace:		test
    Security Policy:	restricted
    Node:			ip-10-20-6-20.ec2.internal/10.20.6.20
    Start Time:		Tue, 05 Dec 2017 12:54:34 -0500
    Labels:			app=demo
    			deployment=demo-2
    			deploymentconfig=demo
    Status:			Running
    IP:			172.16.12.5
    Controllers:		ReplicationController/demo-2
    Containers:
      demo:
        Container ID:	docker://201f3e55b373641eb36945d723e1e212ecab847311109b5cee1fd0109424217a
        Image:		docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Image ID:		docker-pullable://docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a
        Port:		8080/TCP
        State:		Running
          Started:		Tue, 05 Dec 2017 12:54:52 -0500
        Ready:		True
        Restart Count:	0
        Volume Mounts:
          */opt/app-root/src/uploaded from persistent-volume (rw)*
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-8mmrk (ro)
        Environment Variables:	<none>
    ...omitted...

    この出力は永続データが /opt/app-root/src/uploaded ディレクトリーにあることを示しています。

  3. データをローカルにコピーします。

    $ oc rsync demo-2-fxx6d:/opt/app-root/src/uploaded ./demo-app
    receiving incremental file list
    uploaded/
    uploaded/ocp_sop.txt
    uploaded/lost+found/
    
    sent 38 bytes  received 190 bytes  152.00 bytes/sec
    total size is 32  speedup is 0.14

    ocp_sop.txt ファイルはローカルシステムにダウンロードされ、バックアップソフトウェアまたは別のバックアップメカニズムでバックアップされます。

    注記

    また、Pod が起動する場合に pvc を使用せずに直前の手順を実行できますが、後に pvc が必要かどうかを確認する必要があります。データを保持してから復元プロセスを使用し、新規ストレージを設定することができます。