コンテナプラットフォームにおけるコンテナ作成ガイドライン

OpenShiftのドキュメントから、面白そうな部分を翻訳、解説するシリーズをやってみたいと思います。

初回は、コンテナプラットフォームにおけるRed Hat的なコンテナの作り方ガイドラインです。
https://docs.openshift.com/container-platform/3.7/creating_images/guidelines.html

概要

OpenShiftで実行するコンテナイメージを作る際、コンテナを気持ちよく使ってもらうためにはいくつかのベストプラクティスがあります。

コンテナイメージは、変更せずそのまま使うことが前提となっているため、次のガイドラインに従うことでイメージが使いやすくなり、OpenShift上で使うのも簡単になります。

OpenShiftで動作させることを前提にしたドキュメントですが、内容の大半は生のKubernetesでコンテナを動かすときにも参考になるものです。

一般的なコンテナイメージのガイドライン

次のガイドラインは、コンテナイメージを作成する際、OpenShiftで実行するか否かに関わらず当てはまる一般的なガイドラインです。

イメージの再利用

FROM命令で適切な上流イメージを使いましょう。
上流のイメージが更新され、セキュリティ周りの修正が入った時に、簡単にその修正を自分のイメージに取り込むことができます。
上流イメージが適切なものでないと、依存関係も含めた必要なセキュリティ更新を自分でやらなければならなくなります。

ちゃんとメンテされ、セキュリティパッチも随時適用されている公式サポートのイメージをベースイメージ使いましょうということですね。
そうしておけば、FROMでそのセキュリティパッチを随時取り込むことができるので。

さらに、FROM命令で使用するタグは(例: rhel:rhel7)、どのバージョンのベースイメージを使用しているのか、イメージを利用するユーザーに正確に伝わるものにするべきです。
latestタグをベースにしなければ、作成したイメージがベースイメージの破壊的変更にさらされる心配はありません。

ベースイメージにruby:latestみたいなタグを使ってるとある日突然、rubyが2.4から2.5になったりするので、互換性のある適切な粒度のタグのベースを使ったほうがいいですね。

タグで互換性を管理する

コンテナイメージにタグを付けるときは、タグ間で下位互換性を維持することをお勧めします。
例えば、fooという名前のイメージを公開する場合、それが「バージョン1.0」を含むものであればfoo:v1のタグをつけることが多いです。
このイメージを更新する時は、更新前のイメージと互換性があるかぎり、新しいイメージをfoo:v1でタグづけできます。そうすれば、このイメージを使用する人は、何かを壊すことなくアップデートを受け取ることができます。

後で互換性のないアップデートをリリースした場合は、新しいタグ（foo：v2とか）をつけることになります。
イメージの使用者は、好きなタイミングで新しいバージョンに移行することができますが、知らないうちに互換性のないイメージが適用されて壊れてしまうことはありません。
foo:latestを参照している人は、互換性のない変更が導入される危険を冒しているということです。

rubyを例にすれば、TEENYレベルの更新は(互換性が保たれているはずなので)随時適用したいと、社内のポリシーによっては思うかもしれません。
その場合は、ベースイメージにruby:2.4を使えば、ビルドしなおすことでrubyの更新を受け取ることができます。
rubyの公式イメージはタグ間で互換性が考慮されているので、そのような運用も可能です。
自分でイメージをタグ付けするときもそういう、セマンティックなタグ付けを行いましょうということですね。

ラッパースクリプトでは常にexecを使う

これについては、詳しくはProject Atomicのラッパースクリプトで常にexecを使うを参照してください。

また、コンテナ内では、プロセスはPID 1で実行されることにも注意が必要です。
つまり、メインプロセスを終了すれば、すべての子プロセスもkillされてコンテナ全体が停止してしまうということです。
この問題について掘り下げるなら、Blog記事DockerとPID 1のゾンビプロセス刈り取り問題を、またPID 1とinitについて詳しく知るためにinit(PID 1)を解読するを参照してください。

