最初に結論を書いてしまうけど、フロントエンド(だけやる)エンジニアにはたぶんおいしくない。
っていうことに気付くまでの学びを社内勉強会用にまとめたメモ。
概念的なところがメインなので、細かいDockerのコマンドとかそういうのには触れません。
あんまり詳しい分野じゃないので、なんか変なこと書いてたら教えてください・・・!
Docker is 何
Docker is コンテナ型の仮想化技術
コンテナ
- What is a Container | Docker
- 仮想化する部分が一部 = 軽快
- ポータビリティ!
- アプリケーション(WebサーバーとかDBサーバーとか)の実行環境
- そのサービスの実行に必要なものを全部ひとまとめにしたもの
- そんなサービスが起動するプロセスの単位
- 黒い画面でなんかコマンド叩くと実行されて、終わったら消えるアレがプロセス
- 何回やってもどこでやっても同じ結果
- 状態は持たない <- 重要
- あの感覚でアプリケーションを動かせる
コンテナ = イメージをビルドしたもの
- Dockerfile
- コンテナの構成を定義をするファイル
- docker-node/Dockerfile at master · nodejs/docker-node · GitHub
- これを使ってイメージというものをビルド
- このビルドされたイメージ = コンテナ
よさそう
- コンテナの単位でデプロイとかできるといいよね
- Immutable Infrastructureとかいう思想
- BlueGreenDeployment
- Dockerさえ動けば、どこでも動かせる
だが実際は
- コンテナ = ブラックボックス
- メモリ足りなくて死んだりするのどうやって拾うの
- 障害時の切り分け
- ログ吐いたり見たりしたいけどドコに・・
- Dockerfileのメンテが辛い
- 実際に運用するにはオーケストレーションツールが別途でほぼ必須
- docker-compose, Swarm, Kubernetes, ...etc
と、有識者の方々はおっしゃる・・( ˘ω˘)
可能性はあるが、まだ枯れてはいないというのが現状のステータスっぽい。
ここまでのまとめ
- アプリケーションをコンテナという単位で扱えるのがキモ
- Dockerが動くところであればコンテナが動く = サービスが動く
- イメージの中に、アプリのコードや依存関係は含まれる
- コードをGitHubにpush -> CIが動いてイメージをビルド
- そのイメージ(=コンテナ)が、本番環境でもそのまま実行される
というのがそもそものDockerの本意。
我々にとっておいしいか
おいしいも何も、関係ない(かも)
ここまで見てきて、自分には関係ないかな・・と思ったら、関係ない。
Dockerの本来の用途に関して言えば、
っていういわゆるフロントエンド(だけやる)エンジニアにとっては、無用の長物なのは間違いない。
使いたいなら使えばいいけど。
おいしいかもしれない
- フロントエンドはいつもどおり`localhost`で開発
- ただし他にもサーバーがないと開発できない場合
- サーバーサイドで動かすべきロジックがある
- モックデータの入ったDBサーバーがいる
- Redisみたいなやつもいる・・etc
適当にモック用のBFFみたいなの用意したらええやんってのはさておき、こういうのがDockerで動かせる場合はおいしい。
適当なコマンド一発でコンテナが起動して、適当なポートでアクセスできるようにしてるはず。
`npm start`するついでに`docker run`とか`docker-compose up`すればいいだけ。
Docker = ただの軽いVMではない
けども、そういう使い方もできてしまう。
みたいに、コンテナの中で状態が持てないなら、開発中で変化するものはホスト側に残しておくしかない。
コンテナの実行時にコピーしたりボリューム共有したりしてやってく。
ただしその場合、VirtualBoxとかVagrantとかで過去にやってたのと同じ問題がつきまとう。
ホスト <-> ゲスト間のファイルI/Oが激遅い問題
修正した内容が反映されるのが遅いとか、いわゆる`npm run watch`的なやつが遅くて使い物にならん問題。
File access in mounted volumes extremely slow · Issue #77 · docker/for-mac · GitHub
公式でもだいぶ前から取り上げられてるけど、イマイチ解決策が出てきてない。
Vagrant x VirtualBoxの頃は`rsync`で手動コピーしたりしてなんとかしてた思い出がある・・。
Dockerの場合でも一緒。
- docker-sync by EugenMayer
- GitHub - zchee/docker-machine-driver-xhyve: docker-machine/libmachine driver plugin for xhyve/hyperkit (native macOS hypervisor.framework)
などなど結局がんばるしかなくて、Docker for Macとかから参入したエンジョイ勢はたぶんここで駆逐される。
大したファイル数がないとか、別にこの遅さが待てるとかなら問題にはならんけど。
ホストとゲストでOS違う問題
Cとかのネイティブモジュールを使うモジュールにありがち。`node-sass`とか。
`npm install`する側(= ホスト側 = mac)でビルドしたモジュールが、ゲスト側で使えない。
どうしようもない気がする。
諦めて全部ホスト側でやったらいいと思う。
`yarn.lock`で依存関係もだいぶマシになったし、せいぜい解決できてNodeのバージョンくらい・・。
まとめ
というわけで、フロントエンド(だけやる)エンジニアにとっては、知らなくても困らんと思う。
まあ知識は無駄にならんし、CircleCIが2.0になってDockerが1stサポートになったので、ちょっと楽ができるかもーくらい。
本質を見極めた上で、選択・判断しよう、そのために日々勉強しようという話か・・。