OpenStackを使用したテスト環境の構築

著者：ユージンシューマッハ

Eugene Schumacher-Mirantisのビジネスアナリストと提案： OpenStackが解決できない問題を選択しないようにする方法、 クラウドのスピーカーが準拠していること 今年の春にアトランタで開催されるOpenStack Summitで。

昨年10月に実施されたOpenStackユーザーの調査では、テスト環境の構築は、最も一般的な10のOpenStackユースケースの1つであることが示されました。 この投稿では、テスト環境の構築方法について説明し、OpenStackがこのプロセスを簡素化してより効率的にする方法を分析します。

現状

おそらく、テスト環境の最も重要な要件は、対応する作業環境のコピーであることです（実際には、これは常に100％真実とは限りません-以下を参照）。 その他の要件と制限は、ソフトウェア（ソフトウェア）の使用例とテスト方法論から生じます。

試運転前に実行される一連のテストは、機能テストで始まり、並行テストで終わることができます。

次の手順を含むテスト方法を検討してください。
•最初のテスト環境で、ソフトウェアの以前のバージョンでテストを実行します。
•2番目のテスト環境で新しいソフトウェアバージョンでテストを実行します。 そして
•結果を比較します。

このアプローチで、アプリケーションの作業バージョンが仮想化環境で動作せず、ベアメタルで動作する場合、テスト環境ごとに個別のハードウェアクラスターが必要です。 これら2つのテスト環境では、作業環境からのハードウェア、ネットワーク構成、ソフトウェア設定、およびデータ（自然に匿名化）をミラーリングする必要があります。 理想的には、両方のテスト環境を同じハードウェアで実行し、可能であれば同様のネットワーク構成を使用する必要があります。

ほとんどの場合、このようなテスト環境の所有者はシステム管理者です。テスト環境にアクセスしたり変更したりするには、テストチームがさまざまなアプリケーションを作成する必要があります。



このアプローチには、次の欠点があります。
•テスト環境を構築するための高コスト。 ハードウェアに基づいてテスト環境を構築するには、特にテスト対象のソフトウェアが重要であり、および/または多数のサーバーが必要な場合、多大な費用がかかります。 また、2つの環境では、これらのコストは2倍になります。 そして、これは、複数のアプリケーションをテストするときに生じる追加の要件を考慮に入れていません。
•実装の複雑さ。 2つのテスト環境は同様の構成であり、作業設定のレプリカである必要があり、両方とも正常に機能するはずです。
•スケーリングの難しさ。 たとえば、カスタム受け入れテストやユーザビリティテストのために別のテスト環境が必要な場合はどうなりますか？ より多くのリソース、より多くの時間、より多くの依存関係。
•テストチームには、テスト環境を独立して管理する能力はありません。テストチームは主にITチームに依存しています。

OpenStackを使用するとどうなりますか？

次の特性は、テスト環境の主要な要件として特定できます。
•低い建設費。
•シンプルで迅速なセットアップと操作。
•シンプルで高速なスケーリング。
•セルフサービスオプション。

OpenStackとこのテクノロジーの利点に精通している人にとっては、これがまさにあなたが必要としているように思えるかもしれません。 OpenStackは、低コストの汎用ハードウェアに展開できる無料のオープンソースプラットフォームです。 これにより、テスト環境および仮想テスト環境全体のコンポーネントを事前に構成し、必要な規模でそれらを迅速に再現できます。 最後に、OpenStackにはセルフサービスポータル（Horizo​​n）があり、ユーザーはこれを介して次の目的でリソースにアクセスできます。
•仮想サーバー（Nova）を作成します。
•データストレージ（Cinder）のボリュームの作成/接続。
•ネットワークの構成（Neutron）。
•クラウドアプリケーションのインフラストラクチャを構築します（熱）。

クラウドはあなたに適していますか？

