Dockerとコンテナオーケストレーションツール

1. Docker

1.1. 概要

ホストマシンのLinuxカーネルを利用して、ホストマシンとは別のLinuxディストリビューションで仮想環境を起動できるソフトウェアで正式には「Dockerエンジン」。
Docker上で動作する各仮想環境は「コンテナ」と呼ばれる。仮想環境への環境設定の手順(各ソフトウェアのインストールなど)は、ファイルにコードとして記述。

LinuxカーネルとLinuxディストリビューション

Linuxディストリビューション
普段我々がイメージするLinux OS。RedHat, Ubuntu, CentOSとか。

Linuxカーネル
各Linuxディストリビューションが共通で使っている、心臓部となるソフトウェア。

仮想化技術

1台の物理マシン上(ホストマシン)で複数のOSを動作させ、それぞれ別システムとして同時に利用できる という技術。
ハイパーバイザ型、ホスト型、コンテナ型という区分がある。

ハイパーバイザ型

ホストマシンにインストールした「ハイパーバイザ)」というソフトウェア上で仮想環境のOSを動作させる というもの。ホストマシンはOS必要なし (例. VMWare

ホスト型

ホストマシンのOS上で、専用のソフトウェアを介して仮想環境の別OSを動作させるというもの (例. VirtualBox)

コンテナ型

ホストマシンOS上で、専用のソフトウェア(コンテナエンジン)を介して仮想環境を動作させるというもの。仮想環境では、OSはインストールされているわけではなく、ホストマシンのOSのものを共用させてもらう形。

個人的なイメージ

• ハイパーバイザ型: 小さな家を建てるのに適した土地を用意して、その上に小さな家を建てる。小さな家が仮想環境。
• ホスト型: 大きな家の中に小さな家を建てる。小さな家1つ1つが仮想環境。
• コンテナ型: 大きな家の中を壁で仕切って部屋を作る。部屋1つ1つが仮想環境。

1.2. 利用するメリット

• 高速な起動: 仮想環境用のOS(ゲストOS)が不要なため、旧来の仮想化技術だったハイパーバイザ型、ホスト型より高速
• 内部環境の設定を管理しやすい: コードで設定を記述するため、Git等でバージョン管理しやすい
• 高い可搬性: ホストマシン上でLinuxカーネルが動作していれば、同一環境の仮想環境を容易に構築・利用できる

あれ？MacやWindows環境でDockerを利用するときって・・・？

Web系の開発やってるのであれば、開発用のマシンがLinux・・・というのは結構マレで、たいていはMac もしくは Windowsだろう。
これらはLinuxカーネルを利用したOSではない。

これらのOSでDockerを利用する場合には、Docker Desktopというソフトウェアをインストール&起動した上で、コンテナを起動して利用するという流れになるわけだが、
この際、例えばMacなら、HyperKit というLinuxの仮想環境を起動し、その上でDockerコンテナが動作することになるらしい。

つまりは
MacOS -> HyperKit -> Linuxディストリビューション というホスト型の仮想環境の構成があり、
この仮想環境であるLinuxディストリビューションを基盤として、
Linuxディストリビューション -> Dockerエンジン -> Dockerコンテナ というコンテナ型の仮想環境の構成がある・・・
という形で利用している、というワケ。

2. コンテナオーケストレーションツール

2.1. コンテナオーケストレーションとは

複数のコンテナに対する運用管理作業のこと。

• 各コンテナの監視
• あるコンテナに異常があったときに停止させ、別コンテナを起動するクラスター管理
• コンテナの負荷状況に応じてコンテナ数を増減させるスケーリング
• アクセスの分配
  これらの作業を自動化してくれるのが、オーケストレーションツールである。
  各コンテナ個別のDockerfileは、別途記述してある前提で、それらとは別にオーケストレーション専用の設定ファイルを記述した上で、オーケストレーションツールに諸々やってもらう・・・という流れになる。

オーケストレーションツールは色々あるが、筆者の経験上、以下のように使い分けされている現場が多いように思う。

• ローカル環境: Docker Compose一択
• クラウドを利用した開発環境、テスト環境、ステージング環境、本番環境: 本番環境で使うオーケストレーションツール

次に、デファクトスタンダードな2大オーケストレーションツールについて説明する。

2.2. Docker Compose

小規模なプロジェクトの環境を構築する際のデファクトスタンダード。経験上「ローカル環境の構築のみ」に使っている現場が多い。
Docker Desktopをインストールすると同時にインストールされる。
オーケストレーションに必要な設定ファイルは1つで、シンプル&直感的に操作できる。
1ホストマシンでしか使用できず、スケーリングや自動復旧機能は限定的で、複雑なことはできない。
Docker社が開発。

2.3. Kubernetes

大規模プロジェクト、クラウド環境向けのデファクトスタンダード。
3大クラウドベンダー(AWS, GCP, Azure)ともに Kubernetesに対応したサービスを提供している(EKS, GKE, AKS)。
スケーリング、ローリングアップデート、自動復旧機能を備え、非常に複雑なデプロイ工程にも対応できる。
設定が複雑で、学習コストも高い。
Google社が開発し、OSS化された。

その他、各クラウドベンダーが提供するオーケストレーションツールのマネージドサービスについて。

2.4. EKS(AWS)

Kubernetesベースのマネージドサービス。

2.5. ECS(AWS)

AWSのEC2やFargate上で複数コンテナをオーケストレーションできるマネージドサービス。オーケストレーションの機構はAWS独自。

2.6. GKE(GCP)

Kubernetesベースのマネージドサービス。
扱うにはKubernetesの知識が必要。
Kubernetesの機能をフル活用して詳細なカスタマイズをしたい場合、ステートフルなアプリケーションをデプロイしたい場合に。

2.7. Cloud Run services(GCP)

Kubernetesベースのマネージドサービス。
扱うにあたってKubernetesを意識しないでよい。
ステートレスなアプリケーションのみサポート、リクエストタイムアウト(60分)の制限があるが、人的管理コストを抑えたい場合に。

参考