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

PHPカンファレンス北海道出張版(仮)で発表した内容です

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. ありがとうございました