LaravelのECS運用のベストプラクティスを考えてみた

 

kotamat

誰

  • kotamat
  • ROXX CTO
  • サーバー、インフラ寄り
  •  🚴‍♂️

だけkotamats

最近はあんまり主催できてない…

手伝ってくれる人いたらぜひ！

転職にまつわるサービスを展開

エージェント

転職者

求人企業

話す内容

  • ベースとなるコンテナの使い分け
  • ロギング
  • ECSならではのところ
  • GitHub ActionsでCDしてみる

ベースとなるコンテナの使い分け

Laravelの主たる機能

  • WebAPI
  • キューワーカー
  • スケジュールジョブ
  • コンソール(artisanコマンド)

WebAPI

いわゆる通常の構成

  • Nginxがリバースプロキシして
  • PHP-FPMを見に行く

ここでコンテナ1プロセスポリシー

  • 基本的に一つのコンテナには一つのプロセスだけを動かす
  • そうしないと、自前でプロセス管理をしなければならない。

Nginx,PHP-FPMそれぞれのコンテナを生成する

  • Laravelは/publicディレクトリに外だしするファイルを置いているため
  • Nginx側では/publicディレクトリのみをCOPY
  • FPM側にはルートディレクトリそのままを突っ込む

sockでつなぐかポートでつなぐか

  • PHP-FPMとNginxはphpfpm.sockで繋ぐ方法とポートで繋ぐ方法がある。
  • ECSなどはボリュームマウントがあるので、sockでつなげなくもないが、コンテナの死活を考えるとポートのほうが安全

キューワーカー

Supervisorで動かすのもいいが…

  • コンテナ1プロセス管理の原則からは外れる
  • プロセスが死んだらちゃんとコンテナとして死んだ扱いをしたほうが、他の監視ツールとの相性もいい

LaravelのベースとなるDockerfileのentrypointを柔軟にする

  • CMDの指定がない場合→PHP-FPMを起動
  • CMDにartisanがある場合→artisanを起動
  • そうすることで、一つのイメージでどちらの起動方法も使える万能イメージが作れる

entrypoint.sh

#!/bin/bash

if [[ "$1" == *artisan* ]]; then
    set -- php "$@"
else
    set -- php-fpm "$@"
fi

exec "$@"

Dockerfile

# composer installとか
# apt-getとか

RUN chmod +x /app/docker/php-fpm/entrypoint.sh

ENTRYPOINT ["/app/docker/php-fpm/entrypoint.sh"]

docker-compose.ymlでは

version: '3.1'

services:
  php-fpm:
    build:
      context: .
      dockerfile: docker/php-fpm/Dockerfile
    env_file:
      - .env
  worker:
    build:
      context: .
      dockerfile: docker/php-fpm/Dockerfile
    env_file:
      - .env
    command:
      - "artisan"
      - "queue:work"
      - "sqs"
      - "--sleep=3"
      - "--tries=3"

タスク定義（ECS）では

resource "aws_ecs_task_definition" "main" {
  container_definitions = jsonencode(
    [
      // worker
      {
        image     = "baseimage:latest"
        essential = false
        name      = "laravel-worker"
        command = [
          "artisan",
          "queue:work",
          "sqs",
          "--sleep=3",
          "--tries=3"
        ],
      }, 
      // api
      {
        image     = "baseimage:latest"
        essential = true
        name      = "laravel-api"
      } 
    ]
  )
}

こんな感じで

  • サイドカーチックにworkerを動かしてみてもいいし
  • 別Service化して別途起動するコンテナ数を制御してもいい

スケジュールジョブ

ECSを使っているなら標準のタスクスケジューリングが良い

  • CloudWatchによる定期実行
  • 設定はcron形式なので、Laravel公式の通りに設定できる
  • 前に紹介した万能Dockerfileを使えばimage使いまわしでタスク定義を作れる

多重実行防止のために

  • この方法だと前のタスクが終了しているかどうかに関わらず次のタスクが実行されてしまう。
  • 多重実行を防止したいのであれば、Laravelのキャッシュをfile以外の中央集権ストレージに移した上でwithoutOverlappingを設定する

コンソール(artisan)

コンテナ内部でどうやって実行するのか

  • イメージの作り方は前述の通り
  • とはいえコンテナに入れなければタスクは実行できない
  • 実行したいartisanコマンドごとにタスク定義作るのも気が引ける

