Démarrage rapide : déployer un cluster de conteneurs SQL Server sur Azure

  • Article

S’applique à :SQL Server - Linux

Ce guide de démarrage rapide montre comment configurer une instance SQL hautement disponible dans un conteneur avec stockage persistant sur Azure Kubernetes Service (AKS) ou Red Hat OpenShift. En cas d’échec de l’instance SQL, l’orchestrateur la recrée automatiquement dans un nouveau pod. Le service de cluster fournit également une résilience contre les défaillances de nœud.

Ce guide de démarrage rapide utilise les outils en ligne de commande suivants pour gérer le cluster.

Service de cluster Outil de ligne de commande
Azure Kubernetes Service (AKS) kubectl (interface CLI Kubernetes)
Azure Red Hat OpenShift oc (interface CLI OpenShift)

Prérequis

Créer un mot de passe AS

  1. Créez un mot de passe AS dans le cluster Kubernetes. Kubernetes peut gérer des informations de configuration sensibles, comme des mots de passe en tant que secrets.

  2. Pour créer un secret dans Kubernetes nommé mssql qui contient la valeur MyC0m9l&xP@ssw0rd pour le MSSQL_SA_PASSWORD, exécutez la commande suivante. N’oubliez pas de choisir votre propre mot de passe complexe :

    Important

    La variable d’environnement SA_PASSWORD est dépréciée. Utilisez MSSQL_SA_PASSWORD à la place.

    kubectl create secret generic mssql --from-literal=MSSQL_SA_PASSWORD="MyC0m9l&xP@ssw0rd"

Créer un stockage

Pour une base de données dans un cluster Kubernetes, vous devez utiliser le stockage persistant. Vous pouvez configurer un volume persistant et une revendication de volume persistant dans le cluster Kubernetes en suivant les étapes ci-dessous :

  1. Créez un manifeste pour définir la classe de stockage et la revendication de volume persistant. Le manifeste spécifie le fournisseur de stockage, les paramètres et la stratégie de récupération. Le cluster Kubernetes utilise ce manifeste pour créer le stockage persistant.

  2. L’exemple de YAML suivant définit une classe de stockage et une revendication de volume persistant. Le fournisseur de classe de stockage est azure-disk, car ce cluster Kubernetes est dans Azure. Le type de compte de stockage est Standard_LRS. La revendication de volume persistant est nommée mssql-data. Les métadonnées de revendication de volume persistant incluent une annotation qui les reconnecte à la classe de stockage.

    kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
     name: azure-disk
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Managed
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mssql-data
  annotations:
    volume.beta.kubernetes.io/storage-class: azure-disk
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

    Enregistrez le fichier (par exemple, pvc.yaml).

  3. Créez la revendication de volume persistant dans Kubernetes, où <path to pvc.yaml file> est l’emplacement où vous avez enregistré le fichier :

    kubectl apply -f <path to pvc.yaml file>

    Le volume persistant est automatiquement créé en tant que compte de stockage Azure et lié à la revendication de volume persistant.

    storageclass "azure-disk" created
persistentvolumeclaim "mssql-data" created

  4. Vérifiez la revendication de volume persistant, où <persistentVolumeClaim> est le nom de la revendication de volume persistant :

    kubectl describe pvc <persistentVolumeClaim>

    Dans l’étape précédente, la revendication de volume persistant est nommée mssql-data. Pour afficher les métadonnées relatives à la revendication de volume persistant, exécutez la commande suivante :

    kubectl describe pvc mssql-data

    Les métadonnées retournées incluent une valeur appelée Volume. Cette valeur correspond au nom du blob.

    Name:          mssql-data
