しかし、Amazon Linux 2023ではcronがデフォルトで無効になっています。これはcron以外に、cronのようなバッチ実行・定期実行する仕組みがあるということなのかと思い、cronを使わずにE2上でバッチ実行・定期実行する仕組みを考えてみました。

そして、Amazon EventBridge、AWS Step Functions、およびAWS Systems Manager startAutomationExecutionを組み合わせて、EC2インスタンス上でバッチ・定期実行を試してみましたので、紹介します。

特に、Step Functionsを使用することで、エラーハンドリングや通知が容易になり、安全にバッチ実行できるようになります。

エラーハンドリングは以下の状態を把握したいという意味合いです。

• 成功
• 失敗
• タイムアウト(バッチ実行に想定以上に時間がかかっている状態)

使用するAWSサービスの概要

Amazon EventBridge

EventBridgeは、さまざまなAWSサービスやアプリケーションからのイベントをルーティングするサービスです。特定のイベントに基づいてStep Functionsをトリガーするのに適しています。

AWS Step Functions

Step Functionsは、複数のAWSサービスを連携させるワークフローを構築するためのサービスです。ワークフロー内でのエラーハンドリングやリトライ処理が容易であり、信頼性の高いタスク管理が可能です。

AWS Systems Manager startAutomationExecution

SSM オートメーション ドキュメントに則った処理をしてくれます。

実際に試してみる

EC2の準備

EC2の起動

バッチ実行環境のEC2を起動します。

• Amazon Linux 2023 AMIを指定
• インスタンスタイプは、t4g.nanoなど安いやつを選びます
• ネットワーク設定で「からの SSH トラフィックを許可」を指定する
  • セキュリティを考慮して、アクセス元は絞った方がいい
• EC2へはEC2 Instance Connectで接続するため、キーペアはなしでOK

EC2の中に入る

• 諸々設定するため、以下の流れで起動したEC2の中に入ります
  • AWSコンソールのEC2の一覧で、該当のEC2を選択して、接続を押下
    • EC2 Instance Connectタブの接続を押下

EC2上でテスト用のスクリプトを作成

vi test.sh

＜スクリプトの中身＞

exit 0;

スクリプトに実行権限をつける

chmod u+x test.sh

Step Functionsの準備

まず、Step Functionsでワークフローを作成します。このワークフローでは、Systems Manager startAutomationExecutionを使用してEC2インスタンス上でバッチジョブを実行します。

Step Functionsのステートマシンを用意

以下は、EC2インスタンス上でバッチジョブを実行するようになっています。

プログラムが異常終了・時間以内(60秒)に終わらない場合、異常終了となります。

{
  "Comment": "A description of my state machine",
  "StartAt": "StartAutomationWaitForCallBack",
  "States": {
    "StartAutomationWaitForCallBack": {
      "Type": "Task",
      "Resource": "arn:aws:states:::aws-sdk:ssm:startAutomationExecution.waitForTaskToken",
      "Parameters": {
        "DocumentName": "SfnRunCommandByInstanceIds",
        "Parameters": {
          "InstanceIds": [
            "{インスタンスID}"
          ],
          "taskToken.$": "States.Array($$.Task.Token)",
          "workingDirectory": [
            "/"
          ],
          "Commands": [
            "/test.sh"
          ],
          "executionTimeout": [
            "60"
          ],
          "deliveryTimeout": [
            "60"
          ],
          "shell": [
            "Shell"
          ]
        }
      },
      "End": true
    }
  }
}

以下のポリシーをアタッチします。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "ssm:StartAutomationExecution",
			"Resource": "*"
		}
	]
}

SSM オートメーション ドキュメントの作成

以下の「SfnRunCommandByInstanceIds」を使用させていただきます。

GitHub - aws-samples/amazon-stepfunctions-ssm-waitfortasktoken: This pattern implements an automation document wrapper around AWS-RunShellScript execution for a AWS Step Functions waitForTaskToken integration.

This pattern implements an automation document wrapper around AWS-RunShellScript execution for a AWS Step Functions waitForTaskToken integration. - GitHub - aws...

github.com

「SfnRunCommandByInstanceIds」はCloudFormationで作成できます。

このファイルをダウンロードして、CloudFormationで実行すれば作成できます。

EventBridgeの設定

次に、EventBridgeを設定して、Step Functionsの実行をトリガーします。

1. EventBridgeのルール作成: EventBridgeのダッシュボードに移動し、「ルールを作成」をクリックします。
2. ルールの設定:
   • イベントソース: スケジュール（例えば、毎日午前2時に実行）を選択し、cron式を設定します。例えば、cron(0 2 * * ? *)。
   • ターゲット: ターゲットとして、Step Functionsのステートマシンを選択します。
3. ターゲットの設定: Step FunctionsのステートマシンのARNを指定します。

動作確認

• EC2のtest.shに「exit 0」を記載した状態で実行
  • StepFunctionsが成功していればOK
• EC2のtest.shに「exit 1」を記載した状態で実行
  • StepFunctionsが失敗していればOK
• EC2のtest.shに「sleep 61」と「exit 0」を記載した状態で実行
  • タイムアウトするので、StepFunctionsが失敗していればOK

上記記載の方法のメリットとデメリット

メリット

