Docker, Singularityが何かということを以下の記事で過去に紹介しました。
その後実験医学増刊号でもDockerを用いた私のシングルセル解析プラットフォームを紹介させていただきました。ここでも「Dockerは環境が統一できるので有用だよ！」と宣伝しているのですが、実際には、不特定多数の人に使ってもらう環境だと思った以上に環境統一は難しいのでは…？という気がしてきました。以下、その理由です。
・ 皆新しく自分の環境にパッケージをインストールする
「できるから」ということで、当然ではあるのですが。Dockerは実行したコンテナ上で新たにパッケージをインストール可能ですし、SingularityにもSandboxという機能があり、起動したSingularityイメージ上でpipなどでツールをインストールすると自動的にホームディレクトリ内にキャッシュを作成し、ユーザオリジナルの環境をビルドするようです。自分でパッケージをインストール可能であることはコンテナの利点の一つではあるのですが、そのためユーザごとに異なる環境になり得るので冪等性は失われます。かつ、ユーザは意外と自分が何かインストールしたという事実を覚えていません…。「こんなエラーが出るのですが」と質問をいただき、環境が再現しないのでなぜだろうか…とよくよく聞いていると何かしらパッケージをインストールしていてバージョンがコンフリクトしている、のようなこともありました。今後エラー質問メールを受けるたびにそれを確認しないといけないのか？と思うとなかなか大変です。
・ マウントしたローカルディレクトリのツール・ライブラリを読み込む可能性がある
ローカルにあるデータを読み込むためにディレクトリをマウントすることがありますが、マウントされたディレクトリ内にバイナリツールが含まれており、そこにパスが通っていたりすると、イメージ内のツールではなくローカルのツールが呼び出される可能性があります。例えばRのライブラリは一般ユーザ環境ではホームディレクトリに ~/R ディレクトリが作成され、そこに格納されますが、ホームディレクトリ上でSingularityを起動するとホームディレクトリが自動的にマウントされますから、パスによってはローカルのRライブラリが呼び出される可能性もあるわけです。
（Singularityはどこで起動してもホームディレクトリをマウントしているっぽいですね。そうなると.jupyterなどの設定はローカルPCのものが反映されることになりますね。）
また、ツールによっては内部で別のツールを呼び出すような設計になっているものがあります。例えばscATAC-seqのためのSignacはピークコールのために内部でMACS2を呼び出しますが、以下のように macs2.path オプションによって起動するmacs2バイナリを指定可能です。ここで例えばローカルのMACS2を呼び出す設定にしているとすると、それはもう同一環境とは呼べません。これもまた、外部からは見えにくいバグの要因になり得ます。
peaks <- CallPeaks( object = pbmc, group.by = "predicted.id", macs2.path = "/usr/local/bin/macs2" )
・ そもそもインストールしたツールにバグ入ってたりしがち
これはイメージを作成する側の問題でユーザ依存ではないのですが、上で紹介したシングルセル解析プラットフォームに含まれているツール群は個人ベースで開発しているものが多い＋大量の依存関係を持つツールが多いので、アップデートの際にライブラリバージョン依存のバグが入ることがしばしば起きます。私のDockerfileではバージョンを指定せずにツールをインストールしているので（怠慢？すみません）、Dockerfileが同一でも、イメージ作成時によって含まれるツール群のバージョンが異なり、そのためエラーが起きる可能性があります。実際にそういうことは何度も起きています…なので同じDockerfileでもうかつにビルドをやり直さない方がいいのだなという教訓は得ました。
結論
「大量のツール群をインストールした環境」のイメージ、というのがそもそもコンセプト的に矛盾しているような気もしてきました。virtual environmentを切り分けるように、用途ごとに別々のイメージ作るのが本来の使い方だという気もするのですが、自分用ではなく不特定多数の人に公開する目的では切り分けしづらいという感覚もあります。Dockerfileをきれいにしてくれる校正業者とかいたらいいんですけど f^_^;
