Red Hat SummitThis documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.第3章 OpenShift Container Platform コンポーネントの復元
3.1. 概要
OpenShift Container Platform では、クラスターおよびそのコンポーネントの 復元 は、ノードおよびアプリケーションなどの要素を別のストレージから再作成することで実行できます。
クラスターを復元するには、まずバックアップを作成します。
以下のプロセスでは、アプリケーションおよび OpenShift Container Platform クラスターを復元するための通常の方法について説明しています。ここではカスタム要件は考慮されません。クラスターを復元するために追加のアクションを実行する必要がある可能性があります。
3.2. クラスターの復元
クラスターを復元するには、まず OpenShift Container Platform を再インストールします。
手順
- 最初に OpenShift Container Platform をインストールしたのと同じ方法で OpenShift Container Platform を再インストールします。
- OpenShift Container Platform の制御下にないサービスを変更したり、モニターエージェントなどの追加サービスのインストールなど、インストール後のカスタム手順すべてを実行します。
3.3. マスターホストのバックアップの復元
重要なマスターホストファイルのバックアップを作成した後に、それらのファイルが破損しているか、または間違って削除された場合は、それらのファイルをマスターにコピーし直してファイルを復元し、それらに適切なコンテンツが含まれることを確認してから、影響を受けるサービスを再起動します。
手順
/etc/origin/master/master-config.yamlファイルを復元します。# MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)* # cp /etc/origin/master/master-config.yaml /etc/origin/master/master-config.yaml.old # cp /backup/$(hostname)/$(date +%Y%m%d)/origin/master/master-config.yaml /etc/origin/master/master-config.yaml # master-restart api # master-restart controllers
警告マスターサービスの再起動によりダウンタイムが生じる場合があります。ただし、マスターホストを可用性の高いロードバランサープールから削除し、復元操作を実行することができます。サービスが適切に復元された後に、マスターホストをロードバランサープールに再び追加することができます。
注記影響を受けるインスタンスを完全に再起動して、
iptables設定を復元します。パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。
現在インストールされているパッケージの一覧を取得します。
$ rpm -qa | sort > /tmp/current_packages.txt
パッケージの一覧の間に存在する差分を表示します。
$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt > ansible-2.4.0.0-5.el7.noarch足りないパッケージを再インストールします。
# yum reinstall -y <packages> 1- 1
<packages>は、パッケージの一覧ごとに異なるパッケージに置き換えます。
システム証明書を
/etc/pki/ca-trust/source/anchors/ディレクトリーにコピーして復元し、update-ca-trustを実行します。$ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)* $ sudo cp ${MYBACKUPDIR}/external_certificates/my_company.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust注記ファイルをコピーし直す時に、ユーザー ID およびグループ ID だけでなく、
SELinuxコンテキストも復元されていることを常に確認してください。
3.4. ノードホストバックアップの復元
重要なノードホストファイルのバックアップを作成した後に、それらのファイルが破損しているか、または間違って削除された場合、これらのファイルをコピーし直してファイルを復元し、適切なコンテンツが含まれることを確認してから、影響を受けるサービスを再起動します。
手順
/etc/origin/node/node-config.yamlファイルを復元します。# MYBACKUPDIR=/backup/$(hostname)/$(date +%Y%m%d) # cp /etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml.old # cp /backup/$(hostname)/$(date +%Y%m%d)/etc/origin/node/node-config.yaml /etc/origin/node/node-config.yaml # systemctl restart atomic-openshift-node
サービスの再起動によりダウンタイムが生じる場合があります。このプロセスを容易にするためのヒントについては、「ノードの保守」を参照してください。
影響を受けるインスタンスを完全に再起動して、iptables 設定を復元します。
パッケージがないために OpenShift Container Platform を再起動できない場合は、パッケージを再インストールします。
現在インストールされているパッケージの一覧を取得します。
$ rpm -qa | sort > /tmp/current_packages.txt
パッケージの一覧の間に存在する差分を表示します。
$ diff /tmp/current_packages.txt ${MYBACKUPDIR}/packages.txt > ansible-2.4.0.0-5.el7.noarch足りないパッケージを再インストールします。
# yum reinstall -y <packages> 1- 1
<packages>は、パッケージの一覧ごとに異なるパッケージに置き換えます。
システム証明書を
/etc/pki/ca-trust/source/anchors/ディレクトリーにコピーして復元し、update-ca-trustを実行します。$ MYBACKUPDIR=*/backup/$(hostname)/$(date +%Y%m%d)* $ sudo cp ${MYBACKUPDIR}/etc/pki/ca-trust/source/anchors/my_company.crt /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust注記ファイルをコピーし直す時に、ユーザー ID およびグループ ID だけでなく、
SELinuxコンテキストも復元されていることを常に確認してください。
3.5. etcd の復元
etcd 設定ファイルの復元手順では、適切なファイルを置き換えてからサービスを再起動します。
etcd ホストが破損し、/etc/etcd/etcd.conf ファイルが失われる場合は、以下を使用してこれを復元します。
$ ssh master-0 # cp /backup/yesterday/master-0-files/etcd.conf /etc/etcd/etcd.conf # restorecon -Rv /etc/etcd/etcd.conf # systemctl restart etcd.service
この例では、バックアップファイルは /backup/yesterday/master-0-files/etcd.conf パスに保存されます。ここでは外部 NFS 共有、S3 バケットまたは他のストレージソリューションとして使用できます。
3.5.1. etcd v2 および v3 データの復元
以下のプロセスでは正常なデータファイルを復元し、etcd クラスターを単一ノードとして起動してから、etcd クラスターが必要な場合に残りのノードを追加します。
手順
すべての etcd サービスを停止します。
# systemctl stop etcd.service
適切なバックアップが復元されていることを確認するには、etcd ディレクトリーを削除します。
ディレクトリーを削除する前に現在の etcd データをバックアップするには、以下のコマンドを実行します。
# mv /var/lib/etcd /var/lib/etcd.old # mkdir /var/lib/etcd # chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd/
または、ディレクトリーおよび etcd、データを削除するには、以下のコマンドを実行します。
# rm -Rf /var/lib/etcd/*
注記オールインワンクラスターの場合、etcd データディレクトリーは
/var/lib/origin/openshift.local.etcdディレクトリーに置かれます。
正常なバックアップデータファイルをそれぞれの etcd ノードに復元します。この手順は、etcd と同じ場所に配置されているマスターホストを含むすべての etcd ホストで実行します。
# cp -R /backup/etcd-xxx/* /var/lib/etcd/ # mv /var/lib/etcd/db /var/lib/etcd/member/snap/db # chcon -R --reference /backup/etcd-xxx/* /var/lib/etcd/ # chown -R etcd:etcd /var/lib/etcd/R
各ホストで etcd サービスを実行し、新規クラスターを強制的に実行します。
これにより etcd サービスのカスタムファイルが作成されます。これにより、
--force-new-clusterオプションを追加して実行コマンドが上書きされます。# mkdir -p /etc/systemd/system/etcd.service.d/ # echo "[Service]" > /etc/systemd/system/etcd.service.d/temp.conf # echo "ExecStart=" >> /etc/systemd/system/etcd.service.d/temp.conf # sed -n '/ExecStart/s/"$/ --force-new-cluster"/p' \ /usr/lib/systemd/system/etcd.service \ >> /etc/systemd/system/etcd.service.d/temp.conf # systemctl daemon-reload # master-restart etcdエラーメッセージの有無を確認します。
$ journalctl -fu etcd.service
正常性のステータスを確認します。
# etcdctl2 cluster-health member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379 cluster is healthy
クラスターモードで etcd サービスを再起動します。
# rm -f /etc/systemd/system/etcd.service.d/temp.conf # systemctl daemon-reload # master-restart etcd
正常性のステータスとメンバーの一覧を確認します。
# etcdctl2 cluster-health member 5ee217d17301 is healthy: got healthy result from https://192.168.55.8:2379 cluster is healthy # etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=http://localhost:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
- 最初のインスタンスの実行後に、残りの etcd サーバーを復元できます。
3.5.1.1. peerURLS パラメーターの修正
データの復元および新規クラスターの作成後に、peerURLs パラメーターは、 etcd がピア通信をリッスンする IP の代わりに localhost を示します。
# etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=http://*localhost*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
3.5.1.1.1. 手順
etcdctl member listを使用してメンバー ID を取得します。`etcdctl member list`
etcd がピア通信をリッスンする IP を取得します。
$ ss -l4n | grep 2380
メンバー情報をこの IP で更新します。
# etcdctl2 member update 5ee217d17301 https://192.168.55.8:2380 Updated member with ID 5ee217d17301 in cluster
検証するには、IP がメンバーの一覧にあることを確認します。
$ etcdctl2 member list 5ee217d17301: name=master-0.example.com peerURLs=https://*192.168.55.8*:2380 clientURLs=https://192.168.55.8:2379 isLeader=true
3.5.2. etcd v3 スナップショットの復元
v3 データの復元手順は v2 データの復元プロセスと同様です。
スナップショットの整合性については、復元時にオプションで検証できます。スナップショットが etcdctl snapshot save で取得される場合、これには etcdctl snapshot restore でチェックされる整合性ハッシュが含まれます。スナップショットがデータディレクトリーからコピーされる場合には整合性ハッシュはなく、--skip-hash-check を使用して実行されます。
v3 データのみを復元する手順は単一 etcd ホストで実行される必要があります。その後に残りのノードをクラスターに追加することができます。
手順
すべての etcd サービスを停止します。
# systemctl stop etcd.service
古いデータについては、
etcdctlが復元手順が実行されるノードでその再作成を実行するため、それらすべてをクリアします。# rm -Rf /var/lib/etcd
snapshot restoreコマンドを実行し、/etc/etcd/etcd.confファイルの値を置き換えます。# etcdctl3 snapshot restore /backup/etcd-xxxxxx/backup.db \ --data-dir /var/lib/etcd \ --name master-0.example.com \ --initial-cluster "master-0.example.com=https://192.168.55.8:2380" \ --initial-cluster-token "etcd-cluster-1" \ --initial-advertise-peer-urls https://192.168.55.8:2380 \ --skip-hash-check=true 2017-10-03 08:55:32.440779 I | mvcc: restore compact to 1041269 2017-10-03 08:55:32.468244 I | etcdserver/membership: added member 40bef1f6c79b3163 [https://192.168.55.8:2380] to cluster 26841ebcf610583c
パーミッションおよび
selinuxコンテキストを復元ファイルに復元します。# chown -R etcd.etcd /var/lib/etcd/ # restorecon -Rv /var/lib/etcd
etcd サービスを起動します。
# systemctl start etcd
エラーメッセージの有無を確認します。
# master-logs etcd etcd
3.6. etcd ノードの追加
etcd の復元後、他の etcd ノードをクラスターに追加できます。Ansible Playbook を使用するか、または手動の手順を実行して etcd ホストを追加できます。
3.6.1. Ansible を使用した新規 etcd ホストの追加
手順
Ansible インベントリーファイルで、
[new_etcd]という名前の新規グループを作成し、新規ホストを追加します。次に、new_etcdグループを[OSEv3]グループの子として追加します。[OSEv3:children] masters nodes etcd new_etcd 1 ... [OUTPUT ABBREVIATED] ... [etcd] master-0.example.com master-1.example.com master-2.example.com [new_etcd] 2 etcd0.example.com 3
OpenShift Container Platform がインストールされており、Ansible インベントリーファイルをホストするホストから、etcd
scaleupPlaybook を実行します。$ ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/byo/openshift-etcd/scaleup.yml
Playbook が実行された後に、新規 etcd ホストを
[new_etcd]グループから[etcd]グループに移行し、現在のステータスを反映するようにインベントリーファイルを変更します。[OSEv3:children] masters nodes etcd new_etcd ... [OUTPUT ABBREVIATED] ... [etcd] master-0.example.com master-1.example.com master-2.example.com etcd0.example.com
Flannel を使用する場合には、OpenShift Container Platform のホストごとに、
/etc/sysconfig/flanneldにあるflanneldサービス設定を変更し、新しい etcd ホストを追加します。FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
flanneldサービスを再起動します。# systemctl restart flanneld.service
3.6.2. 新規 etcd ホストの手動による追加
手順
現在の etcd クラスターの変更
etcd 証明書を作成するには、値を環境の値に置き換えて openssl コマンドを実行します。
環境変数を作成します。
export NEW_ETCD_HOSTNAME="*etcd0.example.com*" export NEW_ETCD_IP="192.168.55.21" export CN=$NEW_ETCD_HOSTNAME export SAN="IP:${NEW_ETCD_IP}" export PREFIX="/etc/etcd/generated_certs/etcd-$CN/" export OPENSSLCFG="/etc/etcd/ca/openssl.cnf"注記etcd_v3_ca_*として使用されるカスタムのopenssl拡張には、subjectAltNameとしての $SAN 環境変数が含まれます。詳細は、/etc/etcd/ca/openssl.cnfを参照してください。設定および証明書を保存するディレクトリーを作成します。
# mkdir -p ${PREFIX}サーバー証明書要求を作成し、これに署名します (server.csr および server.crt)。
# openssl req -new -config ${OPENSSLCFG} \ -keyout ${PREFIX}server.key \ -out ${PREFIX}server.csr \ -reqexts etcd_v3_req -batch -nodes \ -subj /CN=$CN # openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}server.crt \ -in ${PREFIX}server.csr \ -extensions etcd_v3_ca_server -batchピア証明書要求を作成し、これに署名します (peer.csr および peer.crt)。
# openssl req -new -config ${OPENSSLCFG} \ -keyout ${PREFIX}peer.key \ -out ${PREFIX}peer.csr \ -reqexts etcd_v3_req -batch -nodes \ -subj /CN=$CN # openssl ca -name etcd_ca -config ${OPENSSLCFG} \ -out ${PREFIX}peer.crt \ -in ${PREFIX}peer.csr \ -extensions etcd_v3_ca_peer -batch後で変更できるように、現在の etcd 設定および
ca.crtファイルをサンプルとして現在のノードからコピーします。# cp /etc/etcd/etcd.conf ${PREFIX} # cp /etc/etcd/ca.crt ${PREFIX}存続する etcd ホストから、新規ホストをクラスターに追加します。etcd メンバーをクラスターに追加するには、まず最初のメンバーの
peerURLs値のデフォルトの localhost ピアを調整する必要があります。member listコマンドを使用して最初のメンバーのメンバー ID を取得します。# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ 1 member list- 1
--peersパラメーター値でアクティブな etcd メンバーのみの URL を指定するようにしてください。
etcd がクラスターピアについてリッスンする IP アドレスを取得します。
$ ss -l4n | grep 2380
直前の手順で取得されたメンバー ID および IP アドレスを渡して、
etcdctl member updateコマンドを使用してpeerURLsの値を更新します。# etcdctl --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key \ --ca-file=/etc/etcd/ca.crt \ --peers="https://172.18.1.18:2379,https://172.18.9.202:2379,https://172.18.0.75:2379" \ member update 511b7fb6cc0001 https://172.18.1.18:2380-
member listコマンドを再実行し、ピア URL に localhost が含まれなくなるようにします。
新規ホストを etcd クラスターに追加します。新規ホストはまだ設定されていないため、新規ホストを設定するまでステータスが
unstartedのままであることに注意してください。警告各メンバーを追加し、1 回に 1 つずつメンバーをオンライン状態にします。各メンバーをクラスターに追加する際に、現在のピアの
peerURL一覧を調整する必要があります。peerURL一覧はメンバーが追加されるたびに拡張します。etcdctl member addコマンドは、以下に説明されているように、メンバーを追加する際に etcd.conf ファイルで設定する必要のある値を出力します。# etcdctl -C https://${CURRENT_ETCD_HOST}:2379 \ --ca-file=/etc/etcd/ca.crt \ --cert-file=/etc/etcd/peer.crt \ --key-file=/etc/etcd/peer.key member add ${NEW_ETCD_HOSTNAME} https://${NEW_ETCD_IP}:2380 1 Added member named 10.3.9.222 with ID 4e1db163a21d7651 to cluster ETCD_NAME="<NEW_ETCD_HOSTNAME>" ETCD_INITIAL_CLUSTER="<NEW_ETCD_HOSTNAME>=https://<NEW_HOST_IP>:2380,<CLUSTERMEMBER1_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER2_NAME>=https:/<CLUSTERMEMBER2_IP>:2380,<CLUSTERMEMBER3_NAME>=https:/<CLUSTERMEMBER3_IP>:2380" ETCD_INITIAL_CLUSTER_STATE="existing"- 1
- この行で、
10.3.9.222は etcd メンバーのラベルです。ホスト名、IP アドレスまたは単純な名前を指定できます。
サンプル
${PREFIX}/etcd.confファイルを更新します。以下の値を直前の手順で生成された値に置き換えます。
- ETCD_NAME
- ETCD_INITIAL_CLUSTER
- ETCD_INITIAL_CLUSTER_STATE
以下の変数は、直前の手順で出力された新規ホストの IP に変更します。
${NEW_ETCD_IP}は、値として使用できます。ETCD_LISTEN_PEER_URLS ETCD_LISTEN_CLIENT_URLS ETCD_INITIAL_ADVERTISE_PEER_URLS ETCD_ADVERTISE_CLIENT_URLS
- メンバーシステムを etcd ノードとして使用していた場合には、/etc/etcd/etcd.conf ファイルの現在の値を上書きする必要があります。
ファイルで構文エラーや欠落している IP アドレスがないかを確認します。エラーや欠落がある場合には、etced サービスが失敗してしまう可能性があります。
# vi ${PREFIX}/etcd.conf
-
インストールファイルをホストするノードでは、/etc/ansible/hosts インベントリーファイルの
[etcd]ホストグループを更新します。古い etcd ホストを削除し、新規ホストを追加します。 証明書、サンプル設定ファイル、および
caを含むtgzファイルを作成し、これを新規ホストにコピーします。# tar -czvf /etc/etcd/generated_certs/${CN}.tgz -C ${PREFIX} . # scp /etc/etcd/generated_certs/${CN}.tgz ${CN}:/tmp/
新規 etcd ホストの変更
iptables-servicesをインストールして etcd の必要なポートを開くために iptables ユーティリティーを指定します。# yum install -y iptables-services
etcd の通信を許可する
OS_FIREWALL_ALLOWファイアウォールルールを作成します。- クライアントのポート 2379/tcp
ピア通信のポート 2380/tcp
# systemctl enable iptables.service --now # iptables -N OS_FIREWALL_ALLOW # iptables -t filter -I INPUT -j OS_FIREWALL_ALLOW # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2379 -j ACCEPT # iptables -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2380 -j ACCEPT # iptables-save | tee /etc/sysconfig/iptables
注記この例では、新規チェーン
OS_FIREWALL_ALLOWが作成されます。これは、OpenShift Container Platform インストーラーがファイアウォールルールに使用する標準の名前になります。警告環境が IaaS 環境でホストされている場合には、インスタンスがこれらのポートに入ってくるトラフィックを許可できるように、セキュリティーグループを変更します。
etcd をインストールします。
# yum install -y etcd
バージョン
etcd-2.3.7-4.el7.x86_64以降がインストールされていることを確認します。etcd サービスが実行されていないことを確認します。
# systemctl disable etcd --now
etcd 設定およびデータを削除します。
# rm -Rf /etc/etcd/* # rm -Rf /var/lib/etcd/*
証明書および設定ファイルを展開します。
# tar xzvf /tmp/etcd0.example.com.tgz -C /etc/etcd/
ファイル所有者のパーミッションを変更します。
# chown -R etcd/etcd /etc/etcd/* # chown -R etcd/etcd /var/lib/etcd/
新規ホストで etcd を起動します。
# systemctl enable etcd --now
ホストがクラスターの一部であることと現在のクラスターの正常性を確認します。
v2 etcd 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,\ https://*etcd0.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 8b8904727bf526a5 is healthy: got healthy result from https://192.168.55.21:2379 member ed4f0efd277d7599 is healthy: got healthy result from https://192.168.55.13:2379 cluster is healthyv3 etcd 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,\ https://*etcd0.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 https://etcd0.example.com:2379 is healthy: successfully committed proposal: took = 1.498829ms
各 OpenShift Container Platform マスターの変更
すべてのマスターの
/etc/origin/master/master-config.yamlファイルのetcClientInfoセクションでマスター設定を変更します。新規 etcd ホストを、データを保存するために OpenShift Container Platform が使用する etcd サーバーの一覧に追加し、失敗したすべての etcd ホストを削除します。etcdClientInfo: ca: master.etcd-ca.crt certFile: master.etcd-client.crt keyFile: master.etcd-client.key urls: - https://master-0.example.com:2379 - https://master-1.example.com:2379 - https://master-2.example.com:2379 - https://etcd0.example.com:2379マスター API サービスを再起動します。
全マスターのインストールに対しては、以下を実行します。
# systemctl restart atomic-openshift-master-api
または、単一マスタークラスターのインストールでは以下を実行してください。
＃systemctl restart atomic-openshift-master
警告etcd ノードの数は奇数でなければなりません。そのため、2 つ以上のホストを追加する必要があります。
Flannel を使用する場合、新規 etcd ホストを組み込むために、すべての OpenShift Container Platform ホストの
/etc/sysconfig/flanneldにあるflanneldサービス設定を変更します。FLANNEL_ETCD_ENDPOINTS=https://master-0.example.com:2379,https://master-1.example.com:2379,https://master-2.example.com:2379,https://etcd0.example.com:2379
flanneldサービスを再起動します。# systemctl restart flanneld.service
3.7. OpenShift Container Platform サービスの再オンライン化
変更を終了した後に、OpenShift Container Platform をオンラインに戻します。
手順
それぞれの OpenShift Container Platform マスターで、バックアップからマスターおよびノード設定を復元し、すべての関連するサービスを有効にしてから再起動します。
# cp ${MYBACKUPDIR}/etc/sysconfig/atomic-openshift-master-api /etc/sysconfig/atomic-openshift-master-api # cp ${MYBACKUPDIR}/etc/sysconfig/atomic-openshift-master-controllers /etc/sysconfig/atomic-openshift-master-controllers # cp ${MYBACKUPDIR}/etc/origin/master/master-config.yaml.<timestamp> /etc/origin/master/master-config.yaml # cp ${MYBACKUPDIR}/etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml # cp ${MYBACKUPDIR}/etc/origin/master/scheduler.json.<timestamp> /etc/origin/master/scheduler.json # systemctl enable atomic-openshift-master-api # systemctl enable atomic-openshift-master-controllers # systemctl enable atomic-openshift-node # systemctl start atomic-openshift-master-api # systemctl start atomic-openshift-master-controllers # systemctl start atomic-openshift-node各 OpenShift Container Platform ノードで、必要に応じてノードの設定マップを更新し、atomic-openshift-node サービスを有効化して再起動します。
# cp /etc/origin/node/node-config.yaml.<timestamp> /etc/origin/node/node-config.yaml # systemctl enable atomic-openshift-node # systemctl start atomic-openshift-node
3.8. プロジェクトの復元
プロジェクトを復元するには、oc create -f pods.json を実行して新規プロジェクトを作成してから、エクスポートされたファイルを復元します。ただし、プロジェクトをゼロから復元するには、一部のプロジェクトが他のプロジェクトに依存していることから特定の順序を指定する必要があります。たとえば、pods を作成する前に configmaps を作成する必要があります。
手順
プロジェクトが単一ファイルとしてエクスポートされている場合は、以下のコマンドを実行してこのファイルをインポートします。
$ oc new-project <projectname> $ oc create -f project.yaml $ oc create -f secret.yaml $ oc create -f serviceaccount.yaml $ oc create -f pvc.yaml $ oc create -f rolebindings.yaml
警告Pod およびデフォルトサービスアカウントなどの一部のリソースは作成できない場合があります。
project_export.shスクリプトを使用してプロジェクトをエクスポートした場合、ファイルはprojectnameディレクトリーにあります。それらは、project_import.shスクリプトを再度実行してインポートできます。このスクリプトは適切な順序でoc createプロセスを実行します。$ mkdir ~/git $ cd ~/git $ git clone https://github.com/openshift/openshift-ansible-contrib.git $ cd openshift-ansible-contrib/reference-architecture/day2ops/scripts $ ./project_import.sh <projectname_path>
以下に例を示します。
$ ls ~/backup/myproject bcs.json dc_guestbook_patched.json dc_ruby-ex_patched.json pvcs.json secrets.json builds.json dc_hello-openshift.json iss.json rcs.json serviceaccounts.json cms.json dc_hello-openshift_patched.json ns.json rolebindings.json svcs.json dc_guestbook.json dc_ruby-ex.json pods.json routes.json templates.json $ ./project_import.sh ~/backup/myproject namespace "myproject" created rolebinding "admin" created rolebinding "system:deployers" created rolebinding "system:image-builders" created rolebinding "system:image-pullers" created secret "builder-dockercfg-mqhs6" created secret "default-dockercfg-51xb9" created secret "deployer-dockercfg-6kvz7" created Error from server (AlreadyExists): error when creating "myproject//serviceaccounts.json": serviceaccounts "builder" already exists Error from server (AlreadyExists): error when creating "myproject//serviceaccounts.json": serviceaccounts "default" already exists Error from server (AlreadyExists): error when creating "myproject//serviceaccounts.json": serviceaccounts "deployer" already exists error: no objects passed to create service "guestbook" created service "hello-openshift" created service "ruby-ex" created imagestream "guestbook" created imagestream "hello-openshift" created imagestream "ruby-22-centos7" created imagestream "ruby-ex" created error: no objects passed to create error: no objects passed to create buildconfig "ruby-ex" created build "ruby-ex-1" created deploymentconfig "guestbook" created deploymentconfig "hello-openshift" created deploymentconfig "ruby-ex" created replicationcontroller "ruby-ex-1" created Error from server (AlreadyExists): error when creating "myproject//rcs.json": replicationcontrollers "guestbook-1" already exists Error from server (AlreadyExists): error when creating "myproject//rcs.json": replicationcontrollers "hello-openshift-1" already exists pod "guestbook-1-c010g" created pod "hello-openshift-1-4zw2q" created pod "ruby-ex-1-rxc74" created Error from server (AlreadyExists): error when creating "myproject//pods.json": object is being deleted: pods "ruby-ex-1-build" already exists error: no objects passed to create
注記serviceaccountsおよびシークレットなどの一部のオブジェクトがプロジェクト作成時に自動的に作成されるためにAlreadyExistsエラーが表示される場合があります。buildconfigsを使用するかどうかを確認します。$ oc get bc NAME TYPE FROM LATEST ruby-ex Source Git 1 $ oc get pods NAME READY STATUS RESTARTS AGE guestbook-1-plnnq 1/1 Running 0 26s hello-openshift-1-g4g0j 1/1 Running 0 26s
buildconfigsを使用する場合、ビルドは自動的にトリガーされず、アプリケーションは実行されません。buildconfigsを使用する場合、ビルドをトリガーするにはoc start-buildコマンドを実行します。$ for bc in $(oc get bc -o jsonpath="{.items[*].metadata.name}") do oc start-build ${bc} donePod はビルドの完了後にデプロイされます。
プロジェクトが復元されたことを確認するには、以下を実行します。
$ oc get all NAME TYPE FROM LATEST bc/ruby-ex Source Git 2 NAME TYPE FROM STATUS STARTED DURATION builds/ruby-ex-1 Source Git Error (BuildPodDeleted) About a minute ago builds/ruby-ex-2 Source Git@c457001 Complete 55 seconds ago 12s NAME DOCKER REPO TAGS UPDATED is/guestbook 10.111.255.221:5000/myproject/guestbook latest About a minute ago is/hello-openshift 10.111.255.221:5000/myproject/hello-openshift latest About a minute ago is/ruby-22-centos7 10.111.255.221:5000/myproject/ruby-22-centos7 latest About a minute ago is/ruby-ex 10.111.255.221:5000/myproject/ruby-ex latest 43 seconds 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 1m rc/hello-openshift-1 1 1 1 1m rc/ruby-ex-1 1 1 1 43s NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/guestbook 10.111.126.115 <none> 3000/TCP 1m svc/hello-openshift 10.111.23.21 <none> 8080/TCP,8888/TCP 1m svc/ruby-ex 10.111.162.157 <none> 8080/TCP 1m NAME READY STATUS RESTARTS AGE po/guestbook-1-plnnq 1/1 Running 0 1m po/hello-openshift-1-g4g0j 1/1 Running 0 1m po/ruby-ex-1-h99np 1/1 Running 0 42s po/ruby-ex-2-build 0/1 Completed 0 55s
注記サービスおよび Pod IP アドレスは作成時に動的に割り当てられるので異なります。
3.9. アプリケーションデータの復元
rsync がコンテナーイメージ内にインストールされていることを前提とすると、アプリケーションデータは oc rsync コマンドを使用して復元できます。Red Hat rhel7 ベースイメージには rsync が含まれるので、rhel7 をベースとするすべてのイメージにもこれが含まれます。「CLI 操作のトラブルシューティングおよびデバッグ - rsync」を参照してください。
これはアプリケーションデータの 汎用的な 復元についての説明であり、データベースシステムの特殊なエクスポート/インポート手順などのアプリケーション固有のバックアップ手順については考慮に入れられていません。
使用する永続ボリュームのタイプ (Cinder、NFS、Gluster など) によっては、他の復元手段を使用できる場合もあります。
手順
Jenkins デプロイメントのアプリケーションデータの復元例
バックアップを確認します。
$ ls -la /tmp/jenkins-backup/ total 8 drwxrwxr-x. 3 user user 20 Sep 6 11:14 . drwxrwxrwt. 17 root root 4096 Sep 6 11:16 .. drwxrwsrwx. 12 user user 4096 Sep 6 11:14 jenkins
oc rsyncツールを使用してデータを実行中の Pod にコピーします。$ oc rsync /tmp/jenkins-backup/jenkins jenkins-1-37nux:/var/lib
注記アプリケーションによっては、アプリケーションを再起動する必要があります。
オプションとして、新規データを使ってアプリケーションを再起動します。
$ oc delete pod jenkins-1-37nux
または、デプロイメントを 0 にスケールダウンしてから再びスケールアップします。
$ oc scale --replicas=0 dc/jenkins $ oc scale --replicas=1 dc/jenkins
3.10. Persistent Volume Claim (永続ボリューム要求、PVC) の復元
このトピックでは、データを復元するための 2 つの方法について説明します。最初の方法ではファイルを削除してから、ファイルを予想される場所に戻します。2 つ目の例では、PVC を移行する方法を示します。この移行は、ストレージを移動する必要がある場合や、バックアップストレージがなくなるなどの障害発生時の状況で実行されます。
データをアプリケーションに復元する手順について、特定のアプリケーションについての復元手順を確認してください。
3.10.1. ファイルの既存 PVC への復元
手順
ファイルを削除します。
$ oc rsh demo-2-fxx6d sh-4.2$ ls */opt/app-root/src/uploaded/* lost+found ocp_sop.txt sh-4.2$ *rm -rf /opt/app-root/src/uploaded/ocp_sop.txt* sh-4.2$ *ls /opt/app-root/src/uploaded/* lost+found
PVC にあったファイルの rsync バックアップが含まれるサーバーのファイルを置き換えます。
$ oc rsync uploaded demo-2-fxx6d:/opt/app-root/src/
oc rshを使用してファイルが Pod に戻されていることを確認し、Pod に接続してディレクトリーのコンテンツを表示します。$ oc rsh demo-2-fxx6d sh-4.2$ *ls /opt/app-root/src/uploaded/* lost+found ocp_sop.txt
3.10.2. データの新規 PVC への復元
以下の手順では、新規 pvc が作成されていることを前提としています。
手順
現在定義されている
claim-nameを上書きします。$ oc volume dc/demo --add --name=persistent-volume \ --type=persistentVolumeClaim --claim-name=filestore \ --mount-path=/opt/app-root/src/uploaded --overwrite
Pod が新規 PVC を使用していることを確認します。
$ oc describe dc/demo Name: demo Namespace: test Created: 3 hours ago Labels: app=demo Annotations: openshift.io/generated-by=OpenShiftNewApp Latest Version: 3 Selector: app=demo,deploymentconfig=demo Replicas: 1 Triggers: Config, Image(demo@latest, auto=true) Strategy: Rolling Template: Labels: app=demo deploymentconfig=demo Annotations: openshift.io/container.demo.image.entrypoint=["container-entrypoint","/bin/sh","-c","$STI_SCRIPTS_PATH/usage"] openshift.io/generated-by=OpenShiftNewApp Containers: demo: Image: docker-registry.default.svc:5000/test/demo@sha256:0a9f2487a0d95d51511e49d20dc9ff6f350436f935968b0c83fcb98a7a8c381a Port: 8080/TCP Volume Mounts: /opt/app-root/src/uploaded from persistent-volume (rw) Environment Variables: <none> Volumes: persistent-volume: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) *ClaimName: filestore* ReadOnly: false ...omitted...デプロイメント設定では新規の
pvcを使用しているため、oc rsyncを実行してファイルを新規のpvcに配置します。$ oc rsync uploaded demo-3-2b8gs:/opt/app-root/src/ sending incremental file list uploaded/ uploaded/ocp_sop.txt uploaded/lost+found/ sent 181 bytes received 39 bytes 146.67 bytes/sec total size is 32 speedup is 0.15
oc rshを使用してファイルが Pod に戻されていることを確認し、Pod に接続してディレクトリーのコンテンツを表示します。$ oc rsh demo-3-2b8gs sh-4.2$ ls /opt/app-root/src/uploaded/ lost+found ocp_sop.txt
