Red Hat Training
A Red Hat training course is available for OpenShift Container Platform
第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 ディレクトリー全体のバックアップを作成します。
手順
各マスターノードで以下の手順を実行する必要があります。
マスターホストの設定ファイルのバックアップを作成します。
$ 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-* ${MYBACKUPDIR}/etc/sysconfig/注記設定ファイルは、
/etc/sysconfig/atomic-openshift-master-apiおよび/etc/sysconfig/atomic-openshift-master-controllersディレクトリーに保存されています。警告/etc/origin/master/ca.serial.txtファイルは Ansible ホストインベントリーに一覧表示される最初のマスターでのみ生成されます。最初のマスターホストの使用を終了する場合は、このプロセスの実行前に/etc/origin/master/ca.serial.txtファイルを残りのマスターホストにコピーします。バックアップの計画時に考慮する必要のある他の重要なファイルには以下が含まれます。
ファイル
説明
/etc/cni/*コンテナーネットワークインターフェースの設定 (使用される場合)
/etc/sysconfig/iptablesiptablesルールが保存される場所/etc/sysconfig/docker-storage-setupcontainer-storage-setupコマンドの入力ファイル/etc/sysconfig/dockerdocker設定ファイル/etc/sysconfig/docker-networkdockerネットワーク設定 (例: MTU)/etc/sysconfig/docker-storagedockerストレージ設定 (container-storage-setupで生成される)/etc/dnsmasq.confdnsmasqの主要な設定ファイル/etc/dnsmasq.d/*異なる
dnsmasq設定ファイル/etc/sysconfig/flanneldflannel設定ファイル (使用される場合)/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/パッケージが間違って削除されてしまう場合や、
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これまでの手順を実行している場合には、以下のファイルがバックアップディレクトリーに配置されています。
$ MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d) $ sudo find ${MYBACKUPDIR} -mindepth 1 -type f -printf '%P\n' etc/sysconfig/atomic-openshift-master etc/sysconfig/atomic-openshift-master-api etc/sysconfig/atomic-openshift-master-controllers 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/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 インフラストラクチャーに変更を加える前に、このバックアッププロセスを実行するようにしてください。バックアップは、障害の発生時に最新データが利用可能になるように定期的に実行する必要があります。
OpenShift Container Platform ファイル
ノードインスタンスはコンテナーをベースとする Pod の形式で実行されます。/etc/origin/ および /etc/origin/node ディレクトリーは以下のような重要なファイルを格納します。
- ノードサービスの設定
- インストールで生成される証明書
- クラウドプロバイダー関連の設定
-
キーおよびその他の認証ファイル (
dnsmasq設定など)
OpenShift Container Platform サービスは、ログレベルの引き上げやプロキシーの使用などを実行するためにカスタマイズでき、設定ファイルは /etc/sysconfig ディレクトリーに保存されます。
手順
ノード設定ファイルのバックアップを作成します。
$ 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/OpenShift Container Platform では以下のような特定のファイルを使用します。バックアップポリシーの計画時には、これらのファイルを考慮する必要があります。
ファイル
説明
/etc/cni/*コンテナーネットワークインターフェースの設定 (使用される場合)
/etc/sysconfig/iptablesiptablesルールが保存される場所/etc/sysconfig/docker-storage-setupcontainer-storage-setupコマンドの入力ファイル/etc/sysconfig/dockerdocker設定ファイル/etc/sysconfig/docker-networkdockerネットワーク設定 (例: MTU)/etc/sysconfig/docker-storagedockerストレージ設定 (container-storage-setupで生成される)/etc/dnsmasq.confdnsmasqの主要な設定ファイル/etc/dnsmasq.d/*異なる
dnsmasq設定ファイル/etc/sysconfig/flanneldflannel設定ファイル (使用される場合)/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/パッケージが間違って削除されてしまう場合や、
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以下のファイルがバックアップディレクトリーに配置されているはずです。
$ 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. レジストリー証明書のバックアップ
「セキュリティー保護された外部のレジストリー」を使用する場合には、すべてのレジストリー証明書を保存する必要があります。レジストリーはデフォルトで、セキュリティー保護されています。
各クラスターノードで以下の手順を実行する必要があります。
手順
レジストリー証明書をバックアップします。
# cd /etc/docker/certs.d/ # tar cf /tmp/docker-registry-certs-$(hostname).tar *
- バックアップを外部の場所に移動します。
「セキュリティー保護された外部のレジストリー」を1 つ以上使用している場合には、イメージをプルまたはプッシュするホストは、Pod を実行するにはレジストリー証明書を信頼する必要があります。
4.4. 他のインストールファイルのバックアップ
OpenShift Container Platform をインストールするために使用したファイルをバックアップします。
手順
復元手順には完全な再インストールが必要になるため、初期インストールで使用されたすべてのファイルを保存します。これらのファイルには、以下が含まれる場合があります。
- (「クラスターのインストール」の場合) Ansible Playbook およびインベントリーファイル
- (「非接続インストール」の場合) /etc/yum.repos.d/ose.repo
- インストール後のステップの手順をバックアップします。一部のインストールには、インストーラーに含まれないステップが必要になる場合があります。これには、OpenShift Container Platform の制御範囲外のサービスの変更やモニターエージェントなどの追加サービスのインストールが含まれる場合があります。複数の認証プロバイダーの使用など、通常インストーラー (Advanced Installer) でサポートされていない追加の設定も必要になる場合があります。
4.5. アプリケーションデータのバックアップ
rsync がコンテナーイメージ内にインストールされていることを前提とすると、多くの場合にはアプリケーションデータは oc rsync コマンドを使用してバックアップできます。Red Hat rhel7 ベースイメージには rsync が含まれるので、rhel7 をベースとするすべてのイメージにはこれが含まれることになります。「CLI 操作のトラブルシューティングおよびデバッグ - rsync」を参照してください。
これは、アプリケーションデータの 汎用的な バックアップについての説明であり、データベースシステムの特殊なエクスポート/インポートなどのアプリケーション固有のバックアップ手順については考慮に入れられていません。
使用する永続ボリュームのタイプ (Cinder、NFS、Gluster など) によっては、他のバックアップ手段を使用できる場合もあります。
バックアップのパスも アプリケーションに固有 のものです。deploymentconfig でボリュームの mountPath を参照してバックアップするパスを判別することができます。
この種のアプリケーションデータのバックアップは、アプリケーション Pod が実行中の場合にのみ実行できます。
手順
Jenkins デプロイメントのアプリケーションデータのバックアップ例
アプリケーションデータ
mountPathをdeploymentconfigから取得します。$ oc get dc/jenkins -o jsonpath='{ .spec.template.spec.containers[?(@.name=="jenkins")].volumeMounts[?(@.name=="jenkins-data")].mountPath }' /var/lib/jenkins現在実行中の Pod の名前を取得します。
$ oc get pod --selector=deploymentconfig=jenkins -o jsonpath='{ .metadata.name }' jenkins-1-37nuxoc rsyncコマンドを使用してアプリケーションデータをコピーします。$ oc rsync jenkins-1-37nux:/var/lib/jenkins /tmp/
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.5 API version: 2 $ ETCDCTL_API=3 etcdctl version etcdctl version: 3.2.5 API version: 3.2
v3 への移行方法についての詳細は、OpenShift Container Platform 3.7 ドキュメントの「Migrating etcd Data (v2 to v3)」のセクションを参照してください。
etcd のバックアッププロセスは 2 つの異なる手順で構成されています。
- 設定のバックアップ: 必要な etcd 設定および証明書が含まれます。
- データのバックアップ: v2 と v3 の両方のデータモデルが含まれます。
データのバックアッププロセスは、適切な証明書が提供され、etcdctl ツールがインストールされている etcd クラスターに接続できるホストで実行できます。
バックアップファイルは可能な場合は OpenShift Container Platform 環境外の外部システムにコピーしてから暗号化する必要があります。
etcd のバックアップには現在のストレージボリュームへのすべての参照が含まれることに注意してください。OpenShift Container Platform は、etcd の復元時に、ノードで以前の 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 # mkdir -p /backup/etcd-config-$(date +%Y%m%d)/ # cp -R /etc/etcd/ /backup/etcd-config-$(date +%Y%m%d)/
各 etcd クラスターメンバーの証明書および設定ファルは一意のものです。
4.6.1.2. etcd データのバックアップ
前提条件
OpenShift Container Platform インストーラーはエイリアスを作成するため、etcdctl2 (etcd v2 タスクの場合) と etcdctl3 (etcd v3 タスクの場合) という名前のすべてのフラグを入力しなくて済みます。
ただし、etcdctl3 エイリアスは etcdctl コマンドの詳細なエンドポイント一覧を提供しないため、すべてのエンドポイントと共に --endpoints オプションを指定する必要があります。
etcd をバックアップする前に、以下を確認してください。
-
etcdctlバイナリーが利用可能であるか、またはコンテナー化インストールではrhel7/etcdコンテナーが利用可能であること。 - etcd クラスターとの接続を確認する (ポート 2379/tcp) こと。
etcd クラスターに接続するための適切な証明書があることを確認すること。
etcd クラスターが機能していることを確認するには、その健全性を確認します。
etcd v2 API を使用する場合、以下のコマンドを実行します。
# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://*master-0.example.com*:2379,\ https://*master-1.example.com*:2379,\ https://*master-2.example.com*:2379"\ cluster-health member 5ee217d19001 is healthy: got healthy result from https://192.168.55.12:2379 member 2a529ba1840722c0 is healthy: got healthy result from https://192.168.55.8:2379 member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379 cluster is healthyetcd v3 API を使用する場合、以下のコマンドを実行します。
# ETCDCTL_API=3 etcdctl --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" endpoint health 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
メンバーの一覧を確認します。
etcd v2 API を使用する場合、以下のコマンドを実行します。
# etcdctl2 member list 2a371dd20f21ca8d: name=master-1.example.com peerURLs=https://192.168.55.12:2380 clientURLs=https://192.168.55.12:2379 isLeader=false 40bef1f6c79b3163: name=master-0.example.com peerURLs=https://192.168.55.8:2380 clientURLs=https://192.168.55.8:2379 isLeader=false 95dc17ffcce8ee29: name=master-2.example.com peerURLs=https://192.168.55.13:2380 clientURLs=https://192.168.55.13:2379 isLeader=true
etcd v3 API を使用する場合、以下のコマンドを実行します。
# 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 データをバックアップします。
v2 API を使用する場合には、以下のアクションを実行してください。
すべての etcd サービスを停止します。
# systemctl stop etcd.service
etcd データバックアップを作成し、etcd
dbファイルをコピーします。# mkdir -p /backup/etcd-$(date +%Y%m%d) # etcdctl2 backup \ --data-dir /var/lib/etcd \ --backup-dir /backup/etcd-$(date +%Y%m%d) # cp /var/lib/etcd/member/snap/db /backup/etcd-$(date +%Y%m%d)
v3 API を使用する場合、以下のコマンドを実行します。
重要OpenShift Container Platform の以前のバージョンからアップグレードしたクラスターには、v2 データストアが含まれる可能性があるので、v2 と v3 の両方のデータストアをバックアップしてください。
# mkdir -p /backup/etcd-$(date +%Y%m%d) # etcdctl3 snapshot save /backup/etcd-$(date +%Y%m%d)/db Snapshot saved at /backup/etcd-<date>/db # systemctl stop etcd.service # etcdctl2 backup \ --data-dir /var/lib/etcd \ --backup-dir /backup/etcd-$(date +%Y%m%d) # systemctl start etcd.service注記etcdctl snapshot saveコマンドでは etcd サービスが実行中である必要があります。これらのコマンドでは、
/backup/etcd-<date>/ディレクトリーが作成されます。ここで、<date>は現在の日付を表します。このディレクトリーは、外部 NFS 共有、S3 バケットやその他の外部ストレージの場所のいずれかでなければなりません。オールインワンクラスターの場合、etcd データディレクトリーは
/var/lib/origin/openshift.local.etcdディレクトリーに置かれます。
4.7. プロジェクトのバックアップ
関連するすべてのデータのバックアップの作成には、すべての重要な情報をエクスポートし、新規プロジェクトに復元することが関係します。
OpenShift Container Platform のプロジェクトのバックアップおよび復元ツールについては、現在 Red Hat で開発中です。詳細は、以下のバグを参照してください。
手順
バックアップ予定の関連データをすべて一覧表示します。
$ 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
プロジェクトオブジェクトを
.yamlまたは.jsonファイルにエクスポートします。プロジェクトオブジェクトを
project.yamlファイルにエクスポートするには、以下を実行します。$ oc export all -o yaml > project.yaml
プロジェクトオブジェクトを
project.jsonファイルにエクスポートするには、以下を実行します。$ oc export all -o json > project.json
プロジェクトの
role bindings、secrets、service accounts、およびpersistent volume claimsをエクスポートします。$ for object in rolebindings serviceaccounts secrets imagestreamtags podpreset cms egressnetworkpolicies rolebindingrestrictions limitranges resourcequotas pvcs templates cronjobs statefulsets hpas deployments replicasets poddisruptionbudget endpoints do oc export $object -o yaml > $object.yaml done
一部のエクスポートされたオブジェクトはプロジェクト内の特定のメタデータまたは固有の ID への参照に依存する場合があります。これは、再作成されるオブジェクトのユーザビリティーにおける制限になります。
imagestreamsの使用時に、deploymentconfigのimageパラメーターは、復元される環境に存在しない内部レジストリー内のイメージの特定のshaチェックサムをポイントする場合があります。たとえば、サンプル "ruby-ex" をoc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.gitとして実行すると、イメージをホストするための内部レジストリーを使用するimagestreamruby-exが作成されます。$ oc get dc ruby-ex -o jsonpath="{.spec.template.spec.containers[].image}" 10.111.255.221:5000/myproject/ruby-ex@sha256:880c720b23c8d15a53b01db52f7abdcbb2280e03f686a5c8edfef1a2a7b21ceeoc exportでのエクスポートと同じ方法で、deploymentconfigをインポートすると、イメージが存在しない場合には失敗します。このようなエクスポートを作成するには、
openshift-ansible-contribリポジトリーのproject_export.shを使用します。これにより、複数の異なるファイルに、すべてのプロジェクトオブジェクトが作成されます。このスクリプトの実行先ホストに、このプロジェクト名が指定されたディレクトリーと、そのプロジェクトに含まれるオブジェクトタイプごとのjsonファイルが、このスクリプトにより作成されます。注記以下で参照される
openshift-ansible-contribリポジトリーのコードは Red Hat で明示的にサポートされている訳ではありませんが、リファレンスアーキテクチャーチームはコードが定義通りに動作し、安全であることを確認するためにテストを実行しています。スクリプトは Linux で実行され、これには
jqおよびocコマンドがインストールされている必要があります。また、対象のプロジェクトにある全オブジェクトを読み取ることのできるユーザーで、OpenShift Container Platform 環境のシステムにログインしておく必要があります。$ mkdir ~/git $ cd ~/git $ git clone https://github.com/openshift/openshift-ansible-contrib.git $ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts $ ./project_export.sh <projectname>
例:
$ ./project_export.sh myproject Exporting namespace to project-demo/ns.json Exporting rolebindings to project-demo/rolebindings.json Exporting serviceaccounts to project-demo/serviceaccounts.json Exporting secrets to project-demo/secrets.json Exporting deploymentconfigs to project-demo/dc_*.json Patching DC... Exporting buildconfigs to project-demo/bcs.json Exporting builds to project-demo/builds.json Exporting imagestreams to project-demo/iss.json Exporting imagestreamtags to project-demo/imagestreamtags.json Exporting replicationcontrollers to project-demo/rcs.json Exporting services to project-demo/svc_*.json Exporting pods to project-demo/pods.json Exporting podpreset to project-demo/podpreset.json Exporting configmaps to project-demo/cms.json Exporting egressnetworkpolicies to project-demo/egressnetworkpolicies.json Exporting rolebindingrestrictions to project-demo/rolebindingrestrictions.json Exporting limitranges to project-demo/limitranges.json Exporting resourcequotas to project-demo/resourcequotas.json Exporting pvcs to project-demo/pvcs.json Exporting routes to project-demo/routes.json Exporting templates to project-demo/templates.json Exporting cronjobs to project-demo/cronjobs.json Exporting statefulsets to project-demo/statefulsets.json Exporting hpas to project-demo/hpas.json Exporting deployments to project-demo/deployments.json Exporting replicasets to project-demo/replicasets.json Exporting poddisruptionbudget to project-demo/poddisruptionbudget.json
これが実行されたら、ファイルを確認し、コンテンツが適切にエクスポートされていることを確認します。
$ cd <projectname> $ ls -1 bcs.json builds.json cms.json cronjobs.json dc_ruby-ex.json dc_ruby-ex_patched.json deployments.json egressnetworkpolicies.json endpoint_external-mysql-service.json hpas.json imagestreamtags.json iss.json limitranges.json ns.json poddisruptionbudget.json podpreset.json pods.json pvcs.json rcs.json replicasets.json resourcequotas.json rolebindingrestrictions.json rolebindings.json routes.json secrets.json serviceaccounts.json statefulsets.json svc_external-mysql-service.json svc_ruby-ex.json templates.json $ less bcs.json ...
注記元のオブジェクトが存在しない場合、エクスポート時に空のファイルが作成されます。
imagestreamsを使用している場合、スクリプトはdeploymentconfigをイメージshaの代わりにイメージ参照を使用するように変更し、_patchedの追加情報を使用してエクスポートされたもの以外のjsonファイルを作成します。$ diff dc_hello-openshift.json dc_hello-openshift_patched.json 45c45 < "image": "docker.io/openshift/hello-openshift@sha256:42b59c869471a1b5fdacadf778667cecbaa79e002b7235f8091540ae612f0e14", --- > "image": "hello-openshift:latest",
現時点でこのスクリプトは複数のコンテナー Pod をサポートしていないため、注意して使用してください。
4.8. Persistent Volume Claim (永続ボリューム要求) のバックアップ
コンテナー内の永続データをサーバーと同期できます。
OpenShift Container Platform 環境をホストする一部のプロバイダーでは、バックアップおよび復元目的でサードパーティーのスナップショットサービスを起動する機能がある場合があります。ただし、OpenShift Container Platform ではこれらのサービスを起動する機能を提供していないため、本書ではこれらの手順については説明しません。
特定のアプリケーションに関する正しいバックアップ手順は、製品のドキュメントを参照してください。たとえば、mysql データディレクトリー自体をコピーしても使用可能なバックアップは作成されません。その代わりに、OpenShift Container Platform がホストするプラットフォームで提供されるスナップショットソリューションを使用するなど、関連のアプリケーション特有のバックアップ手順を実行してから、データを同期してください。
手順
プロジェクトおよび 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
永続ボリュームで使用されているボリュームを検索できるように必要な 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ディレクトリーにあることを示しています。データをローカルにコピーします。
$ 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ファイルはローカルシステムにダウンロードされ、バックアップソフトウェアまたは別のバックアップメカニズムでバックアップされます。注記また、
pvcを使用せずに Pod を起動する場合には、直前の手順を使用することもできますが、pvcが必要かどうかを後で確認する必要があります。データを保存してから復元プロセスを使用し、新規ストレージを生成することができます。