Docker：テスト環境

過去5年間で、開発とテスト用の分離された環境をすばやく作成できる膨大な数のテクノロジーが私たちの生活にもたらされました。 しかし、それにもかかわらず、テスト用の安定した環境を編成するのは簡単な作業ではありません。 また、コンポーネントのネットワーク相互作用をテストし、コンポーネントの最大レベルの負荷を分析する必要がある場合、タスクはさらに難しくなります。 環境を迅速に展開し、個々のコンポーネントを柔軟に構成する機能を追加することにより、小さな興味深いプロジェクトを作成できます。

この記事では、クライアントサーバーアプリケーションをテストするためのDockerコンテナーに基づく環境の作成について詳しく説明します。 さらに、グローバルに見ると、この記事はDockerの使用とその最も近いエコシステムの良い例になります。

問題の声明

私たちのアプリケーションは、あらゆる種類のログファイルを収集、分析、保存します。 環境の主なタスクは、負荷のかかったサービスの初期テストを実施することです。

だから私たちが持っているもの：

• Goで記述されたサービスは、クライアントサーバーアーキテクチャを備えています。
• サービスは、さまざまなタイプのストレージに並行してデータを書き込むことができます。 この点は、テスト環境を構築するときに非常に重要です。
• 開発者は、テスト環境で見つかった誤動作を迅速かつ簡単に再現する能力を必要としています。
• 複数のネットワークノード上の分散環境でコンポーネントのネットワークをテストする必要があります。 これを行うには、クライアントとサーバー間のトラフィックの流れを分析する必要があります。
• リソースの消費を制御し、デーモンが高負荷で安定していることを確認する必要があります。
• それで、もちろん、可能なすべてのメトリックをリアルタイムで、テスト結果に基づいて調べたいと思います。

その結果、Dockerおよび関連テクノロジーに基づいてテスト環境を構築することにしました。 これにより、個々のコンポーネントごとに個別のサーバーを購入することなく、すべてのリクエストを実現し、利用可能なハードウェアリソースを効果的に使用することができました。 同時に、ハードウェアリソースは、個別のサーバー、サーバーのセット、または開発者のラップトップである場合があります。

テスト環境のアーキテクチャ

最初に、アーキテクチャの主要コンポーネントを検討します。

• アプリケーションの任意の数のサーバーインスタンス。
• エージェントの任意の数。
• ElasticSearch、MySQL、PostgreSQLなどのデータウェアハウスを備えた個別の環境。
• 負荷ジェネレーター（単純なストレスジェネレーターを実装しましたが、Yandex.TankやApache Benchmarkなど、他のジェネレーターも使用できます）。

テスト環境は、簡単に持ち上げて保守できる必要があります。



Dockerコンテナーと外部サービスを分離するDockerコンテナーと、テスト用に分離されたスペースを整理できるdocker-machineを使用して、分散ネットワーク環境を構築しました。 その結果、テスト環境のアーキテクチャは次のようになります。







Weave Scopeを使用して環境を視覚化します。これは、Dockerコンテナーを監視するための非常に便利で直感的なサービスであるためです。







このアプローチを使用すると、SOAコンポーネント（たとえば、私たちのような小さなクライアントサーバーアプリケーション）の相互作用をテストするのに便利です。

基本環境の実装

次に、docker-composeおよびdocker-machineを使用してDockerコンテナに基づいてテスト環境を作成する各ステップを詳しく見ていきます。

まずはdocker-machineから始めましょう。これにより、テスト仮想環境を簡単に強調できます。 同時に、ホストシステムからこの環境を直接操作することは非常に便利です。

したがって、テストマシンを作成します。

$ docker-machine create -d virtualbox testenv Creating VirtualBox VM... Creating SSH key... Starting VirtualBox VM... Starting VM... To see how to connect Docker to this machine, run: docker-machine env testenv
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは、CoreOSとDockerが内部にインストールされたVirtualBox VMを作成します（WindowsまたはMacOSを使用している場合は、Docker Toolboxをインストールすることをお勧めします。 、docker-compose、VirtualBoxのみ）。 docker-machineのすべての機能に慣れることをお勧めします。これは、環境を管理するためのかなり強力なツールです。



