Zenn
🐡

AWSでワードプレスの環境を構築

2021/04/25に公開
AWS
WordPress
tech

VPCの構築

VPCを作成、その後サブネットを作成
パブリックサブネット、プライベートサブネットを２つづつ作成
耐障害性を高めるため、下記のようにAZを分ける

  • AZ-1a
    • パブリックサブネット01
    • プライベートサブネット01
  • AZ-1c
    • パブリックサブネット02
    • プライベートサブネット02

インターネットゲートウェイを作成し、vpcにアタッチ、ートテーブルを作成し、igwを0.0.0.0/0の送信先として追加し、パブリックサブネット01に関連づける
👉これでパブリックサブネット01はインターネットに接続できる

インスタンス構築

  • EC2,EBSについて
  • IAM,RDSについて
    パブリックサブネット01にEC2を作成、セキュリティグループにHTTPを追加し、webで閲覧できるようにしておく
    キーペアをDL
    RDSの作成をするために、プライベートサブネット01とプライベートサブネット02のDBサブネットグループを作成
    RDSを作成、ここではMySQLを選択し、各種設定を行う際にDBサブネットグループを紐付ける
    作成後RDSのセキュリティグループを編集し、インバウンドルールのソースをIPアドレスからEC2のセキュリティグループに変更
    👉こうすることで、EC2のセキュリティグループを持ってるインスタンスからしかアクセスできないようになる

コンソール操作

$ ssh -i キーペア ec2-user@EC2のパブリックIPアドレス
$ sudo su -

# yum -y update

# amazon-linux-extras install php7.2 -y
# yum -y install mysql httpd php-mbstring php-xml gd php-gd

# systemctl enable httpd.service
# systemctl start httpd.service

# wget http://ja.wordpress.org/latest-ja.tar.gz ~/
# tar zxvf ~/latest-ja.tar.gz
# cp -r ~/wordpress/* /var/www/html/
# chown apache:apache -R /var/www/html

パブリックIPアドレスで参照できる

障害対策

EC2を一度停止して、アクションからイメージを作成するとAMIが立ち上がる
インスタンスを新規で作成する際にマイAMIに作られたAMIがあるのでそれを選択し、サブネットを元のものと違うサブネット（パブリックサブネット02）を選択、共通のSGをアタッチし、作成
その後どちらのインスタンスも開始する

この時点で2つ目のインスタンスにはコンソールでssh通信できるようになっている

ELB

  • ELBについて
    ロードバランサーを作成　リスナーはHTTPのままVPCを選択、それぞれのAZでそれぞれのインスタンスを選択し、新しいSG（80ポート）を作成
    その後ターゲットグループの作成、任意のヘルスチェック設定を行い、ターゲットにそれぞれのインスタンスを登録済みに追加し作成

ターゲットグループのターゲットを見に行ってステータスが問題ないかを確認できたらコンソールへ
RDSに設定されているサイトのアドレスをELBのDNSに書き換える
EC2にssl通信後、ルートユーザーに、その後MySQLに入り、

> USE wordpress（確認）
> UPDATEコマンドでロードバランサーのDNS名に置き換え
> USE wordpress（書き換え確認）

ロードバランサーのDNS名でワードプレスが参照できるかを確認
その後、EC2のSGのインバウンドルールをHTTP許可からELBのSGに変更

これでEC2を片方停止しても片方のEC2につながって、サイトが見れる

RDSのデータベースで既にあるものを変更、マルチAZ配置に変更し、スケジューリングはテストなので今すぐを選択、DBインスタンスを変更、アクションにて再起動をするとフェイルオーバーで再起動できるので選択
データベースのログとイベントにMulti-AZ instance failover completedと出ていれば成功

この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com

冗長化

  • CloudWatch,AutoScalingについて

    AutoScalingグループを作成、ロードバランサーの紐付けを有効し、ターゲットグループを選択
    最大の容量と最小の容量、希望の容量を決める
    作成後、EC2が希望容量分起動する👉希望容量と差分があれば修正される

CloudWatchでCPU稼働率をチェックし、70%以上ならもう一つEC2を追加、30%以下ならEC2を削除というアクションを作成する
まずCloudWatchでAutoScalingグループのメトリクスあてにアラームを作成
その後AutoScalingグループのスケーリングポリシーにアクションを追加し、CloudWatchのアラームと紐付ける

ドメイン設定

  1. まずドメインを何かしらのサービスで取得👉後ほどそのサービスのNS（ネームサーバー）の書き換えが必要
  2. 取得したドメイン名でRoute53のホストゾーンを作成、レコードが２つできる
  3. レコードのうちのNSサーバーにある値を1.の書き換えに使用、4つ全て書き加える
  4. 新しくレコードをシンプルルーティングで作成
  5. ApplicationLoadBalancerとClassicLoadBalancerへのエイリアスにすることでELBとの紐付けができ、ルーティング先として認識される、その後作成

sorrypageの追加

s3のバケット名をドメインと同じ名前で作成
パブリックアクセスのブロックを外す👉外さないと静的webページが公開状態にならない
このバケットのオブジェクトにhtmlファイルをアップロードする
プロパティの静的ウェブサイトホスティングを編集からホスティングを有効にするよう更新👉ドキュメントにhtmlファイルの名前を入力、エラードキュメントにもerror.htmlと入力
s3のアクセス許可メニューからバケットポリシーを作成👉AWS公式サイトにウェブサイトのパブリック読み取りアクセスを許可するバケットポリシーがあるからそれをコピペ
example.comとなってるコード部分を設定したいドメインに変更

セカンダリとしてsorrypageを表示

既にシンプルルーティングで作成されたRoute53のレコードをフェイルオーバーに変更
フェイルオーバーレコードタイプをプライマリにする
新しくフェイルオーバーレコードを作成、名前は同じくドメイン名、レコード定義は前述とは違いS3ウェブサイトエンドポイントへのエイリアスを選択し、タイプをセカンダリとして作成

GitHubで編集を提案

Discussion