OmniLab ATS のクラウド オーケストレーション

Cloud Orchestration アプリは、特に ARM ベースの仮想デバイス(CHD)の Cuttlefish インスタンスを管理するための、高性能でスケーラブルな方法を提供します。OmniLab ATS は、仮想デバイスでテストを実行できるように、クラウド オーケストレーションをサポートしています。仮想デバイスを使用する前に、OmniLab Android Test Station に沿って OmniLab ATS をインストールしてください。

概要

Cloud Orchestration を使用すると、OmniLab ATS は Cuttlefish インスタンスの管理を専用の Cloud Orchestrator サービスに委任できます。このアプローチは、既存のローカル モードとリモートモードに比べて、次のようなメリットがあります。また、使い慣れたユーザー エクスペリエンスを維持できます。

  • 並列インスタンスの起動: 複数の Cuttlefish インスタンスを同時に起動できるため、テスト開始前のオーバーヘッド時間を大幅に短縮できます。
  • スケーラビリティ: 大規模なテスト環境に適しています。
  • リソースの分離: テスト実行環境(ATS ワーカー)をデバイス エミュレーション環境から切り離します。

前提条件

  • Docker を実行できるホストマシン
  • Cuttlefish オーケストレーション Docker イメージへのアクセス

Cloud Orchestrator サービスを設定する

Cloud Orchestrator サービスは、Cuttlefish インスタンスのライフサイクルを管理します。このサービスはさまざまな環境にデプロイでき、x86 と ARM の両方のアーキテクチャをサポートしています。

  • ATS ワーカーと同じホスト: 同じマシン上の Docker コンテナで実行されます
  • 別のマシン: Docker を実行できるオンプレミス サーバーで実行されます。
  • クラウド インスタンス: クラウド環境(Google Compute Engine など)の仮想マシンで実行されます。

サービスをインストールして設定する

Cloud Android Orchestration の README に沿ってサービスを起動します。

認証と権限

Cloud Orchestrator サービスがリモートマシンで実行されている場合は、ATS ワーカーホストに HTTP リクエストでアクセスするために必要な権限があることを確認します。HTTP 接続が許可されていない場合は、SSH ポート転送の設定が必要になることがあります。詳細については、クラウド オーケストレーターを試すをご覧ください。

想定される状態

Cloud Orchestrator サービスが正常に起動されると、HTTP を使用してアクセスできるようになります。API をクエリして、状態を確認できます。

  • サービスに ping を送信する: OmniLab ATS ワーカーホストからサービス エンドポイントに到達できるはずです。たとえば、curl -I http://localhost:8080/v1/zones/local/hosts を実行すると、成功した HTTP レスポンス(HTTP/1.1 200 OK または /username にリダイレクトする 302 Found)が返され、サービスがアクティブで到達可能であることが確認されます。

Cloud オーケストレーション用に OmniLab ATS を構成する

OmniLab ATS を起動する前に、OmniLab ATS ワーカーホスト上のすべての Cuttlefish インスタンスが停止していることを確認します。OmniLab ATS はテストサイクル中に仮想デバイスの起動と停止を自動的に行うため、既存の Cuttlefish インスタンスがあると、OmniLab ATS によって管理されているインスタンスと競合します。Cuttlefish インスタンスの停止について詳しくは、Cuttlefish を停止するをご覧ください。

OmniLab ATS で Cloud Orchestration を有効にするには、OmniLab ATS の起動時に特定のフラグを渡します。

