序章

データと運用要件をあるサーバーから別のサーバーに移動しなければならないシナリオはたくさんあります。 ソリューションを新しいデータセンターに実装するか、より大きなマシンにアップグレードするか、新しいハードウェアまたは新しいVPSプロバイダーに移行する必要がある場合があります。

理由が何であれ、あるシステムから別のシステムに移行する際には、さまざまな考慮事項を考慮する必要があります。 Chef、Puppet、Ansibleなどの構成管理ソリューションを使用していない場合、機能的に同等の構成を取得するのは難しい場合があります。 データを転送するだけでなく、新しいマシンでも同じように動作するようにサービスを構成する必要があります。

注:一般的な注意として、最新のデプロイでは、一時的なKubernetesノードとして設計されているか、システムサービスとコンテナ化されたソフトウェアの組み合わせを実行しているかにかかわらず、可能な限り常に構成管理システムを使用する必要があります。 このガイドは、これがではなくの場合に主に役立ち、サービスを手動でカタログ化して移行する必要があります。

このガイドでは、移行のためにソースシステムとターゲットシステムを準備する方法を確認します。 これには、2台のマシンがSSHキーと通信できるようにすることと、どのコンポーネントを転送する必要があるかを調査することが含まれます。 実際の移行は、このシリーズの次の記事で開始します。

ステップ1-バックアップを作成する

破壊的な可能性のあるアクションを実行するときに実行する最初のステップは、新しいバックアップを作成することです。 交換が稼働する前に、コマンドが現在の実稼働マシンで何かを壊すような状況に置かれたくないでしょう。

サーバーをバックアップするには、さまざまな方法があります。 選択は、シナリオに適したオプションと最も快適なオプションによって異なります。

物理ハードウェアとバックアップ用のスペース(ディスクドライブ、USBなど)にアクセスできる場合は、利用可能な多くのイメージバックアップソリューションのいずれかを使用してディスクのクローンを作成できます。 クラウドサーバーを扱う場合の機能的な同等物は、コントロールパネルインターフェイス内からスナップショットまたはイメージを取得することです。

バックアップが完了すると、続行する準備が整います。 このガイドの残りの部分では、rootとして、またはを使用して多くのコマンドを実行する必要があります。 sudo.

ステップ2–ソースシステムに関する情報を収集する

移行を開始する前に、ソースシステムと一致するようにターゲットシステムを構成する必要があります。

現在のサーバーと移行先のサーバーをできるだけ一致させる必要があります。 新しいターゲットシステムに移行する前に現在のサーバーをアップグレードし、後で別のバックアップセットを作成することをお勧めします。 重要なことは、実際の移行を開始するときに、それらが可能な限り一致することです。

新しいマシン用に作成するサーバーシステムを決定するのに役立つ情報のほとんどは、 uname 指図:

  1. uname -r
Output
5.4.0-26-generic

これは、現在のシステムが実行しているカーネルのバージョンです。 スムーズに進めるために、ターゲットシステムでそれを一致させることをお勧めします。

また、ソースサーバーのディストリビューションとバージョンを一致させるようにしてください。 ソースマシンにインストールしたディストリビューションのバージョンがわからない場合は、次のように入力して確認できます。

  1. cat /etc/issue
Output
Ubuntu 20.04.3 LTS \n \l

可能であれば、これらの同じパラメーターを使用して新しいサーバーを作成する必要があります。 この場合、Ubuntu20.04システムを作成します。 また、カーネルのバージョンをできるだけ一致させるようにしてください。 通常、これはLinuxディストリビューションのリポジトリから入手できる最新のカーネルである必要があります。

ステップ3–ソースサーバーとターゲットサーバー間のSSHキーアクセスを設定する

サーバーがファイルを転送できるように、サーバーが通信できるようにする必要があります。 これを行うには、それらの間でSSHキーを交換する必要があります。 LinuxサーバーでSSHキーを設定する方法を学ぶことができます。

ターゲットサーバーに新しいキーを作成して、既存のサーバーに追加できるようにする必要があります。 authorized_keys ファイル。 これは、他の方法よりもクリーンです。この方法では、新しいサーバーに漂遊キーが含まれないためです。 authorized_keys 移行が完了したときにファイル。

