見出し画像

AWS ECSでWordPressを立ち上げる

Fargate ECSでWordPressを立ち上げてみる

今回の内容は全面的にこちらのサイトに依存している

AWSはこんな構成

VPC:仮想ネットワーク
ELB:ロードバランサー
Fargate ECS:コンテナサービス
Aurora:リレーショナルデータベース
EFS:ファイルシステム

大まかな流れ

  1. VPC(仮想ネットワーク)を作成する

  2. セキュリティーグループを作成する

  3. データベースを作成する

  4. ファイルシステムを作成する

  5. WoedPressのコンテナを作成する

  6. 動作確認

VPC(仮想ネットワーク)を作成する

VPCについて多少詳しく説明しながら作成しているので、
疑問があれば、以下の記事も参考に

AWSコンソールにログインしてVPCダッシュボートへ飛び
[VPCを作成] を選択

作成するリソース:VPCなど
名前タグ:WordPress(任意の名前)
IPv4CIDRブロック:10.0.0.0/16

アベイラビリティゾーンの数:2
第一アベイラビリティゾーン:ap-northeast-1a
第二アベイラビリティゾーン:ap-northeast-1c
パブリックサブネットの数:2
プライベートサブネットの数:2
ap-northeast-1aのパブリックサブネットCIDERブロック:10.0.0..0/20
ap-northeast-1cのパブリックサブネットCIDERブロック:10.0.16.0/20
ap-northeast-1aのプライベートサブネットCIDERブロック:10.0.128.0/20
ap-northeast-1cのプライベートサブネットCIDERブロック:10.0.144.0/20

NAT ゲートウェイ:なし
VPCエンドポイント:S3ゲートウェイ

一通り入力して [VPCを作成] 
以下の感じで成功する

セキュリティーグループを作成する

セキュリティグループはデータの流れを制御するための設定情報だ
今回は図にある3種類のセキュリティグループを作成する

VPC ダッシュボードから [セキュリティグループ] を選択

[セキュリティグループを作成] を選択

ロードバランサー用のセキュリティグループを作成する

セキュリティグループ名:WordPress-LB-SG(任意)
説明:Security group for WordPress Loadbarancer(任意)
VPC:WordPress-vpc(さっき作ったVPC)

インバウンドルール
タイプ/プロトコル/ポート範囲/ソース
HTTTP/TCP/80/Anyware-IPv4(0.0.0.0/0)

HTTP用のTCP80ポートはすべてのアクセスを受け入れる

データベース用のセキュリティグループを作成する

セキュリティグループ名:WordPress-DB-SG(任意)
説明:Security group for WordPress Database(任意)
VPC:WordPress-vpc(さっき作ったVPC)

インバウンドルール
タイプ/プロトコル/ポート範囲/ソース
MySQL/Aurora/TCP/3306/カスタム(WordPress-LB-SG)

MySQL用のTCP3306ポートはWordPress-LB-SGセキュリティグループからの入力だけを受け入れる

ファイルシステム用のセキュリティグループを作成する

セキュリティグループ名:WordPress-FS-SG(任意)
説明:Security group for WordPress FileSystem(任意)
VPC:WordPress-vpc(さっき作ったVPC)

インバウンドルール
タイプ/プロトコル/ポート範囲/ソース
NFS/TCP/2049/カスタム(WordPress-LB-SG)

NFS用のTCP2049ポートはWordPress-LB-SGセキュリティグループからの入力だけを受け入れる

データベースを作成する(Aurora)

今回はMySQL互換のAurora Serverlessタイプを選択する
Aurora Serverlessは他のタイプより性能は落ちるがコストは安く負荷に合わせて自動的に性能をスケールするし障害対応も簡単という魅力的なタイプだ

Amazon RDSダッシュボードから [データベースの作成] を選択する

データベースの作成方法:標準作成
エンジンのタイプ:Aurora(MySQL Compatible)

[Serverless V2をサポートするバージョンを表示] を有効にすると、
利用可能なバージョンが自動的に選ばれるので、そのまま選択する
今回は、Aurora MySQL 3.02.0(compatible with MySQL 8.0.23)になった

テンプレート:開発/テスト

