PerlのDockerコンテナ化に関する考察

PerlのDockerコンテナ化に関する考察を書いてみる。僕は、Dockerをまだ使ったことはないので、実現できない部分に気が付いたのであれば、コメント歓迎です。

OSのデフォルトのPerlを使ったほうが良い理由

コンテナ化する場合は、perlbrewやplenvでインストールするPerlよりも、OSが提供しているシステムPerlを使う方が良いと考えます。

システムPerlは、OSのパッケージ管理コマンドで、試験済みのバイナリのPerlが、数分以内でインストールできるからです。

perlbrewやplenvは、ユーザー領域に、Perlソースコードからインストールして使るようにするという仕組みです。

この仕組みは、便利すぎますが、コンテナ化との相性を考えた場合は、インストールに時間がかかる、容量が多くなるというデメリットになります。

環境構築用サーバーを準備したほうが良い理由

Perlソースコードは、テキストですが、CPANからインストールされるモジュールについていえば、これは当てはまりません。なぜなら、XSと呼ばれるC言語バインディングするモジュールもたくさんあるからです。

アプリケーションを書く場合だけを考えた、ユーザーランドであれば、テキストのソースコードだけを意識すればよいので、これは、素直にgitで配置すればよいでしょう。

Dockerコンテナ化で問題となるのは、CPANモジュールのインストールです。Dockerコンテナを、立ち上げる場合は、CPANモジュールのインストールに時間がかかることと、容量が2倍になることが、課題です。

これを解決する方法は、環境構築用サーバーをDockerコンテナを使って準備して、そこにCPANモジュールをインストールして、その環境を、アプリケーション用のDockerコンテナと同期させることです。


環境構築用Dockerコンテナ(一度だけ作る)

(同期)

アプリケーション用Dockerコンテナ(たくさん作る)

OSの種類と、Perlのマイナーバージョンまで、完全に一致していれば、バイナリ互換性と、モジュールの読み込みパスの同一性が保証されます。

CentOS 7の場合は、以下のようなモジュールの読み込みパスになっています。


/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

コマンドのインストールパスは以下でしょうか。


/usr/local/bin

コマンドとライブラリが存在すれば、動作は大丈夫なはずではあります。

同期は、rsyncかgitで行う

同期は、rsyncかgitが使えるかと思います。

rsyncでやる場合は、グローバルIPとアクセス権限について考える必要はありますが、環境構築サーバーと、アプリケーションサーバーで完結できそうです。

gitでやる場合は、環境構築サーバーが、Gitリポジトリに強制pushして、それを、アプリケーションサーバーが、cloneする方法が考えられます。

どちらにしろ、ここは、仕組み化されてはいないので、ひと手間かかるところではありそうです。

単一サーバーから、コンテナ化の流れは、段階的にできそうではある

小さいアプリケーションは、plenvやperlbrewを使って、作って、アクセスがやばくなってきた段階で、コンテナ化という流れは、直感では、ものすごく難しいという感じはしないです。


追記

NFSで、CPANでインストールしたモジュールを、参照するという方法も、思いついた。これは、作業でいうと楽かもしれない。

全部、いっぺんに、変わっちゃうという怖さはあるけど。


追記2

Perlには、Perl5LIBという環境変数があって、ここからモジュールを読み込める。

となると、クリーンなシステムPerlを準備して、cpanmの-Lオプションを使って、特定のディレクトリにモジュールをインストールできる。

これを、rsyncで同期すれば、さらに簡単にできそう。

コマンドについては、PATH環境変数に追加しよう。