• マネージドプレフィックスリスト(managed prefix list)によりアクセスを絞る
• カスタム HTTP ヘッダーによりアクセスを絞る

上記はよく知られた方法かと思いますので、詳細は割愛します。

本記事で記載したいことは、上記2つを併用した方が安心だよということです。

まずは、用語の説明からです。

用語の説明

マネージドプレフィックスリスト(managed prefix list)とは

AWS Managed Prefix Listは、AWSによって管理されるIPアドレスのプレフィックスリストです。特定のAWSサービス（例えばCloudFrontやAmazon S3など）のIPアドレス範囲を含んでおり、ネットワーク設定やセキュリティ設定を簡素化するために使用されます。

本記事では、「マネージドプレフィックスリスト＝CloudFrontのIP」として記載します。

カスタム HTTP ヘッダー

カスタム HTTP ヘッダーは、HTTP リクエストやレスポンスに含まれるユーザー定義のヘッダーであり、標準の HTTP ヘッダーではカバーされない追加の情報を送信するために使用されるものです。

なぜ併用した方がいいのか

ALB(ロードバランサー)でCloudFront経由のアクセスに絞る際に、マネージドプレフィックスリストとカスタム HTTP ヘッダーを併用する場合、以下のようになります。

• マネージドプレフィックスリスト(managed prefix list)によるアクセス制限
  • IP制限により、CloudFront経由のアクセスを絞る
    • CloudFront経由であれば、別アカウントのものでも許可してしまう
• カスタム HTTP ヘッダーによるアクセス制限
  • カスタムHTTPヘッダーにより、CloudFront経由にアクセスを絞る
    • 自分が作成したCloudFrontのみにアクセスを絞ることができる
• →マネージドプレフィックスリストとカスタム HTTP ヘッダーを併用することで、自分が作成したCloudFrontのみにアクセスを絞ることができる

マネージドプレフィックスリスト(managed prefix list)だけでは、CloudFrontのIP制限のため、CloudFrontからの接続であれば、別アカウントのものでも許可してしまいます。

そのため、カスタム HTTP ヘッダーも併用が必要となります。カスタム HTTP ヘッダーにより、自分が作成したCloudFrontのみにアクセスを絞ることができます。

2段階で網をかけておいた方が安心ですね。

カスタム HTTP ヘッダーとマネージドプレフィックスリストの設定方法

公式記事に詳しく書いてあるので、以下の公式の記事をご参照ください。

Application Load Balancer へのアクセスを制限する - Amazon CloudFront

Amazon CloudFront でカスタムオリジンヘッダーを使用して、ユーザー（閲覧者）が Application Load Balancer に直接アクセスできないようにします。

docs.aws.amazon.com

まとめ

ALB(ロードバランサー)でCloudFront経由のアクセスに絞るときは、カスタム HTTP ヘッダーとマネージドプレフィックスリストを併用するのが良いです。

マネージドプレフィックスリスト単体でも、https(443)の通信にしているから問題とならないケースもあると思いますが、基本的にはカスタム HTTP ヘッダーとマネージドプレフィックスリストを併用した方が安心かと思います。

以下の記事に詳細記載されています。

Amazon API Gateway integration timeout limit increase beyond 29 seconds - AWS

Discover more about what's new at AWS with Amazon API Gateway integration timeout limit increase beyond 29 seconds

aws.amazon.com

以下要約です。

• タイムアウト延長: 以前の29秒からそれ以上に設定可能。
• 対象API: リージョナルREST APIおよびプライベートREST API。
• 使用例: Generative AIなど、長時間処理を必要とするワークロードに対応。
• 追加費用: 追加費用なしで利用可能。
• 制限: アカウントレベルでクォータ制限の調整が必要。

要するに、統合タイムアウトは29秒のままだけど、30秒以上に引き上げは可能になったよということです。

Service Quotasを確認すると以下の通り、統合タイムアウトが、アカウントレベルでの引き上げリクエスト可能になっています。

しかし、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でのバッチ実行も安心かなと思います！

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

AWS でバッチ処理・定期実行する4つの方法(EC2,EventBridge,SQS,ECS,Lambda)

AWS上でバッチ処理を行う場合に、 「どのサービスが選択肢として考えられるか」 「どのサービスを選択すればいいのか」 についてです。 バッチの起動方式として「Cron」 「ECS Task Scheduler」 「キュー」 「Web API」をあげて、特徴等を踏まえて、どのような場合にどのような選択をすればいいか記載。