• 柔軟なスケジューリング: EventBridgeを使用することで、定期的なスケジュール設定が容易になります。
• 詳細なエラーハンドリング: Step Functionsを使用することで、ジョブの成功、失敗、遅延に対する詳細なエラーハンドリングと通知が可能です。

デメリット

• 設定の複雑さ: EventBridge、Step Functions、Systems Manager の設定が必要なため、設定手順が複雑になる可能性があります。
• コスト: 複数のAWSサービスを使用するため、コストが増加する可能性があります。

まとめ

Amazon Linux 2023ではcronがデフォルトで無効になっているため、AWSのサービスを組み合わせて定期的なタスクを実行する方法を検討してみました。

EventBridge、Step Functions、Systems Manager startAutomationExecutionを使用することで、EC2インスタンス上で定期的なバッチジョブを実行し、エラーハンドリングを実現できました。

エラーの場合、通知するようにしておけばEC2でのバッチ実行も安心かなと思います！

バッチの実行は他にもいろいろな方法がありますので、気になる方は以下のリンクをクリックくださーい

https://it.kensan.net/it/aws-batch-method.html

localhost

なるべくお金をかけずに、かつ、高速なLaravel環境を構築したいので、CPUはArm、WEBサーバはNginxを使っていきます

まずは具体的な構成を記載していきます！

構成

• EC2を使用
  • インスタンスはt4g.mediumを使用
    • t4gは、Arm ベースの AWS Graviton2 のインスタンスです
    • T3 インスタンスよりも価格パフォーマンスが最大で 40% 高いようです

Amazon EC2 T4g インスタンス – Amazon Web Services

AWS Graviton2 プロセッサを搭載した T4g インスタンスは、Amazon EC2 のバースト可能な汎用ワークロードとしては最高のコストパフォーマンスを提供します。

aws.amazon.com

• OS
  • Amazon Linux 2023
•  Webサーバ
  • Nginxを使用
  • Apacheより高速
• PHP
  • バージョン：8.2.15
  • Laravelを動かすのに必要なもの
• Webサーバで動かすもの
  • Laravel

では実際にEC2起動からLaravelインストールまでやっていきます！

EC2起動

• 以下の設定でEC2を起動します
  • Amazon マシンイメージ (AMI)でAmazon Linux 2023を指定する
  • アーキテクチャで64ビット(Arm)を指定する
  • インスタンスタイプでt4g.mediumを指定する
  • ネットワーク設定で「からの SSH トラフィックを許可」「インターネットからの HTTP トラフィックを許可」を指定する
    • セキュリティを考慮して、アクセス元は絞った方がいい
  • EC2へはEC2 Instance Connectで接続するため、キーペアはなしでOK

EC2の中に入る

• 諸々設定するため、以下の流れで起動したEC2の中に入ります
  • AWSコンソールのEC2の一覧で、該当のEC2を選択して、接続を押下
    • EC2 Instance Connectタブの接続を押下

もろもろインストール

パッケージ最新化

• パッケージ最新化

sudo dnf update -y

Nginxインストール〜設定

• Nginxインストール

sudo dnf -y install nginx

• Nginx設定変更

sudo vi /etc/nginx/nginx.conf

serverの箇所を以下通り修正

    server {
        listen       80;
        listen       [::]:80;
        server_name  _;
        root         /usr/share/nginx/html/public;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        index index.php;
        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }
        location ~ \.php$ {
            fastcgi_pass unix:/var/run/php-fpm/www.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
            include        fastcgi_params;

       }
    }

• Nginx起動

sudo systemctl start nginx

• Nginx自動起動をON

sudo systemctl enable nginx

• ブラウザでNginxが正常に動作していることを確認
  • EC2に割り当てられているパブリックIPにhttpでアクセスする
    • 「Welcome to nginx!」が出れば、Nginxが起動できているので問題なし

PHPインストール

• PHPをインストールする

sudo dnf install -y php-fpm php-mysqli php-json php php-devel

php-fpm起動

• php-fpmを起動します

sudo systemctl start php-fpm.service

composerをインストールする

• composerインストールします

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php
php -r "unlink('composer-setup.php');"
sudo mv composer.phar /usr/local/bin/composer

Laravel11をインストール

• Laravel11をインストールします。

composer create-project --prefer-dist laravel/laravel laravel-project "11.*"

• 出来上がったファイルをNginxのルートディレクトリにコピー

