EC2 | さゆフィクション http://it.kensan.net/it aws wordpress などなどゆるーく書いてます Sun, 05 May 2024 04:05:36 +0000 ja hourly 1 https://wordpress.org/?v=6.5.2 https://it.kensan.net/wp-content/uploads/2023/03/cropped-icon-32x32.png EC2 | さゆフィクション http://it.kensan.net/it 32 32 WordPressをAmazon Linux 2023×Nginxで動かしてみる https://it.kensan.net/wordpress-amazon-linux-2023.html Fri, 03 May 2024 08:38:39 +0000 http://3.113.9.194/it/?p=1809 WordPressをAmazon Linux 2023×Nginx上で動かしてみます。

なるべくお金をかけずに、かつ、高速な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 のバースト可能な汎用ワークロードとしては最高のコストパフォーマンスを提供します。
  • 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

       

      ]]>
      AWS EC2に割り当てられたパブリックIPアドレスをEC2のインスタンス内から取得する方法 https://it.kensan.net/aws-ec2-ip.html Mon, 29 Apr 2024 01:21:04 +0000 http://3.113.9.194/it/?p=1807 AWS EC2に割り当てられたパブリックIPアドレスをEC2のインスタンス内から取得する方法を記載します。

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

      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/public-ipv4」でパブリックIPアドレスを取得可能
      →「169.254.169.254」はメタデータを戻すサーバのアドレス
      →インスタンスメタデータにアクセスして、そのインスタンスに割り当てられたパブリック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への4つの接続方法について(Instance Connect/セッションマネージャー/SSH/シリアルコンソール) https://it.kensan.net/ec2-connection.html Thu, 27 Apr 2023 14:07:11 +0000 http://3.113.9.194/it/?p=607 EC2接続方法についての記事です。

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

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

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

      4つの接続方法

      EC2 Instance Connect
      セッションマネージャー
      SSHクライアント
      EC2 シリアルコンソール

       

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

      EC2 Instance Connect

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

      接続方法

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

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

      EC2接続

      EC2接続

      使用するための条件

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

      セッションマネージャー

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

      接続方法

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

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

      EC2接続

      EC2接続

      使用するための条件

      • 必要なソフトウェア
        • EC2インスタンスにSSMエージェントをインストール
          • Amazon Linux 2を使用している場合はデフォルトで入っているのでインストール不要
      Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする - AWS Systems Manager
      Amazon EC2 Linux オペレーティングシステムに SSM Agent を手動でインストールおよびアンインストールします。
      • 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接続

      EC2接続

      使用するための条件

      まずAWSマネージメントコンソールのEC2ダッシュボード画面(以下の画面)から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 インスタンスで発生する可能性のある問題を診断およびトラブルシューティングします。

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

      まとめ

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

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

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

      ]]>
      StaticPressを使ってEC2上のWordPressコンテンツをCloudFront経由で簡単に配信する方法 https://it.kensan.net/aws_ec2_wordpress_cloudfront.html Fri, 17 Feb 2023 21:46:32 +0000 http://3.113.9.194/it/?p=454

      WordPressのコンテンツを静的ページ化し、CloudFrontで配信できるようする!ということをやっていきます。

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

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

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

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

      AWSのEC2に簡単にWordPressをインストールする方法(AMIでWordPressを使用)
      簡単にAWSのEC2にWordPressをインストールする方法です。5分で動作確認までできます。 ハマるポイントとしては、WordPressログイン時のパスワードの確認くらいです。 AMIはWordPress Certified by Bitnami and Automatticを使用します
      やること

      ①WordPressコンテンツを静的ページ化
      ②静的ページ化をCloudFrontで配信
      ③WordPressURLにはBasic認証をかける

      使用するプラグイン

      StaticPress
      →静的ページ化で使用
      Clear CloudFront Cache
      →CloudFrontキャッシュの削除で使用

      それでは、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管理画面からインストール可能です。

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

      StaticPress S3と共存できるWordPressプラグインClear CloudFront Cacheを公開!
      StaticPress S3と共存できるWordPressプラグイン「Clear CloudFront Cache」を公開! WordPressコンテンツをCloudFront経由で配信している場合に使えるプラグイン。公開したプラグイン「Clear CloudFront Cache」はWP管理画面からインストール可能

      WordPressURLにBasic認証をかける

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

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

      メリット
      • WordPress管理画面へのアクセスにはBasic認証が必要
        • セキュリティ向上
      • 「WordPressを静的ファイル化して配信するURL」と「WordPressのURL」で、同一の記事が配信されていると、Google等のクローラーにみなされないようにする
        • SEO対策になる

       

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

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

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

      ]]>
      AWSのEC2に簡単にWordPressをインストールする方法(AMIでWordPressを使用) https://it.kensan.net/aws-ec2-wordpress.html Fri, 17 Feb 2023 20:09:26 +0000 http://3.113.9.194/it/?p=439 簡単にAWSのEC2にWordPressをインストールする方法を記載します。

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

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

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

      TerraformでEC2上にWordPressを簡単に構築するーコピペでTerraformでWordPress構築
      TerrafromでEC2上にWordPressを構築します。コピペで簡単にTerraformでEC2上にWordPressを構築できるように記載しています。TerraformソースコードとTerrafromの実行方法、最後に作成したリソースの削除方法を記載しています。

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

      やること

      WordPressがインストールされたEC2を立ち上げる
      →AMI:WordPress Certified by Bitnami and Automatticを使用
      WordPress管理画面にログインするためのパスワードを確認して、実際にログインしてみる

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

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

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

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

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

         

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

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

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

        WordPress EC2システムログ

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

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

        動作確認

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

        EC2インスタンス詳細

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

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

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

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

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

        StaticPressを使ってEC2上のWordPressコンテンツをCloudFront経由で簡単に配信する方法
        WordPressのコンテンツを静的ページ化し、CloudFrontで配信できるようにします。静的ページ化するところはWordPressのプラグインStaticPressを使用します。CloudFrontのキャッシュクリアはClear CloudFront Cacheプラグインを使用します
        ]]>
        WordPressをEC2で運用している際のバックアップ方法(AWS Backupを使用) https://it.kensan.net/wordpress-ec2-backup.html Tue, 07 Feb 2023 00:58:18 +0000 http://ec2-13-112-80-120.ap-northeast-1.compute.amazonaws.com/it/?p=34 WordPressをAWSのEC2で運用している場合の「EC2バックアップの方法」と「バックアップからの復元方法」を記載します。

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

        WordPressをAWSで構築する5つの方法ー構築方法毎の使用するAWSサービスやWordPressプラグイン情報など
        WordPressをAWS上に構築する方法について記載します。 AWS上に構築する方法は5つのパターンがあり、それぞれ特徴やメリットとデメリットがありますので、この点について記載していきます。 構築パターンの特徴を知って適切な構築方法を選択しよう!という記事です。

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

        バックアップの適用範囲

        WordPressをEC2単体で運用している
        →DBはEC2内にインストールしていてAWS RDSのサービスは利用していない
        →AWS RDSを使っている場合、別途RDSのバックアップが必要になります

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

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

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

        バックアップが必要な理由

        サーバー障害でデータが消えてしまった場合でも、バックアップから復元可能となる
        間違って必要なデータを消してしまった場合にも、バックアップから復元可能となる
        攻撃を受けてデータ改ざんされた場合でも、バックアップから復元可能となる

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

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

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

          WordPressのバックアップ方法

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

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

          AWS Backupの設定

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

          バックアップの確認

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

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

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

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

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

          リストア手順
          1. AWS Backup画面のジョブから最新のバックアップジョブ IDを押下
          2. 復旧ポイント ARNを押下
          3. 復元ボタンを押下
          4. バックアップを復元ボタンを押下

          復元(リストア)の確認

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

          復元の確認方法

          新しいインスタンスが立ち上がっていること
          新しいインスタンスの「パブリック IPv4 DNS」にブラウザにアクセスし、WordPressの記事が表示されること

            まとめ

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

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

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

            サービスとしての Backup - 一元化されたバックアップ - AWS Backup - AWS
            AWS Backup は、AWS サービスやサードパーティアプリケーションのバックアップを一元的に管理し、自動化することができます。
            ]]>
            WordPressのプラグインStaticPressで不要な静的ファイルが生成されないようにする https://it.kensan.net/staticpress_-unnecessary_file.html Sun, 05 Feb 2023 21:58:54 +0000 http://ec2-13-112-80-120.ap-northeast-1.compute.amazonaws.com/it/?p=43 WordPressのプラグインStaticPressで不要な静的ファイルが生成されないようにする方法を記載します。

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

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

            【日本語URL対応版】WordPressのコンテンツを StaticPress S3プラグインを使用して配信する方法
            WordPressコンテンツをStaticPressS3を使用してS3+CloudFrontで配信する方法を記載。 コピペで環境構築できます。S3+CloudFrontで配信することで「 低コストで安定したサイト運用ができる」「高速なサイトを構築できる」「セキュリティ的に安全」というメリットがあります。

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

            StaticPressを使ってEC2上のWordPressコンテンツをCloudFront経由で簡単に配信する方法
            WordPressのコンテンツを静的ページ化し、CloudFrontで配信できるようにします。静的ページ化するところはWordPressのプラグインStaticPressを使用します。CloudFrontのキャッシュクリアはClear CloudFront Cacheプラグインを使用します

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

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

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

            2つのメリット

            ディスク容量の削減
            StaticPressでの再構築時間の短縮

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

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

            配信に不要なフォルダ
            • 配信に不要なフォルダ
              • /wp-admin/*
                • 管理画面。配信不要ページ。
              • /wp-content/plugins/*
                • pluginを管理しているフォルダ。配信時にプラグインは不要(動かさない)。
              • /wp-includes/*
                • API、クラス、関数などのプログラムファイルを管理しているフォルダ。配信時は不要
              • /wp-json/*
                • WordPressのAPIレスポンスを保存するフォルダ。配信サーバ時は不要。
              • /author/*
                • 投稿者ごとのページ。必要な場合は残す。

            なぜ対応が必要なのか

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

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

            メリット詳細

            <WordPressサーバ(EC2)からみたメリット>
            メリット1:EC2ディスク容量の節約できる
            メリット2:再構築(HTML生成)時間の短縮


            <配信サーバ(S3)からみたメリット>
            ※WordPressサーバ(EC2)で配信している場合は対象外です。配信サーバにS3を使用している場合、以下のようになります。
            WordPressサーバで不要なページについては静的ファイル(HTMLファイル)の生成対象外となるため、StaticPress S3でS3に同期(コピー)対象から不要なページが含まれないようになります。これにより以下のメリットがあります
            メリット1:S3 APIの節約に役立ちます
            メリット2:S3 ストレージの節約に役立ちます

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

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

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

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

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

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

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

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

              ・/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で再構築をします。

              動作確認準備

              WordPressサーバの静的ファイル出力フォルダをカラにする
              (S3を使用している場合)S3にコピーされたファイルを全て削除する

              StaticPressで再構築後に以下の確認ができればOKです。

              動作確認内容

              WordPressサーバの静的ファイル出力フォルダにファイルが出力されている
              配信用URLにアクセスし、サイトが正常に表示される

              ]]>
              【日本語URL対応版】WordPressのコンテンツを StaticPress S3プラグインを使用して配信する方法 https://it.kensan.net/staticpresss3.html https://it.kensan.net/staticpresss3.html#respond Sat, 04 Feb 2023 02:22:53 +0000 http://ec2-13-112-80-120.ap-northeast-1.compute.amazonaws.com/it/?p=7 WordPressコンテンツをStaticPress S3プラグインを使用してS3+CloudFrontで配信する方法を記載します。自力で構築するとエラーなどではまることも多いですが、本記事の通りに環境構築することで、ほとんどのエラーを回避できます。

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

              回避できるエラー

              静的ファイルが正しく出力されない
              S3に静的ファイルが転送されない
              記事URLに日本語が含まれる場合、日本語が文字化けする

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

              メリット

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

              WordPressのセキュリティリスクとセキュリティ対策
              WordPressはセキュリティ対策を取らないとリスクが高いと思っています。 セキュリティ対策としてはセキュリティプラグインの導入などがあると思いますが、一番安全なのはStaticPress S3を使用してコンテンツをS3+CloudFrontで配信し、WordPressが動いているサーバを隠してしまう対策です。

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

              デメリット

              セットアップが難しい
              →StaticPress S3のセットアップは、一般的なWordPressプラグインよりも複雑です
              →本記事を参照し、構築すればきっと大丈夫です
              静的ファイルに変換する(HTMLに変換する)処理に時間がかかる
              →大量の記事を持つサイトほど、変換に時間がかかります。

               

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

              ゴールイメージ

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

              StaticPress S3+S3+CloudFront

              StaticPress S3+S3+CloudFront

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

              使うもの

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

              AWSリソース

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

              使用するAWSリソース

              EC2
              →EC2にWordPressをインストールします
              S3
              →S3にWord Pressを静的コンテンツ化したHTMLを格納します
              CloudFront
              →S3に格納した静的コンテンツ化したHTMLをCloud Front経由で配信します

              Word Pressプラグイン

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

              使用するWord Pressプラグイン/span>

              Static Press
              →Static Pressを使用してWord PressコンテンツをHTML化する
              StaticPress S3
              →StaticPress S3を使用してHTMLをS3に転送する

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

              構築作業

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

              環境構築

              S3バケット作成
              CloudFrontディストリビューション作成
              CloudFrontとS3の接続設定
              EC2作成&設定
              →ロール設定
              →WordPress起動に必要なミドルウェアのインストール
              →WordPressインストール
              →WordPressプラグインインストール&設定

              S3

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

              Cloud Front

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

              CloudFrontとS3の設定の詳細

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

              AWS CloudFrontからS3へのアクセス制御をOACを使って正しく設定する
              S3のコンテンツをCloudFront経由で配信する際、CloudFrontからS3へのアクセス制御をOAC(Origin access control settings)を使って正しく設定する方法を記載。OACは現在推奨されている設定なので、S3+CloudFrontでサイト公開する際のスタンダードな方法です。

              EC2

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

              EC2インスタンス起動設定

              OS:AmazonLinux2
              スペック:t2.micro(もっと性能が良いインスタンスタイプを選択しても大丈夫です)
              ロール:以下に記載のS3にアクセス可能なロールを割り当てる。

              
              // 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!!";
              • 動作確認

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

              ブラウザで動作確認する

              http://ドメイン/index.phpアクセスする
              →ブラウザに「test!!」と表示されればOK!

               

              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設定画面で以下の設定を行う

              StaticPress設定

              静的サイト URLCloud Frontのドメインを入力
              出力先ディレクトリ
              (ドキュメントルート):「/wordpress_home/」を入力
              S3 Bucket
              :作成したバケットを選択
              AWS Access Key:EC2のロールを使用するため、未入力とする
              AWS Secret Key:EC2のロールを使用するため、未入力とする
              AWS Region:「AP_NORTHEAST_1(東京リージョン)」を選択

               

              次に以下のコマンドで静的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が正常に動作しない場合の対処方法を記載します。

              StaticPressが動作しない時の対処法

              EC2の出力先ディレクトリにコンテンツが生成されない
              S3にコンテンツがコピーされない
              固定記事などが表示されない(403エラーとなる)ケースがある
              画像メディアのみS3にコピーされない
              ドメインが静的サイトURLに置き換わらない
              サイトマップが出力されない

              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の関数を使用する方法を記載しています

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

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

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

              • 以下の記事をご参照ください
              StaticPressでドメインが静的サイト URLに置換されない時の対処法(WordPress)
              WordPressのプラグインStaticPressを使用しているが、 StaticPressで生成された静的ファイルのリンクURLが、StaticPressで設定した「静的サイト URL」に置き換わらないことがありますが、これの対処法を記載しています。対処法はStaticPressのソース修正となります。

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

              • 以下の記事をご参照ください
              さゆフィクション | aws wordpress などなどゆるーく書いてます

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

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

              オススメの追加設定

              WordPressの置いてあるEC2サーバでBasic認証をかける
              不要なページの出力を止める
              CloudFrontのキャッシュを簡単に消せるようにする

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

              • 以下の記事をご参照ください
              WordPressのプラグインStaticPressでBasic認証を使う
              StaticPress利用時のBasic認証のかけ方について記載。StaticPressで静的HTMLを生成して、StaticPress S3で静的ファイルをS3に転送して、配信する場合、Basic認証をかけることをお勧めします。Basic認証をかけるにはStaticPressのソース修正も必要となります

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

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

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

              • 以下の記事をご参照ください
              StaticPress S3と共存できるWordPressプラグインClear CloudFront Cacheを公開!
              StaticPress S3と共存できるWordPressプラグイン「Clear CloudFront Cache」を公開! WordPressコンテンツをCloudFront経由で配信している場合に使えるプラグイン。公開したプラグイン「Clear CloudFront Cache」はWP管理画面からインストール可能
              ]]>
              https://it.kensan.net/staticpresss3.html/feed 0