ゼロからはじめるDocker(9) Dockerに関するTips

本シリーズは、9回にわたりDockerを「ゼロからはじめる」ために、利用方法について初歩的なことを中心に説明してきた。しかしDockerは、これまで説明してきた内容の他にも便利な使い方がたくさんある。今回は、今まで紹介できなかった以下のTipsについて説明する。

・Dockerコンテナのデータの永続化
・GitLabでのAutomated Build方法

Dockerコンテナのデータの永続化

これまでの例題として、コンテナによるWordPressの構築方法を説明してきたが、コンテナがエラーなどの理由で起動しなくなった場合、コンテナ内部のデータは復旧させることが困難である。

開発環境で利用する目的であれば起動しないコンテナを削除し、再度コンテナを起動すればよいが、サービス提供環境ではデータが失われてしまうことや、コンテナの起動と再起動による復旧では問題が起こってしまう可能性が高い。

例えばMySQLのコンテナを削除すると、コンテナ内部の情報が削除されてしまう。そのためコンテナを削除し再度コンテナを起動させると、これまで登録や更新されたMySQL内のデータが存在しない新たなMySQLコンテナが起動する。

このようなことにならないように、蓄積したデータを永続的に利用する方法として、Dockerはデータ保管領域をコンテナ内ではなく、Dockerホストのボリューム領域、またはストレージをマウントして使用する機能を提供している。

この機能については、本シリーズの第3回で説明したMySQLコンテナを、Dockerホストのボリューム領域にマウントしMySQLデータディレクトリーを利用する手順として説明する。

1.docker volume createコマンドで、データ保管領域を作成する。

今回はmysql-dataという名前のボリューム領域を、Dockerホストに作成する。

$ docker volume create mysql-data

作成したボリューム領域が、Dockerホストのどのディレクトリーに割り当てられるかについては、docker volume inspectコマンドで確認できる。

$ docker volume inspect mysql-data
[
    {
        "CreatedAt": "2017-10-26T09:39:17Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/mysql-data/_data",
        "Name": "test",
        "Options": {},
        "Scope": "local"
    }
]

このボリューム領域は、-dオプションでVolume pluginを指定すると、Dockerホストのディレクトリー以外のストレージでも利用可能である。Volume pluginについては、以下のページでまとめられているため、興味のある方は確認してほしい。

Use Docker Engine plugins | Docker Documentation

2.docker container run コマンドに--volumeオプションを追加し、コンテナのMySQLデータディレクトリーをマウントする。

$ docker run \
   --name wordpress-mysql \
   --volume mysql-data:/var/lib/mysql \
   -e MYSQL_ROOT_PASSWORD=mysql \
   -d \
   mysql

これでMySQLコンテナのMySQLデータは、Dockerホストのmysql-dataに格納されるようになり、MySQLコンテナを削除し再度コンテナを起動してもMySQLデータは削除されず、以前の状態のまま利用できる。このDockerホストのボリューム領域へのマウント方法は、Dockerfileでも設定は可能である。

この方法はとても簡単である。DockerfileにVOLUMEと、コンテナ内でマウントしたいディレクトリーを記載するだけでよい。書き方は以下の形式だ。

VOLUME（コンテナ内のディレクトリー）

VOLUMEが記載されたDockerコンテナを起動すると、一意のVolume IDが設定されたボリューム領域が自動的に作成され、指定したコンテナ内のディレクトリーをマウントする。

この設定はコンテナ起動時に強制的に実行されるため、サービス提供環境で利用されるようなデータには、とても秀逸である。ただ開発環境で使い回しをするために、コンテナの起動と削除を繰り返す使い方ではデメリットとなる。それはDockerfileを利用しコンテナの起動と削除を繰り返すごとに、異なるボリューム領域が作成される。すなわちMySQLコンテナを削除しても、自動的に生成されたボリューム領域にMySQLのデータは残り、HDDのリソースを余計に使ってしまう。そのためVOLUMEが指定されているコンテナの起動と削除を繰り返し利用する場合、docker volume lsコマンドでボリューム領域の状況を確認しdocker volume pruneコマンドを実行して、コンテナが利用していないボリューム領域を定期的に削除することをおすすめする。

$ docker volume ls

$ docker volume prune

このように大事なデータが格納されているディレクトリーは、万が一の備えとしてVOLUMEを指定するとよい。

GitLabでのAutomated Build方法

第5回では、GitHubとDocker Hubを連携させ、GitHubにDockerfileのプロジェクトをプッシュすればDocker Hub上で自動的にビルド処理がおこなわれるAutomated Buildの方法を紹介した。

