継続的統合のための Docker でのマイクロサービスの自動テスト

マイクロサービス アーキテクチャの開発に関連するプロジェクトにおいて、CI/CD は楽しい機会のカテゴリーから緊急に必要なカテゴリーに移行しています。 自動テストは継続的統合に不可欠な部分であり、チームに家族や友人と楽しい夜を過ごすことができる有能なアプローチです。 そうしないと、プロジェクトが完了しない危険があります。

モック オブジェクトを使用した単体テストでマイクロサービス コード全体をカバーすることは可能ですが、これでは問題は部分的にしか解決されず、特にデータを使用した作業をテストする場合には多くの疑問と困難が残ります。 いつものように、最も差し迫った問題は、リレーショナル データベースでのデータの整合性のテスト、クラウド サービスでの作業のテスト、モック オブジェクトを作成するときに誤った仮定を行うことです。

これらすべてとそれ以上のことは、Docker コンテナーでマイクロサービス全体をテストすることで解決できます。 テストの有効性を確保する上での疑いのない利点は、実稼働環境に入るのと同じ Docker イメージがテストされることです。

このアプローチの自動化には多くの問題が発生します。その解決策については以下で説明します。

• 同じ Docker ホスト内の並列タスクの競合。
• テスト反復中にデータベース内で識別子の競合が発生する。
• マイクロサービスの準備が整うのを待っています。
• ログをマージして外部システムに出力します。
• 発信 HTTP リクエストをテストする。
• Web ソケットのテスト (SignalR を使用)。
• OAuth 認証と認可をテストします。

この記事は以下に基づいています 私のスピーチ SECR 2019 にて。読むのが面倒な人のために、 これはスピーチの録音です.

この記事では、スクリプトを使用してテスト対象のサービス、データベース、Amazon AWS サービスを Docker で実行し、Postman でテストし、完了後に作成したコンテナを停止して削除する方法を説明します。 テストはコードが変更されるたびに実行されます。 このようにして、各バージョンが AWS データベースおよびサービスで正しく動作することを確認します。

同じスクリプトが、開発者自身の Windows デスクトップと、Linux 上の Gitlab CI サーバーの両方で実行されます。

新しいテストを導入するために、開発者のコ​​ンピュータやコミットでテストが実行されるサーバーに追加のツールをインストールする必要はないはずですが、Docker はこの問題を解決します。

次の理由により、テストはローカル サーバーで実行する必要があります。

• ネットワークは決して完全に信頼できるものではありません。 XNUMX 件のリクエストのうち XNUMX 件が失敗する可能性があります。
  この場合、自動テストは機能せず、作業が停止するため、ログで理由を探す必要があります。
• 一部のサードパーティ サービスでは、あまりに頻繁なリクエストが許可されません。

さらに、次の理由からスタンドの使用は望ましくありません。

• スタンドは、その上で実行されている不正なコードだけでなく、正しいコードが処理できないデータによっても壊れる可能性があります。
• テスト中に行われたすべての変更を元に戻そうとどれだけ努力しても、何か問題が発生する可能性があります (そうでない場合、なぜテストする必要がありますか?)。

プロジェクトとプロセスの組織について

当社は、Amazon AWS クラウドの Docker で実行されるマイクロサービス Web アプリケーションを開発しました。 プロジェクトではすでに単体テストが使用されていましたが、単体テストでは検出されなかったエラーが頻繁に発生しました。 データベースと Amazon サービスとともにマイクロサービス全体をテストする必要がありました。