it.kensan.net

2023.03.29

Lambda関数URLで、HTTPリクエストを介して直接Lambda関数を呼び出すことが可能になりました。

これまで、Lambda関数をAPI経由で実行するためにはAPI Gatewayを使用する必要がありました。しかし、Lambda関数URLの登場により、API Gatewayを使わずにLambda関数を直接実行できるようになりました。

Lambda関数URLを使うと、API Gatewayのセットアップや管理の手間を省けます。また、API Gatewayが引き起こす遅延やコストも削減できます。

ただし、API Gatewayには多くの利点もあります。

この記事では、Lambda関数URLの利用方法とその利点、注意点について詳しく解説します。Lambda関数とAPI Gatewayのどちらを選ぶか迷っている方は、ぜひ参考にしてください。

Lambda関数URLとは

Lambda関数URLは、Lambdaで提供される機能の一つで、直接HTTPリクエストを受け取ることができるエンドポイントURLをLambda関数に対して自動的に生成するものです。

この機能により、API Gatewayなどの中間サービスを使用せずに、簡単にLambda関数をウェブリクエストに対応させることができます。

主な特徴

1. 直接アクセス可能: Lambda関数に対して直接HTTPリクエストを送信可能なURLが生成されます。
2. 簡易な設定: API Gatewayを設定する必要がなく、簡単にHTTPエンドポイントを作成できます。
3. セキュリティ設定: IAM（Identity and Access Management）ポリシーを使用して、アクセス制御を行うことができます。

どのようにLambdaのAPIを構築すればいいか

LambdaのAPIは

• Lambda関数URLを使用
• API Gatewayを使用してLambdaを実行

などいろいろな構築方法があります。実際に構築方法を5つ紹介し、それぞれ特徴やメリットとデメリットについて記載していきます。

5つのAPI実行方式の詳細

API Gateway×Lambda

使用するAWSサービス

API Gateway

Lambda

概要

最もオーソドックスな方式

API Gatewayの利点を活かせる

API Gatewayのタイムアウトの上限は29 秒(上限緩和申請可能)なので、29秒以上の処理はエラーとなる

2024.6.4に、タイムアウトの上限は、引き上げ可能となりました。詳細は以下の記事をご参照ください。

AWS API Gatewayの統合タイムアウト制限の29秒が、30秒以上に引き上げ可能になった

Amazon API Gatewayの統合タイムアウト制限を従来の29秒から延長できるようになりました。統合タイムアウトは29秒のままだけど、引き上げは可能になったよということです。

it.kensan.net

2024.06.05

メリット

最もオーソドックスな方式のため、実装難易度が低い

API Gatewayの利点を活かせる

デメリット

API Gatewayのタイムアウトの上限は29 秒(上限緩和申請可能)なので、29秒以上の処理はエラーとなる

API Gatewayのコストがかかる

API Gateway×Step Functions×Lambda

使用するAWSサービス

API Gateway

Step Functions

Lambda

概要

API Gatewayの利点を活かせる

API Gatewayのタイムアウトの上限の29 秒(上限緩和申請可能)を超えた処理を実行できる

メリット

API Gatewayの利点を活かせる

API Gatewayのタイムアウトの上限の29 秒(上限緩和申請可能)を超えた処理を実行できる。基本的にLambdaのタイムアウトの上限15分までは実行可能。

Step Functionsの機能を活かせる。Lambdaを複数呼び出したり

デメリット

API Gateway/Step Funcstionsのコストがかかる

Step Funcstionsが入る分、実装難易度が高い

Lambda関数URL

使用するAWSサービス

Lambda

概要

Lambda関数URLのエンドポイントURLにアクセスすることで簡単にLambdaを実行できる

簡単にLambda実行できるので、セキュリティ面が懸念

タイムアウトはLambdaのタイムアウトの15分

メリット

実装難易度が低い

API Gatewayのタイムアウトの上限の29 秒(上限緩和申請可能)を超えた処理を実行できる。Lambdaのタイムアウトの上限15分までは実行可能。

デメリット

セキュリティ面が懸念。独自に対策する必要がある

CloudFront×Lambda関数URL

使用するAWSサービス

CloudFront

Lambda

概要

CloudfrontのOAC を利用して Lambda関数URLを実行する想定

