let there be (only) docker

DevLOVE199 越境CON

https://devlove.doorkeeper.jp/events/55648

Transcript

1. (株)永和システムマネジメント @mtsmfm 松島 史秋 Docker あれ
2. 松島 史秋 GitHub, Twitter @mtsmfm
3. self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 - 自社インフラの管理
5. https://www.wantedly.com/projects/28670
6. self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 - 自社インフラの管理 - 西日暮里.rb 主催
7. https://ninirb.github.io
8. https://nishinipporirb.doorkeeper.jp/events/55942
9. self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 - 自社インフラの管理 - 西日暮里.rb 主催 - Ruby と麻雀 が好き
10. Ruby
11. https://github.com/mtsmfm/annotate_routes
12. https://github.com/mtsmfm/qwik2md
13. http://qwik.jp
14. https://asakusarb.esa.io/
15. 8年分の歴史を移行
20. https://github.com/mtsmfm/hubot-test-helper
21. 麻雀
22. http://mtsmfm.github.io/tegaki-jan
24. https://devlove.doorkeeper.jp/events/55648
25. 開発現場における 新たな越境
27. ゲストとホスト の境界を越える
28. (株)永和システムマネジメント @mtsmfm 松島 史秋 Docker あれ
29. Docker 知ってる人? 触ったことある人? 仕事で使ってる人?
30. ※ Docker の説明はしないので 各自調べてください
31. begin
32. 目次 第一部 出会いと挫折 第二部 初仕事 第三部 本番構築 第四部 ゼロから まとめ
33. 第一部 出会いと挫折
34. Heroku Docker
35. $ heroku plugins:install heroku-docker https://blog.heroku.com/introducing_heroku_docker_release_build _deploy_heroku_apps_with_docker ※今は deprecated
36. $ heroku docker:init # Dockerfile とかができる $ # なんか変更 $ heroku docker:start # build しなおして up が走る
37. 変更の度コマンド叩くとか やってらんない
38. http://qiita.com/mtsmfm/items/bb6af62c4cf878a1e3ee
40. 結果
41. “docker run うんたら どうたらかんたら...”
42. “こんなめんどくさいこ とするより 手元にある環境で やった方が早い”
43. Docker を 使うことなく 普通に手元の環境で 開発続行
45. 手元で環境を 用意するのが 辛いときは Docker
46. https://github.com/swagger-api/swagger-codegen Java 入れるのめんどい...
48. まとめ: 慣れた環境と 同じことできないと Docker で 開発辛い
49. 第一部 完
50. 第二部 初仕事
51. self.inspect - 永和システムマネジメント勤務 (4年目) - Rails で Web アプリ開発 - 自社インフラの管理
52. 管理するものは 減らしたい
53. ganeti による仮想サーバ群 お客様事情による - CI サーバ - ステージング (本番はお客様先) 社内用サービス - Redmine - Wiki (qwik) - Git リポジトリ - IRC
54. ganeti による仮想サーバ群 お客様事情による - CI サーバ - ステージング (本番はお客様先) 社内用サービス - Redmine - Wiki (qwik) - Git リポジトリ - IRC
55. 精査すると ほぼ無くなる
56. ステージングも 1つだけ (しかも休止中)
57. ステージングの用途 - アプリケーションの動作確認 - Ansible のテスト - mina (デプロイスクリプト) の テスト
58. 本番は変わらない (変えられない)ので 既存のプロビジョニングツー ルはそのまま活用
59. 手元で試せたほうが いいのでは?
60. Vagrant or Docker
61. Vagrant or Docker
62. ステージングも 1つだけ (しかも休止中)
63. 現ステージングと 同等の環境ができたら docker push して 寝かせておく
64. Ansible on docker
65. ansible_connection=docker
66. mina on docker
67. $ mina deploy to=staging -S | \ head -n -1 | \ docker exec -i container bash
68. $ mina deploy to=staging -S | \ head -n -1 | \ docker exec -i container bash 実行予定のスクリプトを 出力する
71. playbook は ある、が...
72. 「playbook を流す ための前提」 が不足
73. 途中から playbook を 書き始めた?
74. 今の環境になら 流れる
75. 一から流すと 動かない
76. 普段通らない handler とか...
77. ちょいちょい 手でやったと思われる ところがある
78. まとめ: 手でやり得ると 手でやってしまう 捨てやすい コンテナ便利
79. 第二部 完
80. 第三部 本番構築
81. お客様先で オンプレから AWS に移行
82. とりあえず 新しくできるやつは オンプレやめたい
83. https://aws.amazon.com/jp/ecs/
84. http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-20 16-amazon-ec2-container-service
86. まぁそうなるよね という構成
87. Docker の image さえできていれば ECS で動かすのは 難しくない
88. Docker の image さえできていれば ECS で動かすのは 難しくない
89. 誰がどこで build するか問題
90. CI サービス or 自前
91. 自分たちで 管理するものは 減らしたい
92. https://circleci.com/
99. build 遅い
100. http://qiita.com/na-o-ys/items/d16fd4959d4aec405f4f
101. https://app.shippable.com/
102. 10分＋ → 2分
103. しかし...
104. 唐突に cache が 飛んだり
105. 30 分待っても bulid が 始まらなかったり
106. あまりに 不安定だったので Circle CI に出戻り
107. https://circleci.com/beta-access
108. https://semaphoreci.com/
109. 個人のアプリで 素振りしている 範囲だと Semaphore CI よさそう
110. まとめ: ECS らくちん build どうするよ Circle CI 2.0 はよ
111. 第三部 完
112. 第四部 ゼロから
113. ある日
114. 出社してカバンから PC を取り出すと...
117. 修理
118. 代替機で開発
119. →
120. 俺はあと何回 このパッケージ群を 入れるんだろう
121. 本番 Docker なのに...
122. なぜかつて 挫けてしまったか
123. https://speakerdeck.com/takaking22/wo-hanazeyue-jing-surufalseka-yue-jing-m aindosetutotoxian-chang-gai-shan-number-devlove
124. 逃げ道があるのが いけない!!!
125. Docker 縛りで 圧倒的成長
126. - rbenv - nodebrew - PostgreSQL etc...
128. $ ruby -v zsh: command not found: ruby
129. - Atom - Zsh - Git - Docker - Docker Compose くらい
130. .rb の実行だって $ cat a.rb | docker run -i ruby ruby
131. pry での対話的デバッグだって docker-compose.yml で tty: true stdin_open: true しといてから $ docker attach $(docker-compose ps -q web)
132. ワンライナーだって 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")'
133. 自分のパッケージを メンテするときだって https://github.com/mtsmfm/hubot-test-helper/commit/a52f1c b3d8ade2029f048d3a3ce7893db875e162
134. ブログ書くときだって https://github.com/mtsmfm/mtsmfm.github.io/commit/a2200 95383a85c05ad6f55b11744867f74abf3b7
135. Docker 化されてない もの触るときだって https://github.com/mtsmfm/docker-rails-dev-box
136. Selenium 使うのとか むしろ楽だったりする https://github.com/mtsmfm/janjan/blob/3433507392ae055a5c4d4f32e74def8cd 50b11bd/docker-compose.yml#L51-L58
137. なんかもううまくいかない みたいな場合も $ docker-compose down -v $ docker-compose run web bin/setup $ docker-compose up
138. エイリアス
139. alias dc="docker-compose"
140. alias rails="docker-compose exec\ web bin/rails" $ rails db:migrate Rails 触るときに便利
141. alias drv="\ docker run --rm -it \ -v $PWD:/$PWD -w /$PWD" $ drv node npm install 雑になんか書くとか 誰かのパッケージ触るときと かに頻出パターン
142. alias ruby="\ docker run --rm -it \ -v $PWD:/$PWD \ -w /$PWD ruby ruby"
143. .rb の実行 $ cat a.rb | docker run -i ruby ruby
144. .rb の実行 $ cat a.rb | docker run -i ruby ruby $ ruby a.rb
145. alias -g @ruby="\ docker run --rm -i \ -v $PWD:/$PWD \ -w /$PWD ruby ruby"
146. ワンライナー 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")'
147. ワンライナー 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")'
148. あれ、わりといける?
149. みんなで Docker にしても XX でしか起きない現象は あったりする
150. https://github.com/npm/npm/issues/9863 aufs な人しか起きない
151. Docker のバージョンと Storage Driver を 合わせた方が安心かも
152. 最大の問題 lint
153. Atom の Linter plugin は どれも 手元に Linter が インストール されている前提
154. Atom は プロジェクト単位での 設定を持てない
155. 強引な解: ラッパースクリプトに direnv でパスを通す
156. $ 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
157. $ 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
158. https://github.com/docker/compose/pull/4059
159. 一応動いた、が...
160. Atom の環境変数は 複数起動してたら 共通なのであった
161. そこで Talk Driven Development
162. https://atom.io/packages/docker-linter-rubocop
163. https://github.com/mtsmfm/docker-linter-rubocop/blob/v0.2.2/lib/index.coffee#L39-L44
164. 1. 動いてるコンテナを探す 2. そのうち rubocop が 入ってるものを探す 3. rubocop を動かす
165. 動きはする
166. - 他の linter - デバッグ用にファイルを開く類 - save_and_open_screenshot - letter_opener - bundle open - Mac だと遅い - Linux のときにコンテナ内から作ったものの Permission と Owner - エディタも on docker であるべき? - docker-linter-rubocop が雑 困りごとはまだまだ
167. 俺達の戦いは まだ始まったばかり
168. 第四部 完
169. この発表で 伝えたかった こと
170. Docker を 本番で使う 事例をよく聞く ようになった
171. わりと なんとかなる
172. 開発環境 どうですか
173. Docker ありますか
174. Docker “だけ”あれば いいですか
175. “XXさんのところで だけ再現する”
176. “マシンセットアップ”
177. やめたい
178. すべての環境に
179. Docker あれ!
180. Docker “だけ” あれ!
181. Credits Background pattern from subtlepatterns.com Emoji provided free by Emoji One
182. end