PHPカンファレンス北海道出張版(仮)で発表した内容です
PHPなプロダクトをAmazon ECSで開発運用してる話PHPカンファレンス北海道出張版(仮) PHPオフ会＠2017/11/25@taiko19xx / 木村 俊彦
View Slide
Amazon ECS使ってみたPHPカンファレンス北海道出張版(仮) PHPオフ会＠2017/11/25@taiko19xx / 木村 俊彦
こんにちは• PHPを使ったプロダクトをDockerとAmazon ECSで開発運用していますので得られた知見を共有します• DockerとECSの話がメインです• PHPカンファレンスとは？
もくじ• ECS(EC2 Container Service)とは• 構成図• 何故ECSか• Docker/ECSで…• 良かった所• 苦労した所• 全体のまとめ
ECS(EC2 Container Service)とは• EC2上のDockerコンテナを管理できる• いわゆるコンテナオーケストレーションのサービス• 無料• コンソール/AWS CLI/ECS CLI/AWS SDKから操作可能• マネージドなコンテナレジストリも利用可能• ECR(EC2 Container Registry)• ログインがめんどくさい• $0.1/GB/月 + 転送料
構成図
何故ECSか• AWS上に構築するという方針は決まっていた• Dockerで構築するのはどうかという話が出た• 管理をどうするか考えていた所、ECS/ECRを見つけた• 確認や検証の結果、採用する事に
Docker/ECSで良かった所
ローカルとリモートで”ほぼ”同様の環境が使える• ローカルはdocker-composeで• リモートもそれに近いように• イメージはCodeBuildでdocker-composeを使ってビルド• 環境はCloudFormationで同等の環境を構築
ローカルとリモートで”ほぼ”同様の環境が使える• 100% docker-composeを使い回す事はできなかった• ECS CLIを利用すれば可能• CloudFormationにおけるECSのServiceの記述はdocker-composeに比較的近い• 0から書き直しにはならない• 両方ともYAML
展開しやすい• Dockerベースなので、誰でも環境を起動できるように• リポジトリをcloneしたら環境構築して起動するだけ• コンテナ起動時にcomposer installするように仕込んでいた• VMやVagrantと違い、重いイメージファイルを配布せずに済む• ただし、以下の面で幸運だったという可能性も• 利用者が全員mac• フロント側も含めて全員コマンドの操作に慣れていた
開発環境構築にかかる時間が少ない• 基本的にはdocker-compose.ymlと必要なDockerfile書いて終わり• ただし…• 記述に慣れていれば、最低限の立ち上げは早そう• あくまで”開発環境”• AWS側はCloudFormationの記述やら各種設定が大変だった
Docker/ECSで苦労した所
結局Dockerfileを追加変更する事になる• PHPのコンテナ(php:7-fpm-alpine)はそのまま使う予定だったがDockerfileでカスタムした• タイムゾーンの変更• メモリやファイルアップロード周りの設定変更• Composerの追加• 拡張の追加• docker-php-ext-installをRUNする• nginxは最初に1度調整したのみ
変わった事をしようとすると一工夫がいる• cron• 各コンテナにはcrondが入ってるが、デフォルトで起動しない• 各サービスやデーモンと同時に起動する必要がある• コンテナ起動時に実行するスクリプトを用意し、その中に記述• cron専用コンテナを使わずにPHPコンテナ内でスクリプトを起動している
変わった事をしようとすると一工夫がいる• 一時的にコンテナを止める必要がある時• 今回はDBのバックアップ時に一時停止• コールドバックアップ• SDK経由でECSを操作• 手動で停止すると自動で復活するので、回避する設定変更も必要• 上記設定を戻せば元のコンテナが立ち上がるので、リカバリー処理は楽
デプロイフローが複雑になった：開始前の想定
設計完了！
デプロイフローが複雑になった：設計時点
Twitter [CC BY 4.0 (http://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons
デプロイフローが複雑になった：設計時点• リポジトリがGitLabになった• GitLabからCode(Pipeline|Build|Deploy)の直接連携は不可
(CodePipeLineの場合：2017年11月現在)
デプロイフローが複雑になった：設計時点• リポジトリがGitLabになった• GitLab→Code(Pipeline|Build|Deploy)の直接連携は不可• API GatewayとLambdaを追加構築• GitLabのwebhookで起動• S3に配置• CodePipelineはS3をチェック
デプロイフローが複雑になった：設計時点• アプリのビルドとデプロイを別途設定する必要があった• CodeBuildの追加• CodeDeployの設定
リリース！
デプロイフローが複雑になった：リリース時点
デプロイフローが複雑になった：リリース時点• デプロイ処理に時間がかかっていた• 特にDockerのビルドとCloudFormationの適用に時間がかかる• アプリケーションのデプロイのみを行うCodePipelineを別途作成• 大体15～20分ほどかかっていたデプロイが3分ほどに短縮• Composerやnpmによるライブラリ取得が短縮できれば更に…？
全体のまとめ• 思っていたより難易度が高かった• いい勉強になりました• 学習コストも高い• また使うかと言われると正直…• 使ってみないと分からない部分もあったので、使わなければよかったという訳ではない• フローの部分はもう少しすっきり出来たはずというのが反省点
自己紹介• 木村俊彦 @taiko19xx• 株式会社SRIA
株式会社SRIA• Web開発• フロントエンド制作• バックエンド構築• アプリ開発• iOS/Android/UWP• その他、デザインやクラウド(Azure/AWS)構築など…• お仕事＆お仲間募集中
自己紹介• 木村俊彦 @taiko19xx• 株式会社SRIA• Web(フロント・バックエンド)もアプリもクラウドもやってます• 仕事は開発したり打ち合わせに行ったり• 最近はAzureとかAWSをいじっています• 今日は仙台からおいしいものを食べに来ました
ありがとうございました
taiko19xx
fixstars
se_o_chan
foursue
carta_engineering
hhc0null
teckl
tsubakimoto_s
renjikari
sbtechnight
kenichirokimura
yoshinagaiwnl
eileencodes
jponch
jakevdp
bluesmoon
bkeepers
aleyda
bryan
ammeep
akmur
philhawksworth
samlambert
malarkey