DockerfileのCMD命令で、パラメーターなどの設定を行うためにbashのラッパースクリプトを書いて、その中から実際に起動したいアプリケーションを呼び出すことがよくあります。
そのとき、呼び出しにexecを使ってプロセスのジョブを置き換えるようにしようというプラクティスです。
普通に呼び出した場合、メインプロセス(PID 1)がスクリプトになってしまい、コンテナランタイムが送るシグナルがラッパーの方に送られるため期待しない動作をします。

一時ファイルをクリアする

ビルドプロセスの中で作成した一時ファイルはすべて削除するべきです。これには、ADD命令で追加したファイルも含まれます。

ADD命令で追加したファイルはレイヤーに残るので削除してもイメージのサイズは減らないと思いますが、余計なファイルが入っていると混乱の元、くらいの意味かもしれません。

例えば、yum cleanをyum installの後に実行することを強く推奨しています。

yumのキャッシュを最終的なイメージレイヤーに残さないよう、以下のようにRUN命令を使用します。

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

一方、以下の場合はどうでしょうか。

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

最初のyumの実行が余計なファイルをレイヤーに残しますが、これらのファイルは後続のyum cleanでは削除されません。
この余計なファイルは、最終的なイメージでは存在しないように見えますが、レイヤーには残っています。

現在のDockerのビルドプロセスでは、何かのコマンドを実行して、前段のレイヤーで作成されたものを削除したとしても、イメージが使用するスペースが縮小されることはありません(将来的には改善されるかもしれませんが)。
つまり、あるレイヤーでrmコマンドを実行しても、ファイルが隠されるだけで実際にダウンロードされるイメージのサイズは変わりません。
したがって、yum cleanの例のように、余計なファイルは、それを作成したコマンドで同時に削除してしまうべきです。そうすれば、それらのファイルがレイヤーに書き込まれることはありません。

さらに、複数のコマンドを同じRUN命令で実行すれば、レイヤーの数が減り、イメージをダウンロードする時間や展開する時間を削減できます。

Dockerのイメージを小さくする一般的なプラクティスです。以下などが参考になります。
http://docs.docker.jp/engine/articles/dockerfile_best-practice.html#run

新しいDockerであれば、マルチステージビルドもあります。
https://qiita.com/minamijoyo/items/711704e85b45ff5d6405

Docker命令を正しい順番で並べる

Dockerは、Dockerfileを読み込み、上から順に命令を実行していきます。
すべての命令は、正常に終了するとレイヤーを作成し、次回ビルドする際、また別の派生イメージがビルドされる際に再利用されます。
重要なのは、変更が少ない命令をDockerfileの上の方に配置することです。
そうすれば、同じイメージを非常に早くビルドできるようになります。
上のレイヤーが変更されてキャッシュが無効化されることがないからです。

例えば、頻繁に変更されるファイルを追加するADD命令とパッケージをインストールするRUN命令がある場合、ADDをDockerfileの最後に持ってくるべきです。

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

こうしておけば、myfileを変更してdocker buildを再実行する際、yum実行部分ではキャッシュされたレイヤーが使用されるので、ADD命令の部分のレイヤーを作成するだけで済みます。
もし、以下のように書いたら、

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

docker buildの際にmyfileが変更されていると、RUN実行されたレイヤーのキャッシュが無効化されるので、yum実行まで行われることになります。

RubyのGemfile、Gemfile.lockの例が有名ですね。
RubyのプロジェクトをDockerに転送してからビルドすると、Gemfileでない他のファイルを変更したときもbundle installが実行されてしまいます。
そこで、Gemfile、Gemfile.lockを転送してbundle installをしてから、他のファイルをCOPYすることで、bundle installでキャッシュが無効化されないようにしよう、というプラクティスがあります。

重要なポートをマークする

詳細は、Project Atomicの重要なポートを常にEXPOSEするを参照してください。

以下、重要なポートを常にEXPOSEするからの引用です。

EXPOSE命令は、コンテナ内のポートを、ホストで、また別のコンテナで使用できるようにします。
docker run実行時にポートを公開するよう指定することもできますが、それでもEXPOSE命令をDockerfileで使用すれば、人間にとってもソフトウェアにとってもDockerイメージが使いやすくなります。
実行に必要なポートを明示的に宣言すれば、

• docker psでコンテナに関連したポートが表示されます。
• docker inspectで確認できるDockerイメージのメタデータにポートが表示されます。
• コンテナ同士をリンクする際、EXPOSEしたポートが使用されます。

