💨

なぜDockerを導入するべきか:Dockerアーキテクチャ、メリットについて

2025/02/02に公開

前置き

以前の記事ではDocker公式ページで初回している内容とVMについてお話して見ました。

Docker公式ページではDockerを利用することによって
インフラの分離最速なリリースが可能って言うことをアピールしています。

でも実際我々のIT業界ではインフラの分離最速なリリースのために、
一つのサーバーに複数仮想OSを立てる、VM(Vurtual Marchine)技術を使っています。

そう言うこうはDockerは嘘をついているでしょう。

今回はこの既存のVMの代わりに
Dockerを導入すればどんなメリットがあるかについてお話したいと思います。

以前の記事の内容は以下をご覧ください。
https://zenn.dev/nitro/articles/939e103ae85efe

VMと比較


前回の記事で使った例をそのままDockerに切り替えた場合の構成になります。

Hypervisor代わりにDocker Engineが入って
Guest OS代わりにContainer(プロセスに近い)が入ります。

全体的な構成としては変わることはないですが、

VMの場合、Geust OSをセットアップするため、
環境毎にKernalも作成されますが

Dockerの場合はContainer
そのため、Docker Hostのターミナルを利用して各Containerを制御可能ことになりますが
セキュリティー的な問題があります。

つまり、Host OSをハッキングすれば全てのContainerを制御できることになります。

まとめると以下のようになります。

  • エンジン
    VM(Hypervisor) ↔ Docker Engine
  • 単位
    Geust OS ↔ Container
  • Kernal
    Geust OS別 ↔ 共有

構成的にはあまり変わったことがないように見えますが、
OSをセットアップしないことによってブート速度イメージ/サイズ減少と言う効果があります。

Kernal共有に関しては微妙な感じになりますが、
Kernal共有によって特に設定しないと
Host OSの権限があれば全Containerの制御が可能になります。

逆にVMの場合は各OSを持っているので、OSに接近可能な権限が必要です。

Dockerアーキテクチャについて

Dockerの全体的なアーキテクチャは上の画像通りです。

一般的にはTerminalDocker Desktopを、その中でもDocker Desktopを使うと思います。

ご覧の通りdockerコマンドをターミナルで入力したらDocker CLIがコマンドを解析
その後、Docker Daemon内のREST基盤で作られたDocker APIにRequestします。

Docker APIに届いたRequestによって、
つまり画像の例だとしたらbuild,run, pullによって実行されるプロセス/結果が違います。

buildの場合はDocker Host内に存在するDockerイメージをビルド、
runの場合はDocker Host内に存在するビルドされているイメージを稼動
pullの場合はDocker Host内に存在しないイメージを外部のサーバーからダウンロードします。

なぜDockerを導入するべきか

結論から言うとDocker導入することによって
以下のメリットがと自分は思っています。

  • サーバー運用
  • マイクロサービス
  • 有効なリソース管理
  • 「本番環境」と「開発環境」を統一する

なぜDockerを導入するべきか: サーバー運用

まずはサーバー運用からです。

レガシーシステムやアプリでよくあるパターンです。

もしこのシステムやアプリがDocker上で存在するんであれば
(もしくはDockerイメージが存在するんであれば)

docker buildコマンド実行だけでそのまま環境構築が終わります。

その後、docker runコマンドを実行すると、
どんなHost OSでも同様な環境が簡単に作れます。

もちろんHost OS上にdockerをインストールが可能ことが前提になりますが
むしろDockerをインストールできない環境を探すのが難しいと思いますので
デメリットはほぼないかと思います。

Dockerを導入すると一つのサーバー上にレガシーシステムと新規システムを同時にサーバー運用が可能になります。

さらに、2~3年毎にHost OSのサポート終了によってOSの交換またOSのアップデートが必要な場合がありますが
Dockerで運用している場合、各システムもイメージ化することでサーバー遷移も簡単に可能です。

マイクロサービス

簡単にコンポーネント単位で運用も可能ですのでマイクロサービスもできます。

一般的のサイトでのAPIなら最初データをfetchするコンテナと
ユーザー認証するコンテナを分けて運用・保守する方が良いかと思います。

もちろんマイクロサービス化して、
想定した効果が出るので別の問題ですので
既存のシステムをマイクロサービスする時には十分検討する必要があります

マイクロサービスが可能ことによって、 有効なリソース管理も達成できます。

「本番環境」と「開発環境」を統一する

一般的にはサーバーと開発端末のOSが違うので、
本番リリースした時に想定外のエラー発生する時がよくあります。

Dockerを使うと開発端末上に同じ環境のイメージ上で開発が可能ですので
どんな端末で開発しても環境によるエラーは発生しないでしょう。

Dockerライセンスについて

残念ならが、2023年2月からライセンス変更によって
大企業(従業員が 251 人以上、または、年間収入が 1,000 万米ドル以上の会社)の場合、ライセンス代を払わなければなりません。

ただ、Docker Desktopのライセンス、
つまりDocker Engine EE(Enterprise Edition)のライセンスになるので

Docker Engine CE(Community Edition)とDocker CLIをサーバーに直接セットアップすると
環境設定に少し手がかかりますが無料で使えます。

この場合、ビジニス的にはサポートをもらえないため、
Dockerで運用するであれライセンスを購入するほうが良いかと思います。

終わり

ここまででDockerについて紹介しました。

いかがでしょうか。

おそらく、現時点ではほぼDockerを利用する方が良いかと思います。

自分が思うには逆に使わないことによって
他のチームと比較して生産力が低くなるのは当然なぐらいです。

もちろん新しいツールの導入はその分のラーニングカーブが発生してしまいますが、
せめてDockerの場合は今後を考えてもその分の価値はあると思います。

GitHubで編集を提案

Discussion