Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Qall - Development env on Docker for Quipper
Search
Fumiaki MATSUSHIMA
March 25, 2018
Programming
6
5.9k
Qall - Development env on Docker for Quipper
Rails Developers Meetup 2018 Day 2 発表資料
https://railsdm.github.io/2018/
Fumiaki MATSUSHIMA
March 25, 2018
Tweet
Share
More Decks by Fumiaki MATSUSHIMA
See All by Fumiaki MATSUSHIMA
Learning from performance improvements on GraphQL Ruby
mtsmfm
1
1k
Ruby で作る Ruby (物理)
mtsmfm
1
180
GraphQL Ruby benchmark
mtsmfm
1
740
タイムアウトにご用心 / Timeout might break application state
mtsmfm
6
2.5k
Build REST API with GraphQL Ruby
mtsmfm
0
280
GraphQL Ruby をちょっとだけ速くした / Make graphql-ruby faster a bit
mtsmfm
1
680
Gaming PC on GCP
mtsmfm
0
680
How to introduce GraphQL to an existing React-Redux application
mtsmfm
1
220
Canary release in StudySapuri
mtsmfm
0
2.9k
Other Decks in Programming
See All in Programming
テストコードのガイドライン 〜作成から運用まで〜
riku929hr
4
580
menu基盤チームによるGoogle Cloudの活用事例~Application Integration, Cloud Tasks編~
yoshifumi_ishikura
0
110
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
260
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
190
Beyond ORM
77web
7
860
ゆるやかにgolangci-lintのルールを強くする / Kyoto.go #56
utgwkk
2
390
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
780
20年もののレガシープロダクトに 0からPHPStanを入れるまで / phpcon2024
hirobe1999
0
490
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
6
1.1k
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
130
KMP와 kotlinx.rpc로 서버와 클라이언트 동기화
kwakeuijin
0
140
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
770
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Facilitating Awesome Meetings
lara
50
6.1k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Power of CSS Pseudo Elements
geoffreycrofte
73
5.4k
Unsuck your backbone
ammeep
669
57k
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
Transcript
Qall - Docker で作る Quipper の開発環境 @mtsmfm Fumiaki Matsushima 2018.03.25
Rails Developers Meetup 2018: Day 2
➔ Quipper Ltd 所属 ➔ Ruby と麻雀が好き ➔ 西日暮里.rb 主催
➔ GraphQL Tokyo 主催 @mtsmfm.inspect
https://www.quipper.com/
https://studysapuri.jp/
https://github.com/kyanny/railsdm2018/blob/37a08ecef5d295a6d14838f34baa105fbc6c3f53/Quipper%20%E3%81%AB% E3%81%8A%E3%81%91%E3%82%8B%E3%80%8C%E9%96%A2%E5%BF%83%E3%81%AE%E5%88%86%E9%9B%A2% E3%80%8D%E3%81%AE%E6%AD%B4%E5%8F%B2.pdf
None
技術的負債を作らないのは不可能。 簡単に返済できる環境を作る。 - @masatomo, Quipper Ltd CTO
None
Tegaki-jan http://mtsmfm.github.io/tegaki-jan/
https://github.com/mtsmfm/language_server-ruby
西日暮里.rb https://ninirb.github.io
https://nishinipporirb.doorkeeper.jp/events/71936
GraphQL Tokyo https://www.meetup.com/ja-JP/GraphQL-Tokyo/
https://www.meetup.com/ja-JP/GraphQL-Tokyo/events/248222891/
開発環境 Docker 縛り歴 1年半
None
Qall - Docker で作る Quipper の開発環境 @mtsmfm Fumiaki Matsushima 2018.03.25
Rails Developers Meetup 2018: Day 2
Qall - Quipper All
➔ 開発環境としての Docker の啓蒙 ➔ Docker 上の開発環境を前提とした ツールの整備の促進 発表の目的
大事なことは最初に
Docker で やさしい開発環境を 作っていこう
01 02 03 Agenda | Qall がなぜ必要か Qall の構成 課題
01Qall がなぜ必要か
A. セットアップが めんどくさいから
生徒用 先生用 保護者 用 管理者 用 コンテン ツ 入稿用 Mongo
Postgres ...
生徒用 先生用 保護者 用 管理者 用 コンテン ツ 入稿用 Mongo
Postgres ...
生徒用 Mongo Postgres Memcached Redis API Front Worker
➔ API + フロント + ワーカー + etc… を各アプリ毎に ➔
単機能の開発だと全部は要らないことが多い ◆ あまり改修が入らないところのセットアップが 後回しにされがち ◆ 障害調査などとっさの時に困る システム全体の構成要素は増え続ける
ドキュメントは劣化していく
特に新入りには厳しい!
生徒用 先生用 保護者 用 管理者 用 コンテン ツ 入稿用 Mongo
Postgres 全部まとめて Docker Compose で ...
Qall の構成 02
➔ 各リポジトリには Docker 固有のファイルを(ひとまず)持たない ◆ 最小公倍数的な Dockerfile を 1 つ
◆ 違うところは build arg で回避 ➔ 各リポジトリは qall 上に clone してくる Qall の基本方針
qall |----- Dockerfile |----- docker-compose.yml |----- repos | |----- student-api
| |----- student-front | |----- ... |----- envs |----- student-api.env |----- student-front.env |----- ... 各リポジトリ 各リポジトリ毎の ローカル用環境変数
日常的に使うと 見えてくる問題
➔ rails new したての状態で、bin/rails -T がローカルと比べて 10 倍以 上遅いんだけど??? Docker
for Mac が遅い
macOS Docker CLI $ dc run app rails s $
alias dc=docker-compose
Hypervisor Framework (VM) Linux Docker Container Engine macOS Docker CLI
$ dc run app rails s $ alias dc=docker-compose
Hypervisor Framework (VM) Linux OSXFS Docker Container Engine macOS Rails
gem rails s Docker CLI $ dc run app rails s $ alias dc=docker-compose
Hypervisor Framework (VM) Linux OSXFS Docker Container Engine macOS Rails
gem rails s Docker CLI R/Wがすごく遅い $ dc run app rails s $ alias dc=docker-compose
User-guided cache https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/#h.72tgxspoi9yj
User-guided cache https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/#h.72tgxspoi9yj 10秒
User-guided cache https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/#h.72tgxspoi9yj 10秒 rake -T
rake -T が10秒?!?!?!
使い物にならない
OSXFS を使わない
案1. docker-sync
Docker Container Engine macOS Docker CLI app gem $ docker-sync
start
Docker Container Engine macOS Docker CLI docker-sync app gem $
docker-sync start
Docker Container Engine macOS Docker CLI docker-sync OSXFS app gem
app gem /host_sync $ docker-sync start
Docker Container Engine macOS Docker CLI docker-sync OSXFS app gem
app gem /host_sync app gem /app_sync Unison で同期 $ docker-sync start
Docker Container Engine macOS Docker CLI docker-sync OSXFS app gem
app gem /host_sync app gem /app_sync $ dc run app rails s $ alias dc=docker-compose
Docker Container Engine macOS rails s Docker CLI docker-sync OSXFS
app gem app gem /host_sync app gem /app_sync $ dc run app rails s $ alias dc=docker-compose
Docker Container Engine macOS rails s Docker CLI docker-sync OSXFS
app gem app gem /host_sync app gem /app_sync 遅い 速い $ dc run app rails s $ alias dc=docker-compose
理屈上は ローカルと同じ速度になる
docker-sync よく死ぬ問題
Docker Container Engine macOS rails s Docker CLI docker-sync OSXFS
app gem app gem /host_sync app gem /app_sync なぜか死ぬことがある
➔ OSXFS がうまく更新できていなかったり、Unison が同期に失敗したり ➔ 問題が起きたときに気づくのが非常に難しい ◆ エディタ上は保存しているのにコンテナ内には反映されていないか もしれない事を常に気にしないといけない docker-sync
よく死ぬ問題
案2. R/W が多いところを ひたすら Volume 化
Hypervisor Framework (VM) Linux Docker Container Engine macOS rails s
$ dc run app rails s Docker CLI BUNDLE_PATH を Volume に gem app Gem 以外は諦める OSXFS $ alias dc=docker-compose
➔ vendor/bundle、tmp、node_modules とか ◆ sprockets 使っているときは tmp がよく効く ➔ ディレクトリがないところに
mount すると所有者が root に なってしまうため、Rails コマンドなどを実行するユーザとして Dockerfile 内で予め作っておく R/W が多いところは Volume に
速度か安定性か
速度 >>> 安定性
- binding.pry 書いたのに止まらない - なんか SyntaxError - テスト落ちる
エディタを睨んでも わからない -> docker-sync 死んでる
速度 >>> 安定性 そう思った時期もありました
docker-sync なしでも動くように
誰も使わなくなったので 設定を完全削除
速度 <<< 安定性
https://github.com/mtsmfm/rails-on-docker-benchmark
※実際は app 以下が 育つことで もっと docker-sync の方が速 くなる
Dockerfile の例 ARG QALL_REPO_NAME ARG QALL_MOUNT_DIRS RUN mkdir -p /quipper/$QALL_REPO_NAME
&& \ cd /quipper/$QALL_REPO_NAME && \ (test -z "$QALL_MOUNT_DIRS" || mkdir -p $QALL_MOUNT_DIRS) && \ chown -R quipper:quipper /quipper
➔ Bash とか Pry とかのヒストリバックが C-p のあとに何か押さないと動かない ➔ C-p C-q
が Docker のデフォルトのデタッチキーバインド ◆ Docker CLI なら config.json で上書きできるが、 Docker Compose だと config.json を見ない... Compose 介すと C-p が動かない
直した
https://github.com/docker/docker-py/pull/1826
docker-compose 1.20 (docker-py 3.0.0) から ~/.docker/config.json を 見てくれるように
➔ localhost:3000 が生徒用で、localhost:3001 が先生用で... Port 番号が覚えられない
Pow ってあったね
➔ <app name>.test でアクセスできるようにしてくれるやつ Pow http://pow.cx/
Docker でも欲しい
作った
https://mtsmfm.github.io/2017/06/29/yaichi.html
➔ http://<container-name>.localhost でアクセスできる ◆ http://localhost には一覧が出る ◆ ngx-mruby 製 ◆
HMR などもちゃんと動く Yaichi
https://hub.docker.com/r/mtsmfm/yaichi/
➔ このリポジトリには mongo と pg と redis と memcached 、こっちは
redis は要らなくて... ◆ リポジトリ毎に欲しくなるミドルウェアと、それに対応した環境変数を 都度書くのがめんどくさすぎる 複雑化する docker-compose.yml
docker-compose.yml.erb
api: ruby_version: 2.5.0 nodejs_version: 6.13.1 commands: default: bundle exec rails
s -b 0.0.0.0 worker: bundle exec rake resque:start depends_on: [mongo, redis] mount_dirs: [tmp] こんな感じの YAML を元にする Build args に 各々 service と command に Build args に リポジトリ単位の service に
services: api: &api container_name: qall-api command: bundle exec rails s
-b 0.0.0.0 build: context: . args: RUBY_VERSION: 2.5.0 NODEJS_VERSION: 6.13.1 QALL_REPO_NAME: api QALL_MOUNT_DIRS: tmp working_dir: /quipper/api volumes: - vendor:/vendor - home:/home/quipper - ./repos:/quipper:cached - tmp-api:/quipper/api/tmp environment: BUNDLE_PATH: /vendor/bundle/2.5.0 MONGODB_HOST: mongo REDIS_URL: redis://redis-api env_file: - envs/common.env - envs/api.env depends_on: [mongo, redis-api] tty: true stdin_open: true api-worker: <<: *api container_name: qall-api-worker command: bundle exec rake resque:start mongo: container_name: qall-mongo image: mongo volumes: - mongo-data:/data/db redis-api: container_name: qall-redis-api image: redis:alpine yaichi: container_name: qall-yaichi image: mtsmfm/yaichi ports: - 80:3000 volumes: - /var/run/docker.sock:/var/run/docker.sock volumes: home: mongo-data: vendor: tmp-api:
https://gist.github.com/mtsmfm/3235b3fc4a55baa45d8538f8acab911e
課題 03
1. Qall としての課題 2. Docker 上開発環境を 取り巻く課題
➔ 本番 (Deis) と同じイメージに ➔ 各リポジトリ毎に Dockerfile を ➔ 個々人で
docker build せずに pull する構造に ➔ docker-compose やめて k8s に移行 ◆ helm? Qall の課題
Docker 上開発環境を 取り巻く課題
Docker 化によって、 今までのように 動かなくなるものも
➔ letter_opener ◆ コンテナ上にブラウザがいない ➔ ChromeDriver による E2E テスト ◆
コンテナ上にブラウザがいない 今まで通りでは動かなくなるが 解決策があるもの
➔ SMTP サーバと Web インターフェースがくっついたものを Docker 上 で立てるのが楽 ◆ sj26/mailcatcher
◆ djfarrelly/maildev letter_opener
➔ Selenium の公式イメージを使って、Remote Driver として セットアップ ◆ selenium/standalone-chrome-debug はデスクトップ環境が ついてきて、
VNC でログインできて便利 ChromeDriver (Selenium)
詳しくはこっちを https://speakerdeck.com/mtsmfm/rails-system-test-on-docker
➔ save_and_open_page ◆ スクショ.png を ホストに見えるところに置けば開けるが... ➔ bundle open ◆
Gem はホストにない ◆ エディタはホストにある 今までのように動かなくなるもの
➔ Linter などのエディタ連携 ◆ 基本ホストにインストールされている前提 ◆ Gem がコンテナ内にしかない • ホストからは見えないファイルがある
今までのように動かなくなるもの
➔ 静的解析にしろ、動的解析にしろ、アプリと同一環境、 同一イメージじゃないと得られない情報がある ➔ docker-compose の起動コストが高い ◆ Docker 上で何かプロセスを上げといて、そいつとエディタを繋げ ればいいのでは?
• それ Language Server で Docker 時代のエディタ連携
http://rubykaigi.org/2017/presentations/mtsmfm.html
特に OSS とか セットアップの 敷居低いほうがいいよね
docker-py は手元でも docker 上でテスト https://github.com/docker/docker-py/blob/a4e642b015c50d9c628413341ed00c89599f66be/Makefile
https://github.com/mtsmfm/docker-rails-dev-box rails/rails-dev-box の Docker 版
ホストOS上に 何がいるべきか よくわからなくなってくる
エディタ、ブラウザ etc も Docker 上であるべき?
みたいな議論がしたい
そもそも Docker 上に 開発環境作っている人が 少ない (?)
既に環境ができている人、 慣れている人からすると 移行するメリットが薄い
人もアプリも協働するもの
Docker で やさしい開発環境を 作っていこう
None