大人の学びなおしDocker（2）～中身編～

はじめに

前回はDockerの基礎の部分についておさらいしました。
ちょうどDockerの中身についてとても良い記事を見つけたので、今回からはDockerの深い仕様について少しだけ学びたいと思います。

Dockerとdeamon、Runtime

まず、Dockerの構成は以下のようになっています。本来はDocker Engineの上にDocker Swarmがいますが、今回は解説しないので省きます。

Docker Engine（デーモン） は

• クライアントから受け付けたコマンドの処理（docker pull, docker buildなどなど）
• コンテナイメージの管理
• ボリュームの管理
• ネットワークの管理

などの仕事を受け持ちます。Docker EngineはAPIを公開しており、私たちがdocker pullなどのコマンドを叩くとその指示がDocker Engineに届きます。

Docker Engineの下にいるRuntimeはcontainerdとruncを含みます。これらRuntimeは主にコンテナの起動や停止を行います。コンテナのライフサイクルに関する機能はcontainerdが主に担っていますが、コンテナを作成することまではやりません。「何言ってんだ？」 って感じですが、containerdがやるのはコンテナ作成の指示を送るだけです。実際にはcontainerdの下にいるruncがコンテナを作成します。

runcはコンテナを作るとプロセスを終了します。そのためruncのプロセスが無限増殖することはありません。コンテナもプロセス共々死ぬんじゃ？と思いますが、コンテナは生き残ります。

runcは死ぬが、コンテナは死なない

コンテナを作ったruncが死んでいるのにコンテナが生き残っている理由として、shim という存在があります。

このshimはruncが死んだあとでコンテナの親プロセスとして動きます。そのためruncのプロセスだけ落としてもコンテナは死なず、逆にコンテナが終了した場合はこのshimのプロセスがDocker Engineに終了ステータスを伝えてくれます。

Docker EngineとRuntimeが分かれている理由

Docker EngineとRuntimeが分かれていることで、「Docker Engineが動かなくてもコンテナは稼働し続ける」というメリットがあるようです。

もしDocker Engineが不具合で停止してもRuntime側が生きていればコンテナは稼働し続けるし、Docker Engineにアップデートをかけたいときもコンテナを停止せずに実行できます。

まとめ

• docker engineはコンテナを作らない。APIの公開やボリューム管理・ネットワーク管理などをする
• Runtimeにはcontainerdとruncがいる。実際にコンテナを作るのはruncの方
• コンテナは死なないわ、shimが守るもの

参照：https://medium.com/@dmosyan/deep-dive-into-docker-containers-architecture-and-features-530a937f4c87