Orkiestracja w OmniLab ATS

Aplikacja Cloud Orchestration zapewnia wydajny i skalowalny sposób zarządzania instancjami Cuttlefish, zwłaszcza w przypadku wirtualnych urządzeń opartych na architekturze ARM (CHD). OmniLab ATS obsługuje orkiestrację w chmurze, dzięki czemu możesz przeprowadzać testy na urządzeniach wirtualnych. Zanim zaczniesz korzystać z urządzeń wirtualnych, zainstaluj OmniLab ATS, postępując zgodnie z instrukcjami w artykule OmniLab Android Test Station.

Przegląd

Orkiestracja w chmurze umożliwia OmniLab ATS delegowanie zarządzania instancjami Cuttlefish do dedykowanej usługi Cloud Orchestrator. To podejście ma kilka zalet w porównaniu z obecnymi trybami lokalnym i zdalnym, a jednocześnie zapewnia użytkownikom znane im funkcje:

  • Równoległe uruchamianie instancji: umożliwia jednoczesne uruchamianie wielu instancji Cuttlefish, co znacznie skraca czas przygotowania przed rozpoczęciem testów.
  • Skalowalność: odpowiednia dla środowisk testowych na dużą skalę.
  • Izolacja zasobów: oddziela środowisko wykonawcze testu (proces roboczy ATS) od środowiska emulacji urządzenia.

Wymagania wstępne

  • maszyna hosta, na której można uruchomić Dockera;
  • Dostęp do obrazów Dockera do orkiestracji Cuttlefish

Konfigurowanie usługi Cloud Orchestrator

Usługa Cloud Orchestrator zarządza cyklem życia instancji Cuttlefish. Usługę możesz wdrożyć w różnych środowiskach. Obsługuje ona architektury x86 i ARM:

  • Ten sam host co proces ATS: działa w kontenerze Docker na tym samym komputerze.
  • Oddzielne urządzenie: działa na serwerze lokalnym, który może uruchamiać Dockera.
  • Instancja w chmurze: działa na maszynie wirtualnej w środowisku chmurowym, np. w Google Compute Engine.

Instalowanie i konfigurowanie usługi

Aby uruchomić usługę, postępuj zgodnie z instrukcjami w pliku README dotyczącym orkiestracji Cloud Android.

Uwierzytelnianie i uprawnienia

Jeśli usługa Cloud Orchestrator działa na komputerze zdalnym, upewnij się, że host procesu roboczego ATS ma niezbędne uprawnienia dostępu do niej za pomocą żądań HTTP. Jeśli połączenie HTTP nie jest dozwolone, może być konieczne skonfigurowanie przekierowania portu SSH. Więcej informacji znajdziesz w artykule Wypróbuj narzędzie do orkiestracji w chmurze.

Oczekiwany stan

Po pomyślnym uruchomieniu usługi Cloud Orchestrator powinna być ona dostępna za pomocą protokołu HTTP. Jego stan możesz sprawdzić, wysyłając zapytanie do interfejsu API:

  • Pingowanie usługi: punkt końcowy usługi powinien być dostępny z hosta instancji roboczej OmniLab ATS. Na przykład uruchomienie polecenia curl -I http://localhost:8080/v1/zones/local/hosts powinno zwrócić prawidłową odpowiedź HTTP (HTTP/1.1 200 OK lub przekierowanie 302 Found do /username), co potwierdzi, że usługa jest aktywna i dostępna.

Konfigurowanie OmniLab ATS na potrzeby Cloud Orchestration

Przed rozpoczęciem testów OmniLab ATS upewnij się, że wszystkie instancje Cuttlefish na hoście roboczym OmniLab ATS są zatrzymane. OmniLab ATS automatycznie uruchamia i zatrzymuje urządzenia wirtualne podczas cyklu testowego, a istniejące instancje Cuttlefish powodują konflikt z instancjami zarządzanymi przez OmniLab ATS. Szczegółowe informacje o zatrzymywaniu instancji Cuttlefish znajdziesz w sekcji Zatrzymywanie Cuttlefish.

Aby włączyć Cloud Orchestration w OmniLab ATS, przekaż określone flagi podczas uruchamiania 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: określa maksymalną liczbę urządzeń wirtualnych zarządzanych przez Cloud Orchestrator, które OmniLab ATS może jednocześnie przydzielać. Domyślna liczba to 0.
  • --orchestration_service_url: określa adres URL, na którym usługa Cloud Orchestration nasłuchuje, np. http://localhost:8080.
  • --use_host_network: używa przestrzeni nazw sieci hosta dla kontenera. Jest to wymagane do uzyskania dostępu do usługi Cloud Orchestration.
  • --force_ats_version 2: wymusza użycie OmniLab ATS 2.0, które jest wymagane w przypadku Cloud Orchestration. Więcej informacji znajdziesz w przewodniku po uaktualnianiu OmniLab ATS 2.0.
  • --force_update: pobiera najnowszą kompilację kontenera z funkcjami ATS 2.0 i Cloud Orchestration.