このコマンドの出力からわかるように、docker-machineは、仮想マシンでの作業に必要なすべてを作成します。 作成されると、仮想マシンが稼働します。 確認しましょう：

 $ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM testenv virtualbox Running tcp://192.168.99.101:2376
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

素晴らしい、仮想マシンは実行中です。 現在のセッションでアクセスを有効にする必要があります。 前のステップに戻って、最後の行を注意深く見てみましょう。

 To see how to connect Docker to this machine, run: docker-machine env testenv
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、セッションの自動セットアップです。 このコマンドを実行すると、次のように表示されます。

 $ docker-machine env testenv export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.168.99.101:2376" export DOCKER_CERT_PATH="/Users/logpacker/.docker/machine/machines/testenv" export DOCKER_MACHINE_NAME="testenv" # Run this command to configure your shell: # eval "$(docker-machine env testenv)"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、サーバーを探す場所をローカルのdockerクライアントに伝える環境変数のセットです。 最後の行はヒントです。 このコマンドを実行して、 ls



出力を確認します。

 $ eval "$(docker-machine env testenv)" $ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM testenv * virtualbox Running tcp://192.168.99.101:2376
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ACTIVE



列では、アクティブなマシンにアスタリスクが付いています。 マシンは現在のセッション内でのみアクティブであることに注意してください。 別のターミナルウィンドウを開き、そこで別のマシンをアクティブにすることができます。 これは、Swarmを使用したオーケストレーションなどのテストに便利です。 しかし、これは別の記事のトピックです:)。

次に、Dockerサーバーをチェックアウトします。

 $ docker info docker version Client: Version: 1.8.0 API version: 1.20 Go version: go1.4.2 Git commit: 0d03096 Built: Tue Aug 11 17:17:40 UTC 2015 OS/Arch: darwin/amd64 Server: Version: 1.9.1 API version: 1.21 Go version: go1.4.3 Git commit: a34a1d5 Built: Fri Nov 20 17:56:04 UTC 2015 OS/Arch: linux/amd64
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DockerサーバーはVMで実行されるので、忘れないでください。OS/ Archに焦点を当てています。常にlinux / amd64があります。 少し脱線して、VMの内部を見てみましょう。

 $ docker-machine ssh testenv ## . ## ## ## == ## ## ## ## ## === /"""""""""""""""""\___/ === ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~ \______ o __/ \ \ __/ \____\_______/ _ _ ____ _ _ | |__ ___ ___ | |_|___ \ __| | ___ ___| | _____ _ __ | '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__| | |_) | (_) | (_) | |_ / __/ (_| | (_) | (__| < __/ | |_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_| Boot2Docker version 1.9.1, build master : cef800b - Fri Nov 20 19:33:59 UTC 2015 Docker version 1.9.1, build a34a1d5 docker@testenv:~$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、これはboot2dockerですが、これは面白くないです。 マウントされたセクションを見てみましょう。

 docker@testenv:~$ mount tmpfs on / type tmpfs (rw,relatime,size=918088k) proc on /proc type proc (rw,relatime) sysfs on /sys type sysfs (rw,relatime) devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) /dev/sda1 on /mnt/sda1 type ext4 (rw,relatime,data=ordered) [... cgroup skipped ...] none on /Users type vboxsf (rw,nodev,relatime) /dev/sda1 on /mnt/sda1/var/lib/docker/aufs type ext4 (rw,relatime,data=ordered) docker@testenv:~$ ls /Users/ Shared/ logpacker/ docker@testenv:~$
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、MacOSを使用し、それに応じて/ Usersディレクトリがマシン内にマウントされます（Linuxの/ homeに類似）。 これにより、ドッカーの一部としてホストシステム上のファイルを透過的に操作できます。つまり、VMの形式のレイヤーを心配することなく、ボリュームを静かに接続および切断できます。 とても便利です。 理論的には、このVMについては忘れることができます。Dockerが「ネイティブ」環境で動作するためにのみ必要です。 この場合、docker-clientの使用は完全に透過的になります。