コンテナが使用しているポートは、ローカルでもプラットフォーム上でも実行時にバインドできるので無くても動くわけですが、
EXPOSEでマークすることでドキュメンテーション的に、また調査時に色々と役に立ちます。

環境変数を設定する

ENV命令で環境変数を設定するのはよい習慣です。
例えば、自分のプロジェクトのバージョンを環境変数にセットすると、Dockefileを見ることなく簡単にプロジェクトのバージョンを確認できるようになります。

コンテナに入って、printenv などで情報が取れる、ということかな。。。

もしくは、JAVA_HOMEのような、システム上のパスを他のプロセスのために広告するという使い方も考えられます。

デフォルトのパスワードを避ける

パスワードにデフォルト値を設定するのは避けてください。
イメージを継承して使う人の多くはデフォルトのパスワードを削除したり変更したりするのを忘れます。
よく知られたパスワードをセットしたまま本番環境でイメージを使ったりすればセキュリティの問題に繋がります。
パスワードは、環境変数で設定できるようにしましょう。
設定のために環境変数を使うを参照してください。
もしパスワードにデフォルト値を設定するのでしたら、イメージを起動するときに適切な警告メッセージを表示されるようにします。
このメッセージで、デフォルトパスワードの値や変更方法(どの環境変数を使うかなど)をユーザーに知らせます。

SSHDを避ける

SSHDをイメージの中で走らせる必要はありません。ローカルホストで実行されているコンテナには、docker execコマンドでアクセスできます。
OpenShift上では、代わりにoc execコマンドまたはoc rshコマンドを使うことができます。
イメージにSSHDをインストールして実行すると、攻撃される要素も必要なセキュリティパッチも増えます。

永続データにはボリュームを使う

コンテナイメージは永続データのためにDockerのボリュームを使うべきです。
OpenShiftでは、ネットワークストレージがコンテナが実行されているノードにマウントされます。コンテナが別のノードに移動すれば、移動先のノードにマウントされなおします。
永続ストレージが必要なところ全部にボリュームを使用すれば、コンテナが再起動されたり移動されたりした場合でも内容が保持されます。一方、コンテナ内の適当なところにデータを書き込むイメージは、そのデータを失ってしまう可能性があります。

コンテナが破棄されたあとも残しておきたいデータは、必ずボリュームに書き込まなければなりません。
Dockerの1.5では、ReadOnlyコンテナが導入されました。これにより、揮発性のコンテナ内ストレージにデータを書き込まないというプラクティスを厳格に強制できます。
この機能を考慮してコンテナイメージをデザインすれば、より活用しやすいイメージになります。

さらに、Dockerfileで明示的に必要なボリュームを定義しておくことで、イメージを利用する人が実行時にどんなボリュームが必要なのか分かりやすくなります。
OpenShiftでどのようにボリュームが使われるのかについては、詳しくはKubernetesのドキュメントを参照してください。

外部のガイドライン

次のガイドラインも参考にしてください。

• Docker documentation - Dockerfileのベストプラクティス
• Project Atomic documentation - イメージ作成者のガイドライン

OpenShift Container Platform特有のガイドライン

以下のガイドラインは、OpenShift上で動かすイメージを作成するときに有用なものです。

ここのガイドは、Kubernetes上のコンテナに対しても有用なものが多いです。

イメージをSource-To-Image(S2I)で使えるようにする

サードパーティが作成したコードを動かすためのイメージ、例えば開発者のコードを動かすよう設計されたRubyのイメージなどは、Source-to-Image(S2I)で使うことができます。
S2Iは、イメージを簡単に作成するためのフレームワークです。
アプリケーションのソースコードを受け取って、そのコードを動かすイメージを生成します。
例えば、このPythonのイメージでは、様々なバージョンのPythonアプリケーションをビルドするs2iスクリプトを定義しています。
詳細については、S2Iの要件を参照してください。

s2iについては、
http://nekop.hatenablog.com/entry/2015/12/18/114610
https://qiita.com/nak3/items/6407c01cc2d1f153c0f1
が分かりやすいです。