DBクラスター識別子:wordpress-database(任意)
マスターユーザー名:admin(任意)
マスターパスワード:xxxxxxx(適当に決めて忘れないようにしておく)

DBインスタンスクラス:サーバーレス(Serverless v2)
最小ACU:2(デフォルトまま)
最大ACU:16(デフォルトまま)

マルチAZ配置:Auroraレプリカを作成しない
(作成すると読み込み速度が向上するらしい)

コンピューティングリソース:
    EC2コンピューティングリソースに接続しない
ネットワークタイプ:IPv4
VPC:WordPress-vpc(最初に作ったやつ)

DBサブネットグループ:新しいDBサブネットグループの作成
パブリックアクセス:なし
VPCセキュリティグループ:WordPress-DB-SG(既存の選択)
アベイラビリティゾーン:ap-northeast-1a

データベース認証:パスワード認証

保持期間:7日(デフォルトまま)
AWS KMSキー:default(デフォルトまま)

追加設定を開く

最初のデータベース名:wordpress_database(任意)
DBクラスターのパラメータグループ:default.aurora-mysql8.0
DBパラメータグループ:default.aurora-mysql8.0
フェイルオーバー優先順位:指定なし

バックアップ:デフォルトのままで

バックトラック、ログのエクスポート、メンテナンス
デフォルトのままで

すべて入力終わったら [データベースの作成]

ファイルシステムを作成する(EFS)

EFSはEC2やECSのインスタンスの、好きなディレクトリにマウントできるファイルストレージだ
ECSのコンテナは停止するとデータが消えてしまうので、データを永続化する場合必要になる

AWSコンソールのElastic File Systemダッシュボードから
[ファイルシステムの作成] を選択する

名前:WordPress-FS
VPC:WordPress-vpc(最初に作ったVPC)
ストレージクラス:標準

全部入力したら [作成]

WordPressのコンテナを作成する(ECS)

もしクラスター、タスク、サービスがそれぞれどのようなものかピンとこなければこちらに用語の意味を簡単にまとめてある

クラスターの作成

AWSコンソールのAmazon Elastic Container Service(ECS)ダッシュボードからクラスターを選択

クラスターの作成

クラスター名:WordPress-cluster(任意)
VPC:WordPress-vpc(最初に作ったVPC)
サブネット:2つのパブリックサブネットを選択

インフラストラクチャ:AWS Fargate

[作成]

タスクの作成

Amazon ECSダッシュボードからタスク定義に進み
[新しいタスク定義の作成] を選択

タスク定義ファミリー名:WordPress-Task(任意)
コンテナ名:wordpress
イメージURI:wordpress:latest
コンテナポート/プロトコル/ポート名/アプリケーションプロトコル
80/TCP/wordpress-80-tcp/HTTP(デフォルトまま)

環境変数を追加する

環境変数 - オプションの下の [環境変数を追加] を押して
一つずつ追加してゆく

キー / 値
WORDPRESS_DB_HOST / ライターインスタンスのエンドポイントWORDPRESS_DB_NAME/データベース名
WORDPRESS_DB_USER /ユーザー名
WORDPRESS_DB_PASSWORD/ パスワード
WORDPRESS_AUTH_KEY / セキュリティキー
WORDPRESS_SECURE_AUTH_KEY / セキュリティキー
WORDPRESS_LOGGED_IN_KEY / セキュリティキー
WORDPRESS_NONCE_KEY / セキュリティキー
WORDPRESS_AUTH_SALT / セキュリティキー
WORDPRESS_SECURE_AUTH_SALT / セキュリティキー
WORDPRESS_LOGGED_IN_SALT / セキュリティキー
WORDPRESS_NONCE_SALT / セキュリティキー

ライターインスタンスのエンドポイントは
AWSコンソール > RDSダッシュボード > データベース >
wordpress-database > wordpress-database-instance-1の
エンドポイントのことだ

データベース名とパスワードは
データベース作成時に認証情報の設定で入力した内容

セキュリティキーはこのURIで生成することができる

https://api.wordpress.org/secret-key/1.1/salt/

それぞれのキー名の横にある値の ' 'で囲まれた内側の値をコピペする

モニタリングとログ記録はデフォルトのままで

