ずいぶん前の記事だが
これ dockerやめてどうしたか？
とか
これ Docker ではないコンテナ systemd-nspawn を使ってみた / マスタカの ChangeLog メモ
を最近読んで僕も知識不足で自分にイラッときたのでちょっと考えてみた。
なお仕事でコンテナを使った経験はない。
あとsystemd-nspawnとかLXDは適宜各「システムコンテナ技術」に置き換えても同じ。
TL;DR
自分は以下で判断することにした。
- とりあえずDockerイメージがないか探して自分が起こそうとしている環境が簡単に実装できるか見極める
- オーケストレーションする以上に手を加える必要があるならsystemd-nspawnやLXDなどを使う
Dockerfileをいじって思ったのは、
DockerHubなんかにあるDockerfileから実行プロセスを追加・変更するべきではないということ。
自分がゼロからDockerfile書き上げるとしても単一プロセスの簡単なものだと思う。
（cronでpythonスクリプトを走らせるとか）
当初思っていたこと
環境設定や手順をファイルとして保存しておく術として流行りのDockerに乗っていたのだけれども、
使う中でこんなことを思ったのだった。
Dockerでいろいろ試してようやくわかってきたけど、Dockerっていうのは「あるプロセス」を「ある環境」で動かすための仕組みということなんだな。極力デーモンとかに依存しない形で実装したほうがスッキリする。
— 幻覚胡椒 (@MAD_PEPPER) 2018年6月26日
”現場で使われてる皆様方に於かれましては勿論の事このようなことは常識なのだとは思いますが”、
当初想定していたのは「オーバーヘッドのない仮想化みたいな技術」
といったゆるふわな理解だった。
だからあれこれDockerコンテナに閉じ込めようとするとデーモンとかデーモンとかデーモンとかで、
Docker移行前と同じ実行方法にならないケースが出てきた。
そのDockerで動かせるようにするコストもデカかった。
増田の意見について
そんな状況だったから、増田の記事に書いてあるように
「本番環境がDockerでないのならもろもろの努力は全くの無駄である」
というのはとてもよく理解できた。
調べてみたらmachinectl import-tarでDockerのイメージからコンテナを作れるし、
そこからAnsibleやシェルスクリプトで設定すれば、
確かにDockerでなくてもコンテナ作成は自動化できるらしい。
しかもそのコンテナはなんの工夫もなくデーモンも動くし、
Dockerよりも"Dockerでない本番環境"に近い。
ただ、「より多くの人が使える（再利用できる）」というメリットはDockerにあると思う。
そういった中でGKEやECSがあるのであれば、本番環境とシームレスに使える可能性もあるだろう。
また、もしDockerfileとdocker-composeの内容とAnsibleやシェルスクリプトを何度も行き来するなら
たとえ簡単だとしてもそのコストはゼロではないことを頭に入れておかねばならない。
どんなときもsystemd-nspawnが優れているのではなく、状況によって使い分けられるべきなのだろう。
で？っていう
そんなことを考えていたらこんなのに出会った。
第459回 LXDを使ってDockerコンテナをマイグレーション：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社
これによれば、想定されている使い方に差があるのは確かなようだ。
- Dockerがひとつのコンテナでひとつのアプリケーションを動かす「アプリケーションコンテナ」
- LXDは軽量な仮想マシンのように使える「システムコンテナ」
という説明がとても端的でわかりやすかった。
そしてその点がずっと理解できていなかった。
Dockerは基本アプリケーションのコンテナに過ぎないので、
いくつものアプリケーションを1つのコンテナに詰め込もうとするとおそらく困難が伴う。
データボリュームの共有や、ブリッジ接続などでいくつものDockerコンテナを組み合わせていく、
という使い方になるのだろう。だからdocker-composeがあるのか！
Docker in Dockerという手もある。
一方LXDやsystemd-nspawnなどはより仮想環境として広く使うことができそう。
複数のアプリケーションを動かしている"総合的コンテナ"を整える上ではDockerよりも強力そうだけど、
そのコンテナ固有の設定になりがちなので、別の機会にそのまま再利用はできなそう。
あと多分多くのコンテナを立ち上げたときにディスク容量をコンテナの数だけ使うことになる。
IaaSを運用したりするときにはあまり向かないのかもしれない。
あとリソース分離とかいろいろあるらしいけど、読むのは挫折した。 ：-P
rkt vs Other Projects
とりあえずやってみてから考える
Dockerが流行っているのはDockerイメージが再利用しやすいからかもしれない。
「みんなの集合知をパズルのように組み合わせるDocker」
と
「無垢の材木から自分にあった環境を彫り上げるsystemd-nspawn（LXD）」
と言ったところか。
どっちのほうがゴールに近いのか考えてから手を付けたほうが良さそうだ。
増田は「単一プロセスの集合体なんてやってられるか」って言ってたけど、
逆に単一プロセスに分解できない状況っていうのが信頼性高い環境か、という疑問もある。
そんなことを言いつつも「やっぱりデーモンが動かないのはなー」
なんて思いながらいくつかのDockerイメージをsystemd-nspawnに移行してみようと思いましたまる
ほか
そもそもコンテナが必要かって話もあるみたい。
自宅サーバの運用ではEC2とかはお世話にならないと思うけど。
- "私たちはLXCを使いたいがためだけにこれらを再発明していたのです。"
Kodingがコンテナをやめてdockerから仮想マシンに移行したのはなぜ? - Qiita
本番で使うにはおそ松って話もある
- "「俺のマシンでは動いた」なんて簡単には口にしないよ"Dockerの本番運用 | POSTD
蛇足
改行って入れるべき？