この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
サービスの提供を迅速に行いたい場合や環境を変えたテストを行いたい場合にコンテナサービスは有用ですよね。
コンテナ実行環境のAWS Fargateはサーバーの管理をすることなくコンテナを実行でき、シームレスなスケーリングが実現可能です。
今回の記事ではAmazonECS on Fargateを利用して、WordPressサイトを構築する手順を紹介します。
AWS Fargate×WordPress
AWS Fargateを利用してWordPressサイトを構築する前に、AWS Fargateについて紹介します。
■AWSFagateとは
AWS FargateはAmazon ECSで使用できるサービスです。AWSマネージドサービスなので、EC2インスタンスのプロビジョンやスケーリング、サーバー管理不要でコンテナを実行できます。料金は従量課金制で、Compute Savings Plansも用意されています。
また、ELBやCloudWatch,IAMなどのAWSサービスと連携可能です。
AWS Fargateを利用したWordPressサイト構築ハンズオン
それではAWS Fargateを利用したWordPressサイトの構築をしていきます。構築イメージは上の画像を参考にしてください。
■使用するAWSサービス一覧
今回の構築は以下のAWSサービスを使用します。
- Amazon VPC
- Amazon Aurora
- Amazon EFS
- Amazon ECS
- Elastic Load Balancing
■構築手順確認
構築手順は以下の通りです。
- VPC作成
- RDS作成
- EFS作成
- ECS作成
まずはVPCから作成していきます。
■1.VPC作成
はじめにリージョンを確認しましょう。わたしは個人的な理由からシンガーポールリージョンを使用しますが、みなさんは任意のリージョンで問題ありません。
AWSマネージメントコンソールのVPC作成画面では、サブネットやルートテーブル、インターネットゲートウェイまで一気に作ることができます。簡単に作れる半面、設定する値を見落とすことがあるので注意しましょう。設定値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| 作成するリソース | VPCなど |
| 名前タグの自動生成 | ecs-handson |
| IPv4 CIDR ブロック | 10.0.0.0/16 |
| IPv6 CIDR ブロック | IPv6 CIDR ブロックなし |
| アベイラビリティゾーン(AZ)の数 | 2 |
| 第1アベイラビリティゾーン | ap-southeast-1a |
| 第2アベイラビリティゾーン | ap-southeast-1c |
| パブリックサブネットの数 | 2 |
| プライベートサブネットの数 | 2 |
| 1aのパブリックサブネットCIDR | 10.0.1.0/24 |
| 1cのパブリックサブネットCIDR | 10.0.2.0/24 |
| 1aのプライベートサブネットCIDR | 10.0.3.0/24 |
| 1cのプライベートサブネットCIDR | 10.0.4.0/24 |
↓
↓
↓
↓
↓
■1-2セキュリティグループ
つぎにセキュリティグループを作成します。作成するセキュリティグループは3つで、ALB用・EFS用・RDS用です。設定する値は以下の通りです。
| 項目 | インバウンドルール | ソース |
|---|---|---|
| efs-handson-sg-alb | HTTP | 0.0.0.0/0 |
| efs-handson-sg-efs | NFS | efs-handson-sg-alb |
| efs-handson-sg-RDS | MYSQL/Aurora | efs-handson-sg-alb |
VPCのダッシュボード画面の左ペインにあります「セキュリティグループ」をクリックし、作成ボタンを押してください。
↓まずはALB用のセキュリティグループを作成します。
↓つぎにEFS用のセキュリティグループです。
↓続いて、RDS用のセキュリティグループを作成します。
ソースにALB用のセキュリティグループが出てこない場合は、VPCの選択を見てみてください。デフォルトはリージョンのデフォルトVPCです。
■2.RDS作成
データベースであるRDSを作成していきます。WordPressではデータ保管にデータベースが必要です。Amazon RDSはマネージドデータベースなので、ほぼ何もしなくてもAWSが管理してくれます。
RDSインスタンスを作る前に、サブネットグループから作成します。RDSはプライベートサブネット内での運用を前提に作成しますので、サブネットグループの「サブネットを追加」はプライベートサブネットを指定しましょう。設定する値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| 名前 | ecs-handson-rds-subgroups |
| 説明 | 任意 |
| VPC | ecs-handson-vpc |
| アベイラビリティゾーン | ap-southeast-1a,ap-southeast-1c |
| サブネット | プライベートサブネット2つ(10.0.3.0/24,10.0.4.0/24) |
↓
↓
つぎにRDSインスタンスを作成します。設定する値は以下の通りです。
| 項目 | 設定値 | 備考 |
|---|---|---|
| データベース作成方法 | 標準作成 | |
| エンジンのタイプ | Amazon Aurora | 無料枠を利用したい場合MySQL |
| テンプレート | 開発/テスト | |
| DB クラスター識別子 | ecs-handson-database | |
| マスターユーザー名 | admin | |
| マスターパスワード | 任意 | 使いますので忘れずに |
| 可用性と耐久性 | レプリカを作成しない | 本番環境であればレプリカ作成推奨 |
| VPC | ecs-handson-vpc | |
| DBサブネットグループ | ecs-handson-rds-subgroups | |
| セキュリティグループ | ecs-handson-sg-rds | |
| アベイラビリティゾーン | ap-southeast-1a | |
| 最初のデータベース名 | ecs_handson_database | WordPress設定時に使います |
| 削除保護 | 無効 | 本番環境であれば有効化推奨 |
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
今回は構築が目的ですので、「削除保護」は有効化にしていません。運用が目的の場合は有効化をしておきましょう。
■3.EFS作成
EFSを作成していきます。EFSは共有コンテンツストアとして利用し、複数のノードが同時にWordPressファイルにアクセスできるようにします。ECS作成の際に詳しく説明しますが、Amazon ECS on Fargateを利用してWordPressサイトを構築する際は、EFSのような外部ストレージが必要です。設定する値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| 名前 | ecs-handson-efs |
| VPC | ecs-hanson-vpc |
| ストレージクラス | 標準 |
↓
EFSが作成できましたら、マウントターゲットを変更します。パブリックサブネットとプライベートサブネットが用意されている場合、デフォルトではプライベートサブネットをマウントターゲットとして設定されています。
今回の構築ではパブリックサブネットをマウントターゲットとして設定したいので、変更していきましょう。
↓
↓
↓
↓削除が完了しましたら、以下の設定値で設定します。
| 項目 | 設定値 |
|---|---|
| アベイラビリティゾーン | ap-southeast-1a,ap-southeast-1c |
| サブネットID | パブリックサブネットを設定 |
| セキュリティグループ | ecs-handson-sg-efs |
↓
↓
■4.ECS作成
Amazon Elastic Container Service (Amazon ECS)は、非常にスケーラブルで高速なコンテナ管理サービスです。クラスター上のコンテナを実行、停止、管理できます。Amazon ECSを作成する前に、Amazon ECSについて簡単に説明します。
Amazon ECSは、フルマネージドコンテナオーケストレーションサービスであり、コンテナ化されたアプリケーションを簡単にデプロイ、管理、およびスケーリングできます。
コンテナオーケストレーションとはコンテナのデプロイメント、管理、スケーリング、ネットワーキングを自動化する仕組みで、上記に挙げた作業以外にも構成とスケジューリング、リソースの割り当て、ロードバランシングなども自動で行ってくれます。
わたしたちは1つのコンテナオーケストレーター（ECS）に指示するだけで、多数のホストで実行されているコンテナの運用・管理が可能になるということです。
わたしははじめ、Amazon ECSとAWS Fargateを混同していました。しかし、Amazon ECSは運用・管理をする指示役、FargateはECSの指示のもと動くコンテナの実行環境だとわかりました。
オーケストレーターとしての作業は多様ですが、Amazon ECSでは各作業をシンプルなリソース名で表現しています。簡単にまとめましたので、確認してみてください。以下の情報は[AWS Black Belt Online Seminar] CON202 ECS Fargate入門から引用しました。
-
タスク定義：タスクを構成するコンテナ群
⇒コンテナ定義（イメージ場所等）、要求CPU＆メモリ、タスクに割り当てるIAMロール、ネットワークモード、etc…
-
クラスター
⇒実行環境の境界、IAM権限の境界（クラスターに対する操作）、スケジュールされたタスクの実行を設定可能
-
サービス
⇒タスク実行コピー数(n個)、起動後タスク実行コピー数を維持、Elastic Load Balancing(ELB)と連携、起動タイプ(EC2,Fargate)を設定
-
タスク
⇒タスク定義に基づき起動されるコンテナ群、タスク内コンテナは同一ホスト上で実行される
ECSについてなんとなく理解できたでしょうか。各リソースの違いを認識するだけで、ECSの作成が楽になるはずです。それではECSクラスターから作成していきます。
■4-1.ECS-クラスター作成
最初はクラスターの作成です。クラスターはコンテナを動かすための論理的なグループのことです。設定する値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| クラスター名 | ecs-handson-cluster |
| VPC | ecs-handson-vpc |
| サブネット | ap-southeast-1a,ap-southeast-1cに作成したパブリックサブネット |
| インフラストラクチャ | AWS Fargate |
↓
↓
■4-2.ECS-タスク定義作成
次にタスク定義を作成します。タスク定義はタスクを構成するコンテナ群の定義で、タスクをどのように動かすかやコンテナイメージ、CPU、メモリなどの設定をします。
設定する値は以下の通りです。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 起動タイプ | FARGATE | |
| タスク定義名 | wordpress | |
| オペレーティングシステムファミリー | Linux | ホストが使用するOS |
| タスク実行ロール | ecsTaskExecutionRole | イメージをpullやログ送信に必要 |
| タスクメモリ | 2GB | ※1 |
| タスクCPU | 1 vCPU | ※1 |
※1.起動タイプがAWS Fargateの場合、タスクメモリとタスクCPUを指定する必要があります。以前EC2インスタンスを利用してWordPressサイトを構築した際、EC2のインスタンスタイプはt2.microでした。t2.microはvCPU“1”、メモリ“1”です。同じ値を入力しようとすると、以下のエラーが出ます。
AWS公式ドキュメントを確認すると、値の組み合わせが決まっているようです。今回のタスクサイズの決定は以下の図を参考に、タスクCPUの1vCPUに合わせて、タスクメモリを2GBで設定しました。
タスク定義の作成に戻ります。作成する前に画面左上にあります「新しいECSエクスペリエンス」をoffにしてください。新しいタスク定義作成の画面には、EFSのマウント設定がありません。※わたしが見落としているだけかもしれません。
↓
↓
↓
↓
↓作成の流れだと次はコンテナを設定するのですが、コンテナ設定の前にページ下部にあるボリュームを設定します。コンテナ設定内でボリュームの指定があるため、先に設定したほうが便利です。
↓
↓
↓ここからコンテナの定義を設定していきます。重要な部分ですので、詳しく説明していきます。設定する値は以下の通りです。
| 項目 | 設定値 | 備考 |
|---|---|---|
| コンテナ名 | wordpress | 任意 |
| イメージ | wordpress:latest | ※2 |
| ポートマッピング | 80 | ホストにアクセスしトラフィックを送受信するポート |
↓
※2.タスク定義内のコンテナ定義設定で、イメージレジストリから参照するコンテナイメージを決定します。上の画像のイメージ項目で、「wordpress:latest」 と入力してあるのがわかりますでしょうか。
イメージに「wordpress:latest」 と入力しておくことで、タスクが起動する際にdocker hubにあるwordpressのlatestタグのイメージを参照し、タスクが起動されます。
docker hubだけではなく、ECRのリポジトリにあるイメージやAmazon ECR Public Galleryのイメージを入力することも当然ですが可能です。Amazon ECR Public Galleryにあるwordpressのイメージを参照する場合は、下の画像のように入力するイメージ名が違ってきます。
↓ECS-タスク定義作成のコンテナ追加に戻ります。イメージやポートマッピングを入力しましたら、次は環境項目で環境変数を設定します。WordPressの場合はデータベースとcookie情報の保護に関する環境変数の設定が必要です。設定値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| WORDPRESS_DB_HOST | ライターインスタンスのエンドポイント |
| WORDPRESS_DB_NAME | ecs_handson_database(任意で設定したもの) |
| WORDPRESS_DB_USER | admin(任意で設定したもの) |
| WORDPRESS_DB_PASSWORD | xxxxxx(任意で設定したもの) |
| WORDPRESS_AUTH_KEY | 下記URLの生成値 |
| WORDPRESS_SECURE_AUTH_KEY | 下記URLの生成値 |
| WORDPRESS_LOGGED_IN_KEY | 下記URLの生成値 |
| WORDPRESS_NONCE_KEY | 下記URLの生成値 |
| WORDPRESS_AUTH_SALT | 下記URLの生成値 |
| WORDPRESS_SECURE_AUTH_SALT | 下記URLの生成値 |
| WORDPRESS_LOGGED_IN_SALT | 下記URLの生成値 |
| WORDPRESS_NONCE_SALT | 下記URLの生成値 |
セキュリティキー生成はこちらから⇒ https://api.wordpress.org/secret-key/1.1/salt/
WordPressはインストール時にキーがデフォルトで設定されます。タスクが起動するたびに自動で生成するので、キーが変更されてしまし、ログイン状態にあるユーザを強制的に再ログインさせることになってしまいます。タスクが新たに起動してもログイン状態を保持するために、環境変数でセキュリティキーを設定しておきましょう。
↓
↓環境変数の入力が完了しましたら、EFSのマウントポイントを設定します。Wordpressでは/var/www/html/wp-content配下にデータが保管されますので、パスを指定して設定します。
↓
↓
■4-3.ECS-サービス作成
最後にサービスを作成していきます。サービスはタスクの実行コピー数を定義したり、起動後のタスク実行数を維持したり、起動タイプ（EC2、Fagate）を設定したりします。設定する値は以下の通りです。
| 項目 | 設定値 | 備考 |
|---|---|---|
| コンピューティング設定 | キャパシティープロバイダー戦略 | |
| アプリケーションタイプ | サービス | |
| ファミリー | wordpress | コンテナ名です |
| サービス名 | ecs-handson-wordpress | |
| 必要タスク | 0 | 一旦0で入力 |
↓
↓必要なタスクは一旦“0”に設定しておきます。サービスをデプロイするとタスクが即起動されてしまうからです。後ほど作成するALBのターゲットグループの設定を変えてから、必要タスク数を設定しなおします。
↓ネットワーキングの項目を入力していきます。設定する値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| VPC | ecs-hanson-vpc |
| サブネット | ap-southeast-1a,ap-southeast-1cのパブリックサブネット |
| セキュリティグループ | ecs-handson-sg-alb |
| パブリックIP | オン |
↓次にロードバランサーを作成します。設定する値は以下の通りです。
| 項目 | 設定値 |
|---|---|
| ロードバランサーの種類 | ApplicationLoadBalancer |
| ApplicationLoadBalancer | 新しいロードバランサーの作成 |
| ロードバランサー名 | ecs-handson-alb |
| ロードバランス用のコンテナ選択 | wordpress 80:80 |
| リスナー | 新しいリスナーを作成 |
| ポート | 80 |
| プロトコル | HTTP |
| ターゲットグループ | 新しいターゲットグループの作成 |
| ターゲットグループ名 | ecs-handson-tg |
| プロトコル | HTTP |
| ヘルスチェックパス | / |
| ヘルスチェックプロトコル | 80 |
↓
↓
デプロイを押します。作成に数分かかりますので、ターゲットグループのヘルスチェック設定を変更しましょう。
EC2のダッシュボード画面に移動し、左ペインからターゲットグループをクリックしてください。
↓作成したターゲットグループにチェックを入れ、「Health checks」のタブを押します。
↓
↓「Adavanced health check settings」をクリックし、Success codesに“302”を追加してください。「Save chenges」を押して、設定を保存しましょう。
WordPressにはリダイレクトを行うwp_safe_redirect関数が用意され、レスポンスコードの初期値が302です。wordpressの設定が終わるまで302が返ってきますので、設定しておきました。設定が完了しましたら、302を消してもらって大丈夫です。今後HTTPS通信を考えている方は、301も追加してください。
↓「Save chenges」を押して、設定を保存しましょう。
■動作確認
すべての構築が完了しました。動作確認を行っていきます。
【確認すること】
- wordpressサイトが表示され、ログインできるか
- タスクが停止しても、新たなタスクが起動し、サイトを表示し続けるか(可用性)
- 新たなタスクでもwordpressで画像が閲覧できるのか(データの永続化)
■【確認1】WordPress の管理者用ダッシュボードにログイン
WordPressの設定を行います。タスクを起動するためにECSクラスターのサービス設定を変更します。
↓クラスター⇒サービス⇒編集から、必要なタスクを0⇒1に変更し、更新を押してください。
↓
↓
必要なタスク数を変更したことで、コンテナが起動します。確認してみましょう。
↓クラスター⇒タスクタブを押してください。コンテナは高速起動がウリです。1分ほどで実行中になるかと思います。
念のため、ターゲットグループのヘルスチェックも確認しましょう。
ヘルスチェックがunhealthyだった場合、下の画像のように、起動⇒停止⇒新たなタスク起動⇒停止・・・が永遠に続きます。もしそんな状況になった場合、サービスの編集画面で必要タスク数を“1⇒0”に変更しましょう。焦らずに設定項目を確認してください。
ちなみに、この時はロードバランサーのヘルスチェックが原因でした。
次にWordPressのインストールです。
↓クラスター⇒サービス⇒「ecs-handson-wordpress」ロードバランサーをクリックしてください。
↓
↓
DNS名でアクセスしてみましょう。
http://{DNS名}
↓
↓
↓
↓
無事ログインすることができました。
■【確認2】可用性テスト
次は可用性のテストです。稼働中のタスクが停止しても、もうひとつのタスクにロードバランサーが振り分け、サイトを表示し続けられるか確認していきます。一つのタスクに何かあっても、もうひとつ動いていることでユーザーに対しサービスを提供し続けられます。
現在必要タスク数が“1”なので“1⇒2”に変更し、コンテナが2つ稼働している状態にしましょう。ECSクラスターのサービス設定から変更できます。
↓
↓
↓タスクが2つ稼働している状態になりました。疑似障害として最初に起動したタスクを停止します。
停止が確認できましたら、wordpressにログインしてみましょう。
問題なく表示されます。そして、サービスのタスク必要数を2に設定しているので、タスクが2⇒1になった時点で、新たなタスクが起動されます。クラスターのタスクタブを更新してみてください。タスクが2個起動されていますね。
■【確認3】永続化テスト
続いてデータの永続化について確認します。
コンテナサービスにおいて、コンテナ内にあるデータはコンテナを破棄するとすべて消えます。Fargateも同じで、タスクを停止するとタスク内のデータは消えます。wordpressでは画像の保存場所をタスク外に保存しなければ、タスクが停止すると閲覧できなくなってしまいます。
コンテナは生成するデータを保持しません。コンテナが終了すると、書き込み可能なレイヤに書き込んだデータは、コンテナとともに破棄されます。これにより、コンテナはデータをローカルに保存する必要のないステートレスアプリケーションに適しています。データの永続性を必要とするコンテナー化されたアプリケーションには、アプリケーションのコンテナーが終了しても破棄されないストレージバックエンドが必要です。ベストプラクティスよりAmazon Elastic Container Service – のベストプラクティスガイド
今回の構築ではデータの永続化のため、ファイル共有システムサービスのAmazonEFSを利用しています。WordPressサイトで画像データをアップロードし、今あるタスクを停止して新たなに起動したタスクでもアップロードした画像を確認できるか試してみましょう。
↓まずはwordpressサイトにアクセスし、画像をアップロードします。
↓
↓
画像をアップロードしました。それでは現在起動中のタスク2つを一つずつ停止していきます。
↓
停止後、新たなタスクが2つ起動したのを確認できましたので、wordpressサイトにアクセスしライブラリを確認しましょう。
無事画像が確認できました。今回の構築は以上です。
■【番外編】構築時に詰まった点
今回の構築でわたしが詰まった点を紹介します。一つはタスクが起動して数分後に停止し、別のタスクが起動したことです。前述しましたが、原因はALBのヘルスチェックエラーでした。
↓停止したタスクを確認すると、停止理由が記載されていますのでありがたいですよね。
↓
もう一つ詰まった点が、起動したタスクとRDSの接続です。この場合もタスクの起動・停止が繰り返されました。
タスクにはパブリックIPが割り当てられているので、アクセスしてみると、
RDSとの接続エラーが確認できたので、タスク定義の際に設定した環境変数を見てみました。凡ミスなのですが、データベース名をDBインスタンスIDの「ecs-handson-database-instance-1」で設定していました。
わたしが詰まった点は以上です。参考になれば幸いです。
まとめ:【初学者向け】AWS Fargateを利用してWordPressサイトを構築
コンテナサービスを体感するために、Amazon ECS・AWS Fargateを利用してみました。EC2にLAMP環境を構築してWordPressを入れる方法より、アプリを実行する環境構築が楽です。コンテナサービスを利用すればサーバについて考えなくていいので、アプリケーション開発に注力できるようになるのがわかった気がします。
今回は最小限の構成で構築しましたが、実際に運用するためにはRoute53や監視、画像の表示高速化なども必要になります。ネクストステップではRoute53で任意のドメイン名でアクセスできるようにしたり、画像をS3バケットにアップロードできるようにしていきたいですね。
参考リンク：Amazon Elastic Container Service 入門 コンテナイメージを作って動かしてみよう »、AWS Fargate
☆協栄情報では「AWSマイグレーションに関する課題やお悩み」に関する相談を承っています☆
オンプレミスからAWS環境への移行にお悩みの方はぜひこちらから⇒https://www.cp-info.co.jp/service/aws-migration/
↓ほかの協栄情報メンバーもAmazon ECSに関する記事を公開しています。ぜひ参考にしてみてください。
■Fargateコンテナにシェルでアクセスしてみた -Amazon ECS Exec-(TERAO)
https://cloud5.jp/ecsexec-fargate/
■Amazon ECS について調べ、実際に使用してみた 前編(motoishi)
https://cloud5.jp/amazon-elastic-container-service-amazon-ecs-mk/