入力したら [次へ]

アプリケーション環境:AWS Fargate(サーバーレス)
オペレーティングシステム/アーキテクチャ:Linux/X86_64
CPU:.5vCPU(開発中は最小の構成で)
メモリ:1GB(開発中は最小の構成で)
タスクロール:なし(デフォルトのまま)
タスク実行ロール:ecsTaskExecutionRole(デフォルトのまま)

ストレージオプション

エフェメラルストレージ:空欄のまま
[ボリュームの追加] を選択して
ボリュームタイプ:EFS
ボリューム名:wordpress(任意)
ファイルシステムID:fs-xxxxxxx(事前に作成したEFS)
ルートディレクトリ:/
アクセスポイントID:なし

モニタリングとログ

全部デフォルトのままで

すべて入力したら、最後に内容を確認して [作成] を選択する

サービスの作成

サービスは
AWSコンソール > ECSダッシュボード > クラスター  >
WordPress-Cluster > サービス
と進んでいくと出てくる [作成] から作ることができる

コンピューティングオプション:キャパシティプロバイダー戦略
あとはデフォルトのまま

アプリケーションタイプ:サービス
ファミリー:WordPress-Task
リビジョン:1(最新)
サービス名:WordPress-Service(任意)
サービスタイプ:レプリカ
必要なタスク:0

必要なタスクを0にしておかないとサービスの作成が完了した直後からタスクが起動し始める
他の設定が終わるまでひとまず0に設定してタスクた起動しないようにしておく

VPC:WordPress-vpc(最初に作ったVPC)
サブネット:パブリックの二つを選択
セキュリティグループ:WordPress-LV-SG(既存のセキュリティグループ)
パブリックIP:オン

ロードバランサーの種類:Application Load Balancer
新しいロードバランサーの作成選択
ロードバランサー名:WordPress-LB(任意)
ロードバランス用のコンテナの選択:wordpress 80:80
新しいリスナーを作成を選択
ポート/プロトコル:80/HTTP
新しいターゲットグループの作成を選択
ターゲットグループ名/プロトコル:WordPress-TG / HTTP
ヘルスチェックパス/プロトコル: / / HTTP

すべて入力したら [作成] 

ターゲットグループのヘルスチェックを調整

サービスを作る際にロードバランサーとターゲットグループを新規に作成している
詳細は、AWSコンソール > ECSダッシュボード > クラスター >
WordPress-cluster > サービス > WordPress-Service > ネットワーキング
と進むと確認できる

今回のサービスの設定で、ターゲットグループに登録したサブネットに対して自動的にタスクし起動してロードバランスしてくれる

WordPressは初期化の時にインターネットからのリクエストに対して301,302レスポンスするらしくこれがエラーとして検出されてしまう
それを避けるためターゲットグループのヘルスチェックの設定を修正する

AWSコンソール > ECSダッシュボード > クラスター >
WordPress-cluster > サービス > WordPress-Service > ネットワーキング
からターゲットグループを選択する

Health checks > Editを選択

Advanced health check settingsの下にあるSuccess Codesに、301,302を追加しておく

これで全ての準備が整った

動作確認

タスクを起動させる

現状タスク数を0に設定してタスクが勝手に起動しないようにしている状態なのでタスクを起動できるようにする

AWSコンソール > ECSダッシュボード > クラスター >
WordPress-cluster > サービス > WordPress-Service
まで進み [サービスを更新] を選択

必要なタスクを2に変更して [更新]

1,2分待っているとタスクが2つ起動する

WordPressにアクセスする

ロードバランサーのエンドポイントにブラウザでアクセスする

こんなURI
http://wordpress-lb-????????????.ap-northeast-1.elb.amazonaws.com/

AWSコンソール > EC2ダッシュボード > Load Balancers > WordPress-LB
で確認できるDNS nameがそれ

成功していればこうなる

入力内容は適当に

WordPressをインストール

ログイン


今回試してみてAWSの便利さを実感できた
しかしAuroraは思ったよりコストがかかるので小規模なシステムで使うものではないと思った
Servlessなら安いと聞いていたのだけど個人で使うには高かった

この記事が気に入ったらサポートをしてみませんか?