このプロジェクトでは、コミットごとにマイクロサービスをテストすることを含む、標準の継続的統合プロセスが使用されます。 タスクを割り当てた後、開発者はマイクロサービスに変更を加え、手動でテストし、利用可能なすべての自動テストを実行します。 必要に応じて、開発者はテストを変更します。 問題が見つからない場合は、この問題のブランチにコミットが行われます。 各コミットの後、サーバー上でテストが自動的に実行されます。 共通ブランチへのマージとそのブランチに対する自動テストの開始は、レビューが成功した後に行われます。 共有ブランチのテストに合格すると、Amazon Elastic Container Service (ベンチ) のテスト環境でサービスが自動的に更新されます。 スタンドはすべての開発者とテスターに​​とって必要なものであり、壊すことはお勧めできません。 この環境のテスターは、手動テストを実行して修正または新機能をチェックします。

プロジェクトのアーキテクチャ

アプリケーションは XNUMX を超えるサービスで構成されています。 それらの一部は .NET Core で書かれており、一部は NodeJs で書かれています。 各サービスは、Amazon Elastic Container Service の Docker コンテナで実行されます。 それぞれに独自の Postgres データベースがあり、一部には Redis も含まれています。 共通のデータベースはありません。 複数のサービスが同じデータを必要とする場合、このデータは変更されると、SNS (Simple Notice Service) および SQS (Amazon Simple Queue Service) 経由で各サービスに送信され、各サービスはそれを独自の個別のデータベースに保存します。

SQSとSNS

SQS を使用すると、HTTPS プロトコルを使用してメッセージをキューに入れたり、キューからメッセージを読み取ることができます。

複数のサービスが XNUMX つのキューを読み取る場合、各メッセージはそのうちの XNUMX つにのみ到着します。 これは、同じサービスの複数のインスタンスを実行してそれらの間で負荷を分散する場合に便利です。

各メッセージを複数のサービスに配信する場合は、各受信者が独自のキューを持つ必要があり、メッセージを複数のキューに複製するために SNS が必要です。

SNS では、トピックを作成し、それをサブスクライブします (SQS キューなど)。 トピックにメッセージを送信できます。 この場合、メッセージは、このトピックにサブスクライブされている各キューに送信されます。 SNSにはメッセージを読む方法がありません。 デバッグまたはテスト中に、SNS に何が送信されたかを調べる必要がある場合は、SQS キューを作成し、目的のトピックにサブスクライブして、キューを読み取ることができます。

APIゲートウェイ

ほとんどのサービスはインターネットから直接アクセスできません。 アクセスは、アクセス権をチェックする API ゲートウェイ経由で行われます。 これも当社のサービスであり、テストもあります。

リアルタイム通知

アプリケーションが使用するのは、 SignalRユーザーにリアルタイムの通知を表示します。 これは通知サービスに実装されています。 インターネットから直接アクセスでき、それ自体が OAuth で動作します。これは、OAuth と通知サービスを統合する場合と比較して、ゲートウェイに Web ソケットのサポートを組み込むのは非現実的であることが判明したためです。

よく知られたテスト手法

単体テストでは、データベースなどをモック オブジェクトに置き換えます。 たとえば、マイクロサービスが外部キーを使用してテーブルにレコードを作成しようとしたときに、そのキーによって参照されるレコードが存在しない場合、リクエストは完了できません。 単体テストではこれを検出できません。

В マイクロソフトの記事 インメモリデータベースを使用し、モックオブジェクトを実装することが提案されています。

インメモリ データベースは、Entity Framework でサポートされる DBMS の XNUMX つです。 これはテスト用に特別に作成されました。 このようなデータベース内のデータは、それを使用するプロセスが終了するまでのみ保存されます。 テーブルを作成する必要はなく、データの整合性もチェックしません。

モック オブジェクトは、テスト開発者がその動作方法を理解している範囲でのみ、置換対象のクラスをモデル化します。

テストの実行時に Postgres を自動的に起動して移行を実行する方法については、Microsoft の記事には記載されていません。 私のソリューションはこれを行い、さらに、マイクロサービス自体にテスト専用のコードを追加しません。

解決策に移りましょう

開発プロセス中に、すべての問題をタイムリーに発見するには単体テストだけでは不十分であることが判明したため、この問題に別の角度からアプローチすることにしました。

