はじめに
Willow Commons は、Web サイトを新しいサーバーアドレスに移転しようとしています。コミュニティは引き続き site.community.test を使う必要があり、移行中も元の場所を利用できなければなりません。両バックエンドには、それぞれ正規のイベント案内がすでにあります。作業の目的はコンテンツの公開ではなく、DNS の移行です。
まず クライアントが使用するアドレスを確認する を完了してください。この独立した環境は、正式な名前が古いアドレスを指す状態から再び始まり、権威サーバー、別々のキャッシュリゾルバー、稼働する新旧 HTTP サービスが用意されています。前の VM は再利用しません。TTL を準備し、アドレスを変更して、実際のクライアントと完全な内容を確認します。読む時間と一般的なミスへの対応を含め、約 50 分を見込んでください。これは作者による目安です。
これは制御されたローカル DNS 演習です。世界中への反映、無停止、公開レジストラの移転を保証するものではなく、古いサーバーをすぐ削除してよいという意味でもありません。
移行の時間枠を準備する
このステップでは、正式なレコードの TTL を短くする前に、通常のサービスと新しいバックエンドを確認します。Community Preview を開き、Warm Client を選択して、old location ラベルのある既存の Willow Commons ページを読んでください。アドレスを変更するまでは Fresh Client を使わないでください。その独立したリゾルバーは、このサイトをまだ検索していません。
Warm Client に切り替えます。コマンドと curl オプションは最初のユニットと同じです。まず既存のサービスを名前で要求します。
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Service location: old の完全なイベント案内が返るはずです。次に、同じパスとポートを使い、新しいバックエンドをアドレスで確認します。
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
同じ 3 つの集まりと入口情報が、Service location: new とともに返るはずです。この直接の準備確認は、意図的に DNS を迂回します。名前を使うクライアントが移転した証拠ではありません。両方の Web サイトは変更しないでください。
Warm Client の現在のコピーを検索します。
dig @127.0.0.1 site.community.test A +noall +answer
古いアドレスと、120 以下の TTL が返るはずです。準備時にキャッシュされたコピーが読んでいる間に切れた場合、この実際の検索で、まだ有効な旧レコードの別のコピーを取得します。ラボを開いてから数える制限時間はありません。
/home/labex/project/site-move にある DNS Desk に切り替え、レコードファイルと用意されたバックエンド計画を読みます。
cat backends.tsv
cat community.zone
移行で変更できるのは site の A アドレス、TTL、必要な SOA シリアル番号だけです。practice は任意の繰り返し観察用です。keep、ネームサーバー、すべての Web サイトのバイト列を維持してください。準備された旧レコードには、実際の 120 秒の TTL があります。この演習は意図的に秒単位を使っており、本番環境で 1 日保持されるキャッシュが 2 分で消えるという主張ではありません。
アドレスを変更する前に、正式なレコードの TTL だけを下げます。次の完全なリテラルのヒアドキュメントは、最初のユニットで学んだファイル書き込み構文を使います。
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
loaded serial 2 と OK が表示されるはずです。再読み込みする前に、構文の問題をすべて直してください。
sudo /opt/labex/site-move/reload-zone
保存ファイルだけでなく、実行中の権威サーバーを確認します。
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
45 IN A 10.94.0.10 が返るはずです。権威データはまだ古いバックエンドを指しています。Warm Client に切り替えます。
dig @127.0.0.1 site.community.test A +noall +answer
古いキャッシュのコピーは、以前の残り寿命を保持します。残り TTL が 40 秒でも、新しい 45 秒の方針を取得した証拠だと思わないでください。元の 120 秒のコピーも、残りが 40 秒になることがあります。
観察した古いコピーの期限が切れるのを待ち、再度検索します。最後に表示された残り秒数に 1 秒を加えて待ってもかまいません。次の完全で余裕のあるコマンドは、元の最大 120 秒をカバーします。
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
古いアドレスと、新しく取得した 45 秒前後の TTL が返るはずです。最後の DNS リクエストが重要です。期限切れは古いコピーを取り除きますが、それだけで代わりのコピーを取得しません。ネイティブの DNS 交換には、短くなった寿命を持つ旧アドレスの回答が記録されます。チェックは、自分で探査を行う前に既存の交換を読み、この準備を代わりに実行しません。
回答がない、または別のアドレスが返る場合は、先に権威サーバーとクライアントの正確な出力を読み直してください。DNS Desk でファイルの誤りを直し、検証と再読み込みを行ってから、Warm Client で名前の検索を再試行します。リゾルバーを再起動したり消去したりしないでください。短い寿命の旧アドレスを実際に取得してから、この段階のチェックを実行してください。
アドレスを変更して 2 つのクライアントを比較する
このステップでは、正式な名前を移転し、独立したクライアントを比較します。短い操作列を始める前に、このステップを読んでください。次の warm 検索で、残りの比較時間が分かります。キャッシュヒットでは TTL は再スタートしません。自然な期限切れの後で取得した新しいコピーだけが、環境準備とは無関係に、新たな 45 秒の寿命を開始します。編集が遅いと見える差を逃すこともありますが、移転自体は有効です。下の独立した練習用名による復旧方法で、観察を繰り返せます。
Warm Client で現在の状態を確認し直します。
dig @127.0.0.1 site.community.test A +noall +answer
残り TTL がほとんどない場合は、権威サーバーがまだ旧アドレスを返す間に期限切れを待ち、編集前に再度検索します。次に DNS Desk に切り替えます。正式な A アドレスを変更し、45 秒の TTL は保ったまま、シリアル番号を増やします。
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
実行中の権威サーバーは、今度は 45 IN A 10.94.0.20 を返す必要があります。まだ旧アドレスを返す場合、保存ファイルと読み込まれたデータが一致していません。クライアントキャッシュを解釈する前に、構文と再読み込み結果を確認します。
Warm Client に切り替えます。
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
キャッシュの残り寿命の間は、旧アドレスを使って Service location: old を返すことがあります。これは正常です。独自のリゾルバーを持ち、/home/labex/project/site-move/fresh で開始する Fresh Client に切り替えます。
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
新アドレスと、完全な Service location: new のイベント案内が返るはずです。DNS 移行中は、2 つのクライアントが同じ名前を使いながら、異なる有効なバックエンドに到達することがあります。これらは 1 台の VM 内の独立した Linux クライアント名前空間とキャッシュプロセスであり、2 台の物理機器や独立 VM ではありません。
両方がすでに new の場合： 比較する前に warm のコピーが自然に切れました。正式な移転を続けてください。合格にスクリーンショットや過去の重複期間は必要ありません。移転を取り消さずに現象を繰り返すには、最初のユニットのように practice.community.test を使います。DNS Desk では site を新アドレスのまま保ち、practice だけを旧アドレスと 120 秒に設定し、nano community.zone で現在のシリアルを増やします（Ctrl+O、Enter、Ctrl+X）。検証して再読み込みします。Warm Client で現在の練習用コピーが切れるのを待ち、practice を検索して新しい観察時間を始めます。practice だけを新アドレスと 45 秒に変更し、さらに大きなシリアルで検証と再読み込みを行い、両クライアントから practice を比較します。この間、正式な site レコードは移転済みのままです。練習観察は自然な期限切れで終え、キャッシュの消去やサイト内容の置き換えは絶対に行わないでください。
TTL の準備を終える前に正式アドレスを変更した場合は、学んだレコード編集手順で、site だけを旧アドレスと 45 秒に戻し、より大きいシリアルで検証と再読み込みを行います。Warm Client の現在の応答が切れるのを待ち、短い TTL の旧アドレスを要求してから、さらに大きいシリアルで再度切り替えます。元の両バックエンドは利用可能なので、この限定的な DNS ロールバックで、サービスのリセットや作業の削除をせずに順序を修正できます。最終目標は新しい正式アドレスのままです。実行中の権威サーバーが変わったことを確認してから、この段階のチェックを行います。
DNS を介した新しい接続先を確認する
このステップでは、管理下のクライアントが新しい内容に到達でき、旧サービスも利用できることを証明します。まず Warm Client を使います。許可された方針では、移行時の元のコピーは最大 60 秒保持されます（例の手順は 45 秒です）。残り TTL を確認します。
dig @127.0.0.1 site.community.test A +noall +answer
まだ旧アドレスが表示される場合は、残り秒数に 1 秒を足して待ち、再度検索します。次の完全で余裕のある待機は、許可された短い TTL の最大値をカバーします。
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
10.94.0.20 が返り、例の方針では残り TTL が 45 以下になるはずです。アドレスが正しいだけでは不十分です。この名前でホームページを要求し、完全なイベント案内を保存します。
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
実際の new location のホームページと、3 つの集まりおよび入口情報をすべて含む Service location: new の案内が返るはずです。DNS は正しいのに内容が違う場合は、実際のバックエンドのパスとアドレスを調べてください。古い Web サイトを編集して新しいものに見せる操作は、許可範囲外です。
Fresh Client に切り替え、同じ完全なリソースを独立して保存します。
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
同じ新しい場所の内容が返るはずです。Community Preview に切り替え、必要ならブラウザーの Back で選択ページに戻り、各クライアントを選んで実際のページを更新します。今度は両方とも new location を表示します。各表示で Download the programme を使い、完全なテキストを開いてください。このブラウザーリクエストは、ブラウザーのコンピューターの DNS とは独立して、選択したコース用クライアントを使います。
上部付近の new location ラベルと、3 つの集まりの下にある元のイベント案内リンクを確認してください。各クライアントで、この実際の新バックエンドのページが表示されるはずです。
Warm Client に戻り、保全要件を確認します。旧バックエンドを直接要求します。
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
元の旧場所のイベント案内が返るはずです。権威サーバーで、無関係な名前を検索します。
dig @10.94.0.2 keep.community.test A +noall +answer
未変更の 120 IN A 10.94.0.10 が返るはずです。旧サービスは引き続き、この移行契約の一部です。2 つのクライアントが移転したからといって停止しないでください。この観察では、実世界のすべてのクライアントが更新されたとは言えません。
保存ファイルに以前の場所の内容がある場合は、そのクライアントの実際の DNS 検索が変わってから、正しいクライアントタブで同じダウンロードコマンドを繰り返します。パスが誤っていたら、pwd と cd /home/labex/project/site-move/warm、または対応する fresh ディレクトリで復旧します。最終チェックは、自分のリクエストより先に既存の DNS と再読み込みの証拠を読みます。繰り返し採点してもキャッシュを消去せず、権威サーバーも再読み込みしません。通常の読み取りではネイティブログが追記されることがあります。
まとめ
新バックエンドを確認し、権威データが旧アドレスを保持する間に TTL を下げ、実際のクライアントにその方針を取得させました。その後アドレスを変更し、独立したクライアントを比較して、自然な期限切れ後に新サイトの完全な内容を確認しました。元の名前、旧バックエンド、無関係なレコードは利用できるままです。これは管理下のクライアントの観察であり、世界中への DNS 反映の保証ではありません。
