Compartilhar via

Início Rápido: Implantar um cluster de contêiner do SQL Server no Azure

  • Artigo

Aplica-se a: SQL Server – Linux

Este início rápido demonstra como configurar uma instância do SQL Server altamente disponível em um contêiner com armazenamento persistente no AKS (Serviço de Kubernetes do Azure) ou no Red Hat OpenShift. Se a instância do SQL Server falhar, o orquestrador a recriará automaticamente em um novo pod. O serviço de cluster também oferece resiliência com relação a uma falha de nó.

Este início rápido usa as ferramentas de linha de comando a seguir para gerenciar o cluster.

Serviço de cluster Ferramenta de linha de comando
AKS (Serviço de Kubernetes do Azure) CLI do Kubernetes kubectl
Red Hat OpenShift no Azure CLI de OpenShift oc

Pré-requisitos

Criar uma senha SA

  1. Crie a senha SA no cluster Kubernetes. O Kubernetes pode gerenciar informações de configuração confidenciais, por exemplo, senhas como segredos.

  2. Para criar um segredo no Kubernetes chamado mssql que contém o valor MyC0m9l&xP@ssw0rd para MSSQL_SA_PASSWORD, execute o comando a seguir. Lembre-se de escolher sua senha complexa:

    Importante

    A variável de ambiente SA_PASSWORD foi preterida. Use MSSQL_SA_PASSWORD em vez disso.

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

Criar armazenamento

Para um banco de dados em um cluster do Kubernetes, você precisa usar armazenamento persistente. Configure um volume persistente e uma declaração de volume persistente no cluster Kubernetes usando as seguintes etapas:

  1. Crie um manifesto para definir a classe de armazenamento e a declaração de volume persistente. O manifesto especifica o provisionador de armazenamento, os parâmetros e a política de recuperação. O cluster Kubernetes usa esse manifesto para criar o armazenamento persistente.

  2. O exemplo de YAML a seguir define uma classe de armazenamento e uma declaração de volume persistente. O provisionador de classe de armazenamento é azure-disk, porque esse cluster Kubernetes está no Azure. O tipo de conta de armazenamento é Standard_LRS. A declaração de volume persistente é denominada mssql-data. Os metadados da declaração de volume persistente incluem uma anotação que os conecta de volta à classe de armazenamento.

    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

    Salve o arquivo (por exemplo, pvc.yaml).

  3. Crie a declaração de volume persistente no Kubernetes, onde <path to pvc.yaml file> é o local onde você salvou o arquivo:

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

    O volume persistente é criado automaticamente como uma conta de armazenamento do Azure e associado à declaração de volume persistente.

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

  4. Verifique a declaração de volume persistente, onde <persistentVolumeClaim> está o nome da declaração de volume persistente:

    kubectl describe pvc <persistentVolumeClaim>

    Na etapa anterior, a declaração de volume persistente é denominada mssql-data. Para ver os metadados sobre a declaração de volume persistente, execute o seguinte comando:

    kubectl describe pvc mssql-data

    Os metadados retornados incluem um valor chamado Volume. Esse valor é mapeado para o nome do 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>

    O valor do volume corresponde a parte do nome do blob na seguinte imagem do portal do Azure:

    Captura de tela do nome do blob do portal do Azure.

  5. Verifique o volume persistente.

    kubectl describe pv

    kubectl retorna metadados sobre o volume persistente que foi criado automaticamente e associado à declaração de volume persistente.

Criar a implantação

O contêiner que hospeda a instância do SQL Server é descrito como um objeto de implantação do Kubernetes. A implantação cria um conjunto de réplicas. O conjunto de réplicas cria o pod.