OpenShiftでは、レジストリにあるDockerイメージを動かすだけでなく、Dockerイメージ自体をビルドして動かすこともできます。
OpenShiftでイメージをビルドする戦略の一つがSourceで、アプリーションのソースコードをOpenShiftに渡してやるとDockerイメージをビルドして動かしてくれます。
既存のPaaSと同様の体験を提供する機能というわけですね。

この機能で使われているのがs2iです。ソースコードからDockerイメージをビルドするものです。
簡単にいうと、ベースのイメージからコンテナを起動して、そのコンテナにソースコードをtarでコピーし、docker commitでコンテナからアプリケーションのイメージを構築します。

その際、

上記のようなスクリプトをベースのDockerイメージに置いておけば、docker commitの前などにbundle installやnpm installなど追加的なコマンドを実行できます。
このプラクティスは、s2iをOpenShiftで活用する場合、コンテナイメージにこういったスクリプトを用意するなど、s2iで使いやすいイメージにするのがよい、というもののようです。
(ただし、s2iのスクリプトは、OpenShift上で実際にイメージをビルドする際に別途URLで指定することもできるので、スクリプトが同梱されたイメージでないとs2iで使えないというわけではありません。)

任意のUser IDをサポートする

デフォルトでは、OpenShiftはコンテナに適当なユーザーIDを割り当てて動かします。
これはセキュリティ対策の一環で、コンテナエンジンの脆弱性によりプロセスがコンテナの外に漏れ、そのままホストノードのユーザー権限で動作することを防いでいます。

OpenShiftでは、DockerfileのUSER宣言は無視されて、コンテナ実行時にランダムなユーザーIDが割り当てられます。
DockerfileにUSERがない場合、ローカルだとrootでコンテナが起動しますが、OpenShift上だと以下のようなよく分からない一般ユーザーになっています。

$ id                                                                                                                                                     
uid=1000050000 gid=0(root) groups=0(root),1000050000

コンテナプラットフォームではいろんな人がいろんなイメージを動かすので、よく知らないイメージがrootで動いていると怖いですからね。
なので、以下に記載が続きますが、rootで動く前提のイメージや、特定のUIDを前提にしたイメージはうまく動作しません。

イメージをランダムなユーザーIDで動くようにするには、プロセスによって読み書きされるファイルやディレクトリを、rootグループに所有させるようにします。実行ファイルの場合は、実行権限も付与します。

Dockerfileに以下のような行を追加することで、ビルドされるイメージのディレクトリとファイルをrootグループでアクセスできるようになります。

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

OpenShiftがコンテナに割り当てるランダムユーザーは、常にrootグループに所属しているので、こうすることでファイルを読み書きできるようになります。
rootグループは、(rootユーザーと違って)何か特別な権限を持っているわけではないので、この対策でセキュリティの問題が起こることはありません。
さらに、コンテナ内のプロセスは特権ポート(1024以下)を使わないようにしなければなりません。コンテナを実行するのが特権ユーザーではないからです。
コンテナのユーザーIDは動的に生成されるので、/etc/passwdに関連するエントリを持ちません。
これは、ユーザーのIDを参照できることを期待するアプリケーションで問題になります。
この問題に対処する一つの方法は、コンテナが開始スクリプトで、passwdファイルのエントリを動的に作成することです。

RUN chmod g=u /etc/passwd
ENTRYPOINT [ "uid_entrypoint" ]
USER 1001

if ! whoami &> /dev/null; then
  if [ -w /etc/passwd ]; then
    echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
  fi
fi

完全な例は、このDockerfileを参照してください。

この末尾にあるUSER宣言は、ユーザー名ではなく、ユーザーID(数字)を指定してください。
これにより、OpenShiftがこのコンテナイメージが要求する権限を検証し、rootで動こうとするイメージを防ぐことができます。
コンテナを特権ユーザーで実行すると潜在的なセキュリティホールに晒されます。
USERを指定していないイメージは、USERを親イメージから継承します。

OpenShiftによってランダムに割り当てられたUIDは、/etc/passwdに登録されていないので、紐つくユーザー名がなく例えば以下のようなコマンドは失敗します。

$ whoami
whoami: cannot find name for user ID 1000030000

