【Docker】Docker初心者がコンテナ技術に触れて覚えたこと①

こんにちは、キクです。

みなさん、Dockerという技術をご存知ですか？
比較的メジャーな技術なのでご存知の方も多いかもしれませんね。
僕はというと、Dockerのことは以前から知っていましたがちゃんと勉強したことがありませんでした。

「Dockerは知ってるけど、どうやって使うんだろう？」
「DockerイメージとかDockerファイルって何が違うんだろう？」

そんな疑問を持った状態でした。
そして「基礎的な部分でもいいから一度勉強してみよう！」と思い、少し前からDockerを実際に触りながら勉強をしています。

今回は『Dockerの基礎』をテーマに書いていきたいと思います！
先にお伝えしておきたいのですが、本記事は「ザックリとDockerを理解したい方向け」です。

とはいえ、概要は掴めると思いますので「ザックリでもいいからイメージを掴みたい」という方はこのままお付き合いいただければと思います。

また、僕自身が初心者であることからDockerをあまり触ったことがない人に寄り添える記事を書けるのではないかと思いました。
初心者だからこそ分からない部分や理解しにくい部分を少しでも共有できればと思います。

「Docker 初心者」とかで検索したときに、コマンド内容とかその結果の羅列とかは結構あってもシンプルな図を用いた解説などは意外と少ないように思いました。
初心者としてはそもそもDockerの概念が分かりづらかったりしますよね。
なので本記事では自作の図を用いてお話ししていこうと思います。

今回は前半/後半の2回に分けて書いていこうと思います。
前半パートの本記事では以下2点をお話しします。

Dockerの基礎的な登場人物
コンテナの作成について

後半パートの次回の記事では以下3点についてお話ししようと思います。

コンテナからの入退室について
Dockerイメージの作成・更新について
Dockerファイルの内容とコンテナの関係について

それでは、よろしくお願いします。

本記事の内容

Dockerの基礎的な登場人物
コンテナの作成について
- 「pull」して「run」する
- 「run」だけする

Dockerの基礎的な登場人物

まずはじめにDockerを触り始めてすぐに登場するものについてお話ししていきます。
ここで登場するものは本当に基本的な要素ですが、Dockerを使う上でなくてはならない存在です。

また、本記事ではおそらく通常とは逆の流れで各要素をご紹介しているのではなかろうかと思います。
これは「大は小を兼ねる」という言葉があるように、「大」の概念は「小」の概念も含みます。
これはつまり「大」を理解するには「小」の知識も必要ということで、それであれば「小」から説明した方が「大」も理解しやすいのではないかと思ったからです。

それではいきましょう。

コンテナ

まずは「コンテナ」について。
コンテナはDockerという技術のメインの部分です。

「〇〇をしたいけど自分のパソコンでやるのは怖いな・・・」
「本番作業の検証するための環境をサクッと作りたいな・・・」

そんなときにコンテナが便利です。

自分のパソコン（ホストOS）の中ににコンテナを作成して、コンテナの中で開発だったり検証だったりを行うことができます。
コンテナ内で何をしてもホストOS環境には影響がありません。

「やばい、大事なファイルを消しちゃった・・・」

となっても、自分のパソコンから消えるわけではないのです。
自分のパソコンに影響がないのであれば、コンテナでいろいろな実験ができそうですよね。
仮にコンテナの中身が壊れてしまっても、また作り直せばいいだけです。
開発環境としてはもちろん、学習環境としてももってこいですよね！

Dockerイメージ

次に「Dockerイメージ」について。
これは先ほどの「コンテナ」を作成するために必要なものになります。

またDockerイメージを他の人に渡すことで、その人のパソコンにも全く同じコンテナをサクッと作成することができます。
このサクッと感がDockerの大きな魅力かと思います。

「開発でこんなことをした。」
　　　　　　↓
「この環境をこのまま本番環境で使用したい」
　　　　　　↓
「本番機でDockerイメージからサクッとコンテナ作成でOK！」

これがもしコンテナじゃなかった場合、開発環境と同じ環境を本番環境で再現する必要があります。

あれとかこれとかをインストールして・・・
あれとかこれとかをバージョンアップをして・・・
etc・・・

大変ですよね。

でもDockerの場合は開発環境で使っていたDockerイメージから本番環境にコンテナを作成するだけで開発環境と全く同じ環境を作成できてしまいます。

便利ですね。

リポジトリ

続いて「リポジトリ」について。
これは先ほどの「Dockerイメージ」を入れておくための箱のようなものです。
このリポジトリという概念は僕が学習していく中で混乱した部分です。
なのでちょっと重点的にお話ししていこうと思います。

混乱した原因としては、学習中にこんな内容を目にしていたからです。

「Dockerイメージ名　＝　リポジトリ名」

僕としては「Dockerイメージを入れておく箱がリポジトリなのに、それがイコール・・・？」となりました。

ここで一度Dockerイメージに話を戻そうと思います。
リポジトリからホストOSにDockerイメージを取り込みたいときには、以下のような「pullコマンド」を実行します。

$ docker pull <イメージ名（リポジトリ名）>:<タグ名>

反対にホストOSからリポジトリにDockerイメージをアップロードしたいときには、以下のような「pushコマンド」を実行します。

$ docker push <イメージ名（リポジトリ名）>:<タグ名>

どちらのコマンドでも「タグ名」という新しい概念が登場しましたね。
このタグ名は「リポジトリの中にある各Dockerイメージを識別するためのもの」になります。

どういうことかというと、例えばリポジトリの中に「image」という名前のDockerイメージが２つあったとします。
この時、ホストOSから「imageをください」と言われたとしたら「どっちのimageですか？」となりますよね。

