morimorihogeです。1年以上ご無沙汰している間に艦これは卒業してゴ魔乙に引っ越しました。
最近弊社Webチーム内で標準ツール化してきたDockerについて、そこそこ知見も溜まってきたので現状の感想をまとめてみたいと思います。
また、Dockerを開発チーム内で利用するにあたり、もっと気軽な使い方をしてもいいんじゃないかなと思っているところがあるので、ゆるふわDocker部の提案をしたいと思います。
雑なDocker現状まとめ
まずは僕の私見としての現状のDocker事情をまとめてみます。
Dockerってイケてるの？
Docker自体についてはあちこちでいろんな記事も出ているので今更解説することは避けますが、開発者関連の話題状況や実際の周辺サービス事情を見ている限り、そろそろ「一過性の流行りモノとしてのなにか」から「実用シーンを見定めて実用化も考えて良いもの」になってきている印象を受けます。
初期は色々と不便なこともあったDocker CLIもdocker execの実装などを経て今もなお使いやすく進化しているのが見て取れます（ちょくちょくAPIバージョン互換が切れるのはめんどいですが）。
ContainerやDocker Image管理についても、公式GUIのKitematicを始め、ブラウザで管理できるツールなどもあり、多少初心者向けの門戸が広がってきたように思えます。
何より、Docker周りのコミュニティが活発なので、新しい情報に比較的アクセスしやすい状況ということで、今はDockerを新規で勉強するにはちょうど良い環境にあるのではないでしょうか。
本番で使えるの？
実際にサービスを運用する本番環境でDockerが使えるのか？という話を考えてみます。
いわゆる本番環境に新しいモノを導入する点では、いくつかの判断基準が出てくるかと思います。すなわち、
- 安定性：サービスが停止せず動き続けられるか
- 保守性：構成変更やメンテナンスが容易に可能であるか。脆弱性等が発見されたときにセキュリティパッチや対策方法が遅滞なく提供されるか、コミュニティが活発で問題に対する回答が見つけやすいか
- 交換可能性：もし当該技術を使い続けられない要因が出てきたときに、他の同等環境へ乗り換えることが可能か（過剰にロックインされないか）
あたりが気になる所かと思います。Dockerはそうした点ではまだ一部の技術に自信のある組織が運用するに留まっている様に見えます（私見）。
普段から最新の情報を常に追いかけられるスタッフがいる組織なら大丈夫でしょうが、あくまでサービスを構成する1要素、1ツールとして利用するにはまだ「何かあったときに自分でケツを拭くこと」のハードルはまだ高いのかな、と思います。
どこで使うのがいいの？
そんなわけで、現状弊社内でのDocker利用は主にテスト・開発環境に留まります。一部本番系で利用しているサービスもありますが、それはDockerがうまく利用ケースにマッチした場合のみで、インフラを含めた全Docker化の様なagressiveな利用はしていません。
テスト・開発環境での運用については最悪ぶっ壊れても影響範囲が小さいことと、テスト・開発環境に使うCPU/メモリリソースの節約の観点から効率的であるということから採用しています。また、テスト・開発環境でしばらく運用してみることで、今後本番環境での利用も視野に入れた評価をできるということも狙っています。
Dockerをもっと気軽に使いたい
本番ではまだちょっと恐いかもしれないけど、触ってみないと使えるかどうかも分からないじゃないか！というわけで、もっと気軽にDockerを使いたい、、、ですよね。
Dockerって難しい？
Dockerについて調べると、単機能のcontainerを使った運用の例がモデルケースとして挙げられることが多いです。
そういった流れの中では、MySQLやMemcached等のサービスごとにcontainerを分けることで、一つ一つの管理単位を小さくまとめたり交換が容易になるといった昨今のマイクロサービス的な考え方にも通じる話が思想として出てきます。
こうした考え方はDockerの設計思想であり基本なので、理解しておくことに超したことはありません。実際用語定義レベルは流石に理解していないと運用そのものに支障を来すので理解すべきです。
・・・しかし、本当に今運用しているサービスをそんな簡単にcontainerに分離できるものなのでしょうか？
Dockerガチ勢の意識の高さと実運用の狭間で
本来のDockerの思想に則ったDocker運用を行う人達を社内（の一部）では「Dockerガチ勢」と呼んでいます。Dockerガチ勢の作るシステムは、各Docker ImageはDockerfileが提供され、手元でビルドからでき、一つ一つのcontainerはなるべく単機能に閉じており、複数のdaemonを組み合わせて動くようなサービスは複数containerで構成されていたりします。
これらのシステムはもちろんDockerで構築されるインフラとしてはあるべき姿なのですが、正直なところそこまで小さなcontainerに分離するのは面倒なのです。
複数containerを連携させるのが面倒臭い
Docker Containerは単体ではVMに近い使い方ができますが、container同士で通信をさせようとすると途端に面倒になってきます。container Aとcontainer Bの間で通信させたいと思ったとき、A <-> Bで相互にIPなりネットワークなりを繋ぐ設定を書かないといけなくなったり、このネットワーク周りは現在進行形で結構Dockerの仕様が大きく変わっていっている部分でもあります（クラスタ対応とか考えるとこの辺は元々難しい部分なので仕方ないですが）。
単純に1プロセス分だけ接続すれば良ければまだ管理できそうではありますが、監視系も動く様にしたりなど考えていくと割と早い段階で考えるのがおっくうになってきます。
沢山のcontainerを管理するのが面倒臭い
containerが増えればそれだけ管理するのも面倒になってきます。表から見ると1つのサービスなのに、裏では複数のcontainerが動いているとなると監視対象も増えますし、基本ライブラリ関連のアップデートがあればそれぞれのcontainerで対応する必要があります。うーん、考えるのがしんどい。
Dockerfileをきれいに保つのが面倒臭い
DockerfileはChefやAnsibleのrecipeの様なもので、なるべくきれいに保たれているのが良い状態であるのは確かだと思いますが、これをきれいに保つのは思いの外面倒だったりします。
Dockerfileを更新するまでは良いのですが、動作検証をするにはdocker buildせねばならず、動いているcontainerを修正するのなら簡単なのに・・・といったことは割とよくあります。
ゆるふわDocker部のススメ
そんなわけで、弊社社内ではまずは意識の高さには多少目を瞑りつつ、なるべく実運用に載せやすい方法を模索してきました。その結果、Dockerガチ勢に対してゆるふわDocker部を自称して少しずつDockerに慣れようとしています。
以下、ゆるふわDocker部のDocker運用の一端を紹介します。
containerはモノシリックに。1 container 1サービスに詰め込む
MySQLもRailsも、1つのサービスの構成要素は全て1つのcontainerに詰め込みます。イメージとしては1 VMで構成されたシステムをまるごと1 containerに入れる形となります。
これにより、開発者間でcontainerを受け渡す時もdocker export|importするだけで済みますし、開発環境用Dockerサーバでdocker psしたときに大量のcontainerに面食らうこともありません。
Dockerfileの管理は諦める。受け渡しはDocker Imageで
きれいなDockerfileを書くことは諦めます。受け渡し・移動の際はdocker exportしたイメージを使い、container内の設定が必要になったときは潔くshellを叩いて直接修正します。
これにより、containerの設定変更は実質テストサーバで動いているものを直接修正するのと同じ手間でできるので、ほとんどDockerを意識せずに利用することができます。
今動いているサーバを丸ごとDocker Imageにして動かしちゃう
そもそもcontainerを構築する際、新規でcontainerを作るのならともかく、既存サーバをcontainerにしたいということが良くありますが、そういう時は雑に丸ごとtarで固めてDocker Imageにしてしまいます。環境によって多少の微調整は必要ですが、kernelやネットワーク周りでの環境依存があまりないサーバであれば、大体そこそこ動きます。
本番環境として運用するにはきちんと検証してから使いたいですが、テスト・開発環境で一時的に動かしたいといったレベルであればこれで充分なことも多いです。
まとめ
そんなわけで、社内でのゆるふわなDocker運用について、軽く概要を書いてみました。それぞれの具体的なコマンドや注意点などは今後個別に書いていこうかと思いますが、本記事では意外とこんなに雑な運用でもDockerを便利に使うことができるということを紹介しました。
意識が高いのも良いのですが、意識の高さ≒ハードルの高さにも繋がるので、それが導入の障壁になるくらいなら多少は意識を下げて布教に努めるのもいいんじゃないの、というゆるふわDocker部でした。