Você cria um manifesto para descrever o contêiner, com base na imagem do Docker mssql-server-linux do SQL Server.

  • O manifesto referencia a declaração de volume persistente do mssql-server e o segredo mssql que você já aplicou ao cluster Kubernetes.
  • O manifesto também descreve um serviço. Esse serviço é um balanceador de carga. O balanceador de carga garante que o endereço IP persiste após a recuperação da instância do SQL Server.
  • O manifesto descreve as solicitações e os limites do recurso. Eles se baseiam nos requisitos mínimos do sistema.

  1. Crie um manifesto (um arquivo YAML) para descrever a implantação. O exemplo a seguir descreve uma implantação, incluindo um contêiner baseado na imagem de contêiner do 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

    Copie o código anterior para um novo arquivo, denominado sqldeployment.yaml. Atualize os seguintes valores:

    • MSSQL_PID value: "Developer": define o contêiner para executar o SQL Server Developer Edition. A edição Developer não é licenciada para dados de produção. Se a implantação for para uso em produção, defina a edição apropriada (Enterprise, Standard ou Express). Para saber mais, confira Como licenciar o SQL Server.

    • persistentVolumeClaim: esse valor requer uma entrada para claimName: mapeada para o nome usado para a declaração de volume persistente. Este tutorial usa mssql-data.

    • name: MSSQL_SA_PASSWORD: configura a imagem de contêiner para definir a senha SA, conforme definido nesta seção.

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Quando o Kubernetes implanta o contêiner, ele refere-se ao segredo chamado mssql para obter o valor da senha.

    • securityContext: define as configurações de privilégio e controle de acesso para um pod ou contêiner. Nesse caso, ele é especificado no nível do pod e, portanto, todos os contêineres aderem a esse contexto de segurança. No contexto de segurança, definimos o fsGroup com o valor 10001, que é a GID (ID de Grupo) do grupo mssql. Esse valor significa que todos os processos do contêiner também fazem parte do GID 10001 suplementar (mssql). O proprietário do volume /var/opt/mssql e de todos os arquivos criados nesse volume será a GID 10001 (o grupo mssql).

    Aviso

    Usando o tipo de serviço LoadBalancer, a instância do SQL Server pode ser acessada remotamente (pela Internet) na porta 1433.

    Salve o arquivo. Por exemplo, sqldeployment.yaml.

  2. Crie a implantação, em que <path to sqldeployment.yaml file> é o local onde você salvou o arquivo:

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

    A implantação e o serviço são criados. A instância do SQL Server está em um contêiner, conectada ao armazenamento persistente.

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

    A implantação e o serviço são criados. A instância do SQL Server está em um contêiner, conectada ao armazenamento persistente.

    Para exibir o status do pod, digite kubectl get pod.

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

    O pod tem um status de Running. Esse status indica que o contêiner está pronto. Após a criação da implantação, pode levar alguns minutos antes que o pod fique visível. O atraso ocorre porque o cluster efetua pull da imagem mssql-server-linux do Registro de Artefato da Microsoft. Depois o pull da imagem for efetuado pela primeira vez, implantações subsequentes poderão ser mais rápidas se a implantação for para um nó que já tem a imagem armazenada em cache.

  3. Verifique se os serviços estão em execução. Execute o comando a seguir:

    kubectl get services

    Esse comando retorna serviços em execução e os endereços IP internos e externos para os serviços. Observe o endereço IP externo do serviço mssql-deployment. Use o endereço IP para conectar-se ao 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

    Para saber mais sobre o status dos objetos no cluster Kubernetes, execute o comando a seguir. Lembre-se de substituir <MyResourceGroup> e <MyKubernetesClustername> com o grupo de recursos e o nome do cluster do Kubernetes:

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

  4. Você também pode verificar se o contêiner está em execução como não raiz executando o seguinte comando, em que <nameOfSqlPod> é o nome do pod do SQL Server:

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

    Você poderá ver o nome de usuário como mssql se executar whoami. mssql que é um usuário não raiz.

    whoami

Conectar-se à instância do SQL Server

Você pode se conectar com um aplicativo de fora da rede virtual do Azure, usando a conta sa e o endereço IP externo para o serviço. Use a senha que você configurou como o segredo do OpenShift.

É possível usar os seguintes aplicativos para se conectar à instância do SQL Server.

Conectar-se com sqlcmd

Para se conectar com sqlcmd, execute o seguinte comando:

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

Substitua os seguintes valores:

  • <External IP Address> pelo endereço IP do serviço mssql-deployment
  • MyC0m9l&xP@ssw0rd com a sua senha complexa

Verificar falha e recuperação

Para verificar a falha e a recuperação, exclua o pod realizando as seguintes etapas:

  1. Listar o pod que está executando o SQL Server.

    kubectl get pods

    Anotar o nome do pod que está executando o SQL Server.

  2. Excluir o pod.

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 é o valor retornado da etapa anterior para o nome do pod.

O Kubernetes recria automaticamente o pod para recuperar uma instância do SQL Server e se conecta ao armazenamento persistente. Use kubectl get pods para verificar se um novo pod foi implantado. Use kubectl get services para verificar se o endereço IP do novo contêiner é o mesmo.

Limpar os recursos

Se você não planeja passar pelos tutoriais a seguir, limpe os recursos desnecessários. Use o comando az group delete para remover o grupo de recursos, o serviço de contêiner e todos os recursos relacionados. Substitua <MyResourceGroup> pelo nome do grupo de recursos que contém o cluster.

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

Conteúdo relacionado