テスト環境のセットアップ

最初のタスクは、テスト環境を展開することです。 マイクロサービスを実行するために必要な手順:

• ローカル環境用にテスト対象のサービスを構成し、環境変数でデータベースと AWS に接続するための詳細を指定します。
• Postgres を起動し、Liquibase を実行して移行を実行します。
  リレーショナル DBMS では、データベースにデータを書き込む前に、データ スキーマ、つまりテーブルを作成する必要があります。 アプリケーションを更新するときは、できればデータを失わずに、テーブルを新しいバージョンで使用される形式にする必要があります。 これを移行と呼びます。 最初は空のデータベースにテーブルを作成するのは、移行の特殊なケースです。 移行はアプリケーション自体に組み込むことができます。 .NET と NodeJS の両方に移行フレームワークがあります。 私たちの場合、セキュリティ上の理由から、マイクロサービスはデータ スキーマを変更する権利を剥奪されており、移行は Liquibase を使用して実行されます。
• Amazon LocalStack を起動します。 これは、自宅で実行するための AWS サービスの実装です。 Docker Hub には LocalStack 用の既製のイメージがあります。
• スクリプトを実行して、LocalStack に必要なエンティティを作成します。 シェル スクリプトは AWS CLI を使用します。

プロジェクトのテストに使用されます Postman。 以前から存在していましたが、手動で起動し、すでにスタンドにデプロイされているアプリケーションをテストしていました。 このツールを使用すると、任意の HTTP(S) リクエストを作成し、その応答が期待どおりかどうかを確認できます。 クエリは XNUMX つのコレクションに結合され、コレクション全体を実行できます。

自動テストはどのように機能しますか?

テスト中は、テスト対象のサービス、Postgres、移行ツール、Postman、あるいはそのコンソール バージョンである Newman など、すべてが Docker で動作します。

Docker は多くの問題を解決します。

• ホスト構成からの独立性。
• 依存関係のインストール: Docker は Docker Hub からイメージをダウンロードします。
• システムを元の状態に戻すには、コンテナを削除するだけです。

Docker-compose コンテナを、インターネットから隔離された仮想ネットワークに統合します。この仮想ネットワークでは、コンテナはドメイン名によって相互に検索されます。

テストはシェル スクリプトによって制御されます。 Windows でテストを実行するには、git-bash を使用します。 したがって、Windows と Linux の両方に XNUMX つのスクリプトで十分です。 Git と Docker は、プロジェクトのすべての開発者によってインストールされます。 Windows に Git をインストールすると、git-bash がインストールされるので、誰でもそれを持っています。

スクリプトは次の手順を実行します。

• Docker イメージの構築

  docker-compose build

• データベースと LocalStack の起動

  docker-compose up -d <контейнер>

• データベースの移行と LocalStack の準備

  docker-compose run <контейнер>

• テスト中のサービスを起動する

  docker-compose up -d <сервис>

• テストの実行 (Newman)
• すべてのコンテナを停止する

  docker-compose down

• Slack に結果を投稿する
  緑のチェックマークまたは赤のバツが付いたメッセージとログへのリンクが送信されるチャットがあります。

これらの手順には、次の Docker イメージが含まれます。

• テスト中のサービスは本番環境と同じイメージです。 テストの構成は環境変数を通じて行われます。
• Postgres、Redis、LocalStack の場合は、Docker Hub の既製のイメージが使用されます。 Liquibase と Newman 用の既製のイメージもあります。 私たちはそのスケルトンに基づいてファイルを追加し、スケルトンを構築します。
• LocalStack を準備するには、既製の AWS CLI イメージを使用し、それに基づくスクリプトを含むイメージを作成します。

