Orchestration du cloud dans OmniLab ATS

L'application Cloud Orchestration offre un moyen évolutif et performant de gérer les instances Cuttlefish, en particulier pour les appareils virtuels basés sur ARM (CHD). OmniLab ATS est compatible avec Cloud Orchestration, ce qui vous permet d'exécuter des tests sur des appareils virtuels. Avant de commencer à utiliser des appareils virtuels, suivez OmniLab Android Test Station pour installer OmniLab ATS.

Présentation

L'orchestration du cloud permet à OmniLab ATS de déléguer la gestion des instances Cuttlefish à un service Cloud Orchestrator dédié. Cette approche présente plusieurs avantages par rapport aux modes local et à distance existants, tout en préservant une expérience utilisateur familière :

  • Lancement d'instances en parallèle : permet de lancer plusieurs instances Cuttlefish simultanément, ce qui réduit considérablement le temps d'attente avant le début des tests.
  • Évolutivité : convient aux environnements de test à grande échelle.
  • Isolation des ressources : dissocie l'environnement d'exécution des tests (worker ATS) de l'environnement d'émulation d'appareil.

Prérequis

  • Une machine hôte capable d'exécuter Docker
  • Accès aux images Docker d'orchestration Cuttlefish

Configurer le service Cloud Orchestrator

Le service Cloud Orchestrator gère le cycle de vie des instances Cuttlefish. Vous pouvez déployer le service dans différents environnements. Il est compatible avec les architectures x86 et ARM :

  • Même hôte que le nœud de calcul ATS : s'exécute dans un conteneur Docker sur la même machine
  • Machine distincte : s'exécute sur un serveur sur site capable d'exécuter Docker
  • Instance cloud : s'exécute sur une machine virtuelle dans un environnement cloud, par exemple Google Compute Engine.

Installer et configurer le service

Suivez le fichier README de l'orchestration Cloud Android pour lancer le service.

Authentification et autorisations

Si le service Cloud Orchestrator s'exécute sur une machine distante, assurez-vous que l'hôte du worker ATS dispose des autorisations nécessaires pour y accéder via des requêtes HTTP. Si la connexion HTTP n'est pas autorisée, vous devrez peut-être configurer le transfert de port SSH. Pour en savoir plus, consultez Essayer l'orchestrateur cloud.

État attendu

Une fois le service Cloud Orchestrator démarré, il doit être accessible via HTTP. Vous pouvez vérifier son état en interrogeant son API :

  • Envoyez un ping au service : vous devriez pouvoir accéder au point de terminaison du service depuis l'hôte worker OmniLab ATS. Par exemple, l'exécution de curl -I http://localhost:8080/v1/zones/local/hosts doit renvoyer une réponse HTTP réussie (HTTP/1.1 200 OK ou une redirection 302 Found vers /username), ce qui confirme que le service est actif et accessible.

Configurer OmniLab ATS pour l'orchestration du cloud

Avant de démarrer OmniLab ATS, assurez-vous que toutes les instances Cuttlefish sur l'hôte de nœud de calcul OmniLab ATS sont arrêtées. OmniLab ATS lance et arrête automatiquement les appareils virtuels pendant le cycle de test. Les instances Cuttlefish existantes sont en conflit avec les instances gérées par OmniLab ATS. Pour savoir comment arrêter les instances Cuttlefish, consultez Arrêter Cuttlefish.

Pour activer Cloud Orchestration dans OmniLab ATS, transmettez des indicateurs spécifiques lorsque vous démarrez 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 : définit le nombre maximal d'appareils virtuels gérés par Cloud Orchestrator qu'OmniLab ATS peut allouer simultanément. Le nombre par défaut est 0.
  • --orchestration_service_url : spécifie l'URL où le service Cloud Orchestration est à l'écoute, par exemple http://localhost:8080.
  • --use_host_network : utilise l'espace de noms réseau de l'hôte pour le conteneur. Cette autorisation est requise pour accéder au service Cloud Orchestration.
  • --force_ats_version 2 : force l'utilisation d'OmniLab ATS 2.0, qui est requis pour l'orchestration du cloud. Pour en savoir plus, consultez le guide de mise à niveau d'OmniLab ATS 2.0.
  • --force_update : extrait la dernière version du conteneur avec les fonctionnalités ATS 2.0 et Cloud Orchestration.