Lambda関数URLの実行をCloudFront経由のみに絞れる(CloudFront経由以外はエラーにできる)

CloudFrontのWAF設定等を活かせる

タイムアウトはCloudFrontのタイムアウトの60秒(上限緩和申請可能)

メリット

実装難易度が低い

CloudFrontのWAF設定等を活かせる

デメリット

タイムアウトはCloudFrontのタイムアウトの60秒(上限緩和申請可能)

構築方法参照URL

CloudfrontのOAC を利用した Lambdaの 関数URL実行を試してみた | DevelopersIO

Cloudfront OAC が Lambda関数URLをサポート。 オリジンのLambda関数URLが第三者により直接実行される事を簡単に回避できるようになりました。

dev.classmethod.jp

Lambda関数URL(署名付きURL化)

使用するAWSサービス

Lambda

概要

S3の署名付きURLと同じことをLambdaの関数URLでやるイメージ

署名付きURLの場合のみLambdaを実行可能

タイムアウトはLambdaのタイムアウトの15分

メリット

実装難易度が低い

比較的に安全にLambdaを実行できる。(署名付きURLを持っている場合のみLambdaを実行できる)

タイムアウトはLambdaのタイムアウトの15分

デメリット

署名付きURLを発行する仕組みが別途必要

構築方法参照URL

実はLambdaの関数URLは署名付きURL化できるよ、29秒の壁も越えられるよ、という話 - Qiita

この記事を2行でS3の署名付きURLと同じことが、Lambdaの関数URLにもできますLambdaの署名付きURLを使えば、APIGatewayの29秒タイムアウトを超えてLambdaを実行でき…

qiita.com

どのサービスを使えばよいか

29秒以内に処理が終わる場合

以下のいずれかを選択するのが良いかと思われます。

• API Gateway×Lambda
• CloudFront×Lambda関数URL

API GateWayの機能を活かしたい場合は「API Gateway×Lambda」を選択しましょ

30秒〜60秒以内に処理が終わる場合

実装難易度とセキュリティ面から「CloudFront×Lambda関数URL」が良いと思われます。

1分〜15分処理に時間がかかる場合

以下のいずれかを選択するのが良いかと思われます。

• API Gateway×Step Functions×Lambda
• Lambda関数URL(署名付きURL化)

API GateWayの機能を活かしたいか、Step Functionsの実装コストをどう捉えるかを検討して、上記の中から選択するのが良いと思います。

テスト用にとにかく簡単に動かしたい

実装難易度の面から「Lambda関数URL」が良いと思われます。

以下の順で進めていきます。今回はとりあえずFargate上で動くことをゴールにしますので、MySQLは使いません。

1. ローカルでRails7.1を立ち上げる
2. ECR(Amazon Elastic Container Registry)にRailsイメージをpushする
3. ECRのイメージを使って、ECS(Amazon Elastic Container Service)-Fagateにデプロイ

まずは、ローカルでRails7.1を起動していきます。

ローカルでRialsを動かしてみる

アプリケーションの作成

以下のコマンドでアプリケーションを作成して、作成したアプリケーションのフォルダに移動します。

rails new test_app

cd test_app/

まずはDockerfileを修正します。

Dockerfileの修正

Rails newで作成されたDockerfileを修正します。

vi Dockerfile

以下の2点変更します。

<変更①>「ENV RAILS_ENV="production"」をコメントアウトして、「ENV RAILS_ENV=$ENVIROMENTS」を追記します。
#ENV RAILS_ENV="production" \
ENV RAILS_ENV=$ENVIROMENTS \
<変更②>
5行目のFORMの後に以下を追加
ARG ENVIROMENTS

上記変更を加えることで、Railsを以下の指定をして、起動できるようになります。

• production
• development
• tesst

コンテナを立ち上げて動作確認

以下のコマンドでビルドします。

docker build . -t test_app --build-arg ENVIROMENTS='development'

以下のコマンドでコンテナを起動します。

docker run -it -p 3000:3000 --env RAILS_MASTER_KEY=`cat config/master.key` test_app bin/rails server -b 0.0.0.0

http://localhost:3000/にアクセスし、以下の画面が表示されれば、動作確認OKー

ECR(Amazon Elastic Container Registry)にRailsイメージをpush

以下のコマンドで、AWSの接続設定をしておきます。

aws configure

次にECRログインします。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com