したがって、基本的な環境が構築されたら、Dockerコンテナーを起動します。

コンテナの構成と起動

このアプリケーションは、クラスターの原則に基づいて動作することができます。つまり、ノード数が変化した場合にシステム全体のフォールトトレランスを提供します。 内部インターサービスAPIのおかげで、クラスターに新しいノードを追加または削除するのは簡単で、他のノードをオーバーロードする必要もありません。また、環境を構築する際にアプリケーションのこの特徴を考慮する必要があります。

原則として、すべてがDockerのイデオロギー「1つのプロセス-1つのコンテナー」によく適合しています。 したがって、我々は規範から離れず、同じことをします。 開始時に、次の構成を実行します。

• アプリケーションのサーバー側の3つのコンテナー。
• アプリケーションのクライアント部分を持つ3つのコンテナ。
• 各エージェントの負荷ジェネレーター。 たとえば、Ngnixはログを生成し、Yandex.TankまたはApache Benchmarkを使用してそれを刺激します。
• そして、別のコンテナで、イデオロギーから離れます。 私たちのサービスは、いわゆる「デュアルモード」、つまり クライアントとサーバーは同じホスト上にあり、さらに、これはアプリケーションの1つのインスタンスにすぎず、クライアントとサーバーの両方としてすぐに動作します。 スーパーバイザーの管理下にあるコンテナで起動し、メインプロセスと同じコンテナで独自の小さな負荷ジェネレータを起動します。

したがって、アプリケーションのアセンブルされたバイナリがあります-これはGolangのおかげで1つのファイルです:)、テスト環境の一部として、サービスを起動するためのユニバーサルコンテナを収集します。 違いは、送信されるキー（サーバーまたはエージェントを起動する）にあり、コンテナの起動時にそれらを管理します。 「デュアルモード」でサービスを開始する場合、最後の段落にはわずかなニュアンスがありますが、それについては後で詳しく説明します。

そのため、 docker-compose.yml



準備しています。 これは、docker-composeのディレクティブを含むファイルです。これにより、1つのコマンドでテスト環境を上げることができます。



このファイルではすべてが標準です。 最初に主リポジトリとしてelasticsearchを実行し、次にnginxで3つのインスタンスを実行します。これはロードプロバイダーとして機能します。 次に、サーバーアプリケーションを起動します。 後続のすべてのコンテナは前のコンテナとリンクされていることに注意してください。 Dockerネットワークの一部として、これにより名前によるコンテナーへのアクセスが許可されます。 もう少し低めに、「デュアルモード」でのサービスの起動を分析するとき、このポイントに戻って詳細に検討します。 また、エージェントは、サーバーアプリケーションインスタンスが配置されている最初のコンテナにリンクされます。 これは、3つすべてのエージェントがこのサーバーにログを転送することを意味します。



このアプリケーションは、新しいノードをクラスターに追加するように設計されており、エージェントまたはサーバーは、1つの既存のクラスターノードについて報告するだけで、システム全体に関する完全な情報を受け取ります。 各サーバーインスタンスの構成ファイルでは、最初のノードを示し、エージェントはシステムの現在の状態に関するすべての情報を自動的に受け取ります。 システムのすべてのノードを起動してしばらくしてから、このインスタンスをオフにします。 私たちの場合、クラスターはそれを簡単に転送し、システムに関するすべての情報はすでにすべての参加者に配布されています。



そしてもう1つ、ボリュームのマウントのロジックに注意してください。 nginxが含まれるコンテナでは、Dockerネットワークで利用可能な名前付きボリュームを指定し、エージェントが含まれるコンテナでは、サービスの名前を指定するだけで接続します。 したがって、コンシューマとロードプロバイダの間で共有ボリュームを取得します。