Namespace:     default
StorageClass:  azure-disk
Status:        Bound
Volume:        pvc-d169b88e-f26d-11e7-bc3e-0a58ac1f09a4
Labels:        ‹none>
Annotations:   kubectl.kubernetes.io/last-applied-configuration-{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{"volume.beta.   kubernetes.io/storage-class":"azure-disk"},"name":"mssq1-data...
               pv.kubernetes.io/bind-completed-yes
               pv.kubernetes.io/bound-by-controller=yes
               volume.beta.kubernetes.io/storage-class=azure-disk
               volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/azure-disk
Capacity:      8Gi
Access Modes:  RWO
Events:        <none>

    La valeur de volume correspond à une partie du nom du blob dans l’image suivante du Portail Azure :

    Screenshot of the Azure portal blob name.

  5. Vérifiez le volume persistant.

    kubectl describe pv

    kubectl retourne les métadonnées relatives au volume persistant automatiquement créé et lié à la revendication de volume persistant.

Créer le déploiement

Le conteneur qui héberge l’instance est décrit comme un objet de déploiement Kubernetes. Le déploiement crée un jeu de réplicas. Le jeu de réplicas crée le pod.

Vous créez un manifeste pour décrire le conteneur en fonction de l’image de Docker mssql-server-linux de SQL Server.

  • Le manifeste fait référence à la revendication de volume persistant mssql-server et au secret mssql que vous avez déjà appliqué au cluster Kubernetes.
  • Le manifeste décrit également un service. Ce service est un équilibreur de charge. L’équilibreur de charge garantit que l’adresse IP persiste après la récupération de l’instance.
  • Le manifeste décrit les demandes et les limites de ressources. Celles-ci sont basées sur la configuration système minimale requise.

  1. Créez un manifeste (fichier YAML) pour décrire le déploiement. L’exemple suivant décrit un déploiement, y compris un conteneur basé sur l’image de conteneur SQL Server.

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: mssql-deployment
spec:
  replicas: 1
  selector:
     matchLabels:
       app: mssql
  template:
    metadata:
      labels:
        app: mssql
    spec:
      terminationGracePeriodSeconds: 30
      hostname: mssqlinst
      securityContext:
        fsGroup: 10001
      containers:
      - name: mssql
        image: mcr.microsoft.com/mssql/server:2022-latest
        resources:
          requests:
            memory: "2G"
            cpu: "2000m"
          limits:
            memory: "2G"
            cpu: "2000m"
        ports:
        - containerPort: 1433
        env:
        - name: MSSQL_PID
          value: "Developer"
        - name: ACCEPT_EULA
          value: "Y"
        - name: MSSQL_SA_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mssql
              key: MSSQL_SA_PASSWORD
        volumeMounts:
        - name: mssqldb
          mountPath: /var/opt/mssql
      volumes:
      - name: mssqldb
        persistentVolumeClaim:
          claimName: mssql-data
---
apiVersion: v1
kind: Service
metadata:
  name: mssql-deployment
spec:
  selector:
    app: mssql
  ports:
    - protocol: TCP
      port: 1433
      targetPort: 1433
  type: LoadBalancer

    Copiez le code précédent dans un nouveau fichier, nommé sqldeployment.yaml. Utilisez les valeurs suivantes :

    • MSSQL_PID value: "Developer" : Définit le conteneur pour qu’il exécute l’édition SQL Server Développeur. L’édition Développeur n’est pas concédée sous licence pour les données de production. Si le déploiement est destiné à une utilisation en production, définissez l'édition appropriée (Enterprise, Standard ou Express). Pour plus d'informations, consultez Comment installer SQL Server.

    • persistentVolumeClaim: Cette valeur requiert une entrée pour claimName: qui correspond au nom utilisé pour la revendication de volume persistant. Ce didacticiel utilise mssql-data.

    • name: MSSQL_SA_PASSWORD: Configure l’image de conteneur pour définir le mot de passe AS, comme défini dans cette section.

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Quand Kubernetes déploie le conteneur, il fait référence au secret nommé mssql pour obtenir la valeur du mot de passe.

    • securityContext : définit les paramètres de contrôle d’accès et de privilège pour un pod ou un conteneur. Dans ce cas, il est spécifié au niveau du pod, de sorte que tous les conteneurs adhèrent à ce contexte de sécurité. Dans le contexte de sécurité, nous définissons fsGroup avec la valeur 10001, qui est l’ID de groupe (GID) du groupe mssql. Cette valeur signifie que tous les processus du conteneur font également partie du GID 10001 supplémentaire (mssql). Le propriétaire du volume /var/opt/mssql et tous les fichiers créés dans ce volume vont correspondre au GID 10001 (groupe mssql).

    Avertissement

    En utilisant le type de service LoadBalancer, l’instance =est accessible à distance (via Internet) sur le port 1433.

    Enregistrez le fichier . Par exemple : sqldeployment.yaml.

  2. Créez le déploiement, où <path to sqldeployment.yaml file> est l’emplacement où vous avez enregistré le fichier :

    kubectl apply -f <path to sqldeployment.yaml file>

    Le déploiement et le service sont créés. L’instance se trouve dans un conteneur, connecté au stockage persistant.

    deployment "mssql-deployment" created
service "mssql-deployment" created

    Le déploiement et le service sont créés. L’instance se trouve dans un conteneur, connecté au stockage persistant.

    Pour afficher l'état du pod, saisissez kubectl get pod.

    NAME                                READY    STATUS    RESTARTS   AGE
mssql-deployment-3813464711-h312s   1/1      Running   0          17m

    Le pod a l’état Running. Cet état indique que le conteneur est prêt. Une fois le déploiement créé, plusieurs minutes peuvent être nécessaires avant que le pod ne soit visible. Ce délai est dû au fait que le cluster extrait l’image mssql-server-linux du Registre des artefacts Microsoft. Une fois l’image extraite pour la première fois, les déploiements ultérieurs peuvent être plus rapides si le déploiement se fait sur un nœud sur lequel l’image est déjà mise en cache.

  3. Vérifiez que les services sont en cours d'exécution. Exécutez la commande suivante :

    kubectl get services

    Cette commande retourne les services en cours d’exécution, et les adresses IP internes et externes des services. Notez l’adresse IP externe pour le service mssql-deployment. Utilisez cette adresse IP pour vous connecter à SQL Server.

    NAME               TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
kubernetes         ClusterIP      10.0.0.1      <none>          443/TCP          52m
mssql-deployment   LoadBalancer   10.0.113.96   52.168.26.254   1433:30619/TCP   2m

    Pour plus d’informations sur l’état des objets dans le cluster Kubernetes, exécutez la commande suivante. N’oubliez pas de remplacer <MyResourceGroup> et <MyKubernetesClustername> par le nom de votre groupe de ressources et de votre cluster Kubernetes :

    az aks browse --resource-group <MyResourceGroup> --name <MyKubernetesClustername>

  4. Vous pouvez également vérifier que le conteneur s’exécute comme non racine en exécutant la commande suivante, où <nameOfSqlPod> est le nom de votre pod SQL Server :

    kubectl.exe exec <nameOfSqlPod> -it -- /bin/bash

    Vous pouvez voir le nom d’utilisateur comme mssql si vous exécutez whoami. mssql correspond à un utilisateur non-racine.

    whoami

Se connecter à l'instance

Vous pouvez vous connecter à une application en dehors du réseau virtuel Azure, à l’aide du compte sa et de l’adresse IP externe du service. Utilisez le mot de passe que vous avez configuré en tant que secret OpenShift.

Vous pouvez utiliser les applications suivantes pour vous connecter à l’instance.

Se connecter avec sqlcmd

Pour se connecter avec sqlcmd, exécutez la commande suivante :

sqlcmd -S <External IP Address> -U sa -P "MyC0m9l&xP@ssw0rd"

Remplacez les valeurs suivantes :

  • <External IP Address> par l’adresse IP pour le service mssql-deployment
  • MyC0m9l&xP@ssw0rd avec un mot de passe complexe

Vérifier la défaillance et la récupération

Pour vérifier l’échec et la récupération, vous pouvez supprimer le pod en procédant comme suit :

  1. Répertoriez le pod exécutant SQL Server.

    kubectl get pods

    Notez le nom du pod exécutant SQL Server.

  2. Supprimer le pod.

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 est la valeur retournée de l’étape précédente pour le nom du pod.

Kubernetes recrée automatiquement le pod pour récupérer une instance et se connecter au stockage persistant. Utilisez kubectl get pods pour vérifier qu’un nouveau pod est déployé. Utilisez kubectl get services pour vérifier que l’adresse IP du nouveau conteneur est la même.

Nettoyer les ressources

Si vous ne prévoyez pas d’effectuer les tutoriels qui suivent, nettoyez vos ressources inutiles. Utilisez la commande az group delete pour supprimer le groupe de ressources, le service conteneur ainsi que toutes les ressources associées. Remplacez <MyResourceGroup> par le nom du groupe de ressources contenant le cluster.

az group delete --name <MyResourceGroup> --yes --no-wait

Contenu connexe