では、GitLabでAutomated Buildは可能か。もちろん可能であり、GitLab CIを使用すればよい。

GitLab CIは、開発やサービス提供の処理を自動化して、継続的に実行するCI（継続的インテグレーション）ツールのひとつ。GitLab8.0からGitLab本体に統合された機能である。GitLab CIを使用するためには、Dockerfileのプロジェクトにgitlab-ci.ymlという名前のファイルを配置し、処理内容を記載する必要がある。

GitLab CI を使用してDockerfileのプロジェクトを自動でビルドし、ビルドしたイメージをプロジェクト内にあるGitLab Container Registry に配置したい場合は、以下の内容を記載すればよい。

services:
- docker:dind

stages:
- build-image
- build-master-image

variables:
CONTAINER_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_NAME}
CONTAINER_MASTER_IMAGE: ${CI_REGISTRY_IMAGE}:latest

before_script:
- docker info
- docker login -u gitlab-ci-token -p ${CI_BUILD_TOKEN} ${CI_REGISTRY}

build-image:
stage: build-image
image: docker:latest
script:
- docker image build -t ${CONTAINER_IMAGE} .
- docker image push ${CONTAINER_IMAGE}

build-master-image:
stage: build-master-image
image: docker:latest
script:
- docker image pull ${CONTAINER_IMAGE}
- docker image tag ${CONTAINER_IMAGE} ${CONTAINER_MASTER_IMAGE}
- docker image push ${CONTAINER_MASTER_IMAGE}
only:
- master

上記の内容を記載したgitlab-ci.ymlを、Dockerfileのプロジェクトのルートディレクリに配置した後プッシュすれば、自動的にCIによるDockerfileのビルド処理がおこなわれる。

CIの処理状況を確認したい場合は、右ペインのメニューにある「CI/CD」をクリックすればよい。またビルドしたイメージは、同じく右ペインのメニューにある「Registry」をクリックすれば確認可能である。

あとがき

以上で本シリーズ「ゼロからはじめるDocker」は、終了である。

本シリーズの内容は、Dockerの利用方法について初歩的なことを中心に紹介した。この内容が読者の皆様にとって、今後Dockerを実際に利用するきっかけとなることを願う。

Dockerに限らずコンテナ仮想化技術は、いま現在も開発が進められているため、あとがきとして最新の状況について説明しよう。コンテナ仮装化技術は、The Linux FoundationのプロジェクトであるOpen Container Initiative（OCI）が、2017年7月19日にコンテナの標準仕様であるOCIv1.0を発表したことで、大きな動きをみせている。

Open Container Initiative (OCI) Releases v1.0 of Container Standards

いままでのコンテナ仮想化技術を実現しているコンテナソフトウェアは、それぞれで仕様が策定されており、コンテナウェア間の仕様はバラバラであったため、コンテナイメージの流用ができなかった。これでは、ひとつのソフトウェアにロックインしてしまうデメリットが存在した。

だが各コンテナソフトウェアがこの標準仕様に対応すれば、上記のデメリットを払拭することができる。現在コンテナソフトウェアはこの標準仕様への対応をおこなっており、もちろんDockerも対応をおこなっている。

DOCKER LEADS OCI RELEASE OF V1.0 RUNTIME AND IMAGE FORMAT SPECIFICATIONS

現在発表されている標準仕様はコンテナのランタイム、コンテナのイメージフォーマットであり、今後もコンテナ関連の仕様が整備されていくことが予想される。このようにコンテナ仮装技術における基盤ができあがりつつあることから、コンテナ関連のアプリケーションやサービスの開発がさらに加速し、場合によっては状況ががらりと変わることが想定される。

コンテナ利用者にとっては、ますますコンテナを便利に利用できるメリットを享受できる一方で、状況の変化が激しいことによる学んだ知識がいつのまにか古くなってしまっている可能性が高くなる。

この過渡期に起こる特有の状況下だからこそ、読者の皆様には、本シリーズの内容のみで満足せず、コンテナに関わる最新情報に興味を持ち、実際に利用し、試行錯誤を繰り返していただければと願う。

CloudGarage開発担当
IaaS型パブリッククラウドサービス「CloudGarage」の開発エンジニア。バックエンドのサーバ構築からフロントのアプリケーション開発まで幅広く行う。「Docker」は実務でも頻繁に利用するため、実際に使っている立場から「Docker」について解説をする。