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
let there be (only) docker
Search
Fumiaki MATSUSHIMA
January 28, 2017
Programming
2
150
let there be (only) docker
DevLOVE199 越境CON
https://devlove.doorkeeper.jp/events/55648
Fumiaki MATSUSHIMA
January 28, 2017
Tweet
Share
More Decks by Fumiaki MATSUSHIMA
See All by Fumiaki MATSUSHIMA
Learning from performance improvements on GraphQL Ruby
mtsmfm
1
1.2k
Ruby で作る Ruby (物理)
mtsmfm
1
210
GraphQL Ruby benchmark
mtsmfm
1
830
タイムアウトにご用心 / Timeout might break application state
mtsmfm
6
2.6k
Build REST API with GraphQL Ruby
mtsmfm
0
330
GraphQL Ruby をちょっとだけ速くした / Make graphql-ruby faster a bit
mtsmfm
1
730
Gaming PC on GCP
mtsmfm
0
740
How to introduce GraphQL to an existing React-Redux application
mtsmfm
1
250
Canary release in StudySapuri
mtsmfm
0
3.1k
Other Decks in Programming
See All in Programming
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
560
QA x AIエコシステム段階構築作戦
osu
0
150
Porting a visionOS App to Android XR
akkeylab
0
910
AI Ramen Fight
yusukebe
0
110
코딩 에이전트 체크리스트: Claude Code ver.
nacyot
0
990
GPUを計算資源として使おう!
primenumber
1
290
オンコール⼊⾨〜ページャーが鳴る前に、あなたが備えられること〜 / Before The Pager Rings
yktakaha4
2
1.1k
構造化・自動化・ガードレール - Vibe Coding実践記 -
tonegawa07
0
150
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
4
670
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
270
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
2
580
Jakarta EE Meets AI
ivargrimstad
0
280
Featured
See All Featured
Designing Experiences People Love
moore
142
24k
4 Signs Your Business is Dying
shpigford
184
22k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
How GitHub (no longer) Works
holman
314
140k
Side Projects
sachag
455
43k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Code Reviewing Like a Champion
maltzj
524
40k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
It's Worth the Effort
3n
185
28k
RailsConf 2023
tenderlove
30
1.2k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Transcript
(株)永和システムマネジメント @mtsmfm 松島 史秋 Docker あれ
松島 史秋 GitHub, Twitter @mtsmfm
self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 -
自社インフラの管理
None
https://www.wantedly.com/projects/28670
self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 -
自社インフラの管理 - 西日暮里.rb 主催
https://ninirb.github.io
https://nishinipporirb.doorkeeper.jp/events/55942
self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 -
自社インフラの管理 - 西日暮里.rb 主催 - Ruby と麻雀 が好き
Ruby
https://github.com/mtsmfm/annotate_routes
https://github.com/mtsmfm/qwik2md
http://qwik.jp
https://asakusarb.esa.io/
8年分の歴史を移行
None
None
None
None
https://github.com/mtsmfm/hubot-test-helper
麻雀
http://mtsmfm.github.io/tegaki-jan
None
https://devlove.doorkeeper.jp/events/55648
開発現場における 新たな越境
None
ゲストとホスト の境界を越える
(株)永和システムマネジメント @mtsmfm 松島 史秋 Docker あれ
Docker 知ってる人? 触ったことある人? 仕事で使ってる人?
※ Docker の説明はしないので 各自調べてください
begin
目次 第一部 出会いと挫折 第二部 初仕事 第三部 本番構築 第四部 ゼロから まとめ
第一部 出会いと挫折
Heroku Docker
$ heroku plugins:install heroku-docker https://blog.heroku.com/introducing_heroku_docker_release_build _deploy_heroku_apps_with_docker ※今は deprecated
$ heroku docker:init # Dockerfile とかができる $ # なんか変更 $
heroku docker:start # build しなおして up が走る
変更の度コマンド叩くとか やってらんない
http://qiita.com/mtsmfm/items/bb6af62c4cf878a1e3ee
None
結果
“docker run うんたら どうたらかんたら...”
“こんなめんどくさいこ とするより 手元にある環境で やった方が早い”
Docker を 使うことなく 普通に手元の環境で 開発続行
None
手元で環境を 用意するのが 辛いときは Docker
https://github.com/swagger-api/swagger-codegen Java 入れるのめんどい...
None
まとめ: 慣れた環境と 同じことできないと Docker で 開発辛い
第一部 完
第二部 初仕事
self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 -
自社インフラの管理
管理するものは 減らしたい
ganeti による仮想サーバ群 お客様事情による - CI サーバ - ステージング (本番はお客様先) 社内用サービス
- Redmine - Wiki (qwik) - Git リポジトリ - IRC
ganeti による仮想サーバ群 お客様事情による - CI サーバ - ステージング (本番はお客様先) 社内用サービス
- Redmine - Wiki (qwik) - Git リポジトリ - IRC
精査すると ほぼ無くなる
ステージングも 1つだけ (しかも休止中)
ステージングの用途 - アプリケーションの動作確認 - Ansible のテスト - mina (デプロイスクリプト) の
テスト
本番は変わらない (変えられない)ので 既存のプロビジョニングツー ルはそのまま活用
手元で試せたほうが いいのでは?
Vagrant or Docker
Vagrant or Docker
ステージングも 1つだけ (しかも休止中)
現ステージングと 同等の環境ができたら docker push して 寝かせておく
Ansible on docker
ansible_connection=docker
mina on docker
$ mina deploy to=staging -S | \ head -n -1
| \ docker exec -i container bash
$ mina deploy to=staging -S | \ head -n -1
| \ docker exec -i container bash 実行予定のスクリプトを 出力する
None
None
playbook は ある、が...
「playbook を流す ための前提」 が不足
途中から playbook を 書き始めた?
今の環境になら 流れる
一から流すと 動かない
普段通らない handler とか...
ちょいちょい 手でやったと思われる ところがある
まとめ: 手でやり得ると 手でやってしまう 捨てやすい コンテナ便利
第二部 完
第三部 本番構築
お客様先で オンプレから AWS に移行
とりあえず 新しくできるやつは オンプレやめたい
https://aws.amazon.com/jp/ecs/
http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-20 16-amazon-ec2-container-service
None
まぁそうなるよね という構成
Docker の image さえできていれば ECS で動かすのは 難しくない
Docker の image さえできていれば ECS で動かすのは 難しくない
誰がどこで build するか問題
CI サービス or 自前
自分たちで 管理するものは 減らしたい
https://circleci.com/
None
None
None
None
None
None
build 遅い
http://qiita.com/na-o-ys/items/d16fd4959d4aec405f4f
https://app.shippable.com/
10分+ → 2分
しかし...
唐突に cache が 飛んだり
30 分待っても bulid が 始まらなかったり
あまりに 不安定だったので Circle CI に出戻り
https://circleci.com/beta-access
https://semaphoreci.com/
個人のアプリで 素振りしている 範囲だと Semaphore CI よさそう
まとめ: ECS らくちん build どうするよ Circle CI 2.0 はよ
第三部 完
第四部 ゼロから
ある日
出社してカバンから PC を取り出すと...
None
None
修理
代替機で開発
→
俺はあと何回 このパッケージ群を 入れるんだろう
本番 Docker なのに...
なぜかつて 挫けてしまったか
https://speakerdeck.com/takaking22/wo-hanazeyue-jing-surufalseka-yue-jing-m aindosetutotoxian-chang-gai-shan-number-devlove
逃げ道があるのが いけない!!!
Docker 縛りで 圧倒的成長
- rbenv - nodebrew - PostgreSQL etc...
None
$ ruby -v zsh: command not found: ruby
- Atom - Zsh - Git - Docker - Docker
Compose くらい
.rb の実行だって $ cat a.rb | docker run -i ruby
ruby
pry での対話的デバッグだって docker-compose.yml で tty: true stdin_open: true しといてから $
docker attach $(docker-compose ps -q web)
ワンライナーだって git ls-files | xargs -L 1 docker run --rm
-i -v \ $PWD:/$PWD -w /$PWD \ ruby ruby -i -e \ 'puts gets(nil).gsub("docker", "Docker")'
自分のパッケージを メンテするときだって https://github.com/mtsmfm/hubot-test-helper/commit/a52f1c b3d8ade2029f048d3a3ce7893db875e162
ブログ書くときだって https://github.com/mtsmfm/mtsmfm.github.io/commit/a2200 95383a85c05ad6f55b11744867f74abf3b7
Docker 化されてない もの触るときだって https://github.com/mtsmfm/docker-rails-dev-box
Selenium 使うのとか むしろ楽だったりする https://github.com/mtsmfm/janjan/blob/3433507392ae055a5c4d4f32e74def8cd 50b11bd/docker-compose.yml#L51-L58
なんかもううまくいかない みたいな場合も $ docker-compose down -v $ docker-compose run web
bin/setup $ docker-compose up
エイリアス
alias dc="docker-compose"
alias rails="docker-compose exec\ web bin/rails" $ rails db:migrate Rails 触るときに便利
alias drv="\ docker run --rm -it \ -v $PWD:/$PWD -w
/$PWD" $ drv node npm install 雑になんか書くとか 誰かのパッケージ触るときと かに頻出パターン
alias ruby="\ docker run --rm -it \ -v $PWD:/$PWD \
-w /$PWD ruby ruby"
.rb の実行 $ cat a.rb | docker run -i ruby
ruby
.rb の実行 $ cat a.rb | docker run -i ruby
ruby $ ruby a.rb
alias -g @ruby="\ docker run --rm -i \ -v $PWD:/$PWD
\ -w /$PWD ruby ruby"
ワンライナー git ls-files | xargs -L 1 docker run --rm
-i -v \ $PWD:/$PWD -w /$PWD \ ruby ruby -i -e \ 'puts gets(nil).gsub("docker", "Docker")'
ワンライナー git ls-files | xargs -L 1 docker run --rm
-i -v \ $PWD:/$PWD -w /$PWD \ ruby ruby -i -e \ 'puts gets(nil).gsub("docker", "Docker")' git ls-files | xargs -L 1 @ruby -i -e \ 'puts gets(nil).gsub("docker", "Docker")'
あれ、わりといける?
みんなで Docker にしても XX でしか起きない現象は あったりする
https://github.com/npm/npm/issues/9863 aufs な人しか起きない
Docker のバージョンと Storage Driver を 合わせた方が安心かも
最大の問題 lint
Atom の Linter plugin は どれも 手元に Linter が インストール
されている前提
Atom は プロジェクト単位での 設定を持てない
強引な解: ラッパースクリプトに direnv でパスを通す
$ cat .envrc PATH_add ./docker/bin $ cat docker/bin/ruby #!/usr/bin/env sh
if [ -p /dev/stdin ]; then cat - | docker exec -i app_web_1 ruby "$@" else docker exec -i app_web_1 ruby "$@" fi
$ cat .envrc PATH_add ./docker/bin $ cat docker/bin/ruby #!/usr/bin/env sh
if [ -p /dev/stdin ]; then cat - | docker exec -i app_web_1 ruby "$@" else docker exec -i app_web_1 ruby "$@" fi
https://github.com/docker/compose/pull/4059
一応動いた、が...
Atom の環境変数は 複数起動してたら 共通なのであった
そこで Talk Driven Development
https://atom.io/packages/docker-linter-rubocop
https://github.com/mtsmfm/docker-linter-rubocop/blob/v0.2.2/lib/index.coffee#L39-L44
1. 動いてるコンテナを探す 2. そのうち rubocop が 入ってるものを探す 3. rubocop を動かす
動きはする
- 他の linter - デバッグ用にファイルを開く類 - save_and_open_screenshot - letter_opener -
bundle open - Mac だと遅い - Linux のときにコンテナ内から作ったものの Permission と Owner - エディタも on docker であるべき? - docker-linter-rubocop が雑 困りごとはまだまだ
俺達の戦いは まだ始まったばかり
第四部 完
この発表で 伝えたかった こと
Docker を 本番で使う 事例をよく聞く ようになった
わりと なんとかなる
開発環境 どうですか
Docker ありますか
Docker “だけ”あれば いいですか
“XXさんのところで だけ再現する”
“マシンセットアップ”
やめたい
すべての環境に
Docker あれ!
Docker “だけ” あれ!
Credits Background pattern from subtlepatterns.com Emoji provided free by Emoji
One
end