以下のコマンドでリポジトリを作成します。

aws ecr create-repository \
        --repository-name rails \
        --image-scanning-configuration scanOnPush=true \
        --region ap-northeast-1 

Railsアプリのタグ作成します

docker tag test_app:latest {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails:latest

Railsアプリのpushです

docker push {AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails:latest

 

次に、Fagateにデプロイします！

ECS(Amazon Elastic Container Service)-Fagateにデプロイ

クラスターの作成

以下の設定で作成します。指定箇所以外は任意の値で大丈夫です。

• インフラストラクチャ：AWS Fargate (サーバーレス)

タスク定義の作成

以下の設定で作成します。指定箇所以外は任意の値で大丈夫です。

• インフラストラクチャの要件
  • 起動タイプ：AWS Fargate
  • オペレーティングシステム/アーキテクチャ：自分のPCと一致するもの(基本はx86_64でOK、M1/M2 MacはARM64を選択)
    • この設定に誤りがあると「exec /usr/local/bin/start-container: exec format error」エラーになります。
  • タスクサイズ
    • CPU：.5 vCPU
    • メモリ：1GB
• コンテナ – 1
  • 名前：app
  • イメージURI：{AWSアカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/rails:latest
  • コンテナポート:3000
  • アプリケーションプロトコル:HTTP
  • 環境変数
    • キー：RAILS_MASTER_KEY
    • 値：「config/master.key」の値を直接入力
      • 「cat config/master.key」を入力すると「ArgumentError: key must be 16 bytes (ArgumentError)」エラーになる
  • Docker設定
    • コマンドに以下を設定
      • /rails/bin/rails,server,-b,0.0.0.0

タスク起動

作成したクラスターのタスクタブにある「新しいタスクの実行」を押下

• コンピューティング設定：起動タイプ
• デプロイ設定
  • ファミリー:先ほど作成したタスクを設定
  • リビジョン：最新
• ネットワーキング
  • セキュリティグループ：ポート3000の許可を追加

動作確認

作成したクラスターのタスクタブの任意のタスクの詳細を開きます。

パブリックIPが表示されるので、http://パブリックIP:3000でブラウザからアクセスします。

以下の画面が表示されればOKです。

なるべくお金をかけずに、かつ、高速な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〜〜

LocalStackコンテナを自分のPCで立ち上げ、AWS CLIやプログラムの向き先をLocalStackコンテナにすることで、エミュレートされたAWS(実際のAWSではない、自分用のAWSエミュレート環境)を使った動作確認が可能です。

LocalStackのインストール

以下のコマンドで、GitHubからLocalStack環境一式をダウンロードします。

git clone https://github.com/localstack/localstack.git
cd localstack

以下のコマンドで、LocalStackコンテナを立ち上げます。

docker-compose up -d

以下のコマンドで、使用できるAWSサービスの一覧取得してみます。

curl -s "http://127.0.0.1:4566/_localstack/health" | jq .

<取得した使用できるサービスの一覧>

{
  "services": {
    "acm": "available",
    "apigateway": "available",
    "cloudformation": "available",
    "cloudwatch": "available",
    "config": "available",
    "dynamodb": "available",
    "dynamodbstreams": "available",
    "ec2": "available",
    "es": "available",
    "events": "available",
    "firehose": "available",
    "iam": "available",
    "kinesis": "available",
    "kms": "available",
    "lambda": "available",
    "logs": "available",
    "opensearch": "available",
    "redshift": "available",
    "resource-groups": "available",
    "resourcegroupstaggingapi": "available",
    "route53": "available",
    "route53resolver": "available",
    "s3": "running",
    "s3control": "available",
    "scheduler": "available",
    "secretsmanager": "available",
    "ses": "available",
    "sns": "available",
    "sqs": "available",
    "ssm": "available",
    "stepfunctions": "available",
    "sts": "available",
    "support": "available",
    "swf": "available",
    "transcribe": "available"
  },
  "edition": "community",
  "version": "3.4.1.dev"
}

いっぱいある….!素晴らしー

AWS CLIでLocalStackを使ってみる

AWS CLIのインストール

PCがmacの場合

以下のコマンドでAWS CLIをインストールします。

brew  install awscli

PCがWindowsの場合

以下URLからMSI インストーラをダウンロードして、AWS CLIをインストールします。

https://s3.amazonaws.com/aws-cli/AWSCLISetup.exe

s3.amazonaws.com

動作確認

以下のコマンドでAWS CLIがインストールできているか確認します。

aws --version

以下のような出力がされればOKです。

aws-cli/2.15.48 Python/3.11.9 Darwin/23.4.0 source/arm64 prompt/off

AWS CLIの設定

以下のように設定します。

aws configure --profile localstack
AWS Access Key ID [None]: aaa
AWS Secret Access Key [None]: aaa
Default region name [None]: ap-northeast-1
Default output format [None]: 

Access KeyとSecret Access keyは適当な値でOKです。

regionは「ap-northeast-1」を指定、formatは指定なしでOK

S3バケットを作ってみる

以下のコマンドで「test-bucket」という名前のS3バケットを作成可能です。

aws --endpoint-url=http://localhost:4566 --profile localstack s3 mb s3://test-bucket

以下のような結果が出力され、バケットが作成されたことがわかります。

make_bucket: test-bucket

AWS CLIの使い方

「aws –endpoint-url=http://localhost:4566 –profile localstack」の部分は固定で、その後ろに実行したいAWSコマンドを記載します。

aws --endpoint-url=http://localhost:4566 --profile localstack {実行したいAWS CLIコマンド}

プログラムからLocalStackを使ってみる

プログラムからLocalStackを使ってみます。

プログラム言語はPHPを使い、S3にファイルアップロードしてみます。

PHPでLocalStackを使ってみる

まず、aws-sdk-phpをインストールします。

composer require aws/aws-sdk-php

「composer: command not found」と表示された場合、composerのインストールが必要なので、composerインストール後に、上記コマンドを実行します。

macの場合、以下のコマンドでcomposerをインストールできます。

brew install composer

次にPHPファイルを作成します。S3にファイルをアップロードするプログラムです。

vi test.php

<ファイルの中身>

<?php require_once 'vendor/autoload.php'; 
use Aws\S3\S3Client; 
$config = [ 'credentials' => [
        'key' => 'hoge',
        'secret' => 'fuga',
    ],
    'region' => 'ap-northeast-1',
    'endpoint' => 'http://localhost:4566',
    'use_path_style_endpoint' => true,
];

$s3 = new S3Client($config);

// アップロード
$result = $s3->putObject([
    'Bucket' => 'test-bucket',  // バケット名
    'Key' => 'test.txt',      // s3のアップロード先
    'Body' => 'hello world!!', // ファイルの内容
]);

作成したPHPを以下のコマンドで実行します。

php test.php

ファイルがアップロードされているか以下のAWS CLIで確認します。

aws --endpoint-url=http://localhost:4566 --profile localstack s3 ls s3://test-bucket

2024-05-11 17:13:48         13 test.txt

想定通り「test.txt」がアップロードされていることが確認できます。

まとめ

LocalStackを使ってローカル開発環境で AWS 環境をエミュレートする方法を記載しました。

結構簡単に、AWS CLIやプログラムからLocalStackを使用できることがわかりましたー

EC2立ち上げ

EC2を立ち上げます。

• インスタンスタイプは適切に選択
• AMIでAmazonLinux2023を選択

EC2に接続

以下のいずれかの方法で接続します。

• EC2 Instance Connect
• セッションマネージャ
• SSHクライアント

接続方法が分からない場合は、以下の記事をご参照ください。

EC2への4つの接続方法について(Instance Connect/セッションマネージャー/SSH/シリアルコンソール)

「EC2に入りたいけど入れない」 「EC2に入る方法がいくつかあるけど、どれで入るのが良いの？どんな違いがあるの？」という方向けの記事です。 EC2の接続方法は「EC2 Instance Connect」「セッションマネージャー」「SSHクライアント」「EC2 シリアルコンソール」 の4つの接続方法があります。

it.kensan.net

2023.04.27

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

以下のコマンドでMySQLを起動します。

sudo systemctl enable mysqld.service

sudo systemctl start mysqld.service

MySQLに接続するための初期パスワードを確認します

sudo less /var/log/mysqld.log

MySQLに接続して、パスワード更新します。

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

まとめ

以上で完成です。MySQLサーバはRDSを使うケースが多いと思いますが、EC2上にMySQLサーバを立ち上げる場合は上記コマンドで簡単にできます！

なるべくお金をかけずに、かつ、高速な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/{取得したいメタデータを指定}