- 河野 洋志
- twitter: @bonty
- アカツキでエンジニアをしています
- 最近はcocos2d-x、アプリケーションの設計、BigQueryとか興味があります
- 最高の方法を考えないのは悪
- チーム最適
- 「最高」は2つの面から
- スピードやコスト、生産性、プロダクトの完成度などの点で最適
- 開発する人が楽しめる、面白い
- これらを追求しないと良いものづくりができない。常に新しい、より良い手法を取り込む
- 「最高の追求」の裁量は各チームにある。全チーム共通のルールを重視するとプロセスが重くなりがちになって、変化しにくくなる
- 各チームが独立して良い手法を探し共有することで、良い技術は浸透し、悪い技術は淘汰される
- 結果的に組織全体にとってベストの手法に変わっていく
- CI
- Jenkins, Travis CI, Circle CI, HoundCI, TestFlight, DeployGate
- Communication
- Github, HipChat, JIRA, Google Spreadsheet
- DevOps
- AWS CloudFormation + Chef + Capistrano
- AWS Elastic Beanstalk + Docker
- コンテナ型の仮想マシン
- Dockerfileをこねこねして
$ docker runするだけであれこれインストールされた環境が作れる - 環境をそのまま持ち運びできるので、俺の環境だとhogehogeが発生しづらい
- AWSが提供しているHerokuっぽい何か
- ELB + Appサーバ な構成がボタン押してるだけで出来てしまう
- Node.JS、PHP、Python、.NET、Java、Rubyアプリをデプロイできる
- 2014/04からDockerアプリケーションをデプロイできるようになった
- Vagrant + Dockerで開発環境を簡単に持ち運べるようになった
- 俺の環境だと動く・ダメ・絶対
- ついでだからプロダクションでもDockerで動かしたくなった
- Elasticbeanstalkとかいうのが便利らしい
- 開発環境とプロダクション環境の差異を減らせる
- 環境にまつわるトラブルを減らせる
- Twelve-Factor App
- アプリサーバーをImmutableにできる
- 毎回新規作成されたインスタンス上で新たにDockerイメージを起動
色々と試行錯誤した結果、以下の構成に落ち着いた
- ローカルでDockerイメージをビルドしてS3上のプライベートレポジトリにpush
- ローカルマシンからElasticbeanstalkにデプロイリクエスト
- Elasticbeanstalkが環境に対してデプロイ
- 各インスタンスは起動後、S3にあるイメージをpullしてきてDockerを起動
- 最初はDockerイメージを作らずに毎回インスタンス上でDockerfileからビルドしていた
apt-get installから始めるので30分経ってもデプロイが終わらない → 悲しい
- DockerHubにイメージをpushしてから各インスタンスでpullして起動
- デプロイは早くなったけど公開イメージになるのでプロダクションで使えない → 悲しい
- AWSブログの記事でS3をDockerプライベートレポジトリとしてElasticBeanstalkでデプロイする記事が！！
- 開発マシン上でdocker-registryコンテナ(プライベートレポジトリ用コンテナ)を立ち上げてビルドしたイメージをS3にpush
- 各インスタンスでdocker-registryコンテナを立ち上げてプライベートレポジトリのイメージをpull
- 各インスタンスがレポジトリコンテナを立ち上げるので、レポジトリ用サーバを立てるよりも可用性が上がる → 嬉しい
- 環境変数でDBやキャッシュサーバへのエンドポイントを変更できるようにしておくと色々楽
- Elasticbeanstalkで立ち上がるAMIはnginx経由でリクエストがコンテナに来るように設定されているので、コンテナにはnginxを立てないほうが綺麗
- DockerfileとDockerrun.aws.jsonをgitレポジトリルートに配置しておくとDockerrun.aws.jsonが無視される
- (railsアプリの場合)レポジトリルートから1階層奥にアプリ本体とDockerfileを配置するとDockerのコンテキストなど気にしないといけないことが減る
- github上にサンプルアプリケーションを公開しています
- 質問などありましたら遠慮なくインターネットでお声がけください！