アプリケーションのセットアップの手順といえば、通常はインストールマニュアルを書いてその通りインストールする、という流れをとるが、これが個人・環境ごとに差を生んでトラブルの原因となりやすい。一応、ChefやAnsibleのように、インストールを自動化するツールがあることにはあるが、依存するソフトウェア(やライブラリ・フレームワーク)のバージョン違いまでケアすることが難しい。あるアプリケーションのためにミドルウェアをアップデートしたら、そのミドルウェアに依存していた別のアプリケーションが動かなくなったというのはよくある話である。
仮想マシンを用いる動機は色々あるが、上記で述べたような問題を解決して、他のアプリケーションの依存関係に影響を受けない/与えない環境を確保するという目的で用いられることがある。
しかし、通常の仮想マシンの場合、基盤(ハードウェアエミュレーター)・ゲストOS・ミドルウェア・アプリケーションをすべて兼ね備えた形で作成するが、これは非常に重厚である。また、ホストとゲストのOSが共通の場合、ホストと同じOSをゲストに重ねて持たせるのも無駄である。
一方、Dockerではコンテナという軽量の箱の中でアプリケーションを動かす。Dockerでは下図のように基盤(ハードウェアエミュレーター)部分に関しては原則一切面倒を見なくてよいし、OS部分もできる限り共有可能。ミドルウェアやアプリケーション部分にだけ専念すればよい。
| Docker | 仮想マシン方式 | |||
|---|---|---|---|---|
| アプリケーション | コ ン テ ナ |
仮 想 マ シ ン |
アプリケーション | |
| ミドルウェア | ミドルウェア | |||
| Dockerによる カーネルエミュレーション |
ゲストOS | |||
| ハードウェアエミュレータ | ||||
| ホストOS(カーネル) | ホストOS(カーネル) | |||
| ハードウェア | ハードウェア | |||
上記のDockerによるカーネルエミュレーションは命令をほぼそのままホストOSのカーネルに渡すという作業になるため軽量の処理で済む。一方で、ホストOSと全く違うカーネルを動かすのは難しいので、Linux上でLinuxカーネルをエミュレーションするのが基本である。
2022年現在ではWindows上で動作するDockerも存在する。Windows版Dockerでは従来のLinuxカーネル用のコンテナ以外にWindowsカーネル用のコンテナの運用も可能である。
GUI出力機能はデフォルトでは付属しないので、サーバー用プログラムをコンテナ内で動作させるという用途が一般的。というかGUIが必要なら素直にVMWareやVirtualBoxなどの仮想マシンを使う。
従来の開発では開発環境で動いていたものが、ライブラリや細かい設定の違いにより実行環境で動かないという事態が頻発していたが、Dockerでは開発環境と同じ環境を実行先でも再現できるので、問題の発生が大きく軽減されるようになった。
また、1台のマシンで別々のソフトウェアに同じライブラリの異なるバージョンを使用させるということは弊害が大きかったが、Dockerではそれぞれを別のコンテナで実行すれば全く問題を生じない。
発展として、複数のコンテナを同時起動することが容易になったことにより、後述するKubernetesのように一つのコンテナが異常を起こしたら、バックアップコンテナに切り替える、といった耐障害性を持たせる運用が可能になった。
通常の仮想マシンでは、1台の物理マシン内に複数起動するとパフォーマンスの低下を招くので、強力なハードウェアを用意するか、あきらめて複数台の物理マシンに分散するという手段を取らざるを得なかった。
Dockerでは、コンテナの軽量化によりそこまで強力なマシンを用意しなくても仮想マシンより多くのの仮想コンテナを扱えるようになった。これにより粒度の細かい役割分担が可能になった。
たとえばWebサーバー機能ととそれに接続するデータベースサーバー機能を、仮想マシン2台分のリソースが用意できないのであれば、1台の仮想マシン内に同居させなければならないが、DockerならWebサーバーとデータベースサーバーを別々のコンテナに構築する方式が主流である。
複数のコンテナが相互に協働して一つのアプリケーションを構成する様を、オーケストラに例えてコンテナオーケストレーションと呼ぶ。
1台の物理マシン(OS)上で複数のコンテナを扱う場合、Docker Composeを用いるのが2022年現在では主流である(以前は本家謹製のDocker Swarmというものがあった)。
yaml形式で設定を記述する。
さらに高度なオーケストレーションを実現するツールにKubernetesがある。こちらはどちらかというと、メインの物理マシンが故障したらサブマシンの仮想コンテナに切り替える、といったような複数の物理マシンに分散配置されたコンテナを管理する目的に適している。
しばしばi18nの要領でk8sと略記される。
Kubernetesで用いるコンテナについては初期からDocker以外のコンテナを受け入れる設計だったものの、デファクトスタンダードであるDockerが主流だった。しかし、後発コンテナ技術の多様化が進んで2022年からはKubernetesにおいてDockerはむしろ非推奨になっている。
詳細な使い方は後述するが、OS(ディストリビューション)のインストールとミドルウェアやライブラリのセットアップが済んだ「イメージ」を元に「コンテナ」を作成し、「コンテナ」を運用するという使い方になる。
イメージは静的なものであるのに対し、コンテナは実行中・停止中などの状態を持つ。オプションなどで指定しなければ、コンテナは停止後も実行後の状態を保持して残り、再開することも可能である。
Dockerの開発元であるDocker社が運営するDocker Hubという公式サイトがある。このサイトでは各種(言語やミドルウェア)処理系の開発元が各自の処理系を既にインストールした公式イメージ(Docker公式のものと処理系開発元の公式のものがある)などが多数公開されている。実際の開発では素のOSコンテナイメージではなく、そういった処理系の公式コンテナイメージを基盤にイメージを作成することが多い。従ってイメージ名は処理系+OS名+処理系バージョンのような命名になっていることが多い。
ただし、Docker Hubは公式サイトとはいえ、公式イメージ以外に誰が作ったのか分からないイメージも多数アップされているので、使用は自己責任で。
ちなみに、Docker Hubを見ていると頻繁に出てくる"alpine"は、超軽量のディストリビューションAlpine Linuxをベースにしたコンテナイメージであることを示している。
Dockerのインストールであるが、各OSごとに異なるので簡単に説明すると、
からインストーラをダウンロードしてインストールする(個人使用、もしくは250人以下かつ年間売り上げ1000万ドル(約11億5000万円)以下の組織であればDocker Desktopは無料で使用可能)。docker-composeは初めから付属しているに従ってインストール可能であるといった具合である。
まずはdocker run --rm hello-worldとコマンドを打ってみよう。これで何が起きるかというと、
ニコニコ動画でDockerの動画を見に行く
--rmフラグをつけているので、コンテナを削除するDockerイメージを作るには、Dockerfileというファイルを作成する必要がある。簡単に言えば、設計図である。Dockerfileの構造は、
という、大きく3つのパートに分けられる。先ほどのhello-worldイメージのDockerfileを解説すると、
FROM ubuntu:20.04と記述するという意味になる。Dockerfileを作成したら、docker build -t [イメージ名]:[イメージタグ] .というコマンドを、Dockerfileのあるディレクトリで実行する。なお、イメージタグ部分は省略可能で、その場合は、latestタグが補完される。
Dockerのマスコットキャラはコンテナを背中に載せたクジラ。下記はDockerタグに引っかかってるが、クジラをモチーフにした潜水艦の絵という設定で直接の関係はない。
: 各種公式コンテナイメージが集まるHub
: 長文記事だが歴史についても詳しい
掲示板
掲示板に書き込みがありません。
提供: 66
提供: 高坂一臣
提供: 綾瀬瑠璃葉
提供: 猫牛
提供: kuu
提供: 痔獄の鬼灯さん
急上昇ワード改
最終更新：2025/04/21(月) 12:00
最終更新：2025/04/21(月) 12:00
ウォッチリストに追加しました！
すでにウォッチリストに
入っています。
追加に失敗しました。
ほめた！
ほめるを取消しました。
ほめるに失敗しました。
ほめるの取消しに失敗しました。
