レガシSUSE Multi-Linux Managerサーバからコンテナへの移行
レガシSUSE Multi-Linux Managerサーバをコンテナに移行するには、新しいマシンが必要です。
この移行のコンテキストでは、レガシSUSE Multi-Linux Managerサーバ(RPMインストール)は_古いサーバ_とも呼ばれます。
2. GPGキー
-
自己信頼GPGキーは移行されません。
-
RPMデータベースで信頼されているGPGキーのみが移行されます。したがって、
spacewalk-repo-syncでチャンネルを同期すると失敗する可能性があります。 -
管理者は、実際のサーバ移行後にこれらのキーをレガシSUSE Multi-Linux Managerインストールからコンテナホストに手動で移行する必要があります。
-
レガシUyuniサーバから新しいサーバのコンテナホストにキーをコピーします。
-
その後、コマンド
mgradm gpg add <PATH_TO_KEY_FILE>を使用して、移行したサーバに各キーを追加します。
2.1. レガシサーバでの初期準備
移行には、複製が必要なデータの量によって、非常に長い時間がかかることがあります。ダウンタイムを短縮するには、レガシサーバ上のすべてのサービスを稼働させたまま、初期複製、再複製、_最終複製と切り替え_のプロセスで移行を複数回実行することができます。
最終的な移行中にのみ、レガシサーバ上のプロセスを停止する必要があります。
最終複製以外のすべてに対して、パラメータ--prepareを追加し、レガシサーバ上のサービスが自動的に停止するのを防止します。例:
mgradm migrate podman <oldserver.fqdn> --prepare-
SUSE Multi-Linux Managerサービスを停止します。
spacewalk-service stop
-
PostgreSQLサービスを停止します。
systemctl stop postgresql
2.2. SSH接続の準備
-
新しい5.1サーバに
root用のSSHキーが存在することを確認します。キーが存在しない場合は、次のコマンドで作成します。ssh-keygen -t rsa
-
レガシサーバへの接続にパスワードを要求しないように、新しいサーバホストでSSH設定とエージェントの準備ができている必要があります。
eval $(ssh-agent); ssh-add
パスワードを要求しない接続を確立するために、移行スクリプトは、新しいサーバで実行されているSSHエージェントに依存します。このエージェントがまだアクティブではない場合は、
eval $(ssh-agent)を実行して開始します。その後、ssh-addに機密鍵のパスを指定して、実行中のエージェントにSSHキーを追加します。このプロセス中に、機密鍵のパスワードの入力を求められます。 -
ssh-copy-idを使用して、SSH公開鍵をレガシSUSE Multi-Linux Managerサーバ(<oldserver.fqdn>)にコピーします。<oldserver.fqdn>は、レガシサーバのFQDNに置き換えてください。ssh-copy-id <oldserver.fqdn>
SSHキーは、レガシサーバの
~/.ssh/authorized_keysファイルにコピーされます。 詳細については、ssh-copy-idのマニュアルページを参照してください。 -
新しいサーバからレガシSUSE Multi-Linux ManagerサーバへのSSH接続を確立し、パスワードが不要であることを確認します。また、ホストの指紋に問題があってはなりません。問題がある場合は、
~/.ssh/known_hostsファイルから古い指紋を削除してから、再試行してください。指紋はローカル~/.ssh/known_hostsファイルに保存されます。
2.3. 移行の実行
レガシSUSE Multi-Linux Managerからコンテナ化されたSUSE Multi-Linux Managerへの移行を計画する際は、ターゲットのインスタンスがレガシ設定の仕様を満たしているか、上回っていることを確認します。これには、メモリ(RAM)、CPUコア、ストレージ、ネットワーク帯域幅などが含まれますが、これらに限定されません。
|
セキュリティ強化されたSUSE Multi-Linux Managerサーバホストでは、 例: SUSE Multi-Linux Managerの更新では、この回避策が不要になるようにツールが変更されます。 |
2.3.1. カスタム永続ストレージの設定
永続ストレージの設定はオプションですが、コンテナのディスクがいっぱいになった状態での深刻な問題を回避する唯一の方法です。mgr-storage-serverツールを使用してカスタム永続ストレージを設定することを強くお勧めします。
詳細については、mgr-storage-server --helpを参照してください。このツールを使用すると、コンテナストレージとデータベースボリュームの作成が容易になります。
このコマンドは次のように使用します。
mgr-storage-server <storage-disk-device> [<database-disk-device>]|
デバイスにはファイルシステムが存在してはなりません。ファイルシステムがストレージデバイスに存在する場合、コマンドは中止されます。 |
例:
mgr-storage-server /dev/nvme1n1 /dev/nvme2n1|
このコマンドは、 詳細については、以下を参照してください。 |
2.3.2. 移行の実行
-
次のコマンドを実行して、新しいSUSE Multi-Linux Managerサーバをインストールします。
<oldserver.fqdn>は、レガシサーバのFQDN に置き換えます。mgradm migrate podman <oldserver.fqdn>
-
信頼されているSSL CA証明書を移行します。
2.3.3. 証明書の移行
RPMの一部としてインストールされ、レガシSUSE Multi-Linux Managerの/usr/share/pki/trust/anchors/ディレクトリに保存されている信頼済みSSL CA証明書は移行されません。SUSEはRPMパッケージをコンテナ内にインストールしないため、管理者はこれらの証明書ファイルを移行後にレガシインストールから手動で移行する必要があります。
-
ファイルをレガシサーバから新しいサーバにコピーします。 たとえば、
/local/ca.fileです。 -
次のコマンドを使用してファイルをコンテナにコピーします。
mgrctl cp /local/ca.file server:/etc/pki/trust/anchors/
2.3.4. 移行を完了する
|
新しい5.1サーバにリダイレクトするには、新しいサーバの名前をインフラストラクチャレベル(DHCPおよびDNS)で変更して、レガシサーバと同じFQDNとIPアドレスを使用する必要があります。 |
|
移行中に問題が発生した場合は、古いシステムを再起動できます。rootとして、以下のコマンドを実行してPostgreSQLとspacewalkサービスを再起動してください。 |
3. Kubernetesの準備
特に移行ジョブはコンテナを最初から開始することを考慮して、mgradm migrateコマンドを使用して移行を実行する前に、永続ボリュームを事前定義する必要があります。
詳細については、永続コンテナボリュームにあるこれらのボリュームの準備に関するインストールセクションを参照してください。
4. 移行
次のコマンドを実行して、新しいSUSE Multi-Linux Managerサーバをインストールします。<oldserver.fqdn>はレガシサーバの適切なFQDNに置き換えます。
mgradm migrate podman <oldserver.fqdn>
または
mgradm migrate kubernetes <oldserver.fqdn>
|
|