これが問題になるときは、コンテナ起動時に動的に/etc/passwdにエントリを追加しましょう。

! 注意
s2iのイメージが数値のユーザーIDでUSER命令を使用していない場合、デフォルトではビルドに失敗します。
イメージを名前付きユーザーまたはroot(0)でビルドできるようにするには、プロジェクトのbuilderサービスアカウント(system:serviceaccount::builder)にprivilegedのsccを追加しなければなりません。
または、すべてのイメージをあらゆるユーザーIDで実行できるようにすることもできます。

イメージ間の通信にServiceを使う

WebフロントのコンテナとDBのコンテナのように、コンテナ間で通信する必要がある場合、OpenShiftのServiceを使うようにするべきです。
Serviceは、コンテナが停止したり起動したり、移動したりしたときも変わらない静的なエンドポイントを提供します。
また、Serviceはリクエストをロードバランスするので、コンテナインスタンスに対する負荷分散にもなります。

これは、Kubernetesで動かす場合にも当てはまる一般的なプラクティスです。ここでいうOpenShiftのServiceは、KubernetesのServiceとイコールです。
コンテナプラットフォームは、状況に応じてコンテナを再起動したり増やしたり移動したりするので、コンテナ自体のIPアドレスは不定です。
なので、コンテナ間の通信は直でコンテナに向けるのではなく、コンテナの前にいるServiceというロードバランサーを利用します。

共通ライブラリを提供する

開発者のアプリケーションを実行するためにコンテナイメージを用意する場合、プラットフォームで共通的に使われるライブラリはイメージに含めるようにします。
特に、構築したプラットフォームで一般的に使われるであろうデータベースのデータベースドライバーを含めてください。
例えば、Javaフレームワークを使ったアプリケーション向けのコンテナイメージを作成する場合、イメージにMySQLとPostgreSQLのJDBCドライバーを入れてビルドします。
そうすれば、開発者のアプリケーションがビルドされるたびに共通的な依存関係がダウンロードされることがなくなり、ビルド時間が短くなります。
さらに、開発者がアプリケーションに必要な依存関係がすべて含まれているかどうか確認する作業が簡単になります。

最後のフレーズがよく分からないですが、おそらく、ベースイメージに共通ライブラリが含まれていれば、それを使うそれぞれの開発者がいちいちそのライブラリを入れようと頑張る必要がなくなる、という感じでしょうか。

設定のために環境変数を使う

このあたりも、OpenShiftだけでなく、Kubernetesでコンテナイメージを使う時に有用なプラクティスです。

作ったイメージを使ってもらうとき、そのイメージに必要な設定を行うために新たな子イメージを作らなければならない、というのは避けたいものです。
つまり、コンテナの実行に必要な設定は、環境変数を使って行えるようにするべきです。
単純な例で言えば、コンテナのプロセスが環境変数を直接参照すればよいだけです。
複雑な設定を行う必要がある場合や、環境変数を直接使えないプロセスの場合はどうでしょうか。
この場合、設定ファイルのテンプレートを用意し、これをコンテナの起動時に処理して使用することができます。
例えば、コンテナ起動時に設定ファイルテンプレート内のパラメーターを環境変数の値に置き換えたり、環境変数の値を見て、設定ファイル内のどのオプションを設定するか判断する、といった方法が考えられます。

また、証明書と鍵のような秘匿情報に関しても、環境変数でコンテナに渡す方法を推奨します。
こうすれば、秘匿情報がイメージに焼きこまれることも、うっかりDockerレジストリにアップされることもありません。

設定用の環境変数を用意すれば、イメージの使用者は、新しいレイヤーを重ねることなくコンテナの動作をカスタマイズできます。
例でいうと、DBの設定やパスワード、パフォーマンスチューニングなどです。
podを定義するときも、イメージを再ビルドすることなく環境変数を定義して設定を変更できます。

さらに複雑なシナリオもあります。コンテナの設定を、コンテナにマウントしたボリュームで提供するのです。
しかし、この場合、必要なボリュームや設定がないときに分かりやすいエラーメッセージをコンテナ開始時に提供するようにしなければなりません。

