Docker の基本 ── 組版環境をまるごと固定する

はじめに

LaTeX の組版環境をコンテナに閉じ込めて手元を汚さずにコンパイルする（TeX Live 入りコンテナと Makefile）、といった使い方の土台になるのが Docker です。この記事ではその基本を整理します。

Docker を使うと、OS ・ソフト・設定をイメージという単位でまるごと固定できます。ローカルにフルインストールしない、マシンが変わっても同じ、CI とも共有できる ── というメリットは、TeX Live のように大きく更新の速い環境ほど効いてきます。

イメージとコンテナ

この 2 語を区別できれば大半は理解できます。

  • イメージ (image) … 環境の設計図。読み取り専用で、texlive/texlive:TL2024 のように名前とタグで指す。
  • コンテナ (container) … イメージを動かした実体。プロセスが動く箱で、基本は使い捨て。

「1 つのイメージから、コンテナを何個でも起動できる」「コンテナを消してもイメージは残る」という関係です。組版では、イメージは 1 回用意すれば十分で、コンパイルのたびにコンテナを起動しては捨てます。

最初の一歩

インストール後、動作確認をします。

docker run hello-world

run は「イメージを取得（無ければ）してコンテナを起動する」コマンドです。対話的に中へ入るには -it を付けます。

docker run -it --rm debian bash
# コンテナ内のシェルに入る。exit で出ると --rm によりコンテナは消える

よく使うコマンド

コマンド動作
docker pull <image>イメージを取得
docker run <image> <cmd>コンテナを起動してコマンド実行
docker ps / docker ps -a動作中 / 全コンテナの一覧
docker stop <name>コンテナを止める
docker rm <name>停止したコンテナを削除
docker images手元のイメージ一覧
docker rmi <image>イメージを削除
docker logs <name>コンテナの出力を見る
docker exec -it <name> bash動作中のコンテナに入る

run の主要オプション

TeX Live 入りコンテナの記事で使った起動コマンドを分解すると、Docker の要点がひととおり出てきます。

docker run --rm \
  -v "$PWD":/work -w /work \
  -u "$(id -u):$(id -g)" -e HOME=/tmp \
  mytex:latest \
  latexmk main.tex
オプション役割
--rm終了したらコンテナを自動削除。使い捨て運用の基本
-it端末を割り当てて対話的にする（bash に入るときなど）
-v ホスト:コンテナバインドマウント。ホストのディレクトリをコンテナ内に見せる。生成物もホスト側に残る
-w <dir>コンテナ内の作業ディレクトリ
-u <uid>:<gid>実行ユーザーを指定。出力ファイルが root 所有になるのを防ぐ
-e KEY=VALUE環境変数を渡す（例では書き込み可能な HOME を与えている）
-p ホスト:コンテナポート公開。Web サーバー系のイメージで使う

「ホストのフォルダを -v で渡し、その中で処理して、結果もそのフォルダに残す」というのが、組版に限らずコンテナで作業する基本形です。

Dockerfile でイメージを作る

既存イメージに手を加えたいときは Dockerfile を書き、docker build でイメージ化します。

FROM texlive/texlive:TL2024      # ベースイメージ
RUN tlmgr install latexmk collection-langjapanese   # 追加インストール
WORKDIR /work                    # 既定の作業ディレクトリ
CMD ["latexmk", "main.tex"]      # 引数なしで run したときの既定コマンド

docker build -t mytex:latest .

主な命令は FROM（土台）、RUN（ビルド時にコマンド実行）、COPY（ファイルを取り込む）、WORKDIR、CMD（起動時の既定コマンド）です。

各命令はレイヤとして積み上がり、変わっていないレイヤはキャッシュが再利用されます。頻繁に変わるもの（COPY . . など）を下の方に書くと、ビルドが速くなります。

データはどこに残るか

コンテナ内で書いたファイルは、コンテナを削除すると一緒に消えます。残したいデータは外に出す必要があります。

  • バインドマウント（-v ホストのパス:...） … ホストの特定フォルダを直接見せる。原稿のように「手元で編集し、結果も手元で見たい」もの向き。組版はこれ。
  • 名前付きボリューム（-v myvol:...） … Docker が管理する保管領域。DB のデータなど、ホストのファイルツリーに置く必要がないもの向き。

組版の場合は「原稿ディレクトリをバインドマウントし、main.pdf をホスト側に残す」で完結します。

掃除する

イメージやビルドキャッシュは放っておくとディスクを食います。使用量の確認と掃除のコマンドを覚えておきます。

docker system df            # 何がどれだけ容量を使っているか
docker image prune          # どのコンテナからも使われていないイメージを削除
docker system prune         # 未使用のコンテナ・ネットワーク・キャッシュをまとめて削除

prune は消える対象を確認してから実行してください。

タグとレジストリ

イメージ名は リポジトリ名:タグ の形です（texlive/texlive:TL2024 なら タグは TL2024）。タグを省くと latest になります。

latest は「その時点の最新」を指す動く的で、いつの間にか中身が変わります。組版のように再現性が要るものは、TL2024 のような固定タグを使うのが基本です。ローカルの Dockerfile、GitHub Actions の container:、チームの全員が同じタグを指していれば、環境差は生まれません。

イメージの配布元がレジストリで、既定は Docker Hub です。docker pull owner/name:tag で取得し、自作イメージは docker push で公開できます（GitHub の ghcr.io なども同様）。

関連記事

まとめ

  • イメージ＝設計図、コンテナ＝それを動かした使い捨ての実体。
  • docker run は --rm / -v / -w / -u / -e を押さえれば、たいていの作業はこなせる。
  • 手を加えたいときは Dockerfile → docker build。レイヤのキャッシュを意識して命令を並べる。
  • コンテナ内のデータは消える。残すものはバインドマウントかボリュームで外へ。
  • タグは固定する。ローカルと CI で同じイメージを指すことが、環境をまるごと固定するということ。

ここが分かれば、コンテナと Makefile や GitHub Actions がコンテナをどう使っているかも読み解きやすくなります。

LaTeX組版・教材校正のご依頼・ご相談はコレクトコネクトへお問い合わせください。

← コラム一覧へ