WordPress環境をECS＋RDSの環境に変更を試みたので備忘その１（ECSで環境が起動するまで）

2023年6月20日

EC2 on Dockerの環境から変えようと思い立つ

3月にAmazon Linux2023に環境を変更し２ヶ月が経とうとしております。

Amazon Linux 2023に環境入替を行う

Amazon Linux2023自体が大きく問題ということではなさそうですが、移行後に断続的にトラブルが起きていました。
5から10分程度の時間ですが、不定期にサイトに接続ができなくなっているようで通知などで気がついて環境を確認しようと思うとすでに復帰してしていたりという感じしたが証跡や通知メッセージを見る限りではこれと言って突然高アクセスが発生したり不明な通信があったりはないらしく、Amazon Linux2から機能や処理を増やしたりはしておらずDockerの稼働自体でなんらかのI/O待ちでボトルネックが発生しているような気がします。
もう少しいろいろと仕込んで当たればわかるんでしょうか、結局のところ切り分け切れていないです。
致命的にCPUが張り付き続けたりコンテナ自体が落ちたりとか、OSがダンマリになってオートスケールでのリカバリが発生するでもない生○しな状態でした。

そもコンテナはステートレスなものに限った方が良い

と言うことで悶々と答え探しをするよりは根本から改善してしまった方が早いじゃないかと言う結論に達しました。
元々、Dockerコンテナの環境にステートフルなデータストアの機能を担わせるのは考えものです。
これまでもDBコンテナでやらかしたのは一度や二度じゃないわけで抽象化されている分ハマるとリカバリに手こずるという具合です。
DBデータ自体は永続領域に持たせていても、オープンできくなったら意味がないです。
実際、過去にご紹介のコンテナ環境ではデータ層はRDSでステーフルな構成にしていたのでサボらずに基本に忠実に従った方がいざと言うときに無難なわけです。
今回はコンテナを稼働させるのにマネージドサービスを使えばクラウドで仮想マシンを使う必要もないでいっそサーバレスにしてOS層の面倒を見なくて済むようにしてみようかなとも思います。
と言うことで、下図のような構成にあらためることにしました。

構成としてはこんな感じ

• コンテナ　Amazon ECSをFargate構成にしてコンテナ実行環境は意識しない作りに改める
• DBをRDSに改めてデータの保全、トラブル時の復帰の利便性を高める
• とりあえずコスト重視でRDSはマルチAZ構成にはせず、何かあればバックアップから復元して対応
• 今まで通りデータ永続領域はESFで行う
• EC2 on Dockernの既存環境からの切り替えはRoute 53のAレコード変更だけで行う。
• CloudWatch、WAF、S3は継続して利用

環境移行の準備

EC2 on Docke環境のバックアップ

まずは現行環境の移行データ退避から始めます。
現在の環境はWordpressコンテナとMySQLコンテナをdocker-composeで制御しています。
EFSに永続領域を設けていますが今回、VPCから新設しようと思うのでEFSも新しいVPCに新たに作成するので必要なデータをtarで固めてS3に退避します。
MySQLはコンテナに入り、mysqldumpを出力して永続領域側からS3に退避します。

 $ docker-compose exec 【コンテナ名】 /bin/bash
 # cd /var/lib/mysql
# mysqldump -u 【ユーザ名】 -p -x 【DB名】 > 【出力ファイル】Code language:
PHP
(php)

VPCの作成

今回はパブリックサブネットを二つ、プライベートサブネットを二つの構成とします。
ALB、EFS、RDS接続用SGを用意しますが、そもそもマネコンからVPCを作成するのが久しぶりで随分画面が変わっていて新鮮でした。というか、プレビューが大変わかりやすいです。

CIDRや名前などは左のVPCの変更で設定してきますが今回目的の構成はデフォルトで作成されます。
パブリックサブネットを前提とするとインターネットゲートウェイが、プライベートサブネットを前提にするとS3のVPCエンドポイントが自動で用意されるようになってるようです。

RDSの作成

前回はPostgreSQLでしたが今回はMySQLを使います。

AWS WorkSpaces で急造テレワーク環境！ 続き２(owncloud導入編)

