EC2インスタンス間での環境移行で気になったところ

投稿日: 更新日:

はじめに

本ウェブサイトはAWSのEC2を使ってるが、利用してたEC2インスタンスのOS(Amazon Linux 1)がサポート終了するのに伴い、新しいEC2インスタンスに移行した。
今回はその時に気になった事項を備忘録がてら記載する。

やること

大きく分けて、次の作業が必要と考えた。

  • 移行先EC2インスタンスの用意
  • webサーバー設定(nginx)移行
  • CMS環境(Movable Type 7)移行
    • CMSのDB
    • CMS本体ファイルの内、本サイト向けにカスタマイズしたファイル(プラグインとか)
  • SSL移行
    • SSL証明書
    • Let's Encrypt環境
  • Googleアナリティクス移行
  • ElasticIP移行
  • DNS設定更新

難なくやれたところ

webサーバー設定(nginx)移行

SSL証明書のパスを一時的に書き換える以外は、設定の記載内容をそのまま移行できた。

CMS環境(Movable Type 7)移行

CMSのDB、移行するファイルとも移行元から取ってきたものをそのまま適用できた。
特に作業にあたっての一時的な変更は不要だった。

Googleアナリティクス移行

本件の場合、GAのトラッキング処理周りはドメインとSSL周りしか見てないと思われた。更にトラッキングするドメインは変わらない。

DNS移行

本件の場合、DNS設定はAWSのRoute53を使ってる。Aレコード(ドメイン文字列とIPの紐付け)の更新が必要か、と思われたが、そもそも移行元EC2インスタンスに紐づけてるElasticIPを移行先EC2インスタンスに付け替えれば、Aレコードの設定すら必要無い。

移行先EC2インスタンスの用意

移行元/移行先のEC2インスタンスとも、Six Apart が公開してるAMIを利用してるので、殆ど労する事無くインフラの用意ができる。

https://www.sixapart.jp/movabletype/aws/

なお、VPCとセキュリティーグループは共通のものを使用した。

ElasticIP移行前の表示確認

以降に必要な諸々の事前作業が終わりさあElasticIP移行するぞ、という前に、移行先EC2インスタンスに自動付与されるパブリックIPアドレスを使って、CMS管理画面および表側サイトの表示を試みたが、確認作業用の一時的な追加設定は不要だった。

気になったところ

ElasticIP移行

この作業自体はAWSのマネジメントコンソールから簡単にできる。
しかし、この後で移行先SSHのログインを試みたところ、証明書周りのセキュリティに問題あると怒られて接続できなかった。
※この時自身が使ってるのはMacOS Xのターミナル。

具体的には次の様な感じのエラーが出た。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for [対象ホスト名] has changed,
and the key for the corresponding IP address [対象ホスト名と紐づくグローバルIP]
has a different value. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /Users/xxx/.ssh/known_hosts:xxx
(以降略)

後述の参考にした記事より、
どうも上記引用のファイル「known_hosts」に過去のSSH接続時に使ったホスト名とホスト鍵の組み合わせが記録されており、試行したSSH接続で使ってる組み合わせと記録された組み合わせが異なる場合に、問題あると判断してるとのこと。

対応として、known_hostsに記録された組み合わせの情報を削除すれば良い。削除は次のシェルコマンドで可能。

ssh-keygen -R [対象ホスト名]
参考

SSH接続で『WARNING: POSSIBLE DNS SPOOFING DETECTED!』が出る理由と解決方法 - ケイのゲーム&ガジェット部屋
https://www.radical-dreamer.com/programming/ssh-warning/

SSL移行

移行元インスタンスではSSL運用をLet's Encryptでやっていたので、少し回りくどい手順を行わないといけない。具体的には次の手順を行った。

  1. 移行元で利用中のSSL証明書を応急的な証明書として移行
  2. webサーバーのSSL証明書のパス設定を前述の応急的な証明書のパスに変更
  3. 移行先EC2インスタンスへのLet's Encrypt環境のインストール
  4. Let's EncryptによるSSL証明書の再生成および再生成した証明書の適用

上述の内、気になった次についてのみ詳細を記載する。

1.移行元で利用中のSSL証明書を応急的な証明書として移行

作業内容として見出し文言のままだが、Let's Encryptの仕様を少し踏まえる必要がある。
Let's Encryptでは、次の配下に証明書が存在する。

/etc/letsencrypt/live/[ホスト名]

中身を見ると、次の様に証明書のファイルが存在してる。

lrwxrwxrwx 1 root root   37 Feb  9 00:54 cert.pem -> ../../archive/[ホスト名]/cert21.pem
lrwxrwxrwx 1 root root   38 Feb  9 00:54 chain.pem -> ../../archive/[ホスト名]/chain21.pem
lrwxrwxrwx 1 root root   42 Feb  9 00:54 fullchain.pem -> ../../archive/[ホスト名]/fullchain21.pem
lrwxrwxrwx 1 root root   40 Feb  9 00:54 privkey.pem -> ../../archive/[ホスト名]/privkey21.pem

上述引用のとおり、このパスでの証明書ファイルはシンボリックリンクになっており、ファイルの実体は別のパス、つまり次のパスに存在する。なのでここから移行する証明書を取ってくれば良い。

/etc/letsencrypt/archive/[ホスト名]

最後に

論理マシン間でのウェブサイト移行作業としては、CMS周りさえ理解していれば技術難易度は相対的に高くないと見受ける。
ただ作業量としては手順を書いとかないと抜けが出そう。

関連するタグ

AWS, Let's Encrypt, Movable Type 7