このトピックは、コンテナ間通信のときにServiceを使うトピックと関連しています。
データソースのような設定は、Serviceのエンドポイントに関する情報を含めた環境変数で定義するべきです。
これで、アプリケーションはデータソースのエンドポイントを動的に設定できるようになり、OpenShift環境に定義されたデータソースのServiceもアプリケーションを変更することなく利用できます。

さらに、コンテナのチューニングは、適用されているcgroups設定を検出して行われるようにするべきです。
そうすれば、コンテナイメージは、使用するメモリ使用量やCPU、その他リソースを自分自身でチューニングできるようになります。
例えば、Javaのイメージでは、使用するヒープの量を、cgroupの最大メモリ量パラメーターを検出して、それをベースにチューニングされるようにします。そうすることで、コンテナのプロセスがメモリの制限値を超えてOut-of-memoryエラーになるのを防ぐことができます。

どのようにDockerでcgroupのクォータ管理するかについての詳細は、以下の情報を参照してください。

ブログ記事: Dockerでのリソース管理
Dockerのドキュメント: 実行時のメトリクス
ブログ記事: Linuxコンテナ内のメモリ

イメージのメタデータを設定する

イメージのメタデータを定義すれば、OpenShiftがコンテナをよりよく使えるようになり、ひいては開発者がOpenShift上で気持ちよくコンテナを使えるようになります。
例えば、イメージに有用な説明を加えたり、必要に応じて他のコンテナイメージを提案したりすることができます。
サポートされるメタデータやその定義方法について、詳しくはイメージメタデータを参照してください。

例えば、Dockerfileに、

LABEL io.openshift.non-scalable     true

のようにLABEL命令でLABELをつけておくと、OpenShift上でそのイメージを使った時に何らかのサジェストがUI上、コマンド上で表示されるとのことですが、現在のところ、OpenShiftのUIに反映されたりはしないようです。

クラスタリング

「あるイメージのインスタンスを複数動かす」というのが何を意味しているのか、完全に理解しておく必要があります。
もっとも単純なケースでは、Serviceのロードバランス機能がトラフィックをすべてのインスタンスにルーティングしてくれます。
しかし、例えばセッションレプリケーションなどだとどうでしょうか。
リーダー選出やフェイルオーバーのために、インスタンス間で情報を共有しなければならないフレームワークも多くあります。

OpenShiftでインスタンスを立ち上げた時、この情報共有がどのようになされるかを考慮しておく必要があります。
podはお互いに直接通信することもできますが、podのIPアドレスはpodが開始された時、停止した時、移動した時、いつでも変更される可能性があります。
従って、クラスタリングの手法が動的なものであることが重要です。

ロギング

もっともいいのは、すべてのログを標準出力に出すことです。
OpenShiftは、コンテナの標準出力を集め、中央のロギングサービスに送り、閲覧できるようにします。
ログのコンテキストを分ける必要があるなら、ログ出力に必要に応じてプレフィックスをつけ、ログメッセージをフィルタリングできるようにします。

タグを複数のファイルに出しているような場合、標準出力にまとめるときはプレフィックスをつけるとフィルタリングが簡単になりますね。
例えば、Railsであれば、TaggedLoggingといった実装もあるようです。

一方、ログイメージがファイルに出力されている場合、コンテナのユーザーは自分でコンテナに入って、ログファイルを探し、閲覧しなければなりません。

ログファイルがファイルに出力される仕様のアプリケーションの場合、サイドカーパターンでログを回収して標準出力に出しましょう

Liveness Probe、Readiness Probe

作成したイメージで使えるLiveness ProbeとReadiness Probeの例をドキュメント化してください。
これらのProbeを使うと、イメージをデプロイする際、準備ができるまでトラフィックがルーティングされないようにしたり、コンテナがおかしくなった時に再起動されるようにしたりできます。

テンプレート

作成したイメージについて、テンプレートのサンプルを提供することを考慮してください。
テンプレートのサンプルがあれば、ユーザーは正しい設定で簡単にイメージをデプロイできます。
そのテンプレートに、ドキュメント化したLiveness ProbeやReadiness Probeを含めれば完璧です。

参考情報

Dockerの基本

Dockerfileリファレンス

[コンテナイメージ作成者のためのProject Atomicガイダンス](Project Atomic Guidance for Container Image Authors)