テスト環境をクラウドに移行するには、テスト対象のアプリケーションと以下の技術的能力を深く理解する必要があります。
•基本プラットフォームの比較テストを実行し、プロトコルが開発されます。これにより、クラウドとベアメタルに基づいたパフォーマンスがまったく異なる場合に、それらの対応を確立できます。
•パフォーマンスの制限やその他の違いにもかかわらず、必要なテスト範囲を提供するためのクラウドベースのテスト環境の適応。 たとえば、テストデータベース、クエリ、およびその他の変数のサイズを調整して、クラウドベースのテスト環境がベアメタルテスト環境と同等に機能するようにします。 これにより、多くの分野でベアメタルで実行されるソリューションで実行されるテストと同様のテストのクラウドに基づいたテスト環境でテストを実行することができます。

•テスト環境が作業環境を適切にシミュレートしていない状況の適切な評価（ストレステスト中に頻繁に発生する）。

クラウドテクノロジーは非常に急速に発展しており、仮想マシンとそれらが動作するハードウェア間の通信を構成する機会が増えていることを覚えておく必要があります。

アプリケーションが適切に動作し、クラウドでのテストが意味のある結果をもたらすと確信している場合、クラウド（同時にOpenStack）が正しい選択です。

クラウドアーキテクチャ

テスト環境をクラウドに転送すると、状況が変わります。



アプリケーションが実行されているスタックを仮想環境に転送するには何が必要ですか？

既存のハードウェアでOpenStackクラウドを構築しているとします。

最初に考えるべき最も重要なことは、クラウドアーキテクチャです。 多くの側面を考慮する必要があります。 スタックに含まれるレベルが多いほど、各レベルを設計するときに注意する必要があります。

単一の正しいクラウドテスト環境の設計スキームはありませんが、役立つ可能性のある設計のヒントがいくつかあります。

まず、クラウドの高可用性の要件は主要な要件の1つです。 非常にアクセスしやすいOpenStackクラスターを構築する方法については、 Mirantis OpenStackのHAの実装をご覧ください。



次のポイントは、クラスターのパフォーマンスの問題です。 このトピックでは、OpenStackベースのクラウド環境でコンピューティングパフォーマンスを改善する方法に関する役立つ投稿が役立ちます。

以下のような他の設計上の決定：
•ネットワーク構成
oいくつのネットワークが必要ですか？
o VMトラフィックはどのように転送されますか？
oインターネットアクセスは必要ですか？また、どのように提供されますか？
•OpenStackコンポーネントの構成
oどのコンポーネントをインストールする必要がありますか？
o OpenStackサービスはどこにインストールする必要がありますか （計算ノード、コントローラーノード、その他の専用ノード（データストレージノードなど））。

...ソフトウェアの特性、データ伝送方法、トラフィック制限要件（高帯域幅、低遅延、サービス品質、応答時間など）およびテストプロセス自体に依存します。 次の質問に答えてください。
•運用データはどのようにテスト環境にコピーされますか？
•テスト環境はどのくらいの頻度で作成または更新されますか？

その結果、出力は設計ソリューションに変換できる要件のリストになります。

仮想マシンイメージの準備

アーキテクチャを決定したら、仮想マシンのイメージの準備を開始できます。 以下を作成する必要があります。
•vCPU、vRAM、vHDD、ゲストOS、およびインストールおよび構成されているいくつかの固定プログラム用のユニバーサルイメージのセット。
•特定のvCPU、vRAM、vHDD、インストールおよび構成されている可能性のある通常とは異なるオペレーティングシステムおよび特別なプログラムのイメージのセット。
ここでの目標は、さまざまなテスト環境を迅速に展開するためのイメージのライブラリを作成することです。そのコンポーネントは厳密に構成され、事前に文書化およびテストされています。

温めて！

テスト環境の展開を保証する方法は？

Heatは、クラウドアプリケーションのオーケストレーションを担当するOpenStackコンポーネントです。



Heatはテンプレートエンジンを提供します。 Heatテンプレートは、クラウドアプリケーションのインフラストラクチャ、たとえば、サーバーのセット、それらの間のボリュームと接続、ネットワーク設定を記述します。 フローティングIP、セキュリティグループ、認証設定など。 PuppetやChefなどのツールを使用して、ソフトウェアを自動的に構成できます。

ネットワーク設定と仮想クラスター構成が類似している場合、さまざまなタイプのテスト環境用に1つの一般的なHeatパターンを作成できます。 次に、カスタムHeatテンプレートを使用するか、手動で設定することにより、特定の仮想テスト環境に固有の機能を追加できます。

