社団法人 電子情報通信学会

信学技報

THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERSTECHNICAL REPORT OF IEICE.

Docker における複数環境対応のための Dockerﬁle プリプロセッサの調査
馬渕

航†

柗本

真佑†

楠本

真二†

† 大阪大学大学院情報科学研究科
E-mail: †{w-mabuti,shinsuke,kusumoto}@ist.osaka-u.ac.jp
あらまし Docker は可搬性や資源効率の高さからコンテナ仮想化におけるデファクトスタンダードである．Docker コンテ
ナにはベースとなる OS の種類やサービスのバージョン等によって複数の利用形態が存在する．コンテナ配布者は利用形態に合わせて複数の Dockerﬁle（コンテナ構築手順が記載されたソースコード）を用意することが一般的である．ただ，手動での管理は手間がかかるため，開発者は Dockerﬁle を自動生成する Dockerﬁle プリプロセッサを通して管理している．しかし，Docker 自体は DPP をサポートしておらず，コンテナ配布者は自前の DPP を作成し利用している．その実現方法はプロジェ
クトによって多種多様であり，手探りでの開発が求められる．そこで，本研究では Dockerﬁle プリプロセッサの実現方法の体系化を目的として調査を行う．調査の結果，DPP はその構造によって複数の型に分類でき，各型に利点や欠点が存在した．
キーワード

コンテナ仮想化，Docker，Dockerﬁle，プリプロセッサ，実証的調査

1. は じ め に

テキストプロセッサが利用されることが多い．一方で，Python のような高級言語を用いてより高度な DPP 処理を利用している場合

Docker はコンテナ仮想化を実現するプラットフォームである．

もある．よって，DPP 全体の処理をどのように構成するかは様々

コンテナ仮想化は一般的なハイパーバイザ仮想と比べて高い資源効な選択肢があるといえる．また，置換対象となる可変情報をどのよ

率や可搬性を実現する．Docker はコンテナ仮想化におけるデファ

うに管理するか，どのような置換情報の組み合わせが存在するかとクトスタンダードであり，IT 企業の 79% 以上が利用しているといった点も明らかではない．Docker 開発者は，統一的な実現方法の報告がある [1]．また，OSS のようなソフトウェア開発プロジェがない状況下で手探りでの DPP 作成が求められる．

クトでも広く採用されており [2]，ソフトウェアの配布方法として

そこで，本研究では DPP 実現方法の体系化を目的として，DPPの利用のみならず，ソフトウェアの開発支援としても活用されていの実態調査を行う．この調査を通じて，DPP で広く採用されている [3] [4]．さらには学術分野における実験の再現性確保としての活る手法やその利点と欠点を明らかにし，DPP 採用を検討している用も期待されている [5]．

開発者への手がかりを提供できると考える．具体的な調査手法としDocker におけるコンテナ開発においては，複数の環境や利用形ては，Docker Hub 内の高品質なコンテナを対象に，DPP を採用態を想定し，サポートすることが一般的である．例えば，コンテナ

している GitHub プロジェクトを抽出し目視調査を行う．そして，のベースとなる OS（ubuntu や centos）や，提供するサービスの実現方法をパターン化する．さらに各実現方法の利点や欠点を整理バージョン（1.0 や 2.0）, Docker のホストマシンのアーキテクチャ

し，プロジェクトの性質との相性を加味した分析も行う．以下に示（AMD364 や i386）など，様々な利用形態の組み合わせが存在す

す 4 つの RQ に従って調査を進める．

る．これらの組み合わせによって Dockerﬁle(コンテナ構築手順がRQ1: DPP はどの程度利用されているか?

記載されたソースコード) 内の記述内容は変化する．特に，ベース

RQ2: DPP はどのように構成されるか?

OS の違いはコンテナで実行されるコマンドの違いに繫がるため，

RQ3: Dockerﬁle 生成処理はどのように実現されるか?

Dockerﬁle の記述内容は大きく変化することになる．コンテナ開発

RQ4: 可変情報はどう管理されるか?

者は，これら多種多様な利用環境に応じた複数の Dockerﬁle を用意する必要がある．
そこで，複数の Dockerﬁle の開発保守を目的として，Dockerﬁleのプリプロセッサが採用されることがある．DPP では生成対象と

