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
1k
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
670
How to introduce GraphQL to an existing React-Redux application
mtsmfm
1
210
Canary release in StudySapuri
mtsmfm
0
2.9k
Other Decks in Programming
See All in Programming
cmp.Or に感動した
otakakot
3
200
Jakarta EE meets AI
ivargrimstad
0
220
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
230
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
2
350
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
C++でシェーダを書く
fadis
6
4.1k
watsonx.ai Dojo #4 生成AIを使ったアプリ開発、応用編
oniak3ibm
PRO
1
140
Hotwire or React? ~アフタートーク・本編に含めなかった話~ / Hotwire or React? after talk
harunatsujita
1
120
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/After Kaigi on Rails 2024 LT Night
junk0612
5
2.2k
macOS でできる リアルタイム動画像処理
biacco42
9
2.4k
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
1k
Amazon Bedrock Agentsを用いてアプリ開発してみた!
har1101
0
340
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
The Pragmatic Product Professional
lauravandoore
31
6.3k
Code Reviewing Like a Champion
maltzj
520
39k
Docker and Python
trallard
40
3.1k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k
Optimizing for Happiness
mojombo
376
70k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
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