2016/06/30おめでとう!あなたはDockerイメージの作り方を知っていて、わかりやすいアプリケーションで複数のコンテナを作成することができる。できることなら、あなたが継続的デリバリのパイプラインをすでに作っていて、新規作成したイメージを本番環境やテスト環境に押し込む方法を知っているといいのだけれど。Dockerコンテナを、どうやってテストするのだろうか?僕たちが取れるテスト戦略はいくつかある。この記事では、それらのメリットとデメリットをそれぞれ紹介したいと思う。「簡単な」方法これは、一般の人向けのデフォルトのやり方だ。これは、作業をするCIサーバに依存する。使った方法よりも良い選択肢であるDockerをパッケージマネジャとして使っている。CIサーバはアプリケーションコードをコンパイルし、テスト(単体、サービス、機能、その他)を実行する。buildで再利用され、新規イメージが作られる。これは、中心的なデプロイ成果物となる。作られたイメージには、アプリケーションの「バイナリ」だけでなく、あらゆる依存関係やアプリケーション設定などの必須ランタイムも含まれている。アプリケーションの移植性を得られるようになった反面、開発やテストの移植性は失われつつある。僕たちは、CIの外部で全く同じ開発環境やテスト環境を再現することができない。新しいテスト環境を作るには、テストツール(正しいバージョンとプラグイン)をセットアップし、ランタイムやOSの設定を行い、同じバージョンのテストスクリプトと、恐らくテストデータを用意する必要がある。した問題を解決することで、次に進むことができる。アプリケーション&テストコンテナを使った方法ここで、必要なパッケージ、テストツール(特定のバージョン)、テストツールプラグイン、テストスクリプト、テスト環境など全ての必須パッケージを含む、アプリケーションの「バイナリ」を一つにまとめたものを作ってみる。この方法のメリット:CI、開発、ステージング、本番環境において、再現性のあるテスト環境を持てる(同じテストツールを使って全く同じテストを実行できる)ある特定の時点でテストスクリプトをキャプチャするため、どのような環境でも常にそれらを再現することができるテストツールのセットアップや設定をする必要がない(これらはイメージの一部であるため)この方法には重大な欠点がある:イメージのサイズが大きくなる(テストツール、必須パッケージ、テストスクリプト、そして恐らくテストデータをも含むため)特定の設定テストでイメージのランタイム環境を汚染し、不必要な依存関係をもたらすことすらある(結合テストに必要とされる)テスト結果とログをどうするか(どこにどうやってエクスポートするかなど)も決めなければならない次の簡略化した[Dockerfile]が、この方法を説明している。""]Dockerfileコンテナ内テストにはもっと良い方法が必要だし、実際ある。イメージを作成し、いくつかのレジストリに送り、どこでも実行する。僕のつたない意見だが、これには重大な欠落したステップがある。