Docker のベースイメージは、すべてのコンテナイメージの土台になります。
既存の ubuntu イメージをそのまま使えば十分な場面もあります。しかし、企業内や閉域環境、自宅基盤のように構成を揃えたい環境では、タイムゾーン、証明書、基本パッケージ、proxy、内部レジストリの扱いを含めた標準ベースイメージを用意したくなることがあります。
この記事では、Ubuntu を元に Docker ベースイメージを作る意味を、Dockerfile、tag 管理、内部レジストリ、再現性の観点から整理します。
書籍
Docker の基本、コンテナ運用、開発環境構築を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
ベースイメージを自作する意味
ベースイメージを自作する目的は、単にパッケージを追加した Ubuntu イメージを作ることではありません。
目的は、複数のアプリケーションイメージで共通して使う前提を揃えることです。
| 要素 | ベースイメージで揃えたい理由 |
|---|---|
| タイムゾーン | ログ時刻やアプリケーションの表示時刻を揃える |
| CA 証明書 | 内部 CA や TLS 通信の前提を揃える |
| 基本パッケージ | curl、ca-certificates、tzdata など最低限の道具を揃える |
| proxy | 閉域環境や proxy 環境で build できるようにする |
| 更新方針 | どのタイミングで OS package を更新するか管理する |
ただし、ベースイメージに何でも入れればよいわけではありません。共通化しすぎると、不要なパッケージや脆弱性もすべての派生イメージへ広がります。
ベースイメージには、共通の土台として必要なものだけを入れる方が扱いやすくなります。
Dockerfile の例
最小例として、Ubuntu を元にタイムゾーンと CA 証明書を整える Dockerfile を作ります。
FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
&& apt-get -y upgrade \
&& apt-get install -y --no-install-recommends ca-certificates tzdata curl \
&& ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime \
&& echo Asia/Tokyo > /etc/timezone \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*apt-get clean と /var/lib/apt/lists の削除は、イメージサイズを増やしすぎないための基本です。
また、build 時に対話入力が出ないように DEBIAN_FRONTEND=noninteractive を指定しています。これは Ubuntu 系イメージで tzdata などを扱う時に重要です。
build と tag 管理
ベースイメージは、tag 管理が重要です。
latest だけで運用すると、後から同じ環境を再現しにくくなります。ベースイメージを更新するたびに、どのバージョンを使ったアプリケーションイメージなのか分からなくなるためです。
docker build -t registry.local/library/ubuntu-base:22.04-1.0.0 .
docker image ls registry.local/library/ubuntu-baseここでは、Ubuntu の系列とベースイメージの管理バージョンを tag に含めています。実際の運用では、日付、Git commit、CI build 番号などを使っても構いません。
内部レジストリへ push する
作成したベースイメージは、内部レジストリへ push しておくと、他の Dockerfile から再利用しやすくなります。
docker push registry.local/library/ubuntu-base:22.04-1.0.0
docker pull registry.local/library/ubuntu-base:22.04-1.0.0閉域環境や proxy 制約のある環境では、各サーバーや CI runner が外部レジストリへ直接取りに行く構成を避けたいことがあります。その場合、内部レジストリへベースイメージを置くことが、構築の再現性を支えます。
派生イメージから使う
アプリケーション用の Dockerfile では、内部レジストリ上のベースイメージを FROM に指定します。
FROM registry.local/library/ubuntu-base:22.04-1.0.0
WORKDIR /app
COPY . /app
CMD ["/bin/bash"]こうすると、アプリケーションイメージ側では、OS の最低限の前提を毎回書かなくて済みます。ベースイメージの更新は、別の責任として管理できます。
ベースイメージに入れすぎない
ベースイメージを作る時に注意したいのは、便利だからといって何でも入れないことです。
共通パッケージを増やせば、派生イメージの Dockerfile は短くなります。しかし、不要なパッケージ、不要なコマンド、不要なライブラリもすべてのイメージへ入ります。
ベースイメージは、薄すぎると毎回同じ処理を書くことになります。厚すぎると、脆弱性管理や更新管理が重くなります。
そのため、ベースイメージは「共通して必要な最小限」に留め、アプリケーション固有のものは派生イメージ側で管理する方が自然です。
更新責任を分ける
ベースイメージを自作すると、更新責任も発生します。
Ubuntu の package update、CA 証明書の更新、脆弱性対応、tag の更新、派生イメージの rebuild。これらを誰が、どのタイミングで行うのかを決めておく必要があります。
ベースイメージは便利ですが、作って終わりではありません。継続的に更新できる運用があって初めて、標準ベースとして意味を持ちます。
まとめ
Docker のベースイメージを自作する意味は、単に Ubuntu にパッケージを追加することではありません。
タイムゾーン、CA 証明書、基本パッケージ、内部レジストリ、tag 管理、更新責任をそろえ、アプリケーションイメージの土台を標準化することに意味があります。
ただし、ベースイメージに入れすぎると、不要な依存関係や脆弱性も広がります。共通化するものと、アプリケーション側に残すものを分けることが重要です。
ベースイメージは、Dockerfile を短くするための道具ではありません。コンテナイメージの前提を揃え、再現性と運用責任を明確にするための設計単位です。
関連する記事
- Docker プライベートレジストリとは何か – 外部接続を減らし、内部配布基盤を作る
- Docker のプロキシ設定 – systemd drop-in で daemon の外部接続を制御する
- Docker コンテナを自作する #2 MariaDB イメージ