まず、宛先マシンで、次のように入力して、rootユーザーがSSHキーをまだ持っていないことを確認します。

  1. ls ~/.ssh
Output
authorized_keys

と呼ばれるファイルが表示された場合 id_rsa.pubid_rsa、その後、あなたはすでに鍵を持っているので、それらを転送する必要があります。

これらのファイルが表示されない場合は、を使用して新しいキーペアを作成してください ssh-keygen:

  1. ssh-keygen -t rsa

すべてのプロンプトで「Enter」を押して、デフォルトを受け入れます。

これで、キーをパイプでつなぐことにより、ソースサーバーにキーを転送できます。 ssh:

  1. cat ~/.ssh/id_rsa.pub | ssh other_server_ip "cat >> ~/.ssh/authorized_keys"

これで、パスワードを入力しなくても、ターゲットシステムからソースサーバーに自由にSSH接続できるようになります。

  1. ssh other_server_ip

これにより、それ以降の移行手順がはるかにスムーズになります。

ステップ4–要件のリストを作成する

これで、実際にシステムの詳細な分析を行うことになります。

操作の過程で、ソフトウェア要件が変更される可能性があります。 古いサーバーには、ある時点で必要だったものの、置き換えられたサービスやソフトウェアが含まれている場合があります。

一般に、不要なサービスを無効にし、完全に不要な場合はアンインストールすることができますが、それらのストックを取得するには時間がかかる可能性があります。 ソースサーバーで使用されているサービスを検出してから、それらのサービスを新しいサーバーに存在させる必要があるかどうかを判断する必要があります。

サービスとランレベルを検出する方法は、サーバーが採用している「init」システムのタイプによって異なります。 initシステムは、ユーザーのコマンドで、または自動的に、サービスを開始および停止する責任があります。 2014年頃から、ほとんどすべての主要なLinuxディストリビューションがSystemdと呼ばれるinitシステムを採用しました。このガイドには、Systemdが反映されます。

Systemdに登録されているサービスを一覧表示するには、 systemctl 指図:

  1. systemctl list-units -t service