sudo cp -r laravel-project/* /usr/share/nginx/html/

• storageディレクトリの権限設定

cd /usr/share/nginx/html/
chmod -R 777 storage

• .envファイルの作成

vi .env

<ファイルの中身>
APP_KEY={APIキー}
DB_CONNECTION=sqlite

APIキーは
php artisan key:generate
で発行可能

•  以下のコマンドでsqlite用ファイルを作成し権限を付与します。

touch database/database.sqlite
chmod 777 database/database.sqlite

動作確認

• 動作確認
  • 「http://{EC2のIPアドレス}」にアクセスして、以下の画面表示されればOK〜〜

なるべくお金をかけずに、かつ、高速なWordPressを構築したいので、CPUはArm、WEBサーバはNginxを使っていきます

まずは具体的な構成を記載していきます！

構成

• EC2を使用
  • インスタンスはt4g.mediumを使用
    • t4gは、Arm ベースの AWS Graviton2 のインスタンスです
    • T3 インスタンスよりも価格パフォーマンスが最大で 40% 高いようです

Amazon EC2 T4g インスタンス – Amazon Web Services

AWS Graviton2 プロセッサを搭載した T4g インスタンスは、Amazon EC2 のバースト可能な汎用ワークロードとしては最高のコストパフォーマンスを提供します。

aws.amazon.com

• OS
  • Amazon Linux 2023
•  Webサーバ
  • Nginxを使用
  • Apacheより高速
• PHP
  • バージョン：8.2.15
  • WordPressを動かすのに必要なもの
• MySQL
  • バージョン：8.0.37
  • WordPressを動かすのに必要なもの
• Webサーバで動かすもの
  • WordPress

では実際にEC2起動からWordPressインストールまでやっていきます！

EC2起動

• 以下の設定でEC2を起動します
  • Amazon マシンイメージ (AMI)でAmazon Linux 2023を指定する
  • アーキテクチャで64ビット(Arm)を指定する
  • インスタンスタイプでt4g.mediumを指定する
  • ネットワーク設定で「からの SSH トラフィックを許可」「インターネットからの HTTP トラフィックを許可」を指定する
    • セキュリティを考慮して、アクセス元は絞った方がいい
  • EC2へはEC2 Instance Connectで接続するため、キーペアはなしでOK

EC2の中に入る

• 諸々設定するため、以下の流れで起動したEC2の中に入ります
  • AWSコンソールのEC2の一覧で、該当のEC2を選択して、接続を押下
    • EC2 Instance Connectタブの接続を押下

もろもろインストール

パッケージ最新化

• パッケージ最新化

sudo dnf update -y

Nginxインストール〜設定

• Nginxインストール

sudo dnf -y install nginx

• Nginx設定変更

sudo vi /etc/nginx/nginx.conf

serverの箇所を以下通り修正

    server {
        listen       80;
        listen       [::]:80;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location ~ \.php$ {
            root         /usr/share/nginx/html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name;
            include        fastcgi_params;

        }
    }

• Nginx起動

sudo systemctl start nginx

• Nginx自動起動をON

sudo systemctl enable nginx

• ブラウザでNginxが正常に動作していることを確認
  • EC2に割り当てられているパブリックIPにhttpでアクセスする
    • 「Welcome to nginx!」が出れば、Nginxが起動できているので問題なし

PHPインストール

• PHPをインストールする

sudo dnf install -y php-fpm php-mysqli php-json php php-devel

MySQLインストール〜設定

• MySQLをインストールする

sudo dnf -y localinstall https://dev.mysql.com/get/mysql80-community-release-el9-1.noarch.rpm

sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023

→これを実行しないと「Error: GPG check FAILED」エラーになる

sudo dnf install -y mysql-community-server mysql-community-client mysql-community-devel

• 起動

sudo systemctl enable mysqld.service

sudo systemctl start mysqld.service

• 初期パスワード確認

sudo less /var/log/mysqld.log

• MySQL接続

mysql -uroot -p
# パスワード更新
ALTER USER 'root'@'localhost' IDENTIFIED BY '新しいパスワード';

# wordpress用のDBを作成
create database wordpress_db default character set utf8 collate utf8_general_ci;

WordPressインストール

• WordPressインストール

wget https://ja.wordpress.org/latest-ja.tar.gz

tar -zxvf latest-ja.tar.gz

rm latest-ja.tar.gz

sudo mv wordpress/* /usr/share/nginx/html/

sudo chmod -R 777 /usr/share/nginx/html #実際はもっと制限かけたほうがいいけど、今回はとりあえず動けばOKということで...

sudo systemctl start php-fpm.service

sudo systemctl restart nginx.service

動作確認

• 動作確認
  • 以下のアドレスにアクセスして、WordPressの画面表示されればOK

http://{EC2のIPアドレス}/wp-login.php

以下のコマンドで取得できます。

curl http://169.254.169.254/latest/meta-data/public-ipv4

「169.254.169.254」はメタデータを戻すサーバのアドレスですので、環境によってIPアドレスを変更する必要はありません。

EC2のインスタンス内から上記コマンドを打てば、インスタンスメタデータにアクセスして、そのインスタンスに割り当てられたパブリックIPアドレスを取得できます。

インスタンスメタデータで取得できるもの

インスタンスメタデータには他にもいろいろなメタデータが入っています。

以下のコマンドでどんなメタデータが取得できるか確認できます。

curl http://169.254.169.254/latest/meta-data/

上記コマンド実行で、以下の結果が返ってきます。以下のメタデータを取得可能ということです。

mi-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
identity-credentials/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/

上記の取得したいメタデータは以下のコマンドで取得可能です。

curl http://169.254.169.254/latest/meta-data/{取得したいメタデータを指定}

• EC2に入りたいけど入れない
• EC2に入る方法がいくつかあるけど、どれで入るのが良いの？どんな違いがあるの？

という方向けの記事です。

EC2の接続方法は以下の4つの接続方法があります。

それでは、それぞれの接続方法について整理していきます。

EC2 Instance Connect

EC2 Instance Connectを使うとブラウザで簡単にEC2インスタンスに接続できます。

接続方法

EC2ダッシュボードから接続したいEC2インスタンスを選択して、「接続」ボタンを押下します。

次の画面が表示されるのでEC2 Instance Connectを選択して、接続ボタンを押下するとEC2インスタンスに接続できます。

EC2接続

使用するための条件

• OSの条件、以下のOSをサポートしている

• • Amazon Linux 2 (すべてのバージョン)
  • Ubuntu 16.04 以降
• ネットワーク関連の制限
  • インスタンスにパブリック IPv4 アドレスが必要
  • ポート 22 が許可されている
• IAM関連
  • IAMのマネージドポリシーのEC2InstanceConnectをEC2接続するIAMユーザに設定する

セッションマネージャー

セッションマネージャーもブラウザでEC2インスタンスに接続できます。

接続方法

EC2ダッシュボードから接続したいEC2インスタンスを選択して、「接続」ボタンを押下します。

次の画面が表示されるのでセッションマネージャーを選択して、接続ボタンを押下するとEC2インスタンスに接続できます。

EC2接続

使用するための条件

• 必要なソフトウェア
  • EC2インスタンスにSSMエージェントをインストール
    • Amazon Linux 2を使用している場合はデフォルトで入っているのでインストール不要

Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする - AWS Systems Manager

Amazon EC2 Linux オペレーティングシステムに SSM Agent を手動でインストールおよびアンインストールします。

docs.aws.amazon.com

• IAMロール
  • IAMのマネージドポリシーのAmazonSSMManagedInstanceCoreをEC2インスタンスのロールにアタッチ

上記設定後に接続できない場合は、EC2インスタンスを再起動すると接続できるようになったりします。

SSHクライアント

クライアントPCからSSH接続する方法です。

接続方法

以下のようなコマンドを打ちSSH接続します。

ssh -i "鍵の場所" ec2-user@パブリック IPv4 DNS

使用するための条件

• EC2インスタンス作成時にキーを作成しておく必要あり
• ポート 22 が許可されている

EC2 シリアルコンソール

EC2 シリアルコンソールもブラウザでEC2インスタンスに接続できます。

接続方法

EC2ダッシュボードから接続したいEC2インスタンスを選択して、「接続」ボタンを押下します。

次の画面が表示されるのでEC2シリアルコンソールを選択して、接続ボタンを押下するとEC2インスタンスに接続できます。

EC2接続

使用するための条件

まずAWSマネージメントコンソールのEC2ダッシュボード画面(以下の画面)からEC2シリアルコンソールを有効にします。

EC2シリアルコンソール

次に他の接続方法でパスワードを設定しておく必要があります。

他の接続方法でEC2インスタンスに接続し、「passwd」コマンドでパスワードを設定します。

sh-4.2$ sudo passwd root
Changing password for user root.
New password:{hogehoge}
Retype new password:{hogehoge}
passwd: all authentication tokens updated successfully.
sh-4.2$

上記の例では

• ID：root
• パスワード：hogehoge

を使用するとEC2 シリアルコンソールでEC2に接続できます。

4つ接続方法があるがどれを選択すべきか

セキュアに接続したい

セッションマネージャーを使用します。

ポート22を解放しなくていいので、他の接続方法と比べてセキュアです。

とにかく簡単に接続したい

EC2 Instance Connectを使用します。

「ポート 22許可 & OSがAmazon Linux 2 またはUbuntu 16.04」であれば、特別な設定をせずに、接続ボタンで接続できます。

SSHクライアントで接続したい

この場合はそのままSSHクライアントしましょ

トラブルシューティング

EC2 シリアルコンソールを使用します。

Linux インスタンス用 EC2 シリアルコンソール - Amazon Elastic Compute Cloud

Amazon EC2 シリアルコンソールを使用して、Amazon EC2 Linux および Windows インスタンスで発生する可能性のある問題を診断およびトラブルシューティングします。

docs.aws.amazon.com

EC2 シリアルコンソールを使用すると、Amazon EC2 インスタンスのシリアルポートにアクセスできます。このシリアルポートを使用して、起動、ネットワーク設定、およびその他の問題をトラブルシューティングできます。

まとめ

EC2への接続方法についてみてみました。

4つのEC2への接続方法がありましたが、それぞれ特徴と用途が異なっていたかと思います。

EC2への接続は適切な方法で行いましょー

静的ページ化するところはWordPressのプラグインStaticPressを使用します。

CloudFrontのキャッシュクリアはClear CloudFront Cacheプラグインを使用します。

また、WordPressURLにBasic認証をかけるということもやっていきます！

WordPressのインストールは終わっている前提での記載になりますので、インストールが終わっていない場合は、以下の記事をご参照いただきEC2にWodPressをインストールください。

https://it.kensan.net/it/aws-ec2-wordpress.html

localhost

それでは、StaticPressを使用して、WordPressコンテンツの静的ページ化をしていきます！

StaticPressを使用してWordPressコンテンツを静的ページ化する

以下の手順で静的ページ化します。手順に記載のパスはAMI「WordPress Certified by Bitnami and Automattic」を使用時の例ですので、環境に応じて読み替えてください

1. 以下のコマンドのようにWordPressが動いているEC2にSSH接続します

   • ssh -i “{sshキー}” bitnami@{パブリック IPv4 DNS}

2. WordPress管理画面からStaticPressプラグインをインストールして、有効化します
3. StaticPressの設定を以下の通り行います
   • サイトURL：http://{パブリック IPv4 アドレス}/static/
   • ドキュメントルート：/opt/bitnami/wordpress/
4. StaticPressプラグインの再構築ボタンを押下し、静的ファイルを生成します
   • フェッチが進まない場合はソース修正をします

     • /home/bitnami/stack/wordpress/wp-content/plugins/staticpress/includes/class-static_press_admin.php

       // 以下のコードを追加する
       「if( !($('li:last-child', ul).offset() === void 0) )」を追加する

       
       修正後ソース　312行目辺り
       if( !($('li:last-child', ul).offset() === void 0) )//追加

       $('html,body').animate({scrollTop: $('li:last-child', ul).offset().top},'slow');

   • ファイルが生成されずに終了する場合はドキュメントルートの権限を確認します
     • 権限がなければ付与します
       • 「chown -R daemon:daemon /opt/bitnami/wordpress」を実行すると、権限に問題がある場合は問題解消できます
5. 以下のURLにアクセスし画面表示されればOKです。
   • http://{パブリック IPv4 アドレス}/static/

CloudFrontの設定

1. ディストリビューションを以下の設定で新規作成します(他の項目は変更しなくて大丈夫)
   • オリジンドメイン：EC2のパブリック IPv4 DNS
   • オリジンパス ：static
2. 以下のURLにアクセスし画面表示されればOK
   • http://ディストリビューションドメイン名
     • httpsでも大丈夫

次に、Clear CloudFront Cacheプラグインをインストールして、CloudFrontのキャッシュを簡単にクリアできるようにしておきます！

Clear CloudFront Cacheプラグインをインストールする

Clear CloudFront Cacheは、WordPress管理画面からインストール可能です。

インストール方法の詳細は、以下の記事をご参照ください。

https://it.kensan.net/it/cloudfront-cache-clear.html

localhost

WordPressURLにBasic認証をかける

WordPressURLはBasic認証をかけましょ！

Basic認証をかけることで、以下のメリットがあります。

Basic認証のかけ方は以下記事をご参照ください

https://it.kensan.net/it/staticpress-basic-auth.html

localhost

以上で「StaticPressを使ってEC2上のWordPressコンテンツをCloudFront経由で配信」できるようになりましたー

5分で動作確認までできます。ハマるポイントとしては、WordPressログイン時のパスワードの確認くらいです。

構築のポイントとしてはEC2起動時に指定するAMIで「WordPress Certified by Bitnami and Automattic」を指定することです。

Terraformを使って簡単に立ち上げる方法もあります！以下の記事をご参照ください。

https://it.kensan.net/it/terraform-ec2-wordpress.html

localhost

本記事ではAWSコンソール画面からインストールしていきます。

早速インストール(EC2起動)方法から見ていきます。

インストール(EC2起動)方法

1. AWSコンソールのEC2ダッシュボードからインスタンスを起動を選択
2. インスタンス起動画面で以下の設定をする
   • 名前：wordpress（他の名前でも大丈夫）
   • アプリケーションおよび OS イメージ (Amazon マシンイメージ)：WordPress Certified by Bitnami and Automattic
   • インスタンスタイプ：t3.a.small(もっとスペック高いものを選択しても大丈夫)
   • キーペア (ログイン)：任意の名前で作成または既存キーを選択
   • ファイアウォール (セキュリティグループ)：
     • 「セキュリティグループを作成する」を選択し、「インターネットからの HTTP トラフィックを許可」「からの SSH トラフィックを許可する」のチェックボックスのみチェックする（他は外す）
3. インスタンスを起動ボタンを押下

EC2起動時のインスタンス設定

これで、WordPressインストール済みのEC2を立ち上げが終わった状態になります。

 

次に、WordPress管理者アカウントのパスワードの確認方法を記載します。

WordPress管理者アカウントのパスワード確認

1. EC2インスタンス一覧画面から作成したWordPressインスタンスを選択
2. 以下の通りメニューをたどり、システムログを開く
   • アクション->モニタリングとトラブルシューティング->システムログを取得
3. システムログを「Setting Bitnami application password to」で検索し、WordPress管理者のパスワードを調べる

WordPress EC2システムログ

WordPress管理者アカウントのパスワードの確認が終わりました！

次は、実際にWordPressにアクセスして管理画面にログインしてみます！

動作確認

1. EC2インスタンス詳細画面を開き、「http://パブリック IPv4 アドレス/wp-admin」をブラウザのアドレスバーに入力する(httpsだとアクセスできないので注意)
2. WordPressログイン画面が表示されるのでユーザ名は「user」、パスワードはシステムログで調べたパスワードを入力し、ログインできれば完了

EC2インスタンス詳細

EC2インスタンスにSSH接続する方法

以下のようなコマンドでSSH接続可能です。ユーザが「bitnami」である点が要注意です。

• ssh -i “{sshキー}” bitnami@{パブリック IPv4 DNS}

WordPressコンテンツをCloudFrontで簡単に配信したい場合

以下の記事をご参照ください

https://it.kensan.net/it/aws_ec2_wordpress_cloudfront.html

localhost

WordPressの構築方法は以下の記事に記載の5つの方法がありますが、バックアップ方法は本記事に記載の1つの方法で大丈夫です。

https://it.kensan.net/it/use-case-wordpress-aws.html

localhost

本記事で記載するバックアップの適用範囲は、以下の通りです。

まず、なぜバックアップが必要かについて記載します！

なぜかバックアップが必要か

なぜバックアップが必要かについては以下の点が挙げられます。

1つ注意点として、復元はバックアップを取得した時点まで遡って復元となります。好きなタイミングに戻せるということではないということです。

例えば、1日１回9時にバックアップを取得している場合は、9時時点の状態で復元可能となります。何日前の9時時点まで遡れるかは、バックアップの保持期間の設定次第となります。

では、バックアップの方法について記載していきます！

WordPressのバックアップ方法

AWS Backupを使用してバックアップを取得します。

スケジュール機能を使用して定期的にバックアップを取得します。

AWS Backupの設定

1. AWSコンソール画面からAWS Backup画面に行く
2. バックアッププランを作成ボタンを押下
3. バックアッププランを作成画面が表示されるので以下の設定を行いプランを作成ボタンを押下し、以下の設定を行う
   • 起動オプション
     • バックアッププランのオプション：新しいプランを立てる
     • バックアッププラン名：適切なもの
   • バックアップルールの設定
     • バックアップルール名：適切なもの
     • バックアップボールト：新しいバックアップボールトを作成ボタンを押下
       • バックアップボールトを作成画面で以下の設定をしてバックアップボールトを作成する
         • バックアップボールト名：適切なもの
         • 暗号化キー：こだわりがなければデフォルトを選択
     • バックアップ頻度：毎日を選択
     • バックアップウィンドウ：バックアップウィンドウのデフォルトを使用を選択
     • コールドストレージへの移行：しない
     • 保持期間：日数を選択して1を入力（保持期間を1日以上にしたい場合は1より大きい数字を入力）
     • コピー先にコピー：東京リージョンを選択
4. リソースを割り当てる画面に遷移するので以下を設定し、リソースを割り当てるボタンを押下
   • リソース割り当て名：任意のもの
   • IAM ロール：デフォルトのロールを選択
   • リソースの選択：特定のリソースタイプを含める
   • 特定のリソースタイプを選択：EC2
   • インスタンス ID：バックアップ対象のWordPressのEC2インスタンスを選択

バックアップの確認

上記バックアップ設定をしてから、1日くらい経ってから、バックアップが取れているか確認します。

AWS Backup画面のジョブからバックアップされているか確認します。

ジョブが追加されていて、ステータスが「完了」になっていればOKです。

バックアップからの復元方法(リストア)

以下の手順でバックアップからの復元(リストア)を行います。

復元(リストア)の確認

EC2ダッシュボードから実行中インスタンスを確認して、以下の2点が問題なければOKです。

まとめ

AWS Backupを使用して、簡単にWordPressのバックアップとリストアができることが確認できたと思います。

定期的にバックアップを取っておくと、トラブル発生時にも安心かと思いますので、バッックアップしていきましょ★

最後にAWS Backupの公式URLを載せておきます。

サービスとしての Backup - 一元化されたバックアップ - AWS Backup - AWS

AWS Backup は、AWS サービスやサードパーティアプリケーションのバックアップを一元的に管理し、自動化することができます。

aws.amazon.com

WordPressのStaticPressの導入については以下の記事をご参照ください！

StaticPress S3を使用してS3+CloudFrontでコンテンツ配信するケースの導入例

https://it.kensan.net/it/staticpresss3.html

localhost

StaticPressを使用してEC2＋CloudFrontでコンテンツ配信するケースの導入例

https://it.kensan.net/it/aws_ec2_wordpress_cloudfront.html

localhost

本記事はStaticPressを導入後に、不要な静的ファイルが出力されないようにする方法を記載します。

不要な静的ファイルとは配信サーバに不要なページであるWordPressの管理画面などのHTMLを指します。

不要なファイルを生成されないようにすることで、以下のメリットがあります。

配信に不要なページについて

配信サーバに不要なページについて、具体的には以下のフォルダを不要と考えています。

なぜ対応が必要なのか

改めて、不要なページを出力しないようにする理由について、記載していきます。

配信に不要なページについて、静的HTMLを出力しないようにすることで、以下のメリットがあります。

それでは、不要な静的ファイルが生成されないようにする方法を記載します。

不要な静的ファイルが生成されないようにする方法

生成対象外とする対象のフォルダによって対応方法が異なります。

まずは、wp-admin、wp-includesフォルダを除外する方法を記載します。

wp-admin、wp-includesを静的ファイル生成対象外とする

修正対象ソース：/wp-content/plugins/staticpress/includes/class-static_press.php

869行目辺りを以下のように修正する

//修正後ソース
//869行目辺り
private function static_files_url($url_type = 'static_file'){
$urls = array();
 
$static_files_filter = apply_filters('StaticPress::static_files_filter', $this->static_files_ext);
foreach ($static_files_filter as &$file_ext) {
$file_ext = '*.'.$file_ext;
}
$static_files = array_merge(
$this->scan_file(trailingslashit(ABSPATH), '{'.implode(',',$static_files_filter).'}', false),
//$this->scan_file(trailingslashit(ABSPATH).'wp-admin/', '{'.implode(',',$static_files_filter).'}', true),←コメントアウト
//$this->scan_file(trailingslashit(ABSPATH).'wp-includes/', '{'.implode(',',$static_files_filter).'}', true),←コメントアウト
$this->scan_file(trailingslashit(WP_CONTENT_DIR), '{'.implode(',',$static_files_filter).'}', true)
);

次に、以下の静的ファイルを生成されないように対応します。

・/wp-content/plugins/*

・/wp-json/*

・/author/*

/wp-content/plugins/*と/wp-json/*と/author/*を静的ファイル生成対象外とする

修正対象ソース：/wp-content/plugins/staticpress/plugin.php

//以下のソースを追加
add_action('StaticPress::file_put', 'static_rm', 1, 2);
function static_rm($file_dest, $url){
  if(strstr($file_dest, '/author/')
    or strstr($file_dest, '/wp-content/plugins/')
    or strstr($file_dest, '/wp-json/')){
		unlink($file_dest);
  }
}

本記事の通りに構築することで、以下のようなエラーを回避できます。

次に、StaticPress S3プラグインを使用してS3+CloudFrontで配信することのメリットについて触れておきます。以下のメリットがあります。

メリット

低コストで安定したサイト運用ができる
→急なアクセス増にも耐えられ、かつ、安価です
高速なサイトを構築できる
→サイトの速度向上はSEO的にも有利です
訪問者がWordPressに直接アクセスしないのでセキュアになります
→WordPressのセキュリティリスクについては以下の記事をご参照ください

https://it.kensan.net/it/wordpress_security.html

localhost

逆にデメリットも上げておきます

まず、ゴールイメージです。

ゴールイメージ

最終的なゴールイメージのAWS構成図は以下の通りです。

StaticPress S3+S3+CloudFront

次に、環境構築で使用するものをリストアップしていきます！

使うもの

まず、使用するものをリストアップしていきます。

AWSリソース

使用するAWSリソースは以下の通りです。

Word Pressプラグイン

使用するWord Pressプラグインは以下の通りです。

それでは、環境構築していきます！

構築作業

具体的には以下の作業をしていきます！

S3

• 適切なバケット名でバケットを新規作成する

Cloud Front

• ディストリビューションを新規作成する
  • オリジンは作成したS3バケットを指定する

CloudFrontとS3の設定の詳細

CloudFrontとS3の設定の詳細は以下の記事をご参照ください

https://it.kensan.net/it/aws-cloudfront-s3-oac.html

localhost

EC2

次の設定でEC2インスタンスを起動します。

// EC2に割り当てが必要な権限(ポリシー)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "cloudfront:CreateInvalidation",
                "s3:ListBucket",
                "s3:PutObject"
            ],
            "Resource": "*"
        }
    ]
}



• 次にyum updateしておく

sudo yum -y update

Apacheインストール & 設定

• Apacheインストール

sudo yum -y install httpd

• Apacheのconfファイルを編集する

Apacheのconfファイルの場所：/etc/httpd/conf/httpd.conf

次の設定をhttpd.confの末尾に追記する

LoadModule 
rewrite_module modules/mod_rewrite.so

<Directory "/var/www/html/">

AllowOverride All

</Directory>

• Apacheを起動する

sudo service httpd start

• 今後自動で立ち上がるように設定する

sudo chkconfig httpd on

PHPインストール

• 管理者権限に切り替えておく

sudo su

• 時間の設定
  • ロンドンの時間になっているので日本時間に修正

ln -sf /usr/share/zoneinfo/Japan /etc/localtime

• dateコマンドで日本時間になっているか確認する

date

• PHPをインストールする

amazon-linux-extras enable php7.4


yum clean metadata

yum install php


yum install php-mbstring

• apacheを再起動

service httpd restart

Apacheとphpの動作確認

• 動作確認用ファイルの作成

 vi /var/www/html/index.php

• 動作確認用ファイルの中身

<?php


echo"test!!";

• 動作確認

以下の動作確認をします！

MySQLインストール

• yumでMySQLをインストールする

yum remove mariadb-libs


rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022


yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-7.noarch.rpm


yum -y install mysql-community-server


yum install php-xml -y

• phpからMySQLをコントロールするため追加プログラムを入れる

yum install -y php-mysqlnd

• MySQLを起動

service mysqld start

• MySQLの設定

mysql_secure_installation

初期パスワードを聞かれる

初期パスワードは/var/log/mysqld.logに吐かれているので、それを入力する

A temporary password is generated for root@localhost: [初期パスワード]

WordPressインストール

cd /var/www/html/


curl -O https://ja.wordpress.org/latest-ja.tar.gz

tar
xvf latest-ja.tar.gz


chown -R apache:apache wordpress


rm -f latest-ja.tar.gz

MySQLのデータベース作成

mysql -u root -p

CREATE DATABASE wordpress;

StaticPress S3設定

• まずはGitをインストールする

yum install git-all

• StaticPress S3をインストールする

cd wordpress/wp-content/plugins/

git clone https://github.com/megumiteam/staticpress-s3.git

chown -R apache:apache staticpress-s3


• ソース修正が必要なため、修正する

修正①：wp-content/plugins/staticpress-s3/includes/class-S3_helper.php

変更前

$magic_file = '/usr/share/misc/magic';

変更後

$magic_file = '/etc/httpd/conf/magic';

ソース修正②：wp-content/plugins/staticpress-s3/includes/class-S3_helper.php
18行目あたりにある、「__construct」をする
「Access Key」と「Sercret Key」の入力チェックを行っているif文をコメントアウト

修正後ソース

function __construct($access_key = null, $secret_key = null, $region = null) {

// if ($access_key && $secret_key) {

$this->init_s3($access_key, $secret_key, $region);

// }

}

StaticPressをインストールする

「http://ドメイン/wordpress/」にアクセスし、

WordPressの初期設定を行い、

プラグインStaticPressをインストールして有効化する。

ついでにStaticPress S3も有効化しておく。

StaticPressの設定をする

StaticPress設定画面で以下の設定を行う

次に以下のコマンドで静的HTMLファイルの出力先ディレクトリの権限設定をする

mkdir /wordpress_home/

chown -R apache:apache /wordpress_home

• ソース修正が必要なため修正する

修正ソース①：wp-content/plugins/staticpress/includes/class-static_press_admin.php

// 以下のコードを追加する
「if( !($('li:last-child', ul).offset() === void 0) )」を追加する


修正後ソース　312行目辺り
if( !($('li:last-child', ul).offset() === void 0) )//追加

$('html,body').animate({scrollTop: $('li:last-child', ul).offset().top},'slow');

修正ソース②：wp-content/plugins/staticpress/includes/class-static_press.php

// 変更前　以下をコメントアウト

//$permalink = get_permalink($post->ID);

//if (is_wp_error($permalink))

//      continue;

//$count = 1;

// 変更後　コメントアウトした箇所に以下を追記
$permalink = get_permalink($post->ID);
if (is_wp_error($permalink))continue;
if (preg_match('/.*\.html\/.*/', $permalink, $m)) 
{continue;}
$count = 1;