使い方 ボリューム、コンテナーにファイルを追加するためだけに Docker イメージを構築する必要はありません。 ただし、Gitlab CI タスク自体はコンテナー内で実行されるため、ボリュームは私たちの環境には適していません。 このようなコンテナーから Docker を制御できますが、ボリュームはホスト システムからフォルダーのみをマウントし、別のコンテナーからはマウントしません。

遭遇する可能性のある問題

準備が整うのを待っています

サービスを含むコンテナーが実行されていても、接続を受け入れる準備ができていることを意味するわけではありません。 接続が続行されるまで待つ必要があります。

この問題はスクリプトを使用して解決できる場合があります 待ってください.sh、TCP 接続を確立する機会を待ちます。 ただし、LocalStack は 502 Bad Gateway エラーをスローする場合があります。 さらに、それは多くのサービスで構成されており、そのうちの XNUMX つが準備できていても、他のサービスについては何も言えません。

ソリューション: SQS と SNS の両方からの 200 応答を待機する LocalStack プロビジョニング スクリプト。

並列タスクの競合

同じ Docker ホスト上で複数のテストを同時に実行できるため、コンテナー名とネットワーク名は一意である必要があります。 さらに、同じサービスの異なるブランチからのテストも同時に実行できるため、各構成ファイルに名前を記述するだけでは十分ではありません。

ソリューション: スクリプトは COMPOSE_PROJECT_NAME 変数を一意の値に設定します。

Windowsの機能

Windows で Docker を使用する場合、これらの経験はエラーが発生する理由を理解するために重要であるため、いくつか注意したい点があります。

1. コンテナ内のシェル スクリプトには Linux の行末が必要です。
   シェル CR シンボルは構文エラーです。 エラー メッセージからは、これが事実であるかどうかを判断するのは困難です。 Windows でこのようなスクリプトを編集する場合は、適切なテキスト エディターが必要です。 さらに、バージョン管理システムが適切に構成されている必要があります。

git の設定方法は次のとおりです。

git config core.autocrlf input

1. Git-bash は標準の Linux フォルダーをエミュレートし、exe ファイル (docker.exe を含む) を呼び出すときに、Linux の絶対パスを Windows パスに置き換えます。 ただし、ローカル マシン上にないパス (またはコンテナ内のパス) の場合、これは意味がありません。 この動作を無効にすることはできません。

ソリューション: パスの先頭にスラッシュを追加します: /bin の代わりに //bin。 Linux はそのようなパスを認識するため、複数のスラッシュは XNUMX つと同じになります。 しかし、git-bash はそのようなパスを認識せず、変換しようとしません。

ログ出力

テストを実行するとき、Newman とテスト対象のサービスの両方からのログを確認したいと思います。 これらのログのイベントは相互に関連しているため、XNUMX つの別々のファイルよりも XNUMX つのコンソールに結合する方がはるかに便利です。 ニューマンは経由で起動します docker-compose の実行したがって、その出力はコンソールに表示されます。 残っているのは、サービスの出力も確実にそこに送信されるようにすることだけです。

元の解決策は次のとおりでした ドッカー - 構成 フラグがありません -dただし、シェル機能を使用して、このプロセスをバックグラウンドに送信します。

docker-compose up <service> &

これは、Docker からサードパーティのサービスにログを送信する必要があるまでは機能しました。 ドッカー - 構成 コンソールへのログ出力を停止しました。 それでもチームは頑張った ドッカーアタッチメント.

ソリューション:

docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &

テスト反復中の識別子の競合

テストは数回繰り返して実行されます。 データベースはクリアされません。 データベース内のレコードには一意の ID があります。 リクエストに特定の ID を書き留めると、XNUMX 回目の反復で競合が発生します。

これを回避するには、ID を一意にするか、テストによって作成されたすべてのオブジェクトを削除する必要があります。 要件により、一部のオブジェクトは削除できません。

ソリューション: Postman スクリプトを使用して GUID を生成します。

var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);

次に、クエリでシンボルを使用します {{myUUID}}、変数の値に置き換えられます。