Konfigurowanie specyfikacji sprzętowych urządzenia wirtualnego (opcjonalnie)

Domyślnie każda instancja urządzenia wirtualnego zarządzana w chmurze jest wyposażona w 4 procesory, 8192 MB (8 GB) pamięci RAM, zwykłą kartę SIM i dołączony obraz karty SD. Podczas uruchamiania OmniLab ATS z Cloud Orchestration możesz zastąpić dowolne z tych ustawień domyślnych, przekazując odpowiednią flagę serwera laboratorium w poleceniu mtt start za pomocą --extra_docker_args. Każda flaga jest niezależna: podaj tylko te flagi, które chcesz zmienić, a pozostałe pomiń, aby zachować ich wartości domyślne.

  • --android_jit_emulator_cpus: określa liczbę rdzeni procesora dla każdej instancji urządzenia wirtualnego. Jeśli nie jest ustawiona lub ma wartość 0, przyjmuje domyślnie wartość 4.
  • --android_jit_emulator_memory_mb: ustawia pamięć w megabajtach (MB) dla każdej instancji urządzenia wirtualnego. Jeśli nie jest ustawiona lub ma wartość 0, przyjmuje domyślnie wartość 8192.
  • --android_jit_emulator_modem_simulator_sim_type: określa typ karty SIM, który symulator modemu emuluje dla każdej instancji urządzenia wirtualnego: 1 w przypadku zwykłej karty SIM lub 2 w przypadku karty SIM z uprawnieniami operatora (wymagane przez CtsCarrierApiTestCases). Jeśli nie jest ustawiony lub ma wartość 0, domyślnie przyjmuje wartość 1.
  • --android_jit_emulator_use_sdcard: określa, czy ma zostać utworzony pusty obraz karty SD i dołączony do każdej instancji urządzenia wirtualnego (true lub false). Domyślnie ustawiona jest wartość true. Ustaw na false, aby wyłączyć tworzenie karty SD.

Poniższy przykład zastępuje wszystkie 4 wartości domyślne:

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"'

Przeprowadzanie testu na urządzeniach zarządzanych w chmurze

W tej sekcji opisujemy, jak przeprowadzić test na wirtualnych urządzeniach zarządzanych w chmurze.

wybranych urządzeń

Na liście urządzeń OmniLab ATS wyświetla wirtualne urządzenia zarządzane w chmurze jako symbole zastępcze zamiast ich rzeczywistych numerów seryjnych. Symbole zastępcze są wyświetlane w formacie HOSTNAME:PORT (np. thehostname:6520). Stany to Dostępny lub Przydzielony. Symbol zastępczy w stanie Dostępny oznacza, że urządzenie wirtualne nie jest uruchomione i można je przydzielić do testu.

Wybierz Urządzenia zarządzane w chmurze

Rysunek 1. Wybieranie wirtualnych urządzeń zarządzanych w chmurze.

Dodawanie działań na urządzeniu

Gdy na tych urządzeniach zaplanowany jest test, ATS automatycznie dodaje wymagane działania na urządzeniu, aby w trakcie cyklu testowego udostępniać instancje Cuttlefish i nimi zarządzać.

Automatyczne działania na urządzeniu

Rysunek 2. automatyczne działania na urządzeniu;

Ustawianie zasobów testowych

Podczas planowania testu musisz podać wymagane zasoby testowe. W sekcji Ustaw zasoby testu dopilnuj, aby przesłane pliki były mapowane na prawidłowe nazwy zasobów:

  • Przypisz pakiet narzędzi gospodarza, np. cvd-host_package.tar.gz, do nazwy cvd_host_package.
  • Przypisz plik ZIP z obrazem urządzenia do nazwy cvd_device_image.

Zasoby testowe na potrzeby orkiestracji w chmurze

Rysunek 3. Mapowanie zasobów testowych.

Wyświetlanie uruchomień testów i logów

Po zakończeniu testu możesz wyświetlić logi w sekcji plików wyjściowych. W przypadku instancji zarządzanych przez Cloud Orchestrator zbierane są te logi:

  • launcher.log: dzienniki z launchera Cuttlefish,
  • kernel.log: standardowy dziennik jądra Androida