• WordPressのStaticPress画面から「再構築」を実施

Word Pressのパーマリンク設定の変更

WordPressの設定->パーマリンク画面を開き、カスタム構造を選択し、「/%postname%.html」を入力する

MySQLの再設定をする（日本語文字化け対策）

このままですと投稿名が日本語の場合に文字化けするので、テーブルの文字コードを変更する

• /etc/my.cnfの末尾に以下を追記

character-set-server=utf8


sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,ALLOW_INVALID_DATES

• MySQL再起動する

service mysqld restart

• MySQLに接続し、wp_urlsテーブルの文字コードを変更する

 mysql -uroot -p

 use wordpress;


ALTER TABLE wp_urls CONVERT TO CHARACTER SET utf8;

S3にHTMLを転送し、Cloud Frontで配信できるようにする

• WordPressのStaticPress画面から「再構築」を実施
• CloudFrontのドメインにアクセスし、WordPressコンテンツが見れれば成功！

StaticPressがうまく動かない場合

StaticPressが正常に動作しない場合の対処方法を記載します。

EC2の出力先ディレクトリにコンテンツが生成されない

• ドキュメントルートの権限を確認する
  • Apacheユーザで書き込み可能である必要がある
    • 以下のコマンドを実行します。


chown -R apache:apache /wordpress_home

