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.8k
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
980
Ruby で作る Ruby (物理)
mtsmfm
0
180
GraphQL Ruby benchmark
mtsmfm
1
720
タイムアウトにご用心 / Timeout might break application state
mtsmfm
6
2.4k
Build REST API with GraphQL Ruby
mtsmfm
0
270
GraphQL Ruby をちょっとだけ速くした / Make graphql-ruby faster a bit
mtsmfm
1
670
Gaming PC on GCP
mtsmfm
0
660
How to introduce GraphQL to an existing React-Redux application
mtsmfm
1
200
Canary release in StudySapuri
mtsmfm
0
2.9k
Other Decks in Programming
See All in Programming
Synchronizationを支える技術
s_shimotori
1
150
飲食業界向けマルチプロダクトを実現させる開発体制とリアルな現状
hiroya0601
1
400
Amazon Neptuneで始めてみるグラフDB-OpenSearchによるグラフの全文検索-
satoshi256kbyte
4
330
現場で役立つモデリング 超入門
masuda220
PRO
13
2.9k
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
880
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
590
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
1.5k
Pinia Colada が実現するスマートな非同期処理
naokihaba
2
160
qmuntal/stateless のススメ
sgash708
0
120
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
210
NSOutlineView何もわからん:( 前編 / I Don't Understand About NSOutlineView :( Pt. 1
usagimaru
0
150
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
Featured
See All Featured
Fireside Chat
paigeccino
32
3k
The World Runs on Bad Software
bkeepers
PRO
65
11k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
How GitHub (no longer) Works
holman
311
140k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Rails Girls Zürich Keynote
gr2m
93
13k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Become a Pro
speakerdeck
PRO
24
5k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Typedesign – Prime Four
hannesfritz
39
2.4k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
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