Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Conseil / Astuce
Ce contenu est un extrait de l’eBook, Architecting Cloud Native .NET Applications pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.
L’application eShopOnContainers peut être déployée sur différentes plateformes Azure. L’approche recommandée consiste à déployer l’application sur Azure Kubernetes Services (AKS). Helm, un outil de déploiement Kubernetes, est disponible pour réduire la complexité du déploiement. Si vous le souhaitez, les développeurs peuvent implémenter Azure Dev Spaces pour Kubernetes afin de simplifier leur processus de développement.
Azure Kubernetes Service
Pour héberger eShop dans AKS, la première étape consiste à créer un cluster AKS. Pour ce faire, vous pouvez utiliser le portail Azure, qui vous guidera tout au long des étapes requises. Vous pouvez également créer un cluster à partir d’Azure CLI, en prenant soin d’activer Role-Based contrôle d’accès (RBAC) et le routage des applications. La documentation eShopOnContainers détaille les étapes de création de votre propre cluster AKS. Une fois créé, vous pouvez accéder au cluster et le gérer à partir du tableau de bord Kubernetes.
Vous pouvez maintenant déployer l’application eShop sur le cluster à l’aide de Helm.
Déploiement sur Azure Kubernetes Service à l’aide de Helm
Helm est un outil de gestionnaire de package d’application qui fonctionne directement avec Kubernetes. Il vous aide à définir, installer et mettre à niveau des applications Kubernetes. Bien que des applications simples puissent être déployées sur AKS avec des scripts CLI personnalisés ou des fichiers de déploiement simples, les applications complexes peuvent contenir de nombreux objets Kubernetes et tirer parti de Helm.
À l’aide de Helm, les applications incluent des fichiers de configuration textuels, appelés graphiques Helm, qui décrivent de manière déclarative l’application et la configuration dans les packages Helm. Les graphiques utilisent des fichiers au format YAML standard pour décrire un ensemble associé de ressources Kubernetes. Ils sont versionnés en même temps que le code d’application qu’ils décrivent. Les graphiques Helm vont de simples à complexes en fonction des exigences de l’installation qu’ils décrivent.
Helm est composé d’un outil client en ligne de commande, qui consomme des graphiques Helm et lance des commandes sur un composant serveur nommé Tiller. Tiller communique avec l’API Kubernetes pour garantir l’approvisionnement correct de vos charges de travail conteneurisées. Helm est géré par cloud-native Computing Foundation.
Le fichier yaml suivant présente un modèle Helm :
apiVersion: v1
kind: Service
metadata:
name: {{ .Values.app.svc.marketing }}
labels:
app: {{ template "marketing-api.name" . }}
chart: {{ template "marketing-api.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
spec:
type: {{ .Values.service.type }}
ports:
- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
selector:
app: {{ template "marketing-api.name" . }}
release: {{ .Release.Name }}
Notez comment le modèle décrit un ensemble dynamique de paires clé/valeur. Lorsque le modèle est appelé, les valeurs placées entre accolades sont extraites d’autres fichiers de configuration yaml.
Vous trouverez les graphiques Helm d’eShopOnContainers dans le dossier /k8s/helm. La figure 2-6 montre comment les différents composants de l’application sont organisés dans une structure de dossiers utilisée par helm pour définir et gérer des déploiements.
Figure 2-6. Dossier helm d’eShopOnContainers.
Chaque composant individuel est installé à l’aide d’une helm install commande. eShop comprend un script « deploy-all » qui effectue une boucle et installe les composants à l’aide de leurs graphiques Helm respectifs. Le résultat est un processus reproductible, versionné avec l’application dans le contrôle de code source, que toute personne de l’équipe peut déployer sur un cluster AKS avec une commande de script en une seule ligne.
Remarque
La version 3 de Helm supprime officiellement la nécessité du composant serveur Tiller. Pour plus d’informations sur cette amélioration, consultez Pourquoi Tiller est-il absent dans Helm 3?.
Azure Functions et Logic Apps (sans serveur)
L’exemple eShopOnContainers inclut la prise en charge du suivi des campagnes marketing en ligne. Une fonction Azure est utilisée pour suivre les détails de campagne marketing pour un ID de campagne donné. Au lieu de créer un microservice complet, une fonction Azure unique est plus simple et suffisante. Azure Functions dispose d’un modèle de génération et de déploiement simple, en particulier lorsqu’il est configuré pour s’exécuter dans Kubernetes. Le déploiement de la fonction est scripté à l’aide de modèles Azure Resource Manager (ARM) et d’Azure CLI. Ce service de campagne n’est pas orienté client et appelle une seule opération, ce qui en fait un excellent candidat pour Azure Functions. La fonction nécessite une configuration minimale, y compris des données de chaîne de connexion de base de données et des paramètres d’URI de base d’images. Vous configurez Azure Functions dans le portail Azure.