システムマネージャーのハイブリッドアクティベーションを使う

  • 従来はオンプレサーバーにもSSMできるようにする機能
    • SSM: sshポートが空いてなくてもsshっぽいことができる。AWSのリソース権限でのハンドリングができるので権限管理がらく
  • Fargateなどは通常のSSMが使えないので、こちらで代替する

1. アクティベーション生成ロールを作成

resource "aws_iam_role" "activation_create" {
  name = "${var.service_name}-for-create-activation"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "ssm.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      }
    ]
  })
}
resource "aws_iam_role_policy_attachment" "activation_create" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
  role       = aws_iam_role.activation_create.name
}

2. 実行ロールに1のロールへのパスをつける

resource "aws_iam_policy" "activate_code" {
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "iam:PassRole",
          "ssm:CreateActivation"
        ],
        Resource = [
          aws_iam_role.activation_create.arn
        ]
      }
    ]
  })
}
resource "aws_iam_role_policy_attachment" "use_activation" {
  policy_arn = aws_iam_policy.activate_code.arn
  role       = aws_iam_role.task_role_with_ssm.name
}

3. Laravelコンテナのentrypointで登録

if [ "$SSM_ACTIVATE" = "true" ]; then
  # task実行の場合なので、厳密にエラーを補足する
  set -e
  ACTIVATE_PARAMETERS=$(aws ssm create-activation \
    --default-instance-name "$APP_NAME-ssm" \
    --description "$APP_NAME-ssm" \
    --iam-role "$APP_NAME-for-create-activation" \
    --registration-limit 5)

  export ACTIVATE_CODE=$(echo $ACTIVATE_PARAMETERS | jq -r .ActivationCode)
  export ACTIVATE_ID=$(echo $ACTIVATE_PARAMETERS | jq -r .ActivationId)
  amazon-ssm-agent -register -code "${ACTIVATE_CODE}" \
    -id "${ACTIVATE_ID}" -region "${AWS_DEFAULT_REGION}" -y
  amazon-ssm-agent
fi

注意点

  • 当然、アプリケーションの環境変数が全て見えてしまうので、アクセスできる人は最小限にする必要がある。
  • 基本定期的に発生するものであればタスク定義化しておいて、中には入れるようにしないほうが良さそう。

ロギング

laravel.logは使わない

  • コンテナに状態をもたせてもあまりうれしくない
  • laravel.logをfluentdとかで外出ししてるならまだしも、コンテナ内部に入って確認するようなフローは前述の通りあまり望ましくない。
  • ファイル容量オーバーのようなことは避けたい。

Docker log = 標準出力

  • 標準では標準エラー、標準出力を外部のログシステムに転送する機能が備わっている
  • ECSではCloudWatch Logsに転送してくれる

logging.php

<?php

return [
    'channels' => [
        'ecs' => [
            'driver' => 'stack',
            'channels' => ['stderr', 'stdout'],
        ],
        'stdout' => [
            'driver' => 'monolog',
            'level' => 'info',
            'handler' => StreamHandler::class,
            'formatter' => env('LOG_STDOUT_FORMATTER'),
            'formatter_with' => [
                'dateFormat' => '%Y-%m-%d %H:%M:%S'
            ],
            'with' => [
                'stream' => 'php://stdout',
            ],
        ],
        'stderr' => [
            'driver' => 'monolog',
            'level' => 'critical',
            'handler' => StreamHandler::class,
            'formatter' => env('LOG_STDERR_FORMATTER'),
            'formatter_with' => [
                'dateFormat' => '%Y-%m-%d %H:%M:%S'
            ],
            'with' => [
                'stream' => 'php://stderr',
            ],
        ],

ECS側で複数行に渡る一つのログを一つにまとめる

[
  {
    // ... 諸々のコンテナの設定
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {
        "awslogs-group": "${awslog_group}",
        "awslogs-region": "${region}",
        "awslogs-datetime-format": "%Y-%m-%d %H:%M:%S",
        "awslogs-stream-prefix": "ecs"
      }
   }
  },
]

注意点

  • PHP-FPMから直接標準出力にストリームすると、PHP-FPMの設定によっては出力内容にプロセスの表示も出てしまう。
  • PHP7.3以降であれば `decorate_workers_output` をnoにしてあげれば通常のlaravel.logのような出力にしてくれる

デプロイ(GitHub Actions)

ベースのworkflow.yml

jobs:
  job:
    runs-on: ubuntu-latest
    steps:
    # ...
      - name: Change Task Definition
        id: render-td
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ steps.fetch-td.outputs.task-definition }}
          container-name: my-container-name
          image: ${{ steps.built-image.outputs.image }}

      - name: Deploy to Amazon ECS service
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.render-td.outputs.task-definition }}
          service: ecs-service
          cluster: ecs-cluster