そのため、環境を開始します。

 $ docker-compose up -d
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが正常に開始したことを確認します

 $ docker-compose ps Name Command State Ports -------------------------------------------------------------------------------------------- assets_lp_agent_1_1 bash -c cd /opt/logpacker ... Up assets_lp_agent_2_1 bash -c cd /opt/logpacker ... Up assets_lp_agent_3_1 bash -c cd /opt/logpacker ... Up assets_lp_server_1_1 bash -c cd /opt/logpacker ... Up 9995/tcp, 9998/tcp, 9999/tcp assets_lp_server_2_1 bash -c cd /opt/logpacker ... Up 9995/tcp, 9998/tcp, 9999/tcp assets_lp_server_3_1 bash -c cd /opt/logpacker ... Up 9995/tcp, 9998/tcp, 9999/tcp assets_ngx_1_1 nginx -g daemon off; Up 443/tcp, 80/tcp assets_ngx_2_1 nginx -g daemon off; Up 443/tcp, 80/tcp assets_ngx_3_1 nginx -g daemon off; Up 443/tcp, 80/tcp elastic /docker-entrypoint.sh elas ... Up 9200/tcp, 9300/tcp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、環境は上昇し、機能し、すべてのポートが転送されました。 理論的には、テストを開始できますが、いくつかのポイントを完了する必要があります。

コンテナの命名

「デュアルモード」でアプリケーションを実行したいコンテナに戻りましょう。 このコンテナのメインプロセスは、ロードジェネレーター（最も単純なシェルスクリプト）です。 テキスト文字列を生成し、それらをテキスト「ログ」ファイルに入れます。これは、アプリケーションの負荷になります。 最初に、 supervisord



下で実行するアプリケーションを使用してコンテナを構築する必要があります。 環境変数を構成ファイルに転送する機能が必要なため、 supervisord



の最新バージョンを使用してください。 supervisord



バージョン3.2.0が適していますが、ベースイメージとして採用したUbuntu 14.04 LTSでは、 supervisord



バージョンはかなり古い（3.0b2）です。 supervisord



の最新バージョンをpip



経由でインストールします。 結果のDockerfileは次のとおりです。





ロードジェネレーターは非常にシンプルです。

 #!/bin/bash # generate random lines OUTPUT_FILE="test.log" while true do _RND_LENGTH=`awk -v min=1 -v max=100 'BEGIN{srand(); print int(min+rand()*(max-min+1))}'` _RND=$(( ( RANDOM % 100 ) + 1 )) _A="[$RANDOM-$_RND] $(dd if=/dev/urandom bs=$_RND_LENGTH count=1 2>/dev/null | base64 | tr = d)"; echo $_A; echo $_A >> /tmp/logpacker/lptest.$_RND.$OUTPUT_FILE; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

起動スクリプトも複雑ではありません。

 #!/bin/bash # run daemon supervisord -c /etc/supervisor/supervisor.conf # launch randomizer /opt/random.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてのトリックは、 supervisord



構成ファイルにあり、Dockerコンテナーを起動します。

構成ファイルを検討してください。

 [program:logpacker_daemon] command=/opt/logpacker/logpacker %(ENV_LOGPACKER_OPTS)s directory=/opt/logpacker/ autostart=true autorestart=true startretries=10 stderr_logfile=/var/log/logpacker.stderr.log stdout_logfile=/var/log/logpacker.stdout.log
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

%(ENV_LOGPACKER_OPTS)s



注意してください。 Supervisordは、環境変数から構成ファイルへの順列を実行できます。 変数は%(ENV_VAR_NAME)s



として書き込まれ、その値はデーモンの起動時に構成ファイルに代入されます。

次のコマンドを実行してコンテナを起動します。

 $ docker run -it -d --name=dualmode --link=elastic -e 'LOGPACKER_OPTS=-s -a -v -devmode' logpacker_dualmode /opt/random.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-e



