「テスト・フレンドリー」なDockerfileの構文とDockerコマンドの拡張を見てみよう。この大切なステップは、ネイティブにサポートされている場合もある。これは実際の構文ではないが、ちょっと我慢して見ていて欲しい。これから「理想的な」バージョンを定義し、それに非常に近いものを実装する方法をお見せしよう。[INSTRUCTION]既存の[ONBUILD]命令に似た、特別な[ONTEST]命令を定義しよう。[ONTEST]命令は、後にイメージがテストされる時、実行されるトリガー命令をイメージに追加する。build命令はどれもトリガーとして登録される。test]コマンドに認識されるはずだ。‐testタグ(「test」という語が元のイメージタグに追加される)でタグ付けされることだ。ENTRYPOINT)を実行する。test]コマンドは、何らかのテストが失敗すると、0以外のコードを返す。テスト結果は、/var/tests/resultsフォルダを指す、自動生成されたVOLUMEに書きこまれるはずだ。下の修正したDockerfileを見てみよう。提案された新規ONTEST命令を含んでいる。""]Dockerfile「テストアウェアコンテナ」の実現Dockerは、[docker-test]をコンテナ管理のライフサイクルの一部にするべきだと僕らは考えている。現在は簡単な作業ソリューションを持つ必要があり、これから理想的な状態に非常に近いものを紹介しようと思う。前述したとおり、Dockerには非常に便利な[ONBUILD]命令がある。この命令は、後に続くbuildに、もう一つのbuild命令をトリガーできる。基本的な考え方は、[docker-test]実行時に[ONBUILD]命令を使うことだ。[ARG...]]を実行するDockerfile.testファイルを消すなぜONBUIOLD命令なしで新規Dockerfile.testを作成しないのか?なぜなら、正しいイメージ(そしてタグ)をテストするためには、image:tagにFROMを常に更新している必要があるからだ。これは簡単なことではない。前述のやり方には限界がある。Maven:onbuildのように、[onbuild]のイメージには適さないのだ(アプリを自動でbuildするのに使用されるイメージ)[docker-test]コマンドの簡単な実装を見てみよう。ここでは概念に焦点を当てている。[docker-test]コマンドはbuildとrunコマンドオプションを処理し、エラーを適切に処理できるべきだ。Dockerfile.test一番面白い該当箇所に焦点を当ててみよう。結合テストコンテナ何十、何百のマイクロサービスから作られたアプリケーションがあるとしよう。各マイクロサービスが作られた場所に自動化されたCI/CDパイプラインがあり、CIによってテストされ、作成とテストが終わった後、何らかの環境(テスト、ステージングまたは本番)にデプロイされるとする。すごいでしょう?僕たちのCIテストは、単体テスト、サービステスト(またはAPIコントラクトテスト)を実行し、各マイクロサービスを単独でテストできる。compose]ヘルプを使って)。これにより、対処すべき課題が生じる。monkey」などを使ったテスト)はどうなるのか?セキュリティスキャンは?時間のかかるテストやスキャンアクティビティはどうなるのか?そして、完全に運用システム上で実行されるべきなのか?ただ単に新規マイクロサービスバージョンを本番に放り込んでみっちりモニターするのではなく、もっと良い方法があってもいい。特別な結合テストコンテナがあってもいい。これらのコンテナは、テストツールとテスト成果物(つまりテストスクリプト、テストデータ、テスト環境設定など)のみを含んでいる。このようなコンテナのオーケストレーションや自動化を単純化するには、いくつかの約束事を定義してそれに従い、メタデータラベル(DockerfileのLABEL命令)を使わなければならない。[chaos]または何らかの文字のうちの一つである場合が多い。このラベルにより、これが「結合テストコンテナ」であると宣言している。メタデータに関するその他のテスト;ラベル名にはtest.という接頭辞を使うだけでいい結合テストコンテナ結合テストコンテナは、ただの普通のDockerコンテナだ。アプリケーションロジックやコードは特に含まれていない。その唯一の目的は、再現性があってポータブルなテストを作成することだ。...)テストスタートアップスクリプト:テストを実行するための「主要な」スタートアップスクリプト[test.sh]を作り、そこからテストツールを立ち上げればよい。結合テストコンテナは、全てのマイクロサービスがデプロイされる運用環境(テスト、ステージング、本番環境)で実行するべきだ。これらのコンテナはその他全てのサービスとまさに同じようにデプロイされることがある。これらは同じネットワーク層をつかっているため、選択されたサービス発見方法(通常はDNS)を使って、複数のサービスにアクセスすることがある。複数のサービスにアクセスするには、実際の結合テストが必要になる。システムが複数の場所でどう動くかシミュレートし、確認する必要がある。結合テストをアプリケーションサービス内部に留めるのは、コンテナのフットプリントを増やすだけでなく、複数のサービス間に不要な依存関係を作ることになる。僕たちはこれら依存関係を、すべて結合テストコンテナのレベルに留めておく。テスト(またはテストツール)が一度コンテナ内にパッケージ化されれば、いつでも同じテストを、開発機を含むどのような環境においても再実行できる。あなたはいつでも、時間をさかのぼって結合テストコンテナの特定のバージョンを再実行できるというわけだ。あなたはどう思うだろうか?特に[docker-test]コマンド標準化に関するフィードバックをもらえると非常にありがたい。原文:http://blog.terranillius.com/post/docker_testing/(2016-6-29)※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。-TechTweet関連記事パフォーマンスの悪さがeコマースの売上に与える影響とは休暇期間になると、ECサイトが遅いせいでショッピングカートの18%が破棄されるという。情報収集やブラウザチェック、ルーティーンワークCrystalの紹介:Cのように速く、Rubyのように滑らか僕は、Rubyistだ。Rubyと、そのコミュニティ、その生産性など、Rubyにまつわる多くのものがフルスタックエンジニアを目指すには。はてブ数ランキングまとめ皆さん、2014年も残す所1週間を切りましたが、いかがお過ごしでしょうか。102レベルを意図して書かれている。1秒間あたり3,000枚の画像(約200GB)を作成し持続している。PREVフリーランスはつらいよ。