テスト環境をクラウドに転送すると、テストチームをテスト環境の所有者にすることができます。ITチームの介入なしに、テストチームを作成、削除、管理できます。 一方、ITチームは通常、ハードウェアクラスターとクラウド環境を管理します。

使用例

仮想テスト環境を構築する一般的なアプローチは上記で説明されています。 次に、特定のユースケースを見てみましょう。

同社はWEB用のアプリケーションを開発しています。

アプリケーションは、標準のLAMPサーバーテクノロジースタックを使用します。 作業環境は、VMWareベースのクラウドで実行されていました。 このソリューションは、ライセンス料と使用料が必要なため、比較的高価です。 テスト環境もVMWare上に構築され、ITチームによって管理されました。

会社はいくつかの問題を特定しました。
•テストチームは、オンデマンドでローカルテスト環境を作成できませんでした。
•ITプロフェッショナルは、新しいテスト環境の要求を完了するのに時間がかかりすぎました。
•テスト環境のスケーリングや新しい環境の追加に問題がありました。
•テスト環境の作成、保守、およびスケーリングのコストが高かった（部分的には、VMWareライセンスのコストによる）。

同社は、テスト環境を構築するアプローチを変更したいと考えていました。 新しいソリューションは、次の要件を満たす必要がありました。
•セルフサービスポータルを介してテスト環境を作成および維持する機会をテストエンジニアに提供します。
•テスト環境の迅速な作成と準備。
•拡張が容易で、テスト環境の機能をサポートします。
•ソリューションの総コストが低い。
•作業環境のレプリカはテスターチームだけでなく有用であるため、製品コンサルタントなどの他のユーザーがセルフサービスポータルを介してデモ環境を作成できるようにします。
•さまざまなテスト環境の分離。
•ITチームに、テスターの各チームのリソース消費を制御する機能を提供します。

ソリューションアーキテクトは、OpenStackベースのクラウドにテスト環境を構築することを提案しました。 その結果、コントローラノードの可用性が高い10〜20個のノードで構成されるOpenStackクラスターがデプロイされました。

結果のソリューションには、次の利点があります。
•分離を確保するために、各テスト環境は別々のテナントで動作します。 たとえば、テスターチーム用のプロジェクト、コンサルタントチーム用のプロジェクトなどです。 （ docs.openstack.org/trunk/openstack-ops/content/projects_users.htmlを参照）
•Heatテンプレートを使用すると、新しい環境をすばやく作成できます。 テストチームは、独自に新しいHeatテンプレートを作成できます。
•セルフサービスは、OpenStack CLI / Horizo​​nおよびHeatパターンを介して提供されます。
•OpenStackベースのソリューションの総コストはより低いです。 会社はライセンス料を支払う必要がなく、安価なソフトウェアと汎用ハードウェアを使用できます。
•テスターはテスト環境を所有しています。 必要に応じて、いつでも環境を作成および削除できます。
•OpenStackでは、ITスタッフがプロジェクトごとにクォータを設定できます。 Ceilometerと呼ばれるOpenStackコンポーネントを使用して、クラウドインスタンスによるリソース消費を監視することもできます。

おわりに

テスト環境を構築するプロセスは非常に複雑になる場合があります。 どのソフトウェアがテストされているかを考慮することは非常に重要です。 使用されているテスト方法。 テスト環境のサポートなどを担当します。

もちろん、すべてのテスト環境をOpenStackに基づいて構築できるわけではなく、すべてのテストをクラウドで実行できるわけでもありません。 OpenStackは、他のクラウドオペレーティングシステムと同様に、制限と問題があります。 たとえば、パフォーマンステストを設計および実行するときは、それが課すパフォーマンスの制限を考慮する必要があります。

ハードウェア固有のテスト（フェールオーバーテストや復旧テストなど）は、仮想環境では実行できません。 もちろん、この場合でも、ハードウェアエミュレータを使用できますが、結果はどの程度適切ですか？

テスト環境をOpenStackベースのクラウドに移行するかどうかを決定する際には、各ステップを慎重に計画することが重要です。

英語のオリジナル記事。