2. 準

備

2. 1 DockerﬁleDockerﬁle とは，コンテナ生成手順が記載されたソースコード

なる Dockerﬁle の枠組み，及びベース OS やバージョン等の可変である．同一ファイル内に，Dockerﬁle 固有の構文と RUN 命令にな情報を入力として，複数種類の Dockerﬁle を自動生成する．

内包される Shell Script 構文 [7] を用いて，ベース OS やコンテナ

しかしながら，Docker 自体は DPP をサポートしておらず，既内で実行する命令を記述する．図 1 に Python 実行環境を提供す

存のツールも存在しない [6]．そのため，開発者は独自で DPP をるコンテナを生成する際の Dockerﬁle の例（注 1） を示す．図 1 では，作成しなければならず，その実現方法もプロジェクトによって異な

まず FROM 命令でベース OS となる Alpine を選択している．そる．DPP の基本的な処理は，テンプレートファイルに対する具体的な値の埋め込み処理で実現可能である．よって sed や awk 等の（注 1）：https://github.com/docker-library/python/blob/master/3.11/alpine3.16/Dockerfile

—1—

1

FROM alpine

1

FROM mcr . microsoft . com / windows / servercore :1809

2

..

2

..

3

ENV PYTHON_VERSION 3.11.1

3

ENV PY THON_V ERSIO N 3.11.1

4

RUN ..

4

RUN $url = ( ' https ://../ python -{1} - amd64 . exe ' -f (5

apk add --no - cache -- virtual . build - deps \$env : PYT HON_VE RSION - replace '[a - z ]+[0 -9]* $ ' , ' ')6..

, $env : PYTH ON_VER SION ) ; \7wget python . tar . xz " https ://../ Python $P YT H ON _V E RS IO N . tar . xz "; \[ Net . S e r v i c e P o i n t M a n a g e r ]:: S e c u r i t y P r o t o c ol = ..\5

Invoke - WebRequest $url - OutFile ' python . exe '; \

6

8

..

7

..

9

CMD [" python3 "]8CMD [" python "]図 1 Python 実行環境コンテナを生成する際の Dockerﬁle1

FROM buster

2

..

3

ENV PYTHON_VERSION 3.7.16

4

RUN ..

ver baseos
3.11 alpine
3.7 alpine
3.11 buster
可変情報5

apt - get update ; \6apt - get install -y --no - install - recommends \7

patchelf ; \8wget python . tar . xz " https ://../ Python $P YT H ON _V E RS IO N . tar . xz "; \

9

..

10

CMD [" python3 "]図 3 図 1 からベース OS を Windows にした場合の DockerﬁleFROM alpine
RUN ../3.11
CMD ..
入力

生成

DPP

FROM %%baseos%%
RUN ../%%ver%%
CMD ..

FROM buster
RUN ../3.7
CMD ..
FROM windows
RUN ../3.11
CMD ..

テンプレート

図 4 DPP の概略

図 2 図 1 からベース OS を buster, バージョンを 3.7 にした場合の Dockerﬁle2. 3 Dockerﬁle のためのプリプロセッサ（DPP）
複数の利用形態に応じた Dockerﬁle の作成にあたっては，Dock-

して，RUN 命令を用いて，パッケージのインストールや URL 先

erﬁle プリプロセッサ（DPP）が利用されることがある．開発者のファイルの取得など，コンテナ内で実行するコマンド列を記述しが DPP に対して可変情報や Dockerﬁle のテンプレート情報を指ている．最後に，サービスの実行を行う CMD 命令を記述してい定する．DPP は入力された可変情報が示す利用形態に対応した

る．以上のように，Dockerﬁle を作成し配布することで，誰がいつDockerﬁle を自動生成する．

実行しても Python 実行環境をサービスとするコンテナを再現可

Python コンテナの Dockerﬁle を生成する DPP の概略を図 4に示す．図 4 では，Alpine 等のベース OS や 3.11 等のバージョン

能である [8]．

2. 2 複数環境対応のための Dockerﬁle

情報等の可変情報及び Dockerﬁle のテンプレートとなるテキスト

