BFT名古屋 TECH BLOG

日々の業務で得た知識を所属するエンジニアたちがアウトプットしていきます。

トップ > Docker > 【コンテナおじさん】【Docker】コンテナ学習第3回

【コンテナおじさん】【Docker】コンテナ学習第3回

Docker コンテナ

はじめに

こんにちは！BFT名古屋支店の松野です。
前回はコンテナ技術の詳細と最も有名なコンテナエンジンであるDockerの概要についてまとめてみました。
今回はDockerについて前回よりも踏み込んだ内容をまとめていきたいと思います！！
それではよろしくお願いします。

前回の記事は以下リンクからどうぞ。

bftnagoya.hateblo.jp

コンテナおじさんって何？という方は以下リンクからどうぞ。

thinkit.co.jp

Docker概要

Dockerとは現在最もよく使われているコンテナエンジンであり、コンテナへの基本的な操作を「Build, Ship, Run」というシンプルなワークフローによる運用を定着させました。
アイコンのクジラのマークは一度は見たことがあるのではないでしょうか。

f:id:bftnagoya:20210127143714p:plain:w300
Dockerロゴ

それではDokcerの「Build, Ship, Run」についてもう少し掘り下げていこうと思います。

①Build

Buildとはコンテナの素となるコンテナイメージを作成する機能のことです。Dockerにてコンテナイメージを作成するためにはいくつか必要なものがあります。
具体的には

  • Dockerfile
  • Context

以上の二つが必要になります。Dockerfileはコンテナの作成手順書であり、Contextはコンテナに格納するプログラムなどのファイル群です。これらをDockerに渡すとDockerはDockerfileに記された手順に従い、与えられたContextを用いながらコンテナイメージを作成していきます。

f:id:bftnagoya:20210128112052p:plain:w600
Docker Buildのイメージ

②Ship

それでは次にShipについてまとめていきましょう。コンテナを使用する多くの目的がその高いポータビリティを利用して、様々なホストで任意のアプリケーションを実行することです。ホスト間でコンテナイメージを共有するための要となる機能です。
Dockerによって作成されたDockerイメージは「レジストリ」と呼ばれるイメージ配布用のサーバを通じて他のホストと共有されます。レジストリには多くのものがあり、Docker社もDocker Hubを提供しています。その他にもAWS ECRなどの主要クラウドベンダが提供しているものを利用したり、プライベートリポジトリを構築することも出来るようです。
Docker Hubを利用してレジストリ上に「リポジトリ」と呼ばれるイメージの格納場所を作成し、そこにイメージを格納します。リポジトリはレジストリ内に複数作成することができ、それぞれのイメージは「タグ」と呼ばれる文字列を付けて識別されます。また、図中にあるようにレジストリにイメージをアップロードすることをpushといい、ダウンロードすることをpullといいます。

f:id:bftnagoya:20210128152512p:plain:w600
Docker Hubのイメージ

③Run

最後は「Build, Ship, Run」のRunです。ここではまずDockerイメージについて詳しく見ていきましょう。
DockerイメージはUnion File System（UFS）という複数のファイルやディレクトリをレイヤとして積み重ねて、仮想的に1つのファイルシステムとして扱う技術を用いています。土台となるベースレイヤの上にイメージ作成（Build）時に作成される読み込み専用のイメージレイヤが重ねられており、Dockerイメージ起動（Run）時にコンテナレイヤと呼ばれる読み書き可能なレイヤが加えられます。

f:id:bftnagoya:20210129150038p:plain:w600
Dockerイメージの起動（Run）イメージ

上記のようにDockerイメージが実行されることにより、あらゆる環境（ホスト）でDockerコンテナが使用できるようになるだけでなく、同一のホスト上に複数のコンテナがある場合はイメージレイヤを共有でき、それによりストレージ容量を抑える効果も期待できるようです。

複数コンテナの管理

コンテナに関する基本的な考え方として「一つのコンテナが扱うのは一つのプロセスにする。」というものがあります。複数のプロセスを同一コンテナに含めることも可能ですが、プロセスとして実行しているアプリケーションのアップデート等でコンテナを入れ替える必要が出てきた時に、他のプロセスに影響が出てしまうことを防ぐためです。また、この考え方を利用して例えばプログラミング言語をバージョン毎にDockerイメージとしておいて、必要に応じて使い分けるといった運用もするようです。
このように、Dockerをはじめとしたコンテナ技術を利用する時は同一ホストに複数のコンテナを実行することが一般的であり、そういった複数コンテナの管理のコストを削減するために開発されたのが「Docker compose」や「Docker swarm」といったツール群です。詳細は次回以降にまとめていこうと思いますが、こういったツールを利用することにより、手軽にあらゆるホスト上にコンテナを利用してあらゆる環境を構築できるようになりました。

おわりに

今回は前回と引き続きDockerをメインにまとめさせて頂きました。
次回以降はコンテナオーケストレーションシステムであるKubernetesについてまとめていこうと思います！と言いたいところですが、自分の理解がやや不足しているので実際にDockerを導入してみようと思いました。
ここまで読んで頂きありがとうございました！！

参考文献