DBサブネットグループの作成

RDSはプライベートサブネットに配置します。それ用にサブネットグループを作成。

項目	設定
名前	【任意の名前】※1
説明	任意で入力、省略可能
VPC	作成したVPCを選択
アベイラビリティゾーン（AZ）	ap-southeast-1a,ap-southeast-1c
サブネット	上記AZに作成したプライベートサブネットを選択

RDSを作成

続いてRDSを作成します。
今回は無料枠が利用したいのでAuroraではなくRDS for MySQLで作成します。
コスト優先でトラブル時はスナップショットから戻すことを前提にシングルAZ構成とします。
以下設定したらデータベースの作成を押下する。

項目	設定
データベース作成方法	標準作成
エンジンのオプション	MySQL
エディション	MySQL Community
エンジンバージョン	MySQL 8.0.32 ※1
テンプレート	無料利用枠
DBインスタンス識別子	【任意の名前】※2
AWS Secrets Manager で マスター認証情報を管理する	チェックしない
マスターパスワード	任意、もしくは自動生成にチェック （自分は移行元DBと同様にしました）
Amazon RDS Optimized Writes	チェックしない
インスタンスタイプ	db.t4g.micro
ストレージタイプ	汎用 gp3
ストレージ割り当て	20GiB
ストレージの自動スケーリングを有効にする	チェックする
最大ストレージしきい値	1000GiB
コンピューティングリソース	EC2 コンピューティングリソースに接続しない
ネットワークタイプ	IPv4
Virtual Private Cloud (VPC)	作成したVPCを選択
DB サブネットグループ	作成したDBサブネットグループ
パブリックアクセス	なし
VPC セキュリティグループ (ファイアウォール)	既存の選択
既存の VPC セキュリティグループ	作成しRDS用セキュリティグループ
アベイラビリティーゾーン	ap-southeast-1a
RDS Proxy を作成	チェックしない
認証機関 - 任意	デフォルト
データベース認証	パスワード認証
拡張モニタリングの有効化	チェックを入れる
詳細度	60秒
モニタリングロール	デフォルト
追加設定
最初のデータベース名	移行元DBと同じ名前
DB パラメータグループ	default.mysql8.0
オプショングループ	default:mysql-8-0
自動バックアップを有効にします	チェックを入れる
バックアップ保存期間	コスト優先でとりあえず１日に設定
バックアップウィンド	ウィンドの選択
開始時間　期間	16:00(UTC) 0.5時間　※3
バックアップのレプリケーション	チェックしない
暗号化を有効	チェックを入れる
AWS KMS キー	デフォルト
ログのエクスポート	全てチェックを入れる
マイナーバージョン自動アップグレードの有効化	チェックを入れる
メンテナンスウィンド	設定なし
削除保護の有効化	チェックを入れない （一連の確認ができたら有効化）

ESFの作成

EFSの作成を選択後、ファイルの作成のウィンドが表示されたらカスタマイズをクリックします。

以下のように設定し、最後の確認画面で内容を確認後に「作成」をクリックします。

全般
名前-オプション	【任意の名前】英数字またはハイフン
ストレージクラス	標準
自動バックアップを有効化	チェックを付ける
IAへ移行	最後のアクセスから30日
IAから移行	初回アクセス時
保管時のデータの暗号化を有効にする	チェックを付ける
パフォーマンス設定
スループットモード	バースト
ネットワーク
Virtual Privater Cloud(VPC)	作成したVPCを選択
マウントターゲット
アベイラリティゾーン	ap-northeast-1a、ap-northeast-1c
サブネットID	作成したプライベートサブネットを選択
IPアドレス	自動
セキュリティグループ	作成したEFS用セキュリティグループを選択
ファイルシステムポリシー - オプション	何もせずに「次へ」をクリック

以下のように作成されます。ファイルシステムID、「fs-xxxxxx」は後のECSの設定で必要になります。

名前もしくはファイルシステムIDのリンクをクリックすると詳細が確認できます。

ECSの作成