Configurer les spécifications matérielles de l'appareil virtuel (facultatif)

Par défaut, chaque instance d'appareil virtuel orchestrée dans le cloud est provisionnée avec quatre processeurs, 8 192 Mo (8 Go) de RAM, une carte SIM standard et une image de carte SD associée. Lorsque vous lancez OmniLab ATS avec Cloud Orchestration, vous pouvez remplacer l'une de ces valeurs par défaut en transmettant l'indicateur de serveur de laboratoire correspondant dans la commande mtt start à l'aide de --extra_docker_args. Chaque indicateur est indépendant : ne transmettez que les indicateurs que vous souhaitez modifier et omettez les autres pour conserver leurs valeurs par défaut.

  • --android_jit_emulator_cpus : définit le nombre de cœurs de processeur pour chaque instance d'appareil virtuel. Si ce champ n'est pas défini ou est défini sur 0, la valeur par défaut est 4.
  • --android_jit_emulator_memory_mb : définit la mémoire en mégaoctets (Mo) pour chaque instance d'appareil virtuel. Si ce champ n'est pas défini ou est défini sur 0, la valeur par défaut est 8192.
  • --android_jit_emulator_modem_simulator_sim_type : définit le type de carte SIM que le simulateur de modem émule pour chaque instance d'appareil virtuel : 1 pour une carte SIM standard ou 2 pour une carte SIM avec des droits d'accès à l'opérateur (requis par CtsCarrierApiTestCases). Si la valeur n'est pas définie ou est égale à 0, la valeur par défaut est 1.
  • --android_jit_emulator_use_sdcard : indique s'il faut créer une image de carte SD vide et l'associer à chaque instance d'appareil virtuel (true ou false). La valeur par défaut est true. Définissez la valeur sur false pour désactiver la création de cartes SD.

L'exemple suivant remplace les quatre valeurs par défaut :

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

Exécuter un test avec des appareils orchestrés dans le cloud

Cette section décrit la procédure à suivre pour exécuter un test sur des appareils virtuels orchestrés dans le cloud.

Il n'est possible qu'avec certains appareils.

Dans la liste des appareils, OmniLab ATS affiche les appareils virtuels orchestrés dans le cloud sous forme d'espaces réservés au lieu de leurs numéros de série réels. Les espaces réservés sont affichés au format HOSTNAME:PORT (par exemple, thehostname:6520). Les états sont Disponible ou Attribué. Un espace réservé dans l'état Available (Disponible) indique que l'appareil virtuel n'est pas en cours d'exécution et peut être alloué au test.

Sélectionnez "Appareils orchestrés dans le cloud".

Figure 1. Sélection d'appareils virtuels orchestrés dans le cloud.

Ajouter des actions pour un appareil

Lorsqu'un test est planifié sur ces appareils, ATS ajoute automatiquement les actions d'appareil requises pour provisionner et gérer les instances Cuttlefish pendant le cycle de test.

Actions automatiques sur les appareils

Figure 2. Actions automatiques sur les appareils.

Définir des ressources de test

Lorsque vous planifiez un test, vous devez fournir les ressources de test requises. Dans la section Définir les ressources de test, assurez-vous de mapper les fichiers importés aux noms de ressources appropriés :

  • Mappez le package d'outils hôtes, par exemple cvd-host_package.tar.gz, au nom cvd_host_package.
  • Associez le fichier ZIP de l'image de l'appareil au nom cvd_device_image.

Ressources de test pour l'orchestration du cloud

Figure 3. Mappage des ressources de test.

Afficher les exécutions de test et les journaux

Une fois le test terminé, vous pouvez afficher les journaux dans la section des fichiers de sortie. Voici les journaux spécifiques collectés pour les instances gérées par Cloud Orchestrator :

  • launcher.log : journaux du lanceur Cuttlefish
  • kernel.log : journal du noyau Android standard