この記事はCameron Lairdによるゲスト投稿です。

実際にデプロイされるのとは異なるDockerイメージをテストする理由はあるのでしょうか? 教科書的には、本番でも品質保証でもコンテナーは同じです。現実では、この同一性を少しばかりゆるめる理由は多数あります。

テスト環境と本番環境で異なるコンテナーをデプロイするのが妥当であるケースをいくつかとりあげ、どうすればうまくいくのかを検討します。

汝自身を知れ

まず、自身の状況を明確に把握します。ソフトウェアでは、柔軟性と変化がすべてであり、Dockerはそういった性質を極限まで体現しています。

Dockerのベストプラクティスのリストは広く公開されています。しかし、エンジニアリングとはトレードオフを判断することであり、表面的な要件のうち、ゆるめる価値があるものを知るには、私たちが直面するコストと機会について敏感である必要があります。

よくあるシナリオの1つは、テストと本番でシステム的に異なるコンテナーを構築することを選択した場合です。

• テスト用コンテナーには、本番では必要がないテストツールが含まれている。
• 本番用コンテナーには、品質保証では必要がない監視および解析アドオンが含まれている。
• コンテナーの任意の組み合わせが独自のフェールセーフ機構の中で構築されており、実行はもちろん、アクセスも専用の環境で行う必要がある。
• 本番用コンテナーは、テスト用コンテナーにはない特別なセキュリティ機能の上に重ねられる。

このような違いがありうると聞いて、驚いたり、疑問を感じたりしたでしょうか? 私たちテスターは、テスト対象の成果物は顧客に利用されるものと可能なかぎり同じでなければならないと繰り返し教えられています。ところが、この掟をゆるめるべき理由がいくつもあるのです。おそらく、「本番そのまま」より「本番についてできるだけ多くの知識が得られる」のほうがよい目標でしょう。信頼のおける透明性の高いプロセスによってテスト用コンテナーと本番用コンテナーの両方が生成されるのであれば、テスト用コンテナーで発生した事象は、本番用コンテナーについて適切な情報を与えてくれるのではないでしょうか。

違いはテストに役立つことさえあります。おそらく、本番環境と品質保証環境のリソースは異なるでしょう―たとえば、コンテナーエンジンが利用できるメインメモリなどです。こうした現実を認めてテスト計画に織り込むほうが、違いを無視して、本番用環境でも品質保証用環境でも、メモリの枯渇は同様に表れるはずだという誤った仮定をするよりよいでしょう。

制約を検討する

本番環境とテスト環境を同一にしたいと望んでいても、もっともな理由によって、そうしないと判断する場合もあるでしょう。ライセンスの制約によって、特定のデータベースや解析レポーターをテストで使用するのはコストが高いかもしれません。テスト用コンテナーと本番用コンテナーの違いは問題の診断を難しくするでしょうが、その困難はコンテナーを完璧に同一にする費用に比べれば小さい問題かもしれません。

ある種のセキュリティ技術もライセンス方針に対して同様の影響を与えます。テストでは変更を加えたコンテナーを実行するほうが、テストに複雑なセキュリティ制約を課すよりコストが低い場合もあるでしょう。コンテナーを利用する上での基本のアプローチは、不変のコンテナーを使用し、差分がある場合は環境から取得するというものです。どうしてもこのアプローチに適合しない一部のライセンスされたテクノロジーについては、明示的な例外を設けて、わずかに異なるコンテナーをビルドするプロセスを自動化し、明確に定義された結果を適切にテストするのが最善の方法でしょう。

パフォーマンスやセキュリティも違いの原因になります。コンテナーを小さくするために、意図的に本番用コンテナーにテストツールを入れない場合もあるでしょう。これによって必要なディスク容量が少なくなるだけでなく、攻撃面も小さくなります。ライセンスの要件が同様の方針につながるケースもあります。特定のテクノロジーが品質保証用にライセンスされているが、本番環境では存在すらも望ましくない場合があります。

類似のケースは、本番環境に特定用途のコンテナーが複数ある場合にも発生します。通常は、セキュリティ、パフォーマンス、コンプライアンス上の理由が組み合わさって、そのような状況が生まれます。制約のある品質保証用の実行環境でそういった差異を管理するのは、メリットよりは問題が多い可能性があります。複数のコンテナーを集約的にテストしやすい1つのコンテナーにまとめるのが賢明かもしれません。

違いを文書化する

コンテナーを分岐させる必要があると判断したら、必ず以下のようにします。

• 明示的に書面で決定する
• 複数のコンテナーの構築を自動化する
• 違いの影響があった場合は文書化する

周到な計画と実行は、決定を振り返り、新しいコンテナーを作成するべき時を判断するのに役立ちます。Dockerについてもっと知りたい場合は、Dockerに関するTestRailのドキュメントを参照してください。

Cameron Lairdは、賞を授けられたソフトウェア開発者で著述家です。Cameronは、Python Software Foundationの投票権を持つほか、いくつかの業界のサポートや標準化組織に参加しています。長くTexas Gulf Coastに住み、農場自動化アプリケーションがお気に入りです。

（この記事は、開発元Gurock社の Blog 「When Should a Production Docker Container Be Different From a Tested Docker Container?」2021年10月6日の翻訳記事です。）