Amazon Elastic Container Service(ECS)の設定をしていきます。過去、EKSで痛い目（お金的な意味で）をみてトラウマで避けてきましたが、今回はECSでしかもFargate利用。事前にcalculatorで金額シュミレーションして安全圏なのは確認済です。ECSの作成は以下のように進めます。

1. クラスタ定義：ざっくりとコンテナ環境の大枠の定義
2. タスク定義：コンテナの利用リソース、利用イメージなどの定義。今までのdocker-compose.ymlに相当
3. サービス定義：起動環境（EC2 or Fargate）の設定、コンテナの実行数、Auto Scalingの設定、ELBとの関連付定義など

クラスタ定義

ECSのサービス画面からクラスターの作成を選択します。

以下の設定を行い「作成」をクリックしてクラスタ定義を作成します。

クラスタ名	【任意のクラスタ名】※1
ネットワーキング
VPC	作成したVPCを選択
サブネット	作成したパブリックサブネットを選択 （ap-northeast-1a,ap-northeast-1cのパブリックサブネット二つ）
デフォルトの名前空間 - オプション	何もしない
インフラストラクチャ	何もしない （グレーアウトで AWS Fargate(サーバレス)が選択された状態）

タスク定義

クラスタ作成後、タスク定義の画面に移動し「新しいタスク定義の作成」をクリックします。

以下を設定し、設定確認画面まで進んだら「作成」をクリックしてタスク定義を作成します。
今回は今までの環境同様、docker hubのイメージを利用することを前提にします。

タスク定義ファミリー	任意のファミリー名※1
コンテナ - 1
コンテナの詳細
名前	任意の名前
イメージURI	wordpress:latest
プライベートレジストリ	有効化しない
ポートマッピング
コンテナポート	80
プロトコル	TCP
ポート名	【自動で生成されたものを利用】
アプリケーションプロトコル	HTTP
環境変数 - オプション
環境変数を追加	コンテナ環境変数を参照
環境、ストレージ、モニタリング、タグの設定
環境
アプリケーションの環境	AWS Fargate(サーバレス)
オペレーションシステム/アーキテクチャ	Linux/ARM64※2
タスクサイズ
CPU	1vCPU
メモリ	3GB
タスクロール	-
タスク実行ロール	ecsTaskExecutionRole
ネットワークモード	awsvpc
ストレージ-オプション
エフィメラルストレージ
量	21 GiB
Volumes
ボリュームの追加	クリックする
ボリュームタイプ	EFS
ストレージ設定
ボリューム名	作成したEFSの名前を設定
ファイルシステムID	作成したEFSのファイルシステムIDを設定
ルートディレクトリ	/
アクセスポイント ID	-
コンテナマウントポイント
コンテナ	コンテナの詳細の名前で定義したコンテナ名を選択
ソースボリューム	ストレージ設定のボリューム名を選択
コンテナパス	/var/www/html
読み取り専用	いいえ
モニタリングとログ記録
ログ収集の使用	チェックを付ける

コンテナ環境変数

WORDPRESS_DB_USER以降の値は　https://api.wordpress.org/secret-key/1.1/salt/　こちらで生成したセキュリティキーの値を設定します。
コンテナが自動的に増減した時に、キーがリセットされてユーザが再ログインを求められないようにするための措置です。
URLをクリックすると、以下のような形式で表示されます。
【表示例】

define('AUTH_KEY',         '<|b9]fh#f-&b+q|o!8.L4KAd&d}.g^n;z8ct8}7Yi+Tqe+K&Q>/G(QD.Nywa[{zc');Code language:
JavaScript
(javascript)

上記の表示の場合、環境変数は以下のように入力をします。注意点としては' '(シングルコート)で囲むことです。

'<|b9]fh#f-&b+q|o!8.L4KAd&d}.g^n;z8ct8}7Yi+Tqe+K&Q>/G(QD.Nywa[{zc'Code language:
HTML, XML
(xml)