Dockerﬁle の作成や配布においては，複数の利用形態を想定し情報を入力としている．DPP は入力情報を基に処理をおこない出サポートすることが一般的である．利用形態の例としては，コン

力として複数の Dockerﬁle を生成している．このような仕組みを

テナのベースとなる OS やサービスのバージョン等，様々な組み採用することで，開発者は複数種の Dockerﬁle を一度に管理でき，合わせが考えられる．この組み合わせによって Dockerﬁle で記述

手間の軽減やバグの低減に繫がる．

する内容は変化する．図 1 で示した Dockerﬁle は，ベース OS が2. 4 DPP における課題

Alpine，Python のバージョンが 3.11 の場合の Dockerﬁle であっ

DPP は複数 Dockerﬁle の管理において便利であるが，DPP 採

た．ここで，ベース OS を Buster（Debian 系 OS）, Python の用の過程に課題が存在する．まず，Docker 自体は DPP を提供しを図 2 に示す．

ていないため，開発者は自前で DPP を用意しなければならない．

ENV で指定する変数の値が異なっているほか，パッケージマネー

また，統一的な方法も存在せず，DPP の実現方法はプロジェクト（注 2）

バージョンを 3.7 にした場合の Dockerﬁle の例

ジャが apk から apt-get に変わっていることが読み取れる．さらによって異なる．Dockerﬁle のテンプレートとなるファイルに可変を図 3 に示す．図 3 か

情報を置換して生成する方法や awk などのスクリプト言語を用い

ら Linux 系の OS とは記述が全く異なることが読み取れる．コマてテンプレートを処理する方法，さらにはテンプレートすら持たな（注 3）に，ベース OS が Windows の場合の例

ンド名が違うことは当然ながら，図 3 の 6 行目に記述されているい方法まで存在する．多種多様な DPP が存在する状況下で，開発プロトコル変更文のように，新しく追加される文も存在する．配布

者は手探りでの DPP 開発が求められる．

者は以上のような記述内容の違いを反映させ，各種組み合わせに対応した Dockerﬁle を用意する必要がある．

3. Reserch Questions
本研究では DPP 採用プロジェクトを対象に，DPP の実態を調査する．この調査を通じて様々な開発者が培った DPP 実現方法の（注 2）：https://github.com/docker-library/python/blob/master/3.7/buster/Dock

体系化を狙う．調査は以下 4 つの問いに従って進める．

erfile（注 3）：https://github.com/docker-library/python/blob/master/3.11/windows/windowsservercore-1809/Dockerfile—2—

RQ1. DPP はどの程度利用されているか?

Docker Hub

RQ1 では，Docker Hub の複数のプロジェクトを対象として，

生成スクリプト

調査対象コンテナの探索
GitHubプロジェクトURLの取得

DPP を実際に採用しているプロジェクトの割合を調べる．前章で示した，Python や nginx のコンテナの例では DPP が採用されて可変情報ファイル

Git

Git

いたが，どの程度 DPP が採用されているかは不明である．本 RQ

Git
調査対象プロジェクトの抽出により研究の前提となる DPP の採用率を確認する．
RQ1（利用率）
RQ2（DPP構成）

RQ2. DPP はどのように構成されるか?
RQ2 では，RQ1 で発見した DPP 採用プロジェクトのソース
コードを確認し，DPP 全体がどのように．実現されているかを確

RQ3，RQ4の調査対称ファイル抽出

認する．仮説としては DPP は以下 2 種類の情報で構成されると考えられる．

• Dockerﬁle 生成処理

各プロジェクトの生成スクリプト

RQ3（Dockerfile生成）• 可変情報の管理
本調査で，上記 2 つの要素の存在含め，DPP を構成するファイ

各プロジェクトの可変情報管理ファイル

RQ4（可変情報管理）

図 5 調査全体の流れ

ルやその役割を明らかにし，RQ3 と RQ4 で調査するファイルを特定する．

象のコンテナ概要欄から URL を探し，取得する．ただし，URL

RQ3. Dockerﬁle 生成処理はどのように実現されるか?

を取得できなかったコンテナは調査対象から外し，新たなコンテナ