スイッチを使用すると、必要な環境変数を設定でき、コンテナ内でグローバルに設定されます。 そして、 supervisord



設定ファイルでそれを置き換えます。 したがって、デーモンのスタートアップキーを管理し、必要なモードで実行できます。

イデオロギーとは少し矛盾していますが、私たちは普遍的なイメージを得ました。 中を見てみましょう：



コンテナの起動時に明示的に指定した変数に加えて、リンクされたコンテナに関連するすべての変数、つまり、IPアドレス、すべての開いているポート、ENVディレクティブを使用してelasticsearchイメージを構築するときに明示的に設定されたすべての変数も表示されます。 すべての変数には、エクスポートするコンテナの名前とその本質を示す名前の接頭辞があります。 たとえば、 ELASTIC_PORT_9300_TCP_ADDR



は、ポート9300が開いているELASTIC_PORT_9300_TCP_ADDR



という名前とそのIPアドレスを持つコンテナーを指す変数に値が格納されることを意味します。リンクされたコンテナのデータ。 同時に、Dockerコンテナで実行されているアプリケーションでそれらを使用することも可能です。

コンテナ管理および監視システム

そのため、すべての初期要件を満たすテスト環境を構築しました。 いくつかのニュアンスがありました。 まず、Weave Scopeをインストールします（スクリーンショットは記事の冒頭にありました）。 Weave Scopeを使用すると、作業環境を視覚化できます。 コンテナに関するリンクと情報の表示に加えて、任意のコンテナにattach



したり、ブラウザで直接sh



を使用して本格的なターミナルを起動したりできます。 これらは、デバッグとテストに不可欠な機能です。 そのため、ホストマシンから、アクティブセッションの一部として次のアクションを実行します。

 $ wget -O scope https://github.com/weaveworks/scope/releases/download/latest_release/scope $ chmod +x scope $ scope launch
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのコマンドを実行した後、アドレスVM_IP ：4040に移動すると、次の図に示すコンテナー管理インターフェイスに到達します。







まあ、ほとんどすべての準備ができています。 完全な幸福のために、監視システムが不足しています。 GoogleのcAdvisorを活用してください。

 $ docker run --volume=/:/rootfs:ro --volume=/var/run:/var/run:rw --volume=/sys:/sys:ro --volume=/var/lib/docker/:/var/lib/docker:ro --publish=8080:8080 --detach=true --name=cadvisor google/cadvisor:latest
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

VM_IP ：8080には、リアルタイムのリソース監視システムがあります。 次のような環境の基本的なメトリックを追跡および分析できます。

• システムリソースの使用。
• ネットワーク負荷。
• プロセスのリスト。
• その他の有用な情報。

以下のスクリーンショットは、cAdvisorインターフェースを示しています。

おわりに

Dockerコンテナを使用して、すべてのノードの自動展開とネットワーク相互作用の機能を備えた本格的なテスト環境を構築しました。最も重要なことは、各コンポーネントとシステム全体の柔軟な構成です。 すべての基本要件が実装されています。つまり、

• ネットワーク接続をテストするための完全なネットワークエミュレーション。
• アプリケーションでのノードの追加と削除は、docker-compose.ymlの変更により実行され、単一のコマンドで適用されます。
• すべてのノードは、ネットワーク環境に関する情報を完全に受信できます。
• データウェアハウスの追加と削除は、1つのコマンドで実行されます。
• システムの管理と監視は、ブラウザから利用できます。 これは、アプリケーションの隣のコンテナで個別に実行されるツールを使用して実装されます。これにより、ホストシステムからそれらを分離できます。

記事に記載されているすべてのツールへのリンク：

• Docker
• docker-compose
• ドッカーマシン
• Dockerツールボックス
• 織りスコープ
• cAdvisor
• テスト環境の構築に使用されるすべての構成ファイルとスクリプト