Linuxサーバーを移行する方法パート3-最終ステップ
序章
データと運用要件をあるサーバーから別のサーバーに移動しなければならないシナリオはたくさんあります。 ソリューションを新しいデータセンターに実装するか、より大きなマシンにアップグレードするか、新しいハードウェアまたは新しいVPSプロバイダーに移行する必要がある場合があります。
理由が何であれ、あるシステムから別のシステムに移行する際には、さまざまな考慮事項を考慮する必要があります。 Chef、Puppet、Ansibleなどの構成管理ソリューションを使用していない場合、機能的に同等の構成を取得するのは難しい場合があります。 データを転送するだけでなく、新しいマシンでも同じように動作するようにサービスを構成する必要があります。
このシリーズの前回の記事では、rsyncを使用してパッケージやその他のデータを転送する方法について説明しました。 このチュートリアルでは、ユーザー、グループ、crontab、およびその他の設定を移行して、移行を完了します。
ステップ1-ユーザーとグループを移行する
Linuxパッケージマネージャーは非常に強力で再現性があり、前のチュートリアルでシステムパッケージを移行することにより、必要な構成設定のほとんどを移行できます。 ただし、これにより、ユーザーやグループの権限など、古いサーバーで手動で変更した可能性のある設定の一部が省略されます。 これらも移行または再作成する必要があります。
幸い、Linuxのすべてのユーザーとグループ設定はいくつかのファイルに含まれています。 これらのファイルには次のものが含まれます。
-
/ etc / passwd ：このファイルはユーザーとその属性を定義します。 その名前にもかかわらず、このファイルにはパスワード情報が含まれていません。 これには、ユーザー名、ユーザーとプライマリグループ番号、ホームディレクトリ、およびデフォルトのシェルが含まれます。
-
/ etc / shadow ：このファイルには、各ユーザーの実際のパスワード設定が含まれています。 で定義された各ユーザーの行が含まれている必要があります
passwdファイル、パスワードのハッシュ、およびパスワードポリシーに関する情報。 -
/ etc / group ：このファイルは、システムで使用可能な各グループを定義します。 これには、グループ名と関連するグループ番号、およびグループメンバーシップが含まれます。
-
/ etc / gshadow ：このファイルには、システム上の各グループの行が含まれています。 グループの名前、グループ以外のメンバーがグループにアクセスするために使用できるパスワード、管理者のリスト、およびその他のメンバーが一覧表示されます。
これらのファイルをあるライブシステムから別のライブシステムに直接コピーしないでください。 ユーザー番号とグループ番号は、各システムで作成されるときに自動的にインクリメントされ、一致しない場合は競合が発生します。 代わりに、これらを使用して選択的に移行できます awk、前のチュートリアルのように。
移行ファイルの作成
上記の各ファイルに関連付けられた新しい移行ファイルを作成します。 これにより、以下から始めて、それらすべてを体系的に移行できます。 /etc/passwd.
まず、通常のユーザーIDがソースシステムで500からカウントを開始するか1000からカウントを開始するかを確認する必要があります。 最近のほとんどのLinux環境は、システムユーザーのためにより多くのスペースを確保するために、1000から数え始めますが、非常に古いシステムから移行する場合は、500から数えることがあります。 確認するには、の最後の行を印刷できます /etc/passwd 自分のユーザーアカウント番号を確認するためのファイル：
- less /etc/passwd
Output…
vault:x:997:997::/home/vault:/bin/bash
stunnel4:x:112:119::/var/run/stunnel4:/usr/sbin/nologin
sammy:x:1001:1002::/home/sammy:/bin/sh
この場合、出力の3番目の列にある通常のユーザーIDは1000以上のように見えるため、1000になります。 この制限を下回るユーザーまたはグループはエクスポートされません。 また、 nobody IDが自動的に割り当てられるアカウント 65534.
使用する awk、あなたはあなたのための同期ファイルを作成することができます /etc/passwd ファイル。 The awk このチュートリアルのコマンドは、構文が複雑なため、そのまま提供されますが、別のチュートリアルでawkの使用についてさらに学ぶことができることを忘れないでください。
- awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync
次に、同じ構文と同じユーザーID制限を使用して、 /etc/group ファイル：
- awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync
解析するには /etc/shadow、あなたはあなたからのデータを使用することができます /etc/passwd 入力としてのファイル：
- awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync
同じアプローチが /etc/gshadow:
- awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync
これらのコマンドをテストし、実際のデータからエクスポートファイルを作成することを確認したら、それらをに追加できます。 sync.sh 前回のチュートリアルから維持しているスクリプト。 これらの各コマンドをリモートで実行できます。つまり、元のソースマシンから出力を取得することで、ターゲットマシンで実行されるスクリプトの一部として、コマンドの前にコマンドを追加できます。 ssh source_server、およびのラッピング awk 引用符で囲んだコマンド。
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync"
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync"
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync"
ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync"
rsync source_server:~/passwd.sync ~/
rsync source_server:~/group.sync ~/
rsync source_server:~/shadow.sync ~/
rsync source_server:~/gshadow.sync ~/
このデータをターゲットマシンにエクスポートした後、ユーザーとグループをターゲットマシンに自動的に追加できます。 ただし、他のコマンドとは異なり、同じ環境で再実行すると重複が発生するため、移行スクリプトに追加するのではなく、手動で実行する必要があります。
と呼ばれるコマンドがあります newusers 入力ファイルから複数のユーザーを追加できます。 ただし、最初に、別のを使用する必要があります awk 同期ファイルから数値IDを削除するコマンド：
- awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' ~/passwd.sync > ~/passwd.sync.mod
次に、そのファイルをに渡すことができます newusers:
- newusers ~/passwd.sync.mod
これにより、ファイルからローカルにすべてのユーザーが追加されます /etc/passwd ファイル。 また、関連付けられたユーザーグループが自動的に作成されます。 ユーザーに関連付けられていないグループを手動で追加する必要があります /etc/group ファイル。 対応するターゲットファイルを編集するための参照ポイントとして同期ファイルを使用します。
のために /etc/shadow ファイル、あなたはあなたから2番目の列をコピーすることができます shadow.sync 新しいシステムの関連するアカウントの2番目の列にファイルします。 これにより、アカウントのパスワードが新しいシステムに転送されます。 転送する必要のあるアカウントの数に応じて、これらの変更をスクリプト化することもできます。
ステップ2–ジョブを新しいシステムに転送する
ユーザー、パッケージ、およびその他のデータが古いシステムから転送されたので、もう1つのステップがあります。それは、各ユーザーのシステムジョブとメールを転送することです。
The /var/spool Linuxのディレクトリには、公式には「何らかの後の処理を待っているデータが含まれています」。 実際には、これには通常、構成したcronジョブと、システム自体によって処理されるメールが含まれます。 実際にはローカルでメールサーバーを実行していない可能性がありますが、Linuxの「メール」の内部概念には、一部のソフトウェアからのログと通知も含まれているため、これらも確実にキャプチャすることが重要です。
このプロセスを開始するには、spoolディレクトリに対して別のrsyncコマンドを記述します。 The spool ディレクトリには通常、 cron, mail、およびその他のログ：
- ls /var/spool
Outputanacron cron mail plymouth rsyslog
メールディレクトリをターゲットサーバーに転送するには、別のディレクトリを追加します rsync 移行スクリプトへのコマンド：
rsync -azvP --progress source_server:/var/spool/mail/* /var/spool/mail/
内の別のディレクトリ /var/spool 注意が必要なディレクトリは cron ディレクトリ。 このディレクトリには、タスクのスケジューリングに使用されるcronジョブが含まれています。 The crontabs サブディレクトリには、個々のユーザーの cron 構成。
あなたの転送 crontabs を使用して rsync:
rsync -azvP --progress source_server:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*
これは、個々のユーザーを処理します cron 構成。 ただし、システム全体をキャプチャすることはありません cron 設定。 以内 /etc ディレクトリには、システム全体のcrontabと、それを含む他の多くのディレクトリがあります。 cron 設定。
- ls /etc/cron*
Outputcron.d
cron.daily
cron.hourly
cron.monthly
crontab
cron.weekly
The crontab ファイルにはシステム全体が含まれています cron 詳細。 他のアイテムは、他のcron情報を含むディレクトリです。 それらを調べて、必要な情報が含まれているかどうかを判断します。
もう一度、使用します rsync 関連するcron情報を新しいシステムに転送するには：
- rsync -azvP --progress source_server:/etc/crontab /etc/crontab
あなたが調査している間 cron の構成 /etc、他の構成ファイルを見落としていないことを確認してください。 たとえば、NginxWebサーバーはその構成をに保存します /etc/nginx、およびこれが移行スクリプトによってキャプチャされていることを確認する必要があります。
新しいシステムでcron情報を取得したら、それが機能することを確認する必要があります。 これを正しく行う唯一の方法は、個々のユーザーとしてログインし、各ユーザーのcrontabでコマンドを手動で実行することです。 これにより、これらのコマンドが自動的に実行されたときにサイレントに失敗するのを防ぐアクセス許可の問題やファイルパスの欠落がないことが保証されます。
ステップ3–サイトとサービスをテストする
この時点で、移行スクリプトへのコマンドの追加とデータの転送が完了しているはずです。 次のステップは、新しいサーバーで関連するすべてのサービスの再起動を開始することです。 たとえば、再起動できます nginx 実行することによるWebサーバー sudo systemctl restart nginx、ただし、これは、新しいサーバーにNginxパッケージをインストールしたときに自動的に実行されます。 が用に独自のユニットファイルを作成した、またはDockerを介してデプロイしたその他のサービスについては、手動で再起動をテストする必要があります。 また、サーバーを少なくとも1回再起動して、ダウンタイム後にこれらのサービスが適切に再開できるようにする必要があります。 問題が発生するかどうかを確認するためにテストしているときに、関連するログファイルに注意してください。
他のスポットチェックも実行できます。 たとえば、 /data 転送先のディレクトリ rsync、ソースコンピュータとターゲットコンピュータの両方でそのディレクトリに移動し、 du サイズを確認するコマンド：
- cd /data
- du -hs
Output471M .
2つのシステムの間に不一致がある場合は、調査する必要があります。
次に、各マシンで実行されているプロセスを確認できます。 使用できます top アクティブなプロセスの概要を取得するには：
- top
Outputtop - 21:20:33 up 182 days, 22:04, 1 user, load average: 0.00, 0.01, 0.00
Tasks: 124 total, 3 running, 121 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.0 us, 1.0 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 981.3 total, 82.8 free, 517.8 used, 380.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 182.0 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11 root 20 0 0 0 0 I 0.3 0.0 29:45.20 rcu_sched
99465 root 20 0 685508 27396 5372 S 0.3 2.7 161:41.83 node /root/hell
104207 vault 20 0 837416 236528 128012 S 0.3 23.5 134:53.49 vault
175635 root 20 0 11000 3824 3176 R 0.3 0.4 0:00.03 top
1 root 20 0 170636 9116 4200 S 0.0 0.9 8:50.40 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:01.04 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
. . .
また、ソースマシンで最初に行ったチェックの一部を複製して、新しいマシンで環境を正しく再現したかどうかを確認することもできます。 もう一度実行できます netstat とともに -nlp 概要を取得するためのフラグ：
- netstat -nlp
OutputActive Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 104207/vault
tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 3691671/nginx: mast
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3691671/nginx: mast
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3691671/nginx: mast
tcp 0 0 0.0.0.0:1936 0.0.0.0:* LISTEN 197885/stunnel4
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 162540/systemd-reso
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 129518/sshd: /usr/s
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 99465/node /root/he
tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 3691671/nginx: mast
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3691671/nginx: mast
tcp 0 0 0.0.0.0:56733 0.0.0.0:* LISTEN 170269/docker-proxy
tcp6 0 0 :::80 :::* LISTEN 3691671/nginx: mast
tcp6 0 0 :::22 :::* LISTEN 129518/sshd: /usr/s
tcp6 0 0 :::443 :::* LISTEN 3691671/nginx: mast
tcp6 0 0 :::56733 :::* LISTEN 170275/docker-proxy
udp 0 0 127.0.0.53:53 0.0.0.0:* 162540/systemd-reso
raw6 0 0 :::58 :::* 7 162524/systemd-netw
raw6 0 0 :::58 :::* 7 162524/systemd-netw
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 5313074 1/systemd /run/systemd/userdb/io.systemd.DynamicUser
unix 2 [ ACC ] SEQPACKET LISTENING 12985 1/systemd /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 12967 1/systemd /run/lvm/lvmpolld.socket
unix 2 [ ACC ] STREAM LISTENING 12980 1/systemd /run/systemd/journal/stdout
unix 2 [ ACC ] STREAM LISTENING 16037236 95187/systemd /run/user/0/systemd/private
…
再実行することもできます lsof:
- lsof
OutputCOMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node\x20/ 99465 root 20u IPv4 16046039 0t0 TCP 127.0.0.1:3000 (LISTEN)
vault 104207 vault 8u IPv4 1134285 0t0 TCP *:8200 (LISTEN)
sshd 129518 root 3u IPv4 1397496 0t0 TCP *:22 (LISTEN)
sshd 129518 root 4u IPv6 1397507 0t0 TCP *:22 (LISTEN)
systemd-r 162540 systemd-resolve 12u IPv4 5313507 0t0 UDP 127.0.0.53:53
systemd-r 162540 systemd-resolve 13u IPv4 5313508 0t0 TCP 127.0.0.53:53 (LISTEN)
docker-pr 170269 root 4u IPv4 1700561 0t0 TCP *:56733 (LISTEN)
docker-pr 170275 root 4u IPv6 1700573 0t0 TCP *:56733 (LISTEN)
stunnel4 197885 stunnel4 9u IPv4 1917328 0t0 TCP *:1936 (LISTEN)
sshd 3469804 root 4u IPv4 22246413 0t0 TCP 159.203.102.125:22->154.5.29.188:36756 (ESTABLISHED)
nginx 3691671 root 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)
nginx 3691671 root 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)
nginx 3691671 root 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)
nginx 3691671 root 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)
nginx 3691671 root 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)
nginx 3691671 root 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)
nginx 3691671 root 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)
nginx 3691674 www-data 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)
nginx 3691674 www-data 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)
nginx 3691674 www-data 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)
nginx 3691674 www-data 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)
nginx 3691674 www-data 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)
nginx 3691674 www-data 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)
nginx 3691674 www-data 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)
WebサーバーまたはWeb向けアプリケーションを転送した場合は、新しいサーバーでサイトもテストする必要があります。 構成によっては、ドメイン名を移行してHTTPS証明書を再登録する必要がある場合があります。 新しいサーバーがVPNまたは別の入力レイヤーの背後にある場合は、完全な本番カットオーバーを実行する前に、別のURLの背後でサーバーをテストできる場合があります。
また、ファイアウォールルールを移行することもできます。これは通常、に含まれています。 /etc/sysconfig/iptables と /etc/sysconfig/ip6tables.
ルールを新しいサーバーにロードする前に、IPアドレスや範囲の変更など、更新が必要なルールがないかどうかを確認する必要があります。
ステップ4–DNS設定を変更する
ターゲットサーバーにすべての最新データがあり、Webエンドポイントをテストしたら、ドメインのDNSサーバーを変更して新しいサーバーを指すようにすることができます。 古いサーバーのIPへのすべての参照が、新しいサーバーの情報に置き換えられていることを確認してください。
DigitalOceanのDNSサーバーを使用している場合は、ドメイン名の構成方法について読むことができます。
DNSの変更は、通常、ほとんどの家庭用インターネットISPに反映されるまでに数分から1時間かかります。 変更を反映するようにDNSが更新された後、移行スクリプトを最後に実行して、元のサーバーにまだ送信されていた漂遊要求が転送されることを確認する必要がある場合があります。
結論
これで、新しいサーバーが稼働し、要求を受け入れ、以前のサーバーにあったすべてのデータを処理できるようになります。 異常がないか、新しいサーバーを引き続き注意深く監視する必要があります。
移行は簡単ではありません。 ライブサーバーの移行が成功する可能性が最も高いのは、開始する前に、システムをできる限り理解することです。 システムはそれぞれ異なり、毎回、新しい問題を回避する必要があります。 発生する可能性のある問題のトラブルシューティングを行う時間がない場合は、移行を試みないでください。
次に、Ansibleを使用したサーバーの構成とデプロイについて学習することをお勧めします。