S3にコンテンツがコピーされない

• AWSコンソールからS3のバケットを選択
  • アクセス許可タブを開く
    • オブジェクト所有者を編集
      • ACL 無効 (推奨)に更新し、再度、Word PressのStatic Press画面から「再構築」を行う

固定記事などが表示されない(403エラーとなる)ケースがある

• 以下の記事をご参照ください

WordPressのプラグインStaticPress S3で固定記事などが表示されない(403エラー)

WordPressのプラグインStaticPress S3で固定記事などが表示されない(403エラーが発生する)場合の対処法。エラー・表示されない原因と対処法ほうについて記載します。対処方法はStaticPressのPHPプログラムを修正する方法もありますが、CloudFrontの関数を使用する方法を記載しています

it.kensan.net

画像メディアのみS3にコピーされない

• 日本語やスペースが入っていると正常に動作しない模様
  • 画像のファイル名を英語＋スペースなしに変更して再度アップロードしてから、StaticPressで再構築する

ドメインが静的サイトURLに置き換わらない

• 以下の記事をご参照ください

https://it.kensan.net/it/wordpress_staticpress_domain_convers.html

localhost

サイトマップが出力されない

• 以下の記事をご参照ください

https://it.kensan.net/it/wordpress_staticpress_sitemap-xm.html

localhost

追加で設定しておくと良いこと

正常に動いているけど、追加で設定しておくと良いことについて記載します！

WordPressの置いてあるEC2サーバでBasic認証をかける

• 以下の記事をご参照ください

WordPressのプラグインStaticPressでBasic認証を使う

StaticPress利用時のBasic認証のかけ方について記載。StaticPressで静的HTMLを生成して、StaticPress S3で静的ファイルをS3に転送して、配信する場合、Basic認証をかけることをお勧めします。Basic認証をかけるにはStaticPressのソース修正も必要となります

it.kensan.net

不要なページの出力を止める

• 以下の記事をご参照ください

WordPressのプラグインStaticPressで不要な静的ファイルが生成されないようにする

WordPressのプラグインStaticPressで不要な静的ファイルが生成されないようにする方法について記載。不要なファイルを生成されないようにすることで、ディスク容量の削減やStaticPressでの再構築時間の短縮が可能。StaticPressのソースコードを修正することで不要なファイルが生成されなくなります。

it.kensan.net

CloudFrontのキャッシュを簡単に消せるようにする

• 以下の記事をご参照ください

https://it.kensan.net/it/cloudfront-cache-clear.html

localhost