Output
UNIT LOAD ACTIVE SUB DESCRIPTION > accounts-daemon.service loaded active running Accounts Service > apparmor.service loaded active exited Load AppArmor profiles > apport.service loaded active exited LSB: automatic crash repor> atd.service loaded active running Deferred execution schedul> blk-availability.service loaded active exited Availability of block devi> cloud-config.service loaded active exited Apply the settings specifi> cloud-final.service loaded active exited Execute cloud user/final s> cloud-init-local.service loaded active exited Initial cloud-init job (pr> cloud-init.service loaded active exited Initial cloud-init job (me> console-setup.service loaded active exited Set console font and keyma> containerd.service loaded active running containerd container runti> …

Systemdは、サービス管理のために「ターゲット」の概念を実装しています。 従来のinitシステムを使用するシステムは、一度に1つの「ランレベル」にしか存在できませんでしたが、Systemdを使用するサーバーは複数のターゲットに同時に到達できます。 これは実際にはより柔軟ですが、どのサービスがアクティブであるかを把握することはより困難になる可能性があります。

次のように入力すると、現在アクティブなターゲットを確認できます。

  1. systemctl list-units -t target
Output
UNIT LOAD ACTIVE SUB DESCRIPTION basic.target loaded active active Basic System cloud-config.target loaded active active Cloud-config availability cloud-init.target loaded active active Cloud-init target cryptsetup.target loaded active active Local Encrypted Volumes getty.target loaded active active Login Prompts graphical.target loaded active active Graphical Interface local-fs-pre.target loaded active active Local File Systems (Pre) local-fs.target loaded active active Local File Systems multi-user.target loaded active active Multi-User System network-online.target loaded active active Network is Online …

次のように入力すると、使用可能なすべてのターゲットを一覧表示できます。

  1. systemctl list-unit-files -t target
Output
UNIT FILE STATE VENDOR PRESET basic.target static enabled [email protected] static enabled bluetooth.target static enabled boot-complete.target static enabled cloud-config.target static enabled cloud-init.target enabled-runtime enabled cryptsetup-pre.target static disabled cryptsetup.target static enabled ctrl-alt-del.target disabled enabled …

ここから、各ターゲットに関連付けられているサービスを確認できます。 ターゲットは依存関係としてサービスまたは他のターゲットを持つことができるため、次のように入力することで、各ターゲットが実装するポリシーを確認できます。

  1. systemctl list-dependencies target_name.target

multi-user.target は、Systemdサーバーで一般的に使用されるターゲットであり、ユーザーがログインできる起動プロセスの時点で到達します。 たとえば、次のように入力します。

  1. systemctl list-dependencies multi-user.target
Output
multi-user.target ● ├─apport.service ● ├─atd.service ● ├─console-setup.service ● ├─containerd.service ● ├─cron.service ● ├─dbus.service ● ├─dmesg.service ● ├─docker.service ● ├─grub-common.service ● ├─grub-initrd-fallback.service …

これにより、そのターゲットの依存関係ツリーが一覧表示され、そのターゲットに到達したときに開始されるサービスおよびその他のターゲットの一覧が表示されます。

他の方法によるサービスの確認

パッケージマネージャーによって構成されたほとんどのサービスはinitシステムに登録されますが、Dockerデプロイメントなどの他のソフトウェアは登録されない場合があります。

これらのサービスで使用されているネットワークポートとUnixソケットを調べることで、これらの他のサービスとプロセスを見つけることができます。 ほとんどの場合、サービスは相互に、または何らかの方法で外部エンティティと通信します。 サービスが通信できるサーバーインターフェイスの数は限られており、それらのインターフェイスを確認することは、他のサービスを見つけるための良い方法です。

ネットワークポートと使用中のUnixソケットを検出するために使用できるツールの1つは netstat. あなたが実行することができます netstat とともに -nlp 概要を取得するためのフラグ:

  1. netstat -nlp
  • -n ホスト名やユーザー名ではなく、数値のIPアドレスを出力に表示するように指定します。 ローカルサーバーをチェックするとき、これは通常より有益です。
  • -l それを指定します netstat アクティブにリッスンしているソケットのみを表示する必要があります。
  • -p プロセスIDを表示します(PID)およびポートまたはソケットを使用する各プロセスの名前。
Output
Active 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 …

netstat 出力には、2つの別々のブロックが含まれます。1つはネットワークポート用、もう1つはソケット用です。 ここに、initシステムを通じて情報がないサービスが表示された場合は、その理由と、それらのサービスも移行する予定があるかどうかを理解する必要があります。

を使用して、サービスが利用可能にしているポートに関する同様の情報を取得できます。 lsof 指図:

  1. lsof
Output
COMMAND 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)

両方 netstatlsof は、他のさまざまなコンテキストで役立つコアLinuxプロセス管理ツールです。

ステップ5–パッケージバージョンの収集

この時点で、ターゲットサーバーに実装する必要があるソースマシンで実行されているサービスについての良いアイデアが得られるはずです。

実装する必要があることがわかっているサービスのリストが必要です。 移行をスムーズに進めるためには、可能な限りバージョンを一致させるようにすることが重要です。

ソースシステムにインストールされているすべてのパッケージを確認して新しいシステムに複製しようとする必要はありませんが、ニーズにとって重要なソフトウェアコンポーネントを確認し、それらのバージョン番号を見つけてください。

ソフトウェア自体からバージョン番号を取得しようとすることができます。 -v また --version 各コマンドにフラグを立てますが、これはパッケージマネージャーを介して行う方が簡単です。 Ubuntu / Debianベースのシステムを使用している場合は、を使用してインストールされているパッケージのバージョンを確認できます。 dpkg 指図:

  1. dpkg -l | grep package_name

代わりに、Rocky Linux、RHEL、またはFedoraベースのシステムを使用している場合は、次を使用できます。 rpm 同じ目的のために:

  1. rpm -qa | grep package_name

これにより、一致させたいパッケージバージョンの良いアイデアが得られます。 関連するソフトウェアのバージョン番号を必ず保持してください。

結論

これで、ソースサーバー上のどのプロセスとサービスを新しいマシンに転送する必要があるかについての良いアイデアが得られたはずです。 また、2台のサーバーが相互に通信できるようにするための準備手順を完了する必要があります。

これで、移行の基礎が完成しました。 このシリーズの次の記事では、実際の移行プロセスを開始します。