mtt start --max_orchestration_virtual_devices N \
  --orchestration_service_url=http://HOST:PORT \
  --use_host_network \
  --force_ats_version 2 \
  --force_update
  • --max_orchestration_virtual_devices: OmniLab ATS が同時に割り当てることができる、Cloud Orchestrator によって管理される仮想デバイスの最大数を設定します。デフォルト値は 0 です。
  • --orchestration_service_url: Cloud Orchestration サービスがリッスンしている URL を指定します(例: http://localhost:8080)。
  • --use_host_network: コンテナにホストのネットワーク名前空間を使用します。これは、Cloud Orchestration サービスにアクセスするために必要です。
  • --force_ats_version 2: Cloud Orchestration に必要な OmniLab ATS 2.0 の使用を強制します。詳しくは、OmniLab ATS 2.0 アップグレード ガイドをご覧ください。
  • --force_update: ATS 2.0 と Cloud Orchestration の機能を備えた最新のコンテナ ビルドをプルします。

仮想デバイスのハードウェア仕様を構成する(省略可)

デフォルトでは、クラウド オーケストレーションされた各仮想デバイス インスタンスには、4 個の CPU、8,192 MB(8 GB)の RAM、通常の SIM、接続された SD カード イメージがプロビジョニングされます。Cloud Orchestration で OmniLab ATS を起動する際に、--extra_docker_args を使用して mtt start コマンドで対応するラボサーバー フラグを渡すことで、これらのデフォルトをオーバーライドできます。各フラグは独立しています。変更するフラグのみを渡し、残りのフラグは省略してデフォルト値を保持します。

  • --android_jit_emulator_cpus: 各仮想デバイス インスタンスの CPU コア数を設定します。設定されていない場合、または 0 の場合、デフォルトは 4 です。
  • --android_jit_emulator_memory_mb: 各仮想デバイス インスタンスのメモリをメガバイト(MB)単位で設定します。設定されていない場合、または 0 の場合、デフォルトは 8192 です。
  • --android_jit_emulator_modem_simulator_sim_type: モデム シミュレータが各仮想デバイス インスタンスでエミュレートする SIM タイプを設定します。通常の SIM の場合は 1、携帯通信会社の特権を持つ SIM の場合は 2CtsCarrierApiTestCases で必要)。設定されていない場合、または 0 の場合は、デフォルトで 1 になります。
  • --android_jit_emulator_use_sdcard: 空の SD カードイメージを作成して各仮想デバイス インスタンスに接続するかどうかを設定します(true または false)。デフォルトは true です。SD カードの作成を無効にするには、false に設定します。

次の例では、4 つのデフォルトすべてをオーバーライドしています。

mtt start --max_orchestration_virtual_devices N \
  --orchestration_service_url=http://HOST:PORT \
  --use_host_network \
  --force_ats_version 2 \
  --force_update \
  --extra_docker_args '-e LAB_SERVER_OPTS="--android_jit_emulator_cpus=CPUS --android_jit_emulator_memory_mb=MEMORY_MB --android_jit_emulator_modem_simulator_sim_type=SIM_TYPE --android_jit_emulator_use_sdcard=USE_SDCARD"'

クラウド オーケストレーション デバイスでテストを実行する

このセクションでは、クラウド オーケストレーションされた仮想デバイスでテストを実行する手順を説明します。

デバイスの選択

OmniLab ATS のデバイスリストには、実際のシリアル番号ではなく、プレースホルダとしてクラウド オーケストレーションされた仮想デバイスが表示されます。プレースホルダは HOSTNAME:PORT 形式で表示されます(thehostname:6520 など)。状態は [Available] または [Allocated] のいずれかです。[Available] の状態にあるプレースホルダは、仮想デバイスが実行されていないため、テストに割り当てることができることを示します。

[Cloud-Orchestrated Devices] を選択します

図 1. クラウド オーケストレーションされた仮想デバイスを選択する。

デバイス アクションを追加する

これらのデバイスでテストがスケジュールされると、ATS はテストサイクル中に Cuttlefish インスタンスをプロビジョニングして管理するために必要なデバイス アクションを自動的に追加します。

自動デバイス アクション

図 2. デバイスの自動アクション。

テストリソースを設定する

テストをスケジュール設定するときは、必要なテストリソースを指定する必要があります。[テストリソースを設定] セクションで、アップロードしたファイルが正しいリソース名にマッピングされていることを確認します。

  • ホストツール パッケージ(cvd-host_package.tar.gz など)を cvd_host_package という名前にマッピングします。
  • デバイス イメージの zip を名前 cvd_device_image にマッピングします。

クラウド オーケストレーションのテストリソース

図 3. テストリソースをマッピングします。

テスト実行とログを表示する

テストが完了すると、出力ファイル セクションでログを表示できます。Cloud Orchestrator で管理されるインスタンスに対して収集される特定のログは次のとおりです。

  • launcher.log: Cuttlefish ランチャーからのログ
  • kernel.log: 標準の Android カーネルログ