Déployer sur Azure Kubernetes Service

Langue: Français

Cet article a été traduit de l'anglais par IA et peut contenir des erreurs. Vos commentaires nous aideront à l'améliorer.

Ce guide vous explique comment déployer le Serveur auto-géré d'ActivityInfo sur Azure Kubernetes Service (AKS), en s'appuyant sur un disque géré Premium SSD v2. Il est destiné aux professionnels de l'informatique qui sont familiers avec Kubernetes et Microsoft Azure.

Utilisez ce déploiement lorsque la latence réseau d'un système de fichiers partagé limite les performances de la base de données. Consultez Déployer en tant qu'application Web Azure pour une option plus simple qui utilise Azure Files.

Avant de commencer

Le Serveur auto-géré d'ActivityInfo stocke ses données dans une base de données SQLite. Cela détermine l'ensemble du déploiement :

Exécuter une seule réplique. Le serveur est conçu pour évoluer verticalement, et non horizontalement : pour prendre en charge plus d'utilisateurs simultanés, donnez au pod plus de cœurs de processeur et de mémoire plutôt que d'ajouter des répliques.
Utiliser un stockage par blocs durable. Un disque géré Premium SSD v2 offre une latence proche de celle d'un disque local avec des IOPS et un débit configurables. Comme il s'agit d'un disque géré attaché au réseau, ses données sont répliquées dans le backend de stockage et survivent à la perte d'un nœud : le disque se détache et se rattache au nœud où le pod est replanifié.

Ce tutoriel se termine par l'accès au serveur depuis votre propre machine avec la redirection de port. Rendre le serveur disponible pour les utilisateurs via HTTPS est traité dans les liens à la fin de ce guide.

Prérequis

Installez l'Azure CLI et kubectl, puis connectez-vous :

az login

Définir les variables

RESOURCE_GROUP=activityinfo-rg
LOCATION=westeurope
CLUSTER=activityinfo-aks

Créer un cluster

Créez un groupe de ressources et un cluster AKS. Le pilote Azure Disk CSI, qui provisionne les disques gérés, est installé par défaut. Les disques Premium SSD v2 sont zonaux, donc le pool de nœuds doit s'exécuter dans une zone de disponibilité ; --zones 1 le place dans la zone 1. Un seul nœud est suffisant, car ActivityInfo s'exécute en tant que pod unique. Ajoutez un deuxième nœud dans la même zone si vous souhaitez que le pod se replanifie plus rapidement lors d'une panne ou d'une mise à niveau de nœud.

az group create --name $RESOURCE_GROUP --location $LOCATION

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER \
  --node-vm-size Standard_D4s_v5 \
  --node-count 1 \
  --zones 1 \
  --generate-ssh-keys

Connectez kubectl au nouveau cluster :

az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER

Créer une classe de stockage

Les classes de stockage intégrées utilisent d'anciens types de disques. Définissez une classe de stockage pour Premium SSD v2. Enregistrez ce qui suit dans storageclass.yaml :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: activityinfo-premium-v2
provisioner: disk.csi.azure.com
parameters:
  skuName: PremiumV2_LRS
  cachingMode: None
  DiskIOPSReadWrite: "3000"
  DiskMBpsReadWrite: "125"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

WaitForFirstConsumer crée le disque dans la même zone que le pod qui l'utilise. reclaimPolicy: Retain conserve le disque si la revendication est supprimée, afin que la base de données ne soit pas perdue accidentellement. Augmentez DiskIOPSReadWrite et DiskMBpsReadWrite au-dessus de la ligne de base gratuite de 3000 IOPS et 125 Mo/s si votre charge de travail en a besoin. Appliquez-le :

kubectl apply -f storageclass.yaml

Déployer ActivityInfo

Enregistrez ce qui suit dans activityinfo.yaml. Il définit un StatefulSet à réplique unique qui demande un disque Premium SSD v2 à la classe de stockage et le monte sur /data. Le fsGroup dans le contexte de sécurité rend le disque monté accessible en écriture par le conteneur, qui s'exécute en tant qu'utilisateur non root. Un Service expose le conteneur sur le port 80 au sein du cluster.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: activityinfo
spec:
  serviceName: activityinfo
  replicas: 1
  selector:
    matchLabels:
      app: activityinfo
  template:
    metadata:
      labels:
        app: activityinfo
    spec:
      securityContext:
        fsGroup: 1000
      containers:
        - name: activityinfo
          image: activityinfo/activityinfo:5.0.0
          ports:
            - containerPort: 8081
          env:
            - name: ACTIVITYINFO_DATA_DATA_DIRECTORY
              value: /data
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: activityinfo-premium-v2
        resources:
          requests:
            storage: 100Gi
---
apiVersion: v1
kind: Service
metadata:
  name: activityinfo
spec:
  selector:
    app: activityinfo
  ports:
    - port: 80
      targetPort: 8081

Appliquez le manifeste :

kubectl apply -f activityinfo.yaml

Accéder au serveur

Attendez que le pod soit prêt, puis redirigez un port local vers le Service :

kubectl rollout status statefulset/activityinfo
kubectl port-forward service/activityinfo 8081:80

Pendant que la commande s'exécute, ouvrez http://localhost:8081, où vous serez invité à créer le premier compte utilisateur administrateur. Appuyez sur Ctrl+C pour arrêter la redirection.

Exposer le serveur à Internet

La redirection de port ne permet d'accéder au serveur que depuis votre propre machine. Pour rendre ActivityInfo disponible pour les utilisateurs, exposez le Service et servez-le via HTTPS. ActivityInfo peut obtenir et renouveler son propre certificat via Let's Encrypt, ou vous pouvez terminer la connexion TLS au niveau d'un contrôleur d'entrée. Les ressources suivantes décrivent les options :

Configuration SSL automatisée — Prise en charge intégrée de Let's Encrypt par ActivityInfo.
Mode proxy HTTPS — lorsque la connexion TLS est terminée par un contrôleur d'entrée ou un proxy inverse.
Utiliser un équilibreur de charge public dans AKS — exposer le service avec une adresse IP publique.
Entrée NGINX gérée dans AKS — le module complémentaire de routage d'application.

Sauvegarder la base de données

Le disque géré survit à la perte d'un nœud, mais il ne protège pas contre les sinistres, tels qu'un incendie de centre de données. Prenez régulièrement des clichés instantanés de volume du disque, ou copiez le contenu de /data vers un stockage durable tel que Azure Blob Storage de manière planifiée. Conservez les sauvegardes en dehors du cluster afin de pouvoir les restaurer après une perte totale du cluster.

Prochaines étapes

Suivez le guide de Configuration pour configurer la livraison des e-mails et l'authentification unique (Single Sign-On) via l'interface Web.

Élément suivant

Autres plateformes