RQ3 では，Dockerﬁle 生成の実現方法について調査する．複数を調査対象に追加する．また，一部管理者が同じ複数のコンテナがDockerﬁle の自動生成は DPP の目的に直結する処理であり，体存在する．この場合管理方法も同様であるため，同管理者の 2 件目

系化において重要な要素となる．また，プロジェクトによって使以降は調査対象から外し，新たなコンテナを追加する．

用言語や生成する Dockerﬁle が異なるため，開発者によって実現

図 5 の下部に示すのは，全体の流れの 2 つ目に示した，各 RQ

方法のバリエーションが現れる部分であると考える．本 RQ にて，の調査段階である．まず RQ1 の調査として，抽出したプロジェク

Dockerﬁle 生成処理の実現方法をパターン化し，各パターンの利点

トを対象に DPP 採用の有無を確認する．続いて DPP を採用してや欠点を整理する．

いるプロジェクトについて，DPP の構成要素となるファイル群をRQ4. 可変情報はどう管理されるか?

目視で確認し，抽出する．そして，RQ2 の調査として構成要素をRQ4 では，可変情報の処理に焦点を当てて，調査を実施する．

整理する．さらに，各構成要素のファイルの内容を目視で調査し，可変情報の種類数によって，DPP が生成する Dockerﬁle の数は変各調査結果を RQ3，RQ4 の回答として整理する．

化する．例えば，コンテナのベースとなる OS（Alpine, Buster）
を可変情報とするとき，2 種類の Dockeﬁle が生成される．よって，5. 調 査 結 果

可変情報の種類や管理方法は，DPP の実現方法に大きく影響を与5. 1 RQ1: DPP はどの程度利用されているか?

えると考える．本 RQ にて，DPP で管理する可変情報を明らかに

GitHub から収集した 32 件を対象に，DPP の採用割合を調査し，その管理方法を整理する．

4. 調 査 手 法

した結果，87.5%(32 件中 28 件) が DPP を採用していた．例としては，Python，nginx，amazonlinux 等あらゆるサービスのプロ
ジェクトが DPP を採用していた．この結果から，DPP はほとん

本章では，今回の研究で実施した調査の手法を示す．図 5 に示

どの Dockerﬁle 管理プロジェクトで採用されていることが分かる．

すのは，全体の流れである．調査は以下に示す 2 つの段階で実施

また，RQ2〜4 の調査の実施により，多くのプロジェクトを支援でする．

きると考える．

• 調査対象プロジェクトの抽出• 各 RQ の調査

DPP は広く採用されている．



図 5 の上部に示すのは，DPP の構成ファイル群を抽出するまで

5. 2 RQ2: DPP はどのように構成されるか?

の流れである．最初に，調査対象のコンテナを Docker Hub から

RQ1 で収集したプロジェクトの中から，15 件を対象に構成ファ探す．Docker Hub 内には，Docker が高品質と認めたコンテナがイルの精査を実施した．その結果 DPP は，以下に示す 3 種類の要存在し，開発者の特性によって，Docker oﬃcial image，Veriﬁed

素で構成されることが分かった．

Publisher，Sponsoured OSS の 3 種類からいずれかの公認マーク• ひな形が付けられる．例としては，Python や amazon/aws-cli 等のコン

• 可変情報テナが存在し，利用者も多い．今回の調査では，以上のような公認• 生成スクリプト

コンテナの内，32 件を対象とする．

ひな形は，Dockerﬁle に近い構造を持つテキスト情報であり，次に，GitHub の URL を Docker Hub から取得する．大抵のdocker-BASEOS.template のようなファイル名で存在する．図

コンテナは，Docker Hub 内のコンテナ概要欄ページに Dockerﬁleのソースコードを示す GitHub の URL を公開している．調査対

—3—

1

FROM alpine :%% ALPINE _VERSI ON %%2

ENV NGINX_VERSION %% NGINX_VERSION %%3

RUN ..

others
2件
make
2件

調査数
全15件

図 6 ひな形ファイルの例
Bash
11件

1

declare -A nginx =(2[ mainline ]= '1.21.6 '3[ stable ]= '1.20.2 '

4

)

5

