あえてDockerを使う理由

Docker(ドッカー)を使うようになってから3年余りが経ち、やっと普通レベルに到達した気します。
特に最初は、知りたいことを調べるのに時間がかかって苦労しました。

なんで、時間がかかったかと言うと、(たぶん)世間が知りたいことと自分の知りたいことがミスマッチなのかな・・・と思っています。

今回は、あえて Docker を使う理由をまとめてみました。

※ちなみに、Docker 一辺倒というわけではなく(諸事情から)Hyper-V, VMware を併用しています。

目次

仮想化の歴史をおさらい

私が仮想化技術に触れてから20年近くが経ちました。

初めて仮想化に触れたのは、VMware Server(今は Player のみですね)や Windows Virtual PC(こちらも今はないですが Microsoft 謹製です)でした。

※今は無き VMware Server は、クライアント版 Windows で稼働する唯一のサーバ版でした。
(VMware Server は、クライアント版 Windows 対応の仮想化ソフトウェアで唯一アプリケーションを閉じてもサービスが稼働する製品でした)。

最初に使ったのは Windows 版でした。
最初は、システム基盤の整備(をトライ&エラーで確認する)ために使いました。

当時、しくじると環境から作り直していた私には(あまりに多くの時間が短縮できることになり)衝撃でした。
今思うと、これが仮想化にのめり込むきっかけだったのでしょう。

気がつくと、重要度の低い社内サービスには(画面を閉じてもサービス継続可能な)VMware Server を使い、開発用には Windows Virtual PC を使うようになっていました。

これら仮想化技術では、

  • (現行の VMware Workstation Player や Oracle VM VirtualBox 同様に)物理マシンで稼働する OS を「ホスト OS」
  • 仮想化ソフトウェアを経由してインストールした OS が「ゲスト OS」

として稼働することになります。

マシンスペックにも依りますが(当時の PC だとデュアルコアが一般的だったと記憶しています)、1台のマシンに2つ程度なら同時運用できたと思います。
※もちろん、同時稼働させなければもっと多くの環境を構築できました。

仮想化の醍醐味はここで

  • 1台の PC 上に複数の OS をインストールして環境を構築でき
  • しかもそれぞれは隔離されていて互いに干渉しない

ことにつきます。

これは、構築したゲスト OS 上で何か不具合があっても、他のゲスト OS には影響しない(もちろんホスト OS にも影響がない)ことを意味します。
※さすがに、リソースが枯渇するとホスト OS も不安定になりますが..。

これら仮想化技術は(当時は)サービスを止める必要はあったものの(仮想化本体となる)物理ファイルをコピーしておけば、いつでも手軽に元の環境に戻せる、というのは複雑なインフラ構築の際には頼もしく感じました。

DB などのミドルウェアをバージョンアップする際は、事前検証に大いに役立てさせてもらいました。

Dockerとは

本題の Docker(ドッカー)は、ここ10年ほどで登場した製品(サービス)です。
上記、仮想化より後発ですが、実は使われている技術自体は古くからあるもので、スペック(マシンパワー)の向上と(仮想化が浸透したことによる)ニーズの拡大が、登場を後押ししたように思えます。

上記、仮想化と対比して「コンテナ型」や「コンテナ型仮想化」などと呼ばれます。

この Docker を一言で表すと、以下のようになります。

Docker は Linux のコンテナ機能を用いて「複数の環境を用意する」ソフトウェア

Docker は Linux 上でサービスとして動きます。
そして、Linux に以前からあるコンテナ機能を利用して、複数環境の同時稼働を実現しています。

Docker(コンテナ機能)を使うと、何ができるのでしょうか?

  • プロセスを複数のグループに分ける
  • 各々のグループごとに、異なる環境を用意できる
    従来からある chroot などを使い、グループごとにアクセスするファイルを割り振ったりして実現します。
  • 環境が分離された各々のユーザ空間は、互いには見えない
    親 OS となる Linux 上からは、すべて見えます。

ざっくり、上記のようなことが実現されています。

ここでは便宜上、Docker サービスが動いている OS 環境を「ホスト環境」、Docker サービスで稼働する OS 環境を「ゲスト環境」と呼ぶことにします。

DockerはLinux環境で使うべし

意外なんですが「Docker はクロスプラットホーム対応ですよね」と言われることが多いので、改めて違いますよと。

結論

なんで Docker は Linux で使うべきと思うのか、ということですが、別の OS で使うとオーバーヘッドが大きいと感じているからです。

Docker for Windows

Windows 版 Docker は、実際には以下が(インストールされて)実行されます。
※Linux 環境を仮想マシンとして保持する格好です。

  • Hyper-V
    Windows Server エディション、Windows 10 などは(Docker の代わりに)Hyper-V が実行されます。
  • Oracle VM VirtualBox
    Windows 10 Home などの Windows Home エディションは(Dockerの代わりに)VirtualBox が実行されます。
    ※Home ディションは、Docker Toolbox をインストールします。

Docker for Mac

macOS の場合は、Hyperkit VM(Alpine Linux ベース)を使うことになります。
※従来通り VirtualBox を使う方法もあります。

元が Linux ではない(macOS は BSD です)ので Windows 同様、別の場所に Linux 環境を持つのです。

Linux が最適な理由

Linux 版のネイティブな Docker は、(ゲスト環境も一貫して)ホスト環境にあるカーネルを利用します。

仕様

Docker は、Linux のコンテナ機能を利用して(Linux のカーネルを共有して)いるため、Linux 以外の OS を稼働させることができません。

問題点

(オーバーヘッドが少なく)非常に便利な機能ですが、ホスト環境のカーネルを共通で使うことで問題が起きることもあります。

原理上は、新しいカーネル環境で作られた Docker コンテナを、古いカーネル環境(OS 環境上)の Docker へ移行して、且つ、新しいカーネルにのみ存在する機能を呼び出せばエラーになります。

まぁ、古い環境へ移行するパターンは多くないとは思いますが。。。

それでもWindows, macOSで使う理由

ネイティブ Docker 環境でなくても Windows や macOS 版を利用する理由について自分なりにまとめてみました。

  • 仮想環境だから安全
    (Linux のコンテナ機能ではなく)実質仮想環境のため、仮想環境の知見があれば運用できる。

  • Docker の管理ツールを使って、運用したい
    Docker 社提供の管理ツールを使いたい場合も、候補になるのでしょう。