GitHub Actionsで利用したいDockerコンテナの基礎 | cloud.config Tech Blog

はじめに

前回まではAsciiDoc出力に利用したワークフローや「Analog-inc/asciidoctor-action」アクションの内容を通しGitHub Actionsの動作やAsciidoctorの環境構築について簡単に解説しました。今回はその内部で利用しているDockerについて簡単な説明をしたいと思います。

AsciiDocには直接関係無い内容ですが、今回の内容をお読みいただければ前回までの解説への理解がより深まるととともに、今後ご自身でDockerコンテナを利用する際に概念を正しく理解した状態で利用できると思います。

前回までの記事について

これまでの記事はこちらにあります。　そちらも合わせてお読みいただけると嬉しいです。

Dockerについて

DockerはDocker社が開発しているDockerプロジェクト全体を指す言葉でアプリケーションと実行環境を作成、配布、実行するためのプラットフォームです。
また、ホスト上で動く docker デーモンのプロセスでありイメージとコンテナを管理するDocker Engineを指すこともあります。

コンテナについて

コンテナの概念は、船やトラックに積み込まれる輸送用のコンテナから連想したものです。輸送用のコンテナは物資を世界的に輸送するために標準が定義されていますが、Dockerコンテナはソフトウェアの可搬性を向上することを目的としています。

技術としてのコンテナ

コンテナはホストOSのカーネルを利用しプロセスやユーザなどを隔離することで、あたかも別のマシンが動いているかのように動かすことができる技術です。
これによりアプリケーションの実行環境をシンプルに小さく構成することができます。

実行環境としてのコンテナ

実行環境でのコンテナはDockerイメージを実行するときの実体（runtime instance）を意味します。

コンテナ技術と仮想マシン（Virtual Machine）の違い

あたかも別のマシンが動いているかのように動かすコンテナ技術は仮想マシン（Virtual Machine）とよく比較されます。それぞれメリットはありますが、コンテナ技術と仮想マシン（Virtual Machine）を簡単に比べてみましょう。

仮想マシン（Virtual Machine）の特徴

仮想マシンはコンピュータとハードウェアの全体をエミュレートするプログラムです。他のユーザと物理ハードウェアのリソースを共有しますが、OSはそれぞれ別々にインストールする必要があります。このお陰でエンドユーザは専用ハードウェアと同じように仮想マシンを操作できますが、コンテナと比べると実行は重たくなります。

Dockerfileについて

Dockerfile（ドッカーファイル）はテキスト形式のドキュメントで特定の Dockerイメージを構築するために必要な全ての情報を記述します。DockerはDockerfileの内容を読み込みイメージを構築します。

Dockerfileついて詳しく知りたい方は下記のリファレンスを参照してください。

Dockerfileリファレンス

Dockerイメージについて

Dockerイメージはコンテナとして実体（runtime instance）にするための元になります。中身はファイルシステムに対する変更を集めたもので、イメージは状態を保持せず変更もできません。
イメージの理解を深めるために簡単に概念を説明します。

ベースイメージ（base image）とは

親イメージを持たないイメージをベースイメージと呼びます。

レイヤー（layer）とは

イメージの内部においてイメージに対する変更がレイヤーで、Dockerfile内に記載した情報から作成されます。
ベースイメージから最終的なイメージを作成するまでレイヤーは積み重なっていきますが、レイヤーごとにイメージをキャッシュすることができるため、イメージの更新や再構築時には更新が必要となるレイヤーのみを変更することができます。
差分となる変更のみ管理することで最終的なイメージの容量と各レイヤの容量の合計が同じになることが大きな特徴です。
このレイヤーがDockerの軽量さや高速さを支えています。

※ レイヤーにはコンテナとして実体（runtime instance）となった時だけ存在するコンテナレイヤーがあります。このコンテナレイヤーは唯一実行時に情報を書き込むことができるレイヤーになります。

ビルド（build）とは

Dockerfileを使ってDockerイメージを構築することをビルドと言います。

データボリューム（data volume）ついて

データボリューム（data volume）は複数のコンテナ内でマウントすることにより使える、永続的なデータを保管するためのホスト側に用意されるディレクトリです。
コンテナのライフサイクルとは分離されているためDockerはコンテナの削除時にデータボリューム（data volume）を削除しないことでデータの永続性を担保しています。

※このデータボリュームをコンテナからマウントできることで外部アクションでホストランナー上にチェックアウトした.adocファイルをコンテナ上のAsciidoctorが読み込み、出力ファイルを外部アクションでartifactにアップロードすることができます。

まとめ

今回は「Analog-inc/asciidoctor-action」アクションの内部で使用しているDockerコンテナの大まかな概要を簡単に解説しました。

前回の解説に利用した上記の画像の内容とコンテナの概念が少しでも頭の中で繋がっていただけたら嬉しいです。

また、今回の記事ではコンテナ自体に目を向けるため、リポジトリやレジストリの説明は割愛させていただきましたが、コンテナがなぜ軽量で高速で動作するのか感覚として掴めていただく事もできたかと思います。
この知識があるだけで、Dockerfileをご自身で書くときや修正するとき、誰かの作ったイメージを利用する際により気軽に利用できるようになります。

次回以降は改めてAsciiDocがより便利に利用できるようにAsciidoctorで日本語のPDFが出力できるように解説していきます。