PHPなプロダクトをAmazon ECSで開発運用してる話

Transcript

1. PHPなプロダクトをAmazon ECS で開発運用してる話 PHPカンファレンス北海道出張版(仮) PHPオフ会＠2017/11/25 @taiko19xx / 木村 俊彦

2. Amazon ECS使ってみた PHPカンファレンス北海道出張版(仮) PHPオフ会＠2017/11/25 @taiko19xx / 木村 俊彦

3. こんにちは • PHPを使ったプロダクトをDockerとAmazon ECSで開発運用して いますので得られた知見を共有します • DockerとECSの話がメインです • PHPカンファレンスとは？

4. もくじ • ECS(EC2 Container Service)とは • 構成図 • 何故ECSか •

   Docker/ECSで… • 良かった所 • 苦労した所 • 全体のまとめ

5. ECS(EC2 Container Service)とは • EC2上のDockerコンテナを管理できる • いわゆるコンテナオーケストレーションのサービス • 無料 •

   コンソール/AWS CLI/ECS CLI/AWS SDKから操作可能 • マネージドなコンテナレジストリも利用可能 • ECR(EC2 Container Registry) • ログインがめんどくさい • $0.1/GB/月 + 転送料

6. 構成図

7. 何故ECSか • AWS上に構築するという方針は決まっていた • Dockerで構築するのはどうかという話が出た • 管理をどうするか考えていた所、ECS/ECRを見つけた • 確認や検証の結果、採用する事に

8. Docker/ECSで良かった所

9. ローカルとリモートで”ほぼ”同様の環境が使える • ローカルはdocker-composeで • リモートもそれに近いように • イメージはCodeBuildでdocker-composeを使ってビルド • 環境はCloudFormationで同等の環境を構築

10. ローカルとリモートで”ほぼ”同様の環境が使える • 100% docker-composeを使い回す事はできなかった • ECS CLIを利用すれば可能 • CloudFormationにおけるECSのServiceの記述はdocker- composeに比較的近い

    • 0から書き直しにはならない • 両方ともYAML

11. 展開しやすい • Dockerベースなので、誰でも環境を起動できるように • リポジトリをcloneしたら環境構築して起動するだけ • コンテナ起動時にcomposer installするように仕込んでいた • VMやVagrantと違い、重いイメージファイルを配布せずに済む

    • ただし、以下の面で幸運だったという可能性も • 利用者が全員mac • フロント側も含めて全員コマンドの操作に慣れていた

12. 開発環境構築にかかる時間が少ない • 基本的にはdocker-compose.ymlと必要なDockerfile書いて終わり • ただし… • 記述に慣れていれば、最低限の立ち上げは早そう • あくまで”開発環境” •

    AWS側はCloudFormationの記述やら各種設定が大変だった

13. Docker/ECSで苦労した所

14. 結局Dockerfileを追加変更する事になる • PHPのコンテナ(php:7-fpm-alpine)はそのまま使う予定だったが Dockerfileでカスタムした • タイムゾーンの変更 • メモリやファイルアップロード周りの設定変更 • Composerの追加

    • 拡張の追加 • docker-php-ext-installをRUNする • nginxは最初に1度調整したのみ

15. 変わった事をしようとすると一工夫がいる • cron • 各コンテナにはcrondが入ってるが、デフォルトで起動しない • 各サービスやデーモンと同時に起動する必要がある • コンテナ起動時に実行するスクリプトを用意し、その中に記 述

    • cron専用コンテナを使わずにPHPコンテナ内でスクリプトを起 動している

16. 変わった事をしようとすると一工夫がいる • 一時的にコンテナを止める必要がある時 • 今回はDBのバックアップ時に一時停止 • コールドバックアップ • SDK経由でECSを操作 •

    手動で停止すると自動で復活するので、回避する設定変更も 必要 • 上記設定を戻せば元のコンテナが立ち上がるので、リカバ リー処理は楽

17. デプロイフローが複雑になった：開始前の想定

18. 設計完了！

19. デプロイフローが複雑になった：設計時点

20. Twitter [CC BY 4.0 (http://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons

21. デプロイフローが複雑になった：設計時点 • リポジトリがGitLabになった • GitLabからCode(Pipeline|Build|Deploy)の直接連携は不可

22. (CodePipeLineの場合：2017年11月現在)

23. デプロイフローが複雑になった：設計時点 • リポジトリがGitLabになった • GitLab→Code(Pipeline|Build|Deploy)の直接連携は不可 • API GatewayとLambdaを追加構築 • GitLabのwebhookで起動

    • S3に配置 • CodePipelineはS3をチェック

24. デプロイフローが複雑になった：設計時点 • アプリのビルドとデプロイを別途設定する必要があった • CodeBuildの追加 • CodeDeployの設定

25. リリース！

26. デプロイフローが複雑になった：リリース時点

27. Twitter [CC BY 4.0 (http://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons

28. デプロイフローが複雑になった：リリース時点 • デプロイ処理に時間がかかっていた • 特にDockerのビルドとCloudFormationの適用に時間がかかる • アプリケーションのデプロイのみを行うCodePipelineを別途作成 • 大体15～20分ほどかかっていたデプロイが3分ほどに短縮 •

    Composerやnpmによるライブラリ取得が短縮できれば更に…？

29. 全体のまとめ • 思っていたより難易度が高かった • いい勉強になりました • 学習コストも高い • また使うかと言われると正直… •

    使ってみないと分からない部分もあったので、使わなければよ かったという訳ではない • フローの部分はもう少しすっきり出来たはずというのが反省点

30. 自己紹介 • 木村俊彦 @taiko19xx • 株式会社SRIA

31. 株式会社SRIA • Web開発 • フロントエンド制作 • バックエンド構築 • アプリ開発 •

    iOS/Android/UWP • その他、デザインやクラウド(Azure/AWS)構築など… • お仕事＆お仲間募集中

32. 自己紹介 • 木村俊彦 @taiko19xx • 株式会社SRIA • Web(フロント・バックエンド)もアプリもクラウドもやってま す •

    仕事は開発したり打ち合わせに行ったり • 最近はAzureとかAWSをいじっています • 今日は仙台からおいしいものを食べに来ました

33. ありがとうございました