worker入れたい場合はチェインさせる

jobs:
  job:
    runs-on: ubuntu-latest
    steps:
    # ...
      - name: Change Task Definition for api
        id: render-td-api
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ steps.fetch-td.outputs.task-definition }}
          container-name: my-container-name
          image: ${{ steps.built-image.outputs.image }}

      - name: Change Task Definition for worker
        id: render-td-worker
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ steps.render-td-api.outputs.task-definition }}
          container-name: my-container-name
          image: ${{ steps.built-image.outputs.image }}

      - name: Deploy to Amazon ECS service
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.render-td-worker.outputs.task-definition }}
          service: ecs-service
          cluster: ecs-cluster

worker入れたい場合はチェインさせる

jobs:
  job:
    runs-on: ubuntu-latest
    steps:
    # ...
      - name: Change Task Definition for api
        id: render-td-api
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ steps.fetch-td.outputs.task-definition }}
          container-name: my-container-name
          image: ${{ steps.built-image.outputs.image }}

      - name: Change Task Definition for worker
        id: render-td-worker
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ steps.render-td-api.outputs.task-definition }}
          container-name: my-container-name
          image: ${{ steps.built-image.outputs.image }}

      - name: Deploy to Amazon ECS service
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.render-td-worker.outputs.task-definition }}
          service: ecs-service
          cluster: ecs-cluster

GA公式でも下記でデプロイステータスは見れるが…

jobs:
  job:
    runs-on: ubuntu-latest
    steps:
    # ...
      - name: Deploy to Amazon ECS service
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.render-td-worker.outputs.task-definition }}
          service: ecs-service
          cluster: ecs-cluster
          wait-for-service-stability: true #←これ！

GAは従量課金なのでデプロイに時間かかると辛い

// 内部実装
const waitForService = core.getInput('wait-for-service-stability', { required: false });

// Wait for service stability
  if (waitForService && waitForService.toLowerCase() === 'true') {
    core.debug(`Waiting for the service to become stable. 
Will wait for ${waitForMinutes} minutes`);
    const maxAttempts = (waitForMinutes * 60) /
          WAIT_DEFAULT_DELAY_SEC;
    await ecs.waitFor('servicesStable', {
      services: [service],
      cluster: clusterName,
      $waiter: {
        delay: WAIT_DEFAULT_DELAY_SEC,
        maxAttempts: maxAttempts
      }
    }).promise();

ECSのデプロイはCloudWatchEventで補足できるのでSNSに流して通知可能

resource "aws_cloudwatch_event_rule" "main" {
  name = local.base_name
  event_pattern = jsonencode({
    "source" : [
      "aws.ecs"
    ],
    "detail-type" : [
      "ECS Task State Change"
    ],
    "detail" : {
      "clusterArn" : [
        var.cluster_arn
      ]
    }
  })
}

まとめ

  • 本番運用におけるプラクティスを紹介
  • 表面的な紹介が多いと思うので、わからないところは聞いてもらえると
  • 自動でのマイグレーション周りは課題なので、詳しい方教えて下さい。

文章でみたい方はこちら

https://kotamat.com/post/laravel-on-ecs/

 

環境変数の管理、マイグレーションとかも言及してます

LaravelのECS運用のベストプラクティスを考えてみた

By Kota Matsumoto

Made with Slides.com

LaravelのECS運用のベストプラクティスを考えてみた

  • 5,519

More from Kota Matsumoto

  • Nuxt3とLaravel、API generatorで型堅牢なアプリをローコストで作る
    Kota Matsumoto
    2373
  • Optional Chaining + Laravel FormRequestでバリデメッセージを 表示する
    Kota Matsumoto
    3500