LocalStack を介したコラボレーション

テスト対象のサービスが SQS キューの読み取りまたは書き込みを行う場合、これを検証するには、テスト自体もこのキューで動作する必要があります。

ソリューション: Postman から LocalStack へのリクエスト。

AWS サービス API は文書化されており、SDK なしでクエリを実行できます。

サービスがキューに書き込む場合、キューを読み取ってメッセージの内容を確認します。

サービスが SNS にメッセージを送信する場合、準備段階で LocalStack もキューを作成し、この SNS トピックをサブスクライブします。 そうすれば、すべては上で説明したことになります。

サービスがキューからメッセージを読み取る必要がある場合、前のテスト ステップでこのメッセージをキューに書き込みます。

テスト対象のマイクロサービスから発信された HTTP リクエストのテスト

一部のサービスは HTTP 経由で AWS 以外と動作し、一部の AWS 機能は LocalStack に実装されていません。

ソリューション: このような場合に役立ちます モックサーバーに既製のイメージがあります。 Dockerハブ。 予期されるリクエストとそれに対する応答は、HTTP リクエストによって構成されます。 API は文書化されているため、Postman からリクエストを作成します。

OAuth 認証と認可のテスト

私たちはOAuthを使用しており、 JSON Web Tokens（JWT）。 テストには、ローカルで実行できる OAuth プロバイダーが必要です。

サービスと OAuth プロバイダーの間のすべての対話は、XNUMX つのリクエストに帰着します。まず、構成がリクエストされます。 /.well-known/openid-構成、次に、構成のアドレスで公開キー (JWKS) が要求されます。 これはすべて静的なコンテンツです。

ソリューション: 私たちのテスト OAuth プロバイダーは、静的コンテンツ サーバーとその上の XNUMX つのファイルです。 トークンは一度生成され、Git にコミットされます。

SignalR テストの特徴

Postman は WebSocket では機能しません。 SignalR をテストするために特別なツールが作成されました。

SignalR クライアントは単なるブラウザー以上の役割を果たします。 .NET Core にはそのためのクライアント ライブラリがあります。 .NET Core で記述されたクライアントは、接続を確立し、認証されて、特定の一連のメッセージを待ちます。 予期しないメッセージを受信した場合、または接続が失われた場合、クライアントはコード 1 で終了します。予期される最後のメッセージを受信した場合、クライアントはコード 0 で終了します。

ニューマンはクライアントと同時に仕事をします。 メッセージが必要な全員に配信されることを確認するために、いくつかのクライアントが起動されます。

複数のクライアントを実行するには、オプションを使用します - 規模 docker-compose コマンドラインで。

Postman スクリプトは実行前に、すべてのクライアントが接続を確立するのを待ちます。
接続を待機するという問題はすでに発生しています。 しかし、そこにはサーバーがあり、ここにクライアントがあります。 別のアプローチが必要です。

ソリューション: コンテナ内のクライアントがメカニズムを使用します 健康診断ホスト上のスクリプトにステータスを通知します。 クライアントは、接続が確立されるとすぐに、特定のパス (/healthcheck など) にファイルを作成します。 docker ファイル内の HealthCheck スクリプトは次のようになります。

HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fi

チーム dockerinspect コンテナの通常のステータス、健全性ステータス、および終了コードを表示します。

Newman が完了すると、スクリプトはクライアントのすべてのコンテナがコード 0 で終了したかどうかを確認します。

ハピネスは存在する

上記の困難を克服した後、一連の安定した走行テストを行うことができました。 テストでは、各サービスは単一のユニットとして動作し、データベースおよび Amazon LocalStack と対話します。

これらのテストは、30 人以上の開発者からなるチームを、頻繁なデプロイメントを伴う 10 個以上のマイクロサービスの複雑な相互作用によるアプリケーションのエラーから保護します。

出所： habr.com