キー	タイプ	値
WORDPRESS_DB_HOST	value	作成したRDSのエンドポイントを記載
WORDPRESS_DB_NAME	value	作成したRDSのEB名を記載
WORDPRESS_DB_PASSWORD	value	RDSで設定したパスワードを記載
WORDPRESS_DB_USER	value	RDSで設定したユーザ名を記載
WORDPRESS_AUTH_KEY	value	生成したキーを記載
WORDPRESS_AUTH_SALT	value	生成したキーを記載
WORDPRESS_LOGGED_IN_KEY	value	生成したキーを記載
WORDPRESS_LOGGED_IN_SALT	value	生成したキーを記載
WORDPRESS_NONCE_KEY	value	生成したキーを記載
WORDPRESS_NONCE_SALT	value	生成したキーを記載
WORDPRESS_SECURE_AUTH_KEY	value	生成したキーを記載
WORDPRESS_SECURE_AUTH_SALT	value	生成したキーを記載

サービス定義

作成したクラスターからービスタグを選択し、「作成をクリック」します。

以下を設定し「作成」をクリックします。

環境
既存のクラスター	作成したクラスター
コンピューティング設定（(アドバンスト)）	起動タイプ
起動タイプ	FARGATE
プラットフォームのバージョン	LATEST
デプロイ設定	タスク
タスク定義
リビジョンの手動指定	チェックを入れる
ファミリー	作成したタスク定義を選択
リビジョン	1 ※1
サービス名	任意の名前
サービスタイプ	レプリカ
必要なタスク	0 ※2
ネットーワーキング
VPC	作成したVPC
サブネット	パブリックサブネットを選択 (ap-northeast-1a、ap-northeast-1c)
セキュリティグループ	既存のセキュリティグループを選択
セキュリティグループ名	作成したセキュリティグループ全てを適用
パブリックIP	オフになっています
ロードバランシング - オプション
ロードバランサーの種類	Application Load Balancer
Application Load Balancer	新しいロードバランサの作成
ロードバランサー名	任意の名前
ロードバランス用のコンテナの選択	【コンテナ名】80:80
リスナー
新しいリスナーを作成	チェックを付ける
ポート	80
プロトコル	HTTP
ターゲットグループ
新しいターゲットグループの作成	チェックを付ける
ターゲットグループ名	任意の名前
プロトコル	HTTP
ヘルスチェックパス	/
プロトコル	HTTP
ヘルスチェックの猶予期間	0 ※3
サービスの Auto Scaling - オプション	後で設定するためここでは設定しない

コンテナ起動前にALBの追加設定

サービスを作成しても必要なタスクを0にしてあるためコンテナは起動しない状態です。
起動前にALBのターゲットグループのSuccess codesを追加します。
EC2サービスの画面に移動し、ターゲットグループを選択しHealth checksタブを選択後、Editをクリックします。

Advanced health check settingsのSuccess codesに「,301-302」を追加します。
コンテナの初期起動が完了したら後ほど302は削除します。

コンテナの起動と確認

準備が完了したらECSサービスの画面に移動しクラスターから作成したクラスタを選択します。
サービスタブを選択し、作成したサービスをチェックしたら「更新」をクリックします。
デプロイ設定の必要なタスクに1を入れて更新をクリックします。

更新後、サービスをクリックし正常性とメトリクスのステータスを確認します。
正常であれば、タスクが保留後、画面のように「1件が実行中」となります。
またALBのターゲットも「1件が正常」となります。
起動が正常に行われない場合、セキュティグループの設定と必要なリソース適用されいるかなどを確認してください。問題が出る場合は概ね適切なリソースと通信ができないパターンが多いです。

EC2サービス画面のターゲットグループでコンテナがターゲットとして登録されたことを確認します。

ALBのAレコード情報を確認します。
セキュティグループで一時的に80の接続を許可し、ブラウザから確認したAレコードで接続を確認します。

WordPressの初期設定画面が表示されれば成功です。
一旦、ECSのコンテナ環境としては起動が成功となります。

この後の設定

今回はコンテナ環境として正常に起動までの確認ですが、確認後は以下を実施が必要になります。
これらの備忘は次回に紹介します。

1. 作業端末としてAWS Cloud9作成
2. RDSへの dumpデータインポート
3. EFS領域への既存環境データの移行
4. 既存ALBの設定を新ALBに追加
5. 新ALBにWAF適用
6. ECSのAuto Scaling設定
7. Route53のレコード修正を行いECS環境に切り替え