Déployer une solution dans Opérations Azure IoT préversion

Important

Opérations Azure IoT (préversion) – activé parc Azure Arc est actuellement en PRÉVERSION. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Utilisez Azure IoT Orchestrator préversion pour déployer, configurer et mettre à jour les composants de votre scénario d’informatique en périphérie Opérations Azure IoT Préversion.

Orchestrator est un service qui gère les charges de travail d’application sur les clusters Kubernetes qui ont été activés par Arc. Il utilise des outils existants tels que Helm, Kubectl et Arc pour obtenir l’état souhaité sur le cluster cible. Orchestrator utilise un modèle d’extensibilité appelé fournisseurs, ce qui lui permet de prendre en charge les déploiements et la configuration sur un large éventail de plateformes de système d’exploitation et de mécanismes de déploiement. Orchestrator fournit également des fonctionnalités de rapprochement et de création de rapports d’état pour garantir que l’état souhaité est conservé.

Constructions

Plusieurs constructions vous aident à gérer le déploiement et la configuration des charges de travail d’application.

Manifestes

Les trois types de manifestes (solution, cible et instance) fonctionnent ensemble pour décrire l’état souhaité d’un cluster. Pour plus d’informations sur la création des fichiers manifestes, consultez Manifestes.

Solution

Une solution est un modèle qui définit une charge de travail d’application qui peut être déployée sur une ou plusieurs cibles. Une solution décrit les composants d’application. Les composants d’application sont des ressources que vous souhaitez déployer sur le cluster cible et qui utilisent les composants infrastructurels définis dans le manifeste cible, tels que les scripts PowerShell ou les pipelines de processeur de données Azure IoT préversion.

Cible

Une cible est un environnement de déploiement spécifique, tel qu’un cluster Kubernetes ou un appareil de périphérie. Elle décrit les composants infrastructurels, qui sont des composants qui ont été installés sur un appareil, comme PowerShell ou Azure IoT Data Processor. Chaque cible a ses propres paramètres de configuration qui peuvent être personnalisés pour répondre aux besoins spécifiques de l’environnement de déploiement. Une cible spécifie également des liaisons de fournisseur qui définissent les types de ressources à gérer sur la cible (par exemple, Helm, les scripts PowerShell, les CR ou les scripts Bash).

Instance

Une instance est un déploiement spécifique d’une solution vers une cible. Elle peut être considérée comme une instance d’une solution.

Fournisseurs

Les fournisseurs sont un modèle d’extensibilité qui permet à Orchestrator de prendre en charge les déploiements et la configuration sur un large éventail de plateformes de système d’exploitation et de mécanismes de déploiement. Les fournisseurs sont responsables de l’exécution des actions requises pour atteindre l’état souhaité d’une ressource. Orchestrator prend en charge plusieurs outils standard tels que Helm, Kubectl et Arc. Pour plus d’informations, consultez Fournisseurs.

Rapprochement

Un processus de rapprochement garantit que l’état souhaité d’une ressource est conservé. Le gestionnaire de ressources sur le cluster compare l’état actuel de toutes les ressources par rapport à l’état souhaité spécifié dans le manifeste de solution. En cas d’incohérence, le gestionnaire de ressources appelle le fournisseur approprié sur le cluster pour mettre à jour la ressource à l’état souhaité.

Si le gestionnaire de ressources ne peut pas rapprocher l’état souhaité, ce déploiement est signalé en tant qu’échec et le cluster reste sur l’état réussi précédent.

Par défaut, le gestionnaire des ressources déclenche le rapprochement toutes les trois minutes pour vérifier les mises à jour à l’état souhaité. Vous pouvez configurer cette stratégie d’intervalle d’interrogation et la personnaliser pour les scénarios nécessitant des vérifications plus fréquentes ou ceux qui requièrent des vérifications moins fréquentes pour réduire la surcharge.

Création de rapports d’état

Les fonctionnalités de création de rapports d’état garantissent que l’état souhaité est conservé. Lorsque le gestionnaire de ressources sur le cluster détecte un échec pour un composant unique, il considère que l’ensemble du déploiement est un échec et retente le déploiement. Si un composant particulier échoue à nouveau, le déploiement est considéré comme ayant échoué à nouveau et en fonction d’un paramètre de rapprochement configurable, le gestionnaire de ressources arrête la recherche d’état et met à jour l’instance avec l’état échoué. Cet état d’échec (ou de réussite) est synchronisé avec le cloud et mis à disposition via les API du fournisseur de ressources. Les flux de travail d’expérience peuvent ensuite être générés pour avertir le client, tenter de réessayer ou pour déployer une version précédente de la solution.