declare -A debian =(

DPP は生成スクリプト，ひな形，可変情報の 3 種類の要素で構[ stable ]= ' bullseye '78[ mainline ]= ' bullseye '6

図 9 生成スクリプトの記述言語別採用数とその割合成される．ひな形や可変情報の要素は生成スクリプトに含まれる場合もある．

)


図7

可変情報の記述例

5. 3 RQ3: Dockerﬁle 生成処理はどのように実現されるか?
RQ3 では，生成スクリプトやひな形ファイルを対象に，Dock-

1for variant in \2

alpine { , - perl } \3debian { , - perl }; do

4

..

5

template =" Dockerfile - $ { variant % - perl }. template "6{

erﬁle 生成がどのように実現されているかを調査した．その結果を記述言語と実現方法の 2 つの観点から述べる．

5. 3. 1 記 述 言 語
生成スクリプトの記述言語の種類を調査した結果を図 9 に示す．

7cat " $template "一番多い言語は Bash であり，15 件中 11 件が採用していた．Linux

8} >" $dir / Dockerfile "のデフォルトのログインシェルであることから，高速かつ実装し9..

やすい点が，高い採用率につながっていると考える．その他にも，

10

sed -i \11-e 's ,%% AL PINE_ VERSIO N %% , '" $alpinever " ' , ' \make や Python 等が採用されていた．ひな形の置換処理を実現し12..

やすい点が採用理由として考えられる．
図 8 生成スクリプトの例

5. 3. 2 実 現 方 法次に，生成スクリプトの記述内容から，Dockerﬁle 生成の実現方

6 に nginx プロジェクト（注 4） のひな形の一部を示す．FROM や
RUN 等の Dockerﬁle と同様の構造を持つが，ベース OS やバージョンなどの可変情報が変数となっている．
可変情報は，複数の Dockerﬁle において記述を変えなければならないデータの集合である．図 7 に nginx コンテナ管理プロジェクトの可変情報の記述例（注 5） を示す．nginx のバージョン情報（1.21.6
や 1.20.2）やベース OS（Bullseye）の情報が変数として定義されている．
生成スクリプトは，実際に Dockerﬁle の生成を実行するスクリプトである．ひな形のテキスト情報や可変情報をもとに，生成ファ
イルに Dockerﬁle の命令を書き込む．図 8 に nginx プロジェクトの生成スクリプトの例（注 6） を示す．5 行目にてひな形の内容を生成する Dockerﬁle に書き込み，ひな形内の変数を 10 行目から sed を用いて置換している．そしてそれらの処理を各ベース OS に対しておこなっていることが 1 行目から 3 行目の記述で分かる．
以上のように，DPP の構成要素は 3 つ存在する．RQ3 では，ひな形と生成スクリプトを対象に，Dockerﬁle 生成の実現方法を調査する．RQ4 では可変情報に着目し，その管理方法を調査する．

法を調査した．その結果，以下に示す 3 種類の実現パターンの存在を確認した．

• テンプレート型• メソッド型• ハイブリッド型
テンプレート型は，ひな形ファイル内の変数を可変情報に応じて置換しながら Dockerﬁle を生成する方法である．ひな形ファイ
ルと生成スクリプト 2 種のファイルが存在し，生成スクリプトからひな形ファイルの変数を sed 等を用いて置換する．ひな形ファ
イル自体が Dockerﬁle の構造を保っているため，生成対象となるDockerﬁle の見通しが立ちやすく，可読性の高い手法と言える．一方で，ひな形ファイルがそのプロジェクトに特化していることが多く，他のプロジェクトへの移植性は低いと言える．また，このテンプレート型はひな形の変数置換方法でさらに分類でき，単純な文字列置換のケースと，スクリプト言語を用いた複雑な置換のケースが存在した．
単純な置換の例として，nginx コンテナ管理プロジェクトの生成
スクリプトの例（注 7） を図 10 に示す．図 6 に示したひな形内の変数（%%ALPINE_VERSION%% 等）を，生成スクリプト内の可変情報データ（$alpinever 等）に sed 等の置換命令を用いて置換しな
がら Dockerﬁle を生成する．この方法は実装が容易であり，UNIX系の命令を用いることから軽量な点が特徴である．

（注 4）：https://github.com/nginxinc/docker- nginx/blob/d039609e/Dockerfile-

一方で複雑な置換では，awk 等のスクリプト言語を用いて，if 分

alpine.template（注 5）：https://github.com/nginxinc/docker- nginx/blob/d039609e/Dockerfilealpine.template（注 6）：https://github.com/nginxinc/docker-nginx/blob/d039609e/update.sh（注 7）：https://github.com/nginxinc/docker-nginx/blob/d039609e/update.sh

—4—

1

sed -i \pri n t _ u b u n t u _ p k g () {12

-e 's ,%% A LPINE_ VERSION %% , '" $alpinever " ' , ' \2cat >> $1 <<' EOI '3-e 's ,%% D EBIAN_ VERSION %% , '" $debianver " ' , ' \3

RUN apt - get update \

4

..

4

&& apt - get install .. wget ca - certificates \&& rm - rf / var / lib / apt / lists /*

5

図 10

生成スクリプトに含まれる単純な置換処理

1{{ if is_alpine then ( -}}2

FROM alpine :{{ env . variant | ltrimstr (" alpine ") }}3{{ ) elif is_slim then ( -}}4

FROM debian :{{ env . variant | ltrimstr (" slim -") }} -5{{ ) else ( -}}6

FROM buildpack - deps :{{ env . variant }}7{{ ) end -}}

6

EOI

7

}

図 12

make
1件

ハイブリッド
1件

メソッド
1件

slim

図 11

メソッド型を利用した生成スクリプト

txt
2件

調査数
全15件

Python3件

テンプレート13件

ひな形に含まれる複雑な置換処理
図 13

岐等の制御文を駆使して置換をおこなう．この方法では，ひな形

調査数
全15件

JSON
2件

各型の採用数と

図 14

その割合

Bash
7件

可変情報管理の言語別採用数と割合

ファイルにスクリプト言語が埋め込まれており，単一ファイルに 2
種類の言語が記述されている．例として，Python プロジェクトでのひな形ファイルの例（注 8） を図 11 に示す．図 11 の 2 行目や 4 行
目は Dockerﬁle の構文で書かれている．しかし，1 行目や 3 行目
はスクリプト言語である awk の制御文が書かれている．つまり，1に生成スクリプトとは異なる言語を導入する必要があった．メソッ
ド分割を取り入れることで，生成スクリプトと同じ言語による複雑な実装が可能になる．しかし，メソッド型の持つ可読性の低さが目立つことから，万能な方法とは言い難い．

つのひな形ファイルに FROM で始まる Dockerﬁle の構造を持つ
文と，スクリプト言語による制御文が混在している．生成スクリ
プトで制御文を実行させることで，生成対象の Dockerﬁle には 3
つの FROM 文の内 1 つが記述されることになる．この方法は sed
等による単純な置換に比べ，複雑な制御が可能となる．しかしながら，ひな形に制御文が混じることで，可読性は低下するといえる．
次に 3 種の生成スクリプト実現パターンの 2 つ目であるメソッド
型について説明する．メソッド型は，生成スクリプト内で Docker-

ﬁle の生成メソッドを宣言し，そのメソッドの組み合わせによって以上の 3 種の Dockerﬁle 実現パターンが存在した．3 種類の型の採用数を調べた結果を図 13 に示す．テンプレート型が 15 件中13 件とテンプレート型の採用割合が圧倒的に多かった．テンプレー
ト型が多い理由や，メソッド型やハイブリッド型のプロジェクトがテンプレート型を採用しない理由はまだ分かっておらず，それらの調査は今後の課題である．





DPP での Dockerﬁle 生成の実現方法は 3 つの型に大別され，その中でもテンプレート型の採用割合が圧倒的に多い．



Dockerﬁle を生成する方法である．ibmjava プロジェクトでの生5. 4 RQ4: 可変情報はどう管理されるか?

成スクリプトの例（注 9） を図 12 に示す．図 12 では，FROM 文や，

RQ4 では，可変情報の管理ファイルを対象に調査を実施した．

RUN を用いたパッケージマネージャ関連の文等を，Dockerﬁle のその結果を，可変情報の種類，記述言語，生成スクリプトとの切り構造で分けて，それぞれの生成メソッドを定義する．そして，可変分けの有無の 3 つの観点から述べる．

情報に合わせたメソッドの使い分けや，メソッド内での変数処理を

5. 4. 1 可変情報の種類

用いて，Dockerﬁle を生成する．ひな形となるファイルが独立して調査の結果，以下に示す 3 種類の可変情報の存在を確認した．

いないことから，テンプレート型と比較して生成ファイルの全体像• ベース OSの把握は難しい．一方で，各メソッドがプロジェクトに依存してい• サービスのバージョン

ないため，高い移植性を持つと考える．実際にメソッド型を採用し• ホストマシンのアーキテクチャているプロジェクトはあらゆるサービスのコンテナを提供しており，メソッドを再利用していた．
ハイブリッド型は，テンプレート型とメソッド型を組み合わせたまず 1 つ目はコンテナのベースとなる OS である．複数のベース OS の例としては Alpine，CentOS，Buster や Bullseye 等のDebian 系，Ubuntu，Windows 等が挙げられる．調査した 15 件方法である．Dockerﬁle をメソッドに分けて生成する方法は残し中 10 件がベース OS を可変情報として扱っていた．残りの 5 件はつつ，各メソッドで Dockerﬁle に書き込む情報をひな形ファイル

1 つのベース OS のみでの Dockerﬁle 提供を行っていた．

として管理している．したがって，Dockerﬁle の構造で分けられた

2 つ目は，コンテナの提供するサービスのバージョンである．例

複数のひな形ファイルと 1 つの生成スクリプトで構成されている．

えば，Python の実行環境を提供するコンテナであれば，3.10 やテンプレート型では，可変情報の違いによる複雑な処理を行うため

3.9 等によって複数の Dockerﬁle を作成する．調査した 15 件中 12
件がサービスのバージョンを可変情報として扱っていた．残りの 3（注 8）：https://github.com/docker- library/python/blob/master/Dockerfilelinux.template

件は最新バージョンのみの Dockerﬁle を提供していた．

3 つ目は，ホストマシンのアーキテクチャである．Docker Hub（注 9）：https://github.com/ibmruntimes/ci.docker/blob/master/ibmjava/update.sh—5—

6. 妥当性の脅威{

1"3.10": {..

2
3" variants ": [4

" buster " ,調査対象に関して考える．今回の調査では，Docker 公認コンテ
ナ 32 件に対して DPP の採用割合を調査し，15 件を対象にファイ" alpine "

5
6

],

ルの詳細まで精査し，DPP の特徴を整理した．しかし，未調査の7" version ": "3.10.9"

17 件や未収集の Docker コンテナに対しても同様の調査を実施し

8

},

9

"3.11": {..

た場合，異なる結果が得られた可能性がある．

}

10

7. ま と め

}

11

図 15

本研究では，Dockerﬁle のプリプロセッサ（DPP）の実現方法の深い構造を持つ可変情報のデータファイル

体系化を目的として，GitHub リポジトリ上に存在する Dockerﬁleで"arch"として扱われる情報であり，AMD364 や i386 等が該当す

管理プロジェクトの調査を実施した．調査の結果，DPP は広く採る．アーキテクチャを可変情報として扱うプロジェクトは，15 件

用されており，何種類かの実現パターンの存在を確認した．

中 3 件と少なかった．アーキテクチャの可変情報としての処理は

今後の課題として，まず DPP 構成ファイルのファイル名の調査

Docker Compose や Docker Buildx が標準でサポートしているこを検討している．調査時，DPP を構成するファイルのファイル名ともあり，DPP での処理は少ないと考える．

はプロジェクトによって違いが見られた．しかしながら，生成スク

5. 4. 2 記 述 言 語

リプトのファイル名は update.sh が多い等，よく使われるファイ

可変情報の処理を記述する言語を調査した結果，プロジェクト

ル名の存在も確認している．そこで，頻繁に使われるファイル名やによって違いが見られた．可変情報の処理を記述する言語の種類

ディレクトリ名を調査する．これらの調査を実施することで，DPPを調査したグラフを図 14 に示す．一番多い言語は Bash であり調を作成する際のファイル名の提案及び DPP 自動検出の実現に役立査した 15 件中 7 件が採用していた．生成スクリプトの記述言語もつと考える．また，テスト方法の調査も検討している．調査した中Bash が多かったことから，同言語で実装しやすい点が採用理由とには，生成した Dockerﬁle の妥当性をテストするツールが用意さして挙げられる．

れているプロジェクトも存在した．テストを構成するファイル調査

5. 4. 3 生成スクリプトとの切り分け

し，Dockerﬁle のテスト方法を整理する．さらに過去のソフトウェ

複数ファイルで分けているプロジェクトは 4 件存在．残り 11 件

ア工学におけるテストの考え方を取り入れた提案も可能と考える.
謝辞

は生成スクリプト内で可変情報の管理も行っていた．
単一ファイルで処理する場合，生成スクリプト内で可変情報を変で記述される．図 7 で示した変数宣言の例は，生成スクリプトの中に含まれており，生成スクリプトと同じ言語で記述されていた．
複数ファイルで処理する場合は実際の可変情報（alpine と buster
や，1.1 と 1.2 等）を具体的に記述したデータファイルが別に存在
し，生成スクリプト内でデータファイルを読み取る．別ファイルで分けられたデータの例として，Python イメージの管理プロジェク
トでの可変情報ファイル（注 10） を図 15 に示す．JSON 形式の深い構
造に，バージョンの数字やベース OS 等の可変情報が保存される．
生成スクリプトと同じファイルで可変情報を処理する場合，実装は単純である．しかし，ベース OS やバージョンデータの更新と生成スクリプト自体の更新のどちらが更新されたか判別しづらい点があげられる．一方で複数ファイルに分けると，データの読み取りに

可変情報には，ベース OS，サービスのバージョン，ホストマシ
ンのアーキテクチャの 3 種類が存在する．また，その管理は生成スクリプトと同一ファイルで実現される場合もあれば，複数のファイルで実現される場合もある．



JP20H04166，JP21K18302，JP21K11829）による助成を受けた．
文

数として宣言して処理している．また，生成スクリプトと同じ言語

多少実装の手間がかかるものの，更新箇所の判別は容易となる．

本 研 究 の 一 部 は ，JSPS 科 研 費（JP21H04877，

献[1] Portworx, “Annual container adoption report,” 2019. https://portworx.com/wp- content/uploads/2019/05/2019container-adoption-survey.pdf (accessed 2023-01-31).
[2] J. Cito, G. Schermann, J.E. Wittern, P. Leitner, S. Zumberi,and H.C. Gall, “An empirical analysis of the docker container
ecosystem on github,” International Conference on Mining
Software Repositories (MSR), pp.323–333, 2017.
[3] M.U. Haque, L.H. Iwaya, and M.A. Babar, “Challenges indocker development: A large-scale study using stack overﬂow,” International Symposium on Empirical Software Engineering and Measurement (ESEM), pp.1–11, New York, NY,
USA, 2020.
[4] D. Morris, S. Voutsinas, N.C. Hambly, and R.G. Mann, “Useof docker for deployment and testing of astronomy software,”Astronomy and Computing, vol.20, pp.105–119, 2017.
[5] C. Boettiger, “An introduction to docker for reproducible
research,” SIGOPS Operating System Review, vol.49, no.1,
p.71 ‒ 79, 2015. https://doi.org/10.1145/2723872.2723882[6] M.A. Oumaziz, J.-R. Falleri, X. Blanc, T.F. Bissyandé, and J.
Klein, “Handling duplicates in dockerﬁles families: Learningfrom experts,” International Conference on Software Maintenance and Evolution (ICSME), pp.524–535, 2019.
[7] J. Henkel, C. Bird, S.K. Lahiri, and T. Reps, “A datasetof dockerﬁles,” International Conference on Mining Software
Repositories (MSR), p.528 ‒ 532, Association for Computing
Machinery, 2020. https://doi.org/10.1145/3379597.3387498[8] Y. Jiang and B. Adams, “Co-evolution of infrastructure andsource code - an empirical study,” Working Conference on
Mining Software Repositories (MSR), pp.45–55, 2015.

（注 10）：https://github.com/docker-library/python/blob/master/versions.json—6—