そんなときに必要なのがタグ名です。

image:tag1

image:tag2

こんな風にタグ名を付けていれば、ホストOSからは「tag2のimageをください」という明確な指定が可能になります。
こうすることで欲しいDockerイメージを間違えずに取得することができます。

次のコマンドはホストOS上に取得したDockerイメージ一覧を表示するコマンドです。

$ docker images

このコマンドにより、以下のような結果が表示されます

REPOSITORY      TAG        IMAGE ID         CREATED         SIZE
image           tag2       e5dd56412096     3 hours ago     73.9MB
image           tag1       c8971e894f6e     3 hours ago     73.9MB

上記はDockerイメージの一覧ですが、一列目の項目名が「REPOSITORY」となっています。

Dockerイメージ一覧なのになんでリポジトリが表示されているの？

実はこれは「pushコマンド」をするときのDockerの動作に関係があります。
「pushコマンド」を実行すると、Dockerイメージ名を元にpush先を決めます。
そのため、通常はDockerイメージ名をpush先すなわちリポジトリ名に揃えるそうです。
※この部分に関しては実業務でDockerを使用したことがないので学んだことをそのままお話ししています。

つまり、ここで表示されているREPOSITORYというのはリポジトリそのものを指しているのではなく、
「この名前のリポジトリにDockerイメージをpushするよ」というニュアンスに近いです。
そのため、ここで表示されているのはDockerイメージ名でもありリポジトリ名でもあるわけです。
これが僕が苦戦した「Dockerイメージ名　＝　リポジトリ名」の正体だったんですね。

同じリポジトリにDockerイメージを何個もpushしていくとなれば、必然的に同じDockerイメージ名になりますよね。
そうなってくるとそれらを判別するためにもタグ名は必要な要素であることが分かりますよね。

少し話がリポジトリから逸れてしまいましたが、結局のところリポジトリとは「リポジトリ名と同じ名前を持つタグ付きのDockerイメージを格納する場所」ということです。
※厳密には違ったケースもあるのかもしれませんが、現状の知識で僕が思うリポジトリとはこういうものです。

Docker Hub

最後の登場人物は「Docker Hub」です。
これは冒頭の図からも分かるように「複数のリポジトリを管理しているレジストリ」です。
とはいえってもこの手の技術を触ってこなかった僕としては

「レジストリってなんぞ」

というのが正直なところでした。

レジストリとは和訳すると「記載」「登記」「登録」などの意味があります。
つまりは「こんなリポジトリ達が登録されてまっせ」を把握しているデータベースとでも言ったところでしょうか。

そしてリポジトリの中にはDockerイメージが入っていますから、「レジストリ（Docker Hub）はDockerイメージを管理している」と同義になります。

先ほど「$ docker pull」コマンドを実行していたと思いますが、
実際にはその手前で以下のようなコマンドを実行します。

$ docker login

このコマンドを実行するとレジストリへのログイン情報を要求されるので、ユーザ名とパスワードを入力してログインをします。
「レジストリへのログイン情報」と記載したのは、レジストリが「Docker Hub」以外にもあるからです。

しかし本記事ではDocker Hubに絞って話を進めていきます。
・・・というより僕がまだDocker Hubしか触ったことがないからです。すみません(笑)

そしてDocker Hubにログインすることにより、そこで管理されているリポジトリのDockerイメージをホストOSに取得(pull)したり新たに登録(push)したりすることができるようになります。

コンテナの作成について

ここまでの話の中で、コンテナは「Dockerイメージから作成されるホストOSとは異なる環境」とお伝えしてきました。
それではどのようにしてDockerイメージからコンテナを作成するのでしょうか？

ここではDockerイメージからコンテナを作る２つの流れをご紹介して、前半パートを終えたいと思います。

「pull」して「run」する

「リポジトリ」の話の中でDockerイメージをホストOSに取得するために「$ docker pull」を実行していたと思います。
これにより、文字通りDockerイメージがホストOS内に存在する状態になりました。

「「pull」して「run」する」では一度明示的にDockerイメージを取得してからコンテナを作成します。
「pull」したDockerイメージを使ってコンテナを作成するためには以下のように「runコマンド」を実行します。

$ docker run <イメージ名（リポジトリ名）>:<タグ名>

「run」以降の部分は上記の例以外にもいくつかパターンがあり、例えばタグ名がなくてもコンテナを作成できたりもします。

$ docker run <イメージ名（リポジトリ名）>

しかし少し前の内容のような「image:tag1」「image:tag2」がホストOS上に存在していた場合、
タグ名を指定しなかったら「どっちのimage？」となってしまうわけです。

そのため、環境に応じて実行するコマンドは少しずつ変化していきます。
でもこれはDockerに限った話ではありませんよね。

「run」だけする

先の例では「pull」をしてから「run」を実行しましたが、「run」だけを実行した場合にはどうなるのでしょうか？

「runコマンド」を実行すると以下のようなことが行われます。

①ローカル（ホストOS）上にある指定されたDockerイメージからコンテナを作成しようとする
②レジストリ上で管理されているDockerイメージを自動的に取得してコンテナを作成しようとする

先ほどの「pull」してからの「run」は①に該当します。
「pull」をしてローカルにDockerイメージを取得し、そのローカルにあるDockerイメージからコンテナをrun（作成）するという流れです。

②は指定したDockerイメージがローカルになかった場合にレジストリで管理されているリポジトリからDockerイメージを自動的にローカルにpullして、そのDockerイメージからコンテナをrun（作成）するという流れです。
つまり、明示的にpullしなくても自動的にpullしてくれるということになります。