社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

構文種別に着目した Dockerﬁle のコードクローン検出手法
鶴

智秋†

中川

将†

柗本 真佑†

肥後 芳樹†

楠本真二†† 大阪大学大学院情報科学研究科
E-mail: †{t-tsuru,t-nakagw,shinsuke,higo,kusumoto}@ist.osaka-u.ac.jp
あらまし

本論文では，Docker に対する Type-2 コードクローンの検出手法を提案する．Docker とは，コンテナ型

仮想環境を実現するプラットフォームであり，サーバインフラを支える技術として注目されている．Docker では仮
想環境実現の手順を，Dockerﬁle と呼ばれる一種のソースコードの形式で記述する．そのため，似た構造の繰り返しや重複といったコードクローンが必ず含まれる．本研究は，Dockerﬁle における Type-2 クローンの検出を目的として， Dockerﬁle 固有のネスト構造という性質に着目した検出手法を提案する．提案手法では，構文要素に対して適切な正規化を行い， Dockerﬁle 構文と Shell Script 構文に分離し，それぞれの構文ごとに接尾辞配列アルゴリズム
を用いてコードクローン検出を行う．GitHub 上に公開されている約 2,000 個の Dockerﬁle を対象に適用実験を行い，高い適合率で Type-2 クローンを検出した．また，Dockerﬁle における定型処理を発見した．
キーワード

Docker，Dockerﬁle，コードクローン，コードクローン検出

1. は じ め に検出手法を提案する．本研究の貢献は以下の通りである．
• Dockerﬁle における Type-2 クローンの検討と定義：

コンテナ仮想化と呼ばれるリソース効率に優れた仮想環境

Type-2 クローンでは，プログラムの振る舞いに影響を与えなを実現するプラットフォームとして，Docker が着目されていいトークンの違いを許容する．よってその検出には，変数名

る [1]．Docker はインフラの構成自動化，IaC（Infrastructure

や関数名，定数の適切な正規化が必須である．Dockerﬁle では

as Code）を実現する技術の一つであり，コンテナ構築手順を変数以外にも，ファイルパスやポート番号などの様々な定数

Dockerﬁle と呼ばれるソースコードに記述する．インフラ構築

要素が含まれる．さらには，Shell Script 構文内でのパラメタ

手順のコード化により，誰がいつ実行しても全く同じインフ

順序やオプション名のエイリアスなどのように，振る舞いにラ環境を迅速に再現することが可能となる [2]．Docker は近年影響を与えない記法が多数存在する．本研究では，正規化対注目されている技術であり，多くの企業や OSS で採用されて象とするトークン要素を整理することで，Dockerﬁle における始めている [3] [4]．一方で，Docker をはじめとする IaC の周辺技術は黎明期にあり，研究が未熟な領域が存在することもType-2 クローンを検討する．
• 構文種別を考慮した Dockerﬁle におけるクローン検出

指摘されている [5]．

手法の提案：Dockerﬁle は，単一ファイル内に複数言語の構文

本研究では，Dockerﬁle で発生するコードクローン（以後，を記述可能なネスト言語である [1] [14]．コンテナ内部での処クローン）について考える．クローンとはソースコード内に理を Shell Script 構文で記述し，それ以外のコンテナの外界とおける一致，または類似コード片のことであり，様々な研究の処理（ホスト OS からのファイルコピーやコンテナの公開者によって盛んに研究されている [6] [7] [8]．クローンの検出

ポート番号の指定など）を Dockerﬁle 構文で記述する．提案により，利用 API の推薦 [9] や，冗長な記述に対するリファ

するクローン検出手法では，まず与えられた Dockerﬁle から

クタリングの推薦 [10]，同一変更を要する箇所に対する変更推

抽象構文木を作成し，トークンの正規化を行う．さらに 2 種

薦 [11]，ライセンス違反の検出 [12]，といった様々な応用が可類の構文を分離し，接尾辞配列アルゴリズムを適用すること能となる．
これまでに Java や C などの手続き言語に限らず，様々な言で構文種別を考慮したクローン検出を実現する．
• 公開されている Dockerﬁle に対する Type-2 クローン語やファイルを対象としたクローン検出技術が研究されてきた検出，及び Dockerﬁle における定型処理の発見：GitHub 上のが，Dockerﬁle に対するクローン検出の提案は少ない．一部，

223 リポジトリ内に存在する 1,897 個の Dockerﬁle を対象と

Oumaziz らによって Dockerﬁle を対象とした重複コード片のして，提案手法を用いた Type-2 クローン検出を行う．提案手検出手法が提案されている [13]．この手法では，Dockerﬁle の法を用いた結果，適合率 95 % で Type-2 クローンを検出できトークンを分離し，転置索引と呼ばれるアルゴリズムを用いてた．また，空のコンテナからディストリビューションを構成

重複箇所を検出する．しかし，この手法は完全一致する重複するといった処理のように，Dockerﬁle における定型処理を発コード片（Type-1 クローン）のみを対象としており，変数名

見した．

の違いを許容したクローン（Type-2）の検出は不可能である．
本研究では，Dockerﬁle に対する Type-2 コードクローンの
—1—

2. 準
2. 1

備

A B A C D A B
トークン列

コードクローン

1. 接尾辞列挙

コードクローン（クローン）とは，ソースコード内における一致コード片または類似コード片を指す．一致コード片及び

位置

接尾辞

2. 辞書順ソート
位置

接尾辞

3. クローンセット
出⼒

0 2 5

類似コード片の集合はクローンセットと呼ばれる．クローン

0 A B A C D A B

5 A B

1

B A C D A B

0 A B A C D A Bは，一般的にその類似度の違いに基づき，以下の 3 種類に分2

A C D A B

類される [6]．
• Type-1: 空白や改行，及びコメントの差異を除いて完全

3

C D A B

4

D A B

5

A B

3 C D A B

1 3

一致するクローン• Type-2: 変数名や関数名などの識別子名の差異を除い

6B

4 D A B

クローンセット “B”

クローンセット “A”

2 A C D A B
6 B

0 2
クローンセット “A B”

1 B A C D A B

図 1: 接尾辞配列の構成手順及びクローン検出方法て一致するクローン• Type-3: 命令文単位での挿入や削除，変更が行われたクを適用して，重複コードを検出する．なお，Dockerﬁle におい

ローンて，単一の RUN 命令内部に複数の Shell Script 命令を記述す

これまでに，一般的なプログラミング言語において，多数

るプラクティスが存在する．彼らの手法では，Shell Script 命のクローン検出手法が提案されている [6] [7] [8]．また，ビルド

令に内在する重複コードも検出するために，構文解析時に RUN

ツールや要求定義書などといった，プログラミング言語以外の命令を内部の Shell Script 命令単位で分離させる．

言語においてもクローン検出研究が行われている [15] [16] [17]．
2. 2DockerOumaziz らの手法は，トークンの正規化を適用していないため，文の類似ではなく完全一致，すなわち Type-1 クロー

Docker は，コンテナと呼ばれる OS レベルの仮想化を実現

ンのみを検出対象としている．また，Dockerﬁle 構文と Shell

するプラットフォームである．Docker は近年注目されている

Script 構文とを区別していないため，例えば，Shell Script 構技術であり，IT 企業の 87 % で使用されているほか，多様な文（RUN 命令の中身）の内容が本質的にクローンの関係にあOSS で採用されている [3] [4]．

るものの，片方の Dockerﬁle では RUN 命令の途中に ENV 命

Docker は IaC (Infrastructure as Code) と呼ばれるインフ

令等の Dockerﬁle 構文が挿入されている場合，クローンとしラの構成自動化を実現する重要な技術の一つであり，コンテて検出することはできない．さらに，転置索引アルゴリズム

ナ構築手順をソースコードとして記述できる [2]．Docker コ

では最短クローン長を固定しているため，長さがそれ未満のンテナ構築手順を記したソースコードを Dockerﬁle と呼び，クローンを検出できない [18]．

Dockerﬁle から構成されるコンテナのテンプレートをイメージ

2. 4と呼ぶ．Dockerﬁle は表 1 に示す主な Dockerﬁle 構文で記述さ接尾辞配列は，文字列検索アルゴリズムで使用されるデーれる．また，Dockerﬁle は RUN 命令に Shell Script 構文を内

タ構造の一種であり，検索文字列における接尾辞を辞書順に包できるという性質を持つ，ネスト言語でもある [1] [14]．

並べ替えて得られる配列である [19]．接尾辞配列を用いるこDockerﬁle における重複コード検出手法とにより，長さが n の文字列から，長さが m である検索対

2. 3

接尾辞配列アルゴリズム

Oumaziz らは，Dockerﬁle に対する重複コード検出手法を

象文字列の出現位置を O(m + log n) の時間計算量で求められ提案している [13]．彼らは，Dockerﬁle を構文解析したのち，る [19]．また，SA-IS 法を用いることで，接尾辞配列を O(n)Dockerﬁle 命令 6 種を 1 単位とした転置索引アルゴリズム [18]の時間計算量で構築できる [20]．接尾辞配列は，クローン検出の分野においても採用されている [21]．図 1 に，トークン

表 1: 主な Dockerﬁle 構文の一覧

列 “A B A C D A B” を基にした接尾辞配列の構成手順及びクローン検出方法を示す．まず，接尾辞列挙により入力トークン

命令名

概要

FROM

コンテナの基となるイメージの指定

ARG

Dockerﬁle 内部における一時変数定義

ENV

コンテナ内部における環境変数定義同士に対し，前方一致する部分トークン列同士をトークンセッ

RUN

Shell Script で記述されるコンテナ構築手順

トとして出力する（手順 3）．トークン列 “A B A C D A B” のCOPY

ホスト OS 上のファイルをコンテナへコピー

例では，“A”，“A B”，“B” の 3 種類がクローンである．

ADD

ホスト OS 上のファイルをコンテナへコピー
tar アーカイブであるならばコンテナ上で展開

WORKDIR

ワーキングディレクトリ変更

USER

ユーザ名・グループ名の指定

EXPOSE

コンテナ外部に開放するポート番号の指定

ENTRYPOINT コンテナ起動時に実行するコマンドの指定
CMD

コンテナ起動時に実行するコマンド引数の指定

列の各接尾辞を配列に格納する（手順 1）．次に接尾辞配列を辞書順にソートする（手順 2）．最後に，接尾辞配列内の接尾辞

3. 提 案 手 法
3. 1

概

要

提案手法の概要を図 2 に示す．提案手法の入力は複数のDockerﬁle であり，出力は検出したクローンセットである．手法の流れについて図 2 に従って説明する．まず，入力として

—2—

1.
AST
構成

2.
トークン
正規化

3.
命令単位で
ハッシュ化

4.
構⽂ごとに
統合

5.
接尾辞配列
構成・⽐較

0
1
2
5
0

3

0

4

Dockerfile構⽂

3
1

6.
クローンセット
出⼒
0

3

0

4

3

0

0

4
0

4

Dockerfile構⽂の
接尾辞配列
1

0
1
4
5

1

2

1

1

2

Shell Script構⽂

2

Dockerfile

抽象構⽂⽊
(AST)

正規化された
AST

ハッシュ値列

1

4

1
1
1
2
2

1
2
2

2
1

1

1

1

2

2

Shell Script構⽂の
接尾辞配列

2

2

⽔⾊ Dockerfile構⽂
橙⾊ Shell Script構⽂
⻘ 異なるトークン
茶 正規化されたトークン
ファイル間の区切り

図 2: 提案手法の概要

与えた複数の Dockerﬁle から，それぞれに対応する抽象構文

なる．さらに，ソースコードの処理内容の同一性という観点

木を生成する（手順 1）．次に，各トークンの正規化を行う

では，Shell Script でのオプション順序（ls -l . と ls . -l）（手順 2）．この正規化処理により Type-1 クローンの検出からや，オプション名のエイリアス（ls -list と ls -l）など，

Type-2 クローン検出への拡張が可能となる．さらに命令単位同一処理を実現可能な別記法が多数存在する．これらを適切のハッシュ化（手順 3），及び構文毎の統合（手順 4）を適用すに正規化することで Dockerﬁle の Type-2 クローンが検出可能

る．Dockerﬁle 構文と Shell Script 構文をあらかじめ分離し，となる．

続く接尾辞配列アルゴリズム（手順 5）とクローンセットの検本研究では，正規化対象とするトークンを表 2，正規化対出（手順 6）を行うことで，構文毎のクローンの検出を実現象としないトークンを表 3 の通り定義した．図 3 は，提案手する．

法によるトークン正規化の例である．正規化対象トークンの以降の節では，手順 2 で正規化するトークン（3. 2 節），手一つに，Shell コマンドにおけるパラメタ・オプション順序が順 4 で Dockerﬁle 構文と Shell Script 構文にあらかじめ分離ある．Shell コマンドは，コマンドの種別ごとにパラメタやオする理由（3. 3 節），そして手順 5 で接尾辞配列アルゴリズム

プションの順序が定められている．コマンドによっては，パを採用する理由（3. 4 節）について述べる．

ラメタやオプションの記述順序の違いを許容している．その正規化対象トークンの検討ため，パラメタやオプションが異なるにもかかわらず同じ動3. 2

Type-2 クローンの検出のためには，ソースコード内のトー作を行うコマンドが，複数の Dockerﬁle 内で発生する．例えクンを適切に正規化する必要がある．Java や C 等を対象とし

ば，RUN apt-get install --yes --no-install-recommends

た一般的なコードクローン研究においては，変数名や関数名なと RUN apt-get install --no-install-recommends --yes

どの識別子名を正規化対象とすることが多い [22]．変数名や関はパラメタ・オプション順序が異なるクローン片の一例で数名は一種のラベル情報であり，そのラベルが異なっても同一処理を実現可能なためである．Dockerﬁle でも一時変数（ARG（注 1）：https://github.com/docker-library/rabbitmq/blob/master/Dockerfile-

命令で宣言される変数）などが存在しており，正規化の対象とubuntu.template

表 2: 正規化対象とするトークン
トークン名

理由

正規化の例

一時変数名

コンテナ内の外部プロセスに影響を与えないため

ARG tag=bionic → ARG $$VAR0=bionic

パラメタ・オプション順序 意味的に同値なコマンドを実行できるため

set -xe → set -e -x

オプションのエイリアス

意味的に同値なコマンドを実行できるため

rm -fr → rm --force --recursive

ファイルパス

パスの差異が振る舞いに影響を与えないため

cd webapps/convertigo → cd $$PATH0

ユーザ・グループ

ユーザやグループの差異が振る舞いに影響を与えないため

USER spark:spark → USER $$USER0:$$GROUP0

コンテナのポート番号

ポート番号の差異が振る舞いに影響を与えないため

EXPOSE 80 → EXPOSE $$PORT0

FROM 命令のタグ

タグによるコンテナの機能差がほとんど無いため

FROM ubuntu:16.04 → FROM ubuntu:$$TAG0

表 3: 正規化対象としないトークン
トークン名

理由

環境変数名

コンテナ内の外部プロセスに影響を与えるため

FROM 命令のイメージ名

イメージごとに内包されるパッケージマネージャが異なるため—3—3 FROM ubuntu:18.04

3 FROM ubuntu:$$TAG0

...

...

16 ARG PGP_KEYSERVER=ha.pool.sks-keyservers.net

16 ARG $$VAR0=ha.pool.sks-keyservers.net

...

...

59 RUN set –e –u -x; ¥¥60
61$$VAR1="$(apt-mark showmanual)”: ¥apt-get update; ¥6263
apt-get install --no-install-recommends –-yes ¥59 RUN set -eux; ¥¥60
61
savedAptMark="$(apt-mark showmanual)"; ¥apt-get update; ¥6263
apt-get install --yes --no-install-recommends ¥
...

72
73

...

72
73

; ¥
rm -rf /var/lib/apt/lists/*; ¥; ¥rm –-force --recursive $$PATH0/*; ¥

...

83
84
85

...

for key in $OPENSSL_PGP_KEY_IDS; do ¥gpg --batch --keyserver "$PGP_KEYSERVER" --recv-keys "$key"; ¥done; ¥

83
84
85

chown -R rabbitmq:rabbitmq "$RABBITMQ_HOME"; ¥

255

...

255

for $$VAR2 in $OPENSSL_PGP_KEY_IDS; do ¥gpg --batch --keyserver "$$VAR0” --recv-keys ”$$VAR2"; ¥done; ¥
chown -R $$USER0:$$GROUP0 "$RABBITMQ_HOME"; ¥...

292 EXPOSE 4369 5671 5672 15691 15692 25672

292 EXPOSE $$PORT0 $$PORT1 $$PORT2 $$PORT3 $$PORT4 $$PORT5 $$PORT6(a) 正規化前

図 3: 実際の Dockerﬁle

30
31
32
33
34
35
36

$OPENSSL_PGP_KEY_IDSは環境変数であるため，正規化を施さない．

...

...

21
22
23

茶⾊ 抽象概念への変換
⽔⾊ オプションのエイリアス
下線 オプションの分離・順序変更(b) 正規化後（注 1）# set up ssh keys
RUN mkdir -p /var/run/sshd ¥&& ssh-keygen -A ¥...
&& chmod 700 /root/.ssh ¥&& cp /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys# download and install mlnx
RUN wget -q -O - http://www.mellanox.com/downloads/ofed/
MLNX_OFED-4.6-1.0.1.1/MLNX_OFED_LINUX-4.6-1.0.1.1-rhel7.6-x86_64.tgz| tar -xzf - ¥&& ./MLNX_OFED_LINUX-4.6-1.0.1.1-rhel7.6-x86_64/mlnxofedinstall--user-space-only --without-fw-update --all --force ¥&& rm -rf MLNX_OFED_LINUX-4.6-1.0.1.1-rhel7.6-x86_64

に対するトークン正規化の例
11
12
13
20
21
22
23
24
25
26
27
28
29
30

(a) OpenFOAM イメージの Dockerﬁle （注3） から抽出したクローン片# set up ssh keys
RUN mkdir -p /var/run/sshd ¥&& ssh-keygen -A ¥...
&& chmod 700 /root/.ssh ¥&& cp /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys# set up workdir
ENV INSTALL_PREFIX=/opt
WORKDIR /tmp/mpi# download and install mlnx
RUN wget -q -O – http://www.mellanox.com/downloads/ofed/
MLNX_OFED-4.6-1.0.1.1/MLNX_OFED_LINUX-4.6-1.0.1.1-rhel7.6-x86_64.tgz| tar -xzf - ¥&& ./MLNX_OFED_LINUX-4.6-1.0.1.1-rhel7.6-x86_64/mlnxofedinstall--user-space-only --without-fw-update --all --force ¥&& rm -rf MLNX_OFED_LINUX-4.6-1.0.1.1-rhel7.6-x86_64(b) mpibench イメージの Dockerﬁle （注 2） から抽出したクローン片

図 4: Shell Script 命令列に Dockerﬁle 命令列が挿入された Type-1 クローンの一例（図 4(b)）の 23 行目 ∼ 25 行目には，OpenFORM イメー

ある．
3. 3

構文種別の分離

Dockerﬁle は Shell Script 構文を内包したネスト言語である [1] [14]．そのため，Dockerﬁle でトークンを正規化するなら
ば，Dockerﬁle 構文における抽象構文木と Shell Script 構文の抽象構文木をそれぞれ構成しなければならない．

ジ Dockerﬁle （注 3）（図 4(a)）で出現しなかった Dockerﬁle 命令列が挿入されている．提案手法では，図 4 のようなクローンが検出可能である．
3. 4

接尾辞配列の構成及び比較

Oumaziz らは，Dockerﬁle 開発者が長さが 6 未満の命令列

また，Dockerﬁle は，一方の構文で記述された命令列に対も必要としていると述べている [13]．本研究では，接尾辞配して，もう一方の構文で記述された命令及びその構文の命令

列は可変長クローンを検出可能であるという特徴に着目し列を挿入できる．例えば，Dockerﬁle 命令列に Shell Script 構

た [21]．提案手法では，Dockerﬁle 命令及び Shell Script 命令文を内包した RUN 命令を挿入できる．一方，RUN 命令が内

1 個ごとにハッシュ化を施しているため，任意の長さにおける包する複数の Shell Script 命令列は，Shell Script 命令単位でDockerﬁle 命令列や Shell Script 命令列をクローン片として検分離可能である．したがって，RUN 命令を Shell Script 命令

出できる．

単位で分離して，Shell Script 命令列に Dockerﬁle 命令及びなお，提案手法では，全ての Dockerﬁle のハッシュ値列を構

Dockerﬁle 命令列を挿入できる．一般的なプログラミング言語

文種別ごとに統合した巨大なハッシュ値列に対して，接尾辞と同様に，Dockerﬁle における命令文単位の修正で生じる上記

配列アルゴリズムを適用する．単純な接尾辞配列アルゴリズのような類似コードは，Type-3 クローンとして定義可能であムでは，異なるファイル間で統合されたコード片をクローンる．しかし，各構文に着目すると，構文ごとで命令文単位でのとして検出するため，ハッシュ値ごとに，そのハッシュ値の基修正は行われていない．したがって，本研究では，Dockerﬁleとなった構文が含まれている Dockerﬁle の情報を含める必要がネスト言語である特徴に着目し，構文種別が異なる命令列
単位の修正によって発生する類似コード片は Type-2 クローンに分類する．
図 4 は，Shell Script 命令列に Dockerﬁle 命令列が挿入されたクローンの一例である．mpibench イメージ Dockerﬁle （注2）

（注 2）：https://github.com/Azure/batch-shipyard/blob/master/recipes/
mpiBench-Infiniband-MPICH/docker/Dockerfile（注 3）：https://github.com/Azure/batch-shipyard/blob/master/recipes/
OpenFOAM-Infiniband-OpenMPI/docker/Dockerfile

—4—

1

1

FROM scratch
...

3
4

FROM scratch
...

3
4

ADD rootfs.tar.xz /CMD ["/bin/bash"](a) CRUX イメージ （注 4） の Dockerﬁle から抽出したクローン片ADD smgl-stable-0.62-docker-x86_64.tar.xz /CMD ["/bin/bash"](b) Source Mage イメージ （注 5） の Dockerﬁle から抽出したクローン片

図 5: 提案手法で発見した定型処理（Type-2）

がある．

4. 実
4. 1

実験結果

4. 3

4. 3. 1験

検出できるクローンの個数及び精度

表 4 は，実験で検出できたクローン片やクローンセット，適合率を載せた実験結果である．まず，既存手法と正規化ありの

実験目的

実験の目的は，提案手法による Dockerﬁle の Type-2 クロー

提案手法について比較すると，提案手法が検出したクローン片

ン検出能力の確認である．比較対象としては，Oumaziz らにの数及びクローンセット数は，既存手法で検出できたクローン

よる Type-1 クローン検出手法 [13] を用いる．以降では，この片及びクローンセット数よりも多い．提案手法では，トーク手法を既存手法と呼ぶ．計測指標は，検出クローンの個数とンを適切に正規化して，接尾辞配列を用いて任意の長さを持適合率であり，Type-2 クローンは Type-1 クローンを包含す

つクローン片を検出できる．そのため，提案手法が既存手法るため提案手法の検出数が増えると期待される．適合率とは，より多くのクローンを検出できるという期待にそった結果と検出したクローンのうち，実際にクローンである候補の割合なった．次に，正規化を施した提案手法と正規化を施さないである．適合率が高いほど，よいクローン検出手法と言える．

提案手法を比較すると，正規化を施した提案手法の方が，正規

なお対象とした Dockerﬁle における真のクローンの集合は未化を施さない提案手法よりも検出できるクローン片の数及び知であるため，検出したクローンセットから各手法ごとでラ

クローンセット数が少ない．正規化ありの提案手法（Type-2）

ンダムに 101 個抽出し，目視確認により適合率を算出する．

は正規化なしの提案手法（Type-1）を包含するためクローン

4. 2の検出数が多い，という期待を反する結果となった．その原

実験対象

GitHub 上で人気がある 223 リポジトリのうち，それらの因として，正規化前のトークン名が同じであるにも関わらず，

リポジトリ内に存在する 1,897 ファイルを対象とする．なお，

正規化処理によって抽象化されたトークン名に差異が生じた

Docker ではテンプレートファイルにコンテナ構築の全体の流ためと考えられる．そのため，クローン片の数及びクローンれを記述し，ディストリビューションやバージョンの細かなセット数が減少しないように改善した正規化処理の提案は今差異を可変変数で定義する，というプラクティスが存在する．

後必須である．最後に，既存手法と正規化ありの提案手法の適

このテンプレートを実行，あるいはコンパイルすることで目的合率について比較すると，正規化を施した提案手法の適合率の Dockerﬁle を自動生成する．この自動生成された Dockerﬁleは既存手法の適合率より低い．一般的に正規化を施すほど適は Type-2 クローンの関係にあるが，自動生成を理由としたク

合率は下がりやすい．Type-1 クローンよりも Type-2 クロー

ローンであり検出対象とすべきではない．よって，テンプレー

ンが，Type-2 クローンよりも Type-3 クローンの方が検出はトファイルが存在するリポジトリに対しては，そのリポジト困難となる．しかしながら，提案手法は適合率 95 % と高く，リに存在する Dockerﬁle ではなく，テンプレートそのものをType-2 クローン検出手法として有用であると言える．

対象とする．

4. 3. 2検出した Type-2 クローンの一例

多くの Dockerﬁle では Shell Script 構文として Bash shell を

本実験では，提案手法で検出した Type-2 クローンの内，採用している [1] [14]．したがって，本実験では Shell Script 構

Dockerﬁle における定型処理を発見した．図 5 は，提案手法で文を Bash に限定する．また，抽象構文木構成のために構文解発見した，定型処理を含む Type-2 クローンの一例である．ど析を行う Bash コマンドを，Henkel らが調査した Dockerﬁle

ちらの Dockerﬁle も，scratch と呼ばれる空のコンテナへ，tar

で頻繁に用いられる上位 50 種類に限定する [1] [14]．なお，クアーカイブをホスト OS からコピーし，その tar アーカイブをローン検出において，転置行列の大きさは通常 7 または 10 以
下でなければならない [18]．そのため，既存手法における転置索引の大きさは，彼らの論文で採用された値である 6 とする．

（注 4）：https://github.com/cruxlinux/docker-crux/blob/master/Dockerfile（注 5）：https://github.com/vaygr/docker-sourcemage/blob/master/stable/
Dockerfile

表 4: 検出できたクローン数及び適合率
既存手法 [13]

提案手法（正規化なし）
Dockerﬁle 構文

Shell Script 構文

提案手法（正規化あり）
Dockerﬁle 構文 Shell Script 構文

クローン片数

24,68793,435211,104

94,153

クローンセット数

4,630

18,884

56,11818,75754,369100.00 %100.00 %100.00 %95.05 %

98.02 %

適合率207,748—5—

コンテナ上で展開して，新たなディストリビューションを構

[7]

成する．
[8]

5. お わ り に本研究では，Dockerﬁle における Type-2 クローンの定義，及び Dockerﬁle 固有の文法構造に着目した Type-2 クローンの[9]検出手法を提案した．提案手法を用いて，223 個の GitHub リ
ポジトリ上に存在する 1,897 ファイルに対して実験を行ったと[10]

ころ，Type-2 クローンを検出できた．また，提案手法の適合率が Dockerﬁle 構文及び Shell Script 構文のそれぞれで 95 %以上であったため，提案手法が有効であるといえた．

[11]

本研究の今後の課題としては以下が考えられる．
• トークン正規化による検出クローンの減少：4. 3. 1 節で述べた通り，本研究の実験では，トークン正規化によって検出[12]できるクローンが減少した．そのため，この問題を改善する手法の提案は今後必須である．1 つの解決策として，一次変数同士を同一視してクローン検出するというように，正規化し[13]た同種トークンを区別しない方法が考えられる．しかし，この解決策ではトークン種別以外を同一視するため，適合率が低くなると考えられる．
• 構文を分離しない Type-2 クローン検出：提案手法では，[14]

両構文を分離して各構文ごとにクローンを検出しているため，Dockerﬁle 命令列と Shell Script 命令列の双方を含むクローン[15]を検出できない．Dockerﬁle 構文と Shell Script 構文が一式となるクローンも活用できると考えられるため，両構文を含有するクローンも検出する必要がある．
• Type-3 クローンへの拡張：Dockerﬁle には，パッケージ[16]

マネージャの違いにより発生するクローンが存在する．パッケージマネージャによって必要な Shell Script コマンドが異なるため，文単位で修正されたクローンを検出する手法が必要

[17]

である．
謝辞

本研究の一部は，日本学術振興会科学研究費補助金

基盤研究（B）（課題番号：18H03222）の助成を得て行われた．
文

[18]

献

[1] J. Henkel, C. Bird, S.K. Lahiri, and T. Reps, “A dataset of
dockerﬁles,” In Proceedings of International Conference on
Mining Software Repositories, pp.528–532, 2020.
[2] Y. Jiang and B. Adams, “Co-evolution of infrastructure andsource code-an empirical study,” In Proceedings of Working
Conference on Mining Software Repositories, pp.45–55, 2015.
[3] Portworx, “Annual container adoption report,” https://
portworx.com/wp-content/uploads/2019/05/2019-containeradoption-survey.pdf, 2019. [Online; accessed 18. Jan. 2021].
[4] 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,” In Proceedings of International Conference on Mining Software Repositories, pp.323–333, 2017.
[5] R. Jabbari, N. binAli, K. Petersen, and B. Tanveer, “What isdevops? a systematic mapping study on deﬁnitions and practices,” In Proceedings of the Scientiﬁc Workshop Proceedingsof XP2016, pp.1–11, 2016.
[6] S. Bellon, R. Koschke, G. Antoniol, J. Krinke, and E. Merlo,“Comparison and evaluation of clone detection tools,” IEEE
Transactions on Software Engineering, vol.33, no.9, pp.577–
591, 2007.

[19]

[20]

[21]

[22]

A. Sheneamer and J. Kalita, “A survey of software clone detection techniques,” International Journal of Computer Applications, vol.137, no.10, pp.1–21, 2016.
H. Min and Z. Li Ping, “Survey on software clone detection research,” In Proceedings of International Conference on
Management Engineering, Software Engineering and Service
Sciences, pp.9–16, 2019.
I. Keivanloo, J. Rilling, and Y. Zou, “Spotting working code
examples,” In Proceedings of International Conference on
Software Engineering, pp.664–675, 2014.
N. Yoshida, S. Numata, E. Choiz, and K. Inoue, “Proactive
clone recommendation system for extract method refactoring,” In Proceedings of International Workshop on Refactoring, pp.67–70, 2019.
M. Mondal, C.K. Roy, and K.A. Schneider, “An exploratory
study on change suggestions for methods using clone detection,” In Proceedings of International Conference on Computer Science and Software Engineering, pp.85–95, 2016.
A. Monden, S. Okahara, Y. Manabe, and K. Matsumoto,“Guilty or not guilty: Using clone metrics to determine open
source licensing violations,” IEEE software, vol.28, no.2,
pp.42–47, 2010.
M.A. Oumaziz, J.-R. Falleri, X. Blanc, T.F. Bissyandé, andJ. Klein, “Handling duplicates in dockerﬁles families: Learning from experts,” In Proceedings of International Conference
on Software Maintenance and Evolution, pp.524–535, 2019.
J. Henkel, C. Bird, S.K. Lahiri, and T. Reps, “Learning from,understanding, and supporting devops artifacts for docker,”
In Proceedings of International Conference on Software Engineering, pp.38–49, 2020.
S. McIntosh, M. Poehlmann, E. Juergens, A. Mockus, B.
Adams, A.E. Hassan, B. Haupt, and C. Wagner, “Collecting and leveraging a benchmark of build system clones toaid in quality assessments,” In Proceedings of International
Conference on Software Engineering, pp.145–154, 2014.
E. Juergens, F. Deissenboeck, M. Feilkas, B. Hummel, B.
Schaetz, S. Wagner, C. Domann, and J. Streit, “Can clone
detection support quality assessments of requirements speciﬁcations?,” In Proceedings of International Conference on
Software Engineering, pp.79–88, 2010.
C. Domann，E. Juergens, and J. Streit, “The curse of
copy&paste̶ cloning in requirements speciﬁcations,” In Proceedings of International Symposium on Empirical Software
Engineering and Measurement，pp.443–446，2009．
B. Hummel, E. Juergens, L. Heinemann, and M. Conradt,“Index-based code clone detection: incremental, distributed,
scalable,” In Proceedings of International Conference on Software Maintenance, pp.1–9, 2010.
U. Manber and G. Myers, “Suﬃx arrays: a new method foron-line string searches,” Siam Journal on Computing, vol.22,
no.5, pp.935–948, 1993.
G. Nong, S. Zhang, and W.H. Chan, “Two eﬃcient algorithms for linear time suﬃx array construction,” IEEE Transactions on Computers, vol.60, no.10, pp.1471–1484, 2010.
H.A. Basit and S. Jarzabek, “Eﬃcient token based clone detection with ﬂexible tokenization,” In Proceedings of European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp.513–516, 2007.
C.K. Roy, J.R. Cordy, and R. Koschke, “Comparison andevaluation of code clone detection techniques and tools: A
qualitative approach,” Science of Computer Programming,
vol.74, no.7, pp.470–495, 2009.

—6—