ECSでWprdPressを動かしてみた

投稿者: nakamuraryoALB、AWS、Docker、ECS

ECS（Amazon Elastic Container Service）でWprdPressを動かすことが出来ましたので、備忘録を残したいと思います。

１、システム構成

今回作成した構成では、クライアントからのWebアクセスをALBで受付し、ECS上で動作するWordpressに転送します。Wordpressのコンテンツデータ(PHPファイルや画像など)はEFSに格納されるように設定しています。

また、ページ内のテキストデータなどはAurora Serverlessに保存する構成となっています。

後述する、Terraformテンプレートを実行することで、同様の環境を作成することが出来ます。

という方は、「３、Terraformによる環境構築方法」をご覧ください。

２、各リソースの詳細について

２－１、VPC

今回作成する構成では、AWSリソースが少ないため、/24ビットのIPレンジでVPCを作成する設定としています。

２－２、Subnet

パブリックサブネット2つとプライベートサブネット2つの合計4つサブネットを作成しています。

サブネットに割り当てるネットワークアドレスは、Terraformの関数を用いて自動的に割り当てています。そのため、VPCのアドレスレンジを変更する場合は、関数の設定を変更する必要があります。

２－３、IGW・RouteTable

後述するECSは、VPC内に作成されたENI経由でDocker Hubやパラメータストアへアクセスします。そのため、IGWを作成し、インターネット接続が可能となるようにルートテーブルを設定する必要があります。

インターネットにアクセスできない環境で同様の構成を行いたい場合は、VPCエンドポイントを作成することで実現することが出来ます。この構成とした場合、Docker Hubにアクセスできなくなるため、コンテナイメージはECRに登録する必要があります。

２－４、ECS(Fargate)

Fargateとは

ECSでWordpressを動作させます。

今回、ECSの起動タイプは「AWS Fargate」を使用しています。そのため、EC2のリソース管理をする必要はありません。

AWS Fargateのプラットフォームバージョン1.3.0まではEFSにアクセスできませんでしたが、バージョン1.4.0からEFSにアクセスできるようになりました。そのため、今回はDockerのVolume 設定でEFSを指定し、WordpressのPHPファイルや画像コンテンツをEFSに配置する構成としています。

また、Fargateを最大7割引きで利用できる、「Fargat Spot」という機能がありましたので、利用する構成としています。

Fargateをスポットで7割引で使うFargate Spotとは？

２－５、EFS

Amazon Elastic File System とは

WordPressのPHPファイルや画像コンテンツなどを保存するために、EFSを使用しています。

EFSからECSを利用する場合はDockerのvolumeマウント機能を設定します。

また、セキュリティグループの設定も行い、ECSからのアクセスを許可します。

EFSではストレージ容量が事実上無制限で、保存した容量に対して課金される仕組となります。そのため、ディスクの容量監視やディスク拡張を行う必要はありません。

しかしながら１GB当たりの請求金額はEBSやS3と比べ高いため、データ保存時の金額については注意する必要があるかもしれません。

２－６、RDS

Amazon Aurora Serverless を使用する

WordPressのテキストコンテンツ保存用に「Aurora Serverless」を使用しています。

Aurora Serverlessでは、インスタンスの負荷状況に応じて、リソースがオートスケールすることが特徴となります。アクセス数が少ない時は最小限のリソースとなる為、費用を安く抑えることが出来ます。

今回は、アクセス数が少ないWebサイトを想定しているため、「Aurora Serverless」を使用してみましたが、ある程度アクセス数が見込めるWebサイトの場合は通常のAuroraを使用するのが良いと思います。

また、通常のAuroraと比べて、以下の様な制約がある為、注意が必要です。

  • Aurora Serverless は、以下で使用できます。
    • MySQL バージョン 5.6 と互換性がある Aurora MySQL バージョン 1。
    • MySQL バージョン 5.7 と互換性がある Aurora MySQL バージョン 2。MySQL 5.7 と互換性がある Aurora Serverless を使用できるようにするには、Aurora MySQL バージョン 2.07.1 を選択します。
    • PostgreSQL バージョン 10.7 と互換性がある Aurora
  • 接続のポート番号は、以下のように設定します。
    • Aurora MySQL の場合は 3306
    • 5432 (Aurora PostgreSQL)
  • Aurora Serverless DB クラスターにパブリック IP アドレスを割り当てることはできません。Aurora Serverless DB クラスターには、Amazon VPC サービスに基づく Virtual Private Cloud（VPC）内からのみアクセスできます。
  • 各 Aurora Serverless DB クラスターには、2 つの AWS PrivateLink エンドポイントが必要です。VPC 内の AWS PrivateLink エンドポイントが制限に達した場合、その VPC にそれ以上 Aurora Serverless クラスターを作成することはできません。VPC 内のエンドポイントに関する制限の確認および変更については、「Amazon VPC の制限」を参照してください。
  • Aurora Serverless で使用される DB サブネットグループは、同じアベイラビリティーゾーン内に複数のサブネットを持つことはできません。
  • Aurora Serverless DB クラスターで使用されるサブネットグループの変更は、クラスターに適用されません。
  • Aurora Serverless DB クラスターへの接続は、1 日より長く開いたままになると、自動的に閉じられます。
  • Aurora Serverless DB クラスターでは、バイナリログベースのレプリケーションはサポートされていません。
  • Aurora Serverless では、以下の機能はサポートされていません。
    • Amazon S3 バケットからのデータの読み込み
    • データを Amazon S3 バケットに保存する
    • Aurora MySQL ネイティブ関数での AWS Lambda 関数の呼び出し
    • Aurora レプリカ
    • バックトラック
    • マルチマスタークラスター
    • データベースのクローン化
    • IAM データベース認証
    • MySQL DB インスタンスからのスナップショットの復元
    • Amazon RDS パフォーマンスインサイト

２－７、SSMパラメータストア

AWS Systems Manager パラメータストア

WordPressがRDSに接続する際の接続情報を保存するために使用しています。

Terraformテンプレートに設定値をそのまま記載すると、ECSのタスク定義項目でDBの接続パスワードが見える状態となるため、よろしくありません。

WordPress起動時にSSMパラメータストアから設定情報を読み込むことで、セキュアに接続情報を渡すことが出来ます。

２－８、IAM Role

ECSがSSMパラメータストアとCloudWatchLogsにアクセスする場合、アクセス許可が必要となります。そのため、ECSのアクセス許可用にIAM Roleを設定しています。

２－９、Cloud Watch Logs

WordPress実行時に出力されるログを保存します。Terraformに記述しなくても、ログ出力時に自動作成されますが、自動作成された場合は手動削除が必要となることから、Terraformで明示的に作成しています。

３、Terraformによる環境構築方法

ここでは、上記で説明した環境をTerraformで作成する方法を説明します。

Terraformの実行は、CentOS8でsudoできるユーザーで行う事を想定しています。

３－１、構成ツールのインストール

３－１－１、unzipのインストール

sudo yum -y install unzip

３－１－２、AWSCLIのインストール

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

#インストール確認
aws --version
aws-cli/2.X.X～～が表示される事

３－１－３、Terraformのインストール

TER_VER=`curl -s https://api.github.com/repos/hashicorp/terraform/releases/latest | grep tag_name | cut -d: -f2 | tr -d \"\,\v | awk '{$1=$1};1'`
wget https://releases.hashicorp.com/terraform/${TER_VER}/terraform_${TER_VER}_linux_amd64.zip
unzip terraform_${TER_VER}_linux_amd64.zip
sudo mv terraform /usr/local/bin/

#インストール確認
terraform --version
Terraform v0.XX.Xが表示される事

３－２、クリデンシャル情報の設定

実行環境に認証情報を設定します。アクセスキー及びシークレットキーをまだ作成していない場合は、以下のページを参照して作成します。

アクセスキー ID とシークレットアクセスキー

３－２－１、認証情報の設定

「aws configure」コマンドを実行し「AWS Access Key ID」、「AWS Secret Access Key」の項目を設定します。

残りの項目は、空欄でEnterを押します。

$ aws configure
AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]:
Default output format [None]:

３－２－２、認証設定の確認

「aws configure list」コマンドを実行し、上記で設定した認証情報の一部が表示されている事を確認します。

$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************XXXX shared-credentials-file
secret_key     ****************XXXX shared-credentials-file
    region           ap-northeast-1             imds

３－３、AWS環境へデプロイ

３－３－１、Terraformファイルのダウンロード

以下のコマンドを実行して、Terraform設定ファイルをダウンロードします。

git clone https://github.com/nakamura-ryo727/ECS_Wordpress.git
cd ECS_Wordpress/

３－３－２、設定パラメータの修正

「00_variables.tf」を開き、自身の環境に合わせてパラメータを変更します。

※項目を変更しなくてもデプロイすることはできます。

認証情報をprofileパラメータを使用して管理している場合は、「01_provider.tf」ファイルを編集します。

３－３－３、Terraformの初期化

「terraform init」コマンドを実行して、Terraformの初期化を行います。

$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/random...
- Finding latest version of hashicorp/aws...
- Installing hashicorp/random v2.3.0...
- Installed hashicorp/random v2.3.0 (signed by HashiCorp)
- Installing hashicorp/aws v3.9.0...
- Installed hashicorp/aws v3.9.0 (signed by HashiCorp)

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* hashicorp/aws: version = "~> 3.9.0"
* hashicorp/random: version = "~> 2.3.0"

Terraform has been successfully initialized!
 ★表示される事

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

３－３－４、Wordpress実行環境の作成

「terraform apply」コマンドを実行し、デプロイを実行します。

「Enter a value:」が表示されるので「yes」を入力します。

作成後に「Apply complete! Resources: 35 added, 0 changed, 0 destroyed.」と表示され、ALBのエンドポイントが表示されれば成功しています。

表示されたエンドポイントへの接続は、１０分ほど待機した後にブラウザーから行ってください。

$terraform apply
～～～省略～～～
Enter a value: yes
～～～省略～～～(完了まで５分ほかかります。)
Apply complete! Resources: 35 added, 0 changed, 0 destroyed.

Outputs:

alb-dns-name = hogehoge-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com

「alb-dns-name」が表示後10分ほど待機し、ブラウザーでエンドポイントに接続します。

DNSサーバへALBエンドポイントをCNAMEで登録します。

３－３－５、Wordpress環境の削除

環境が不要になった場合は、「terraform destroy」コマンドを実行し、全て削除します。

terraform destroy
～～～省略～～～
  Enter a value: yes
～～～省略～～～
Destroy complete! Resources: 35 destroyed.

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）