次の方法で共有

クイックスタート: Azure 上に SQL Server コンテナー クラスターをデプロイする

  • [アーティクル]

適用対象: SQL Server - Linux

このクイックスタートでは、永続ストレージを使って、Azure Kubernetes Service (AKS) または Red Hat OpenShift 上のコンテナーで高可用性 SQL Server インスタンスを構成する方法について説明します。 SQL Server インスタンスで障害が発生した場合、オーケストレーターによって新しいポッドに自動的に再作成されます。 クラスター サービスはノード障害に対する回復性も備えています。

このクイックスタートでは、次のコマンド ライン ツールを使って、クラスターを管理します。

クラスター サービス コマンド ライン ツール
Azure Kubernetes Service (AKS) kubectl (Kubernetes CLI)
Azure Red Hat OpenShift oc (OpenShift CLI)

前提条件

SA パスワードを作成する

  1. Kubernetes クラスターで SA パスワードを作成します。 Kubernetes では、パスワードなどの機密構成情報をシークレットとして管理できます。

  2. MSSQL_SA_PASSWORD に対する値 MyC0m9l&xP@ssw0rd を保持する mssql という名前のシークレットを Kubernetes に作成するため、次のコマンドを実行します。 独自の複雑なパスワードを選択してください。

    重要

    SA_PASSWORD 環境変数は非推奨です。 代わりに MSSQL_SA_PASSWORD を使用してください

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

ストレージを作成する

Kubernetes クラスター内のデータベースの場合は、永続ストレージを使用する必要があります。 次の手順を使用して、Kubernetes クラスターで永続ボリュームと永続ボリューム要求を構成できます。

  1. マニフェストを作成して、ストレージ クラスと永続ボリューム要求を定義します。 マニフェストでは、ストレージ プロビジョナー、パラメーター、再要求ポリシーを指定します。 Kubernetes クラスターでは、このマニフェストを使って、永続ストレージが作成されます。

  2. 次の YAML 例では、ストレージ クラスと永続ボリューム要求が定義されています。 この Kubernetes クラスターは Azure 内にあるため、ストレージ クラス プロビジョナーは azure-disk です。 ストレージ アカウントの種類は Standard_LRS です。 永続ボリューム要求は mssql-data という名前です。 永続ボリューム要求のメタデータには、それをストレージ クラスに接続するための注釈が含まれています。

    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

    ファイルを保存します (例: pvc.yaml)。

  3. Kubernetes で永続ボリューム要求を作成します。<path to pvc.yaml file> はファイルを保存した場所です。

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

    永続ボリュームが Azure ストレージ アカウントとして自動的に作成され、永続ボリューム要求にバインドされます。

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

  4. 永続ボリューム要求を確認します。<persistentVolumeClaim> はその永続ボリューム要求の名前です。

    kubectl describe pvc <persistentVolumeClaim>

    前のステップでは、永続ボリューム要求に mssql-data という名前が指定されています。 永続ボリューム要求に関するメタデータを表示するには、次のコマンドを実行します。

    kubectl describe pvc mssql-data

    返されるメタデータには、Volume という名前の値が含まれます。 この値は、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>

    Volume の値は、Azure portal の次の図における BLOB の名前の一部と一致します。

    Azure portal での BLOB 名のスクリーンショット。

  5. 永続ボリュームを確認します。

    kubectl describe pv

    kubectl では、自動的に作成されて永続ボリューム要求にバインドされた永続ボリュームに関するメタデータが返されます。

配置を作成する

SQL Server インスタンスをホストしているコンテナーは、Kubernetes "デプロイ オブジェクト" として記述されています。 このデプロイでは "レプリカ セット" が作成されます。 このレプリカ セットによってポッドが作成されます。

これから、SQL Server mssql-server-linux の Docker イメージに基づいてコンテナーを記述するマニフェストを作成します。

  • マニフェストでは、mssql-server 永続ボリューム要求と、Kubernetes クラスターに既に適用されている mssql シークレットが参照されます。
  • また、マニフェストではサービスについても記述されています。 このサービスはロード バランサーです。 ロード バランサーにより、SQL Server インスタンスの復旧後も IP アドレスが維持されることが保証されます。
  • マニフェストには、リソースの "要求" と "制限" が記述されています。 これらは最小システム要件に基づいています。

  1. 配置を記述するマニフェスト (YAML ファイル) を作成します。 次の例では、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

    前のコードを、sqldeployment.yaml という名前の新しいファイルにコピーします。 次の値を更新します。

    • MSSQL_PID value: "Developer": SQL Server Developer Edition を実行するようにコンテナーを設定します。 Developer Edition には、運用データ用のライセンスは付与されません。 配置を運用環境で使用する場合は、適切なエディション (Enterprise、Standard、または Express) を設定します。 詳細については、「SQL Server のライセンス方法」を参照してください。

    • persistentVolumeClaim:この値には、永続ボリューム要求に使用される名前にマップされる claimName: のエントリが必要です。 このチュートリアルでは mssql-data を使用します。

    • name: MSSQL_SA_PASSWORD:このセクションで定義されているように、コンテナー イメージを構成して SA パスワードを設定します。

      valueFrom:
  secretKeyRef:
    name: mssql
    key: MSSQL_SA_PASSWORD

      Kubernetes では、コンテナーを配置するときに、mssql という名前のシークレットを参照してパスワードの値が取得されます。

    • securityContext: ポッドまたはコンテナーの権限とアクセス管理設定を定義します。 この場合、ポッド レベルで指定されるため、すべてのコンテナーがそのセキュリティ コンテキストに準拠します。 そのセキュリティ コンテキストで、mssql グループのグループ ID (GID) である値 10001 を指定して fsGroup を定義します。 この値は、そのコンテナーのすべてのプロセスも補助 GID 10001 (mssql) の一部であることを意味します。 ボリューム /var/opt/mssql およびそのボリュームで作成されたすべてのファイルは、GID 10001 (mssql グループ) になります。

    警告

    LoadBalancer サービスの種類を使うことにより、SQL Server インスタンスにポート 1433 で (インターネットを経由して) リモート アクセスできるようになります。

    ファイルを保存します。 たとえば、sqldeployment.yaml のようにします。

  2. デプロイを作成します。<path to sqldeployment.yaml file> はファイルを保存した場所です。

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

    配置とサービスが作成されます。 SQL Server インスタンスはコンテナー内にあり、永続ストレージに接続されています。

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

    配置とサービスが作成されます。 SQL Server インスタンスはコンテナー内にあり、永続ストレージに接続されています。

    ポッドの状態を表示するには、「kubectl get pod」と入力します。

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

    ポッドの状態は Running です。 この状態は、コンテナーの準備ができていることを示します。 配置が作成された後、ポッドが表示されるまでに数分かかることがあります。 遅延は、クラスターによって Microsoft アーティファクト レジストリから mssql-server-linux イメージがプルされるためです。 イメージが初めてプルされた後の配置は、既にイメージがキャッシュされているノードに対するものの場合は、高速になる可能性があります。

  3. サービスが実行されていることを確認します。 次のコマンドを実行します。

    kubectl get services

    このコマンドでは、実行されているサービスと共に、サービスの内部および外部の IP アドレスも返されます。 mssql-deployment サービスの外部 IP アドレスを記録しておきます。 この IP アドレスを使って 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

    Kubernetes クラスター内のオブジェクトの状態に関する詳細情報を取得するには、次のコマンドを実行します。 <MyResourceGroup> と <MyKubernetesClustername> は、実際のリソース グループと Kubernetes クラスターの名前に置き換えてください。

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

  4. 次のコマンドを実行して、コンテナーが非ルートとして実行されていることを確認することもできます。<nameOfSqlPod> は SQL Server ポッドの名前です。

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

    mssql を実行すると、ユーザー名が whoami と表示されます。 mssql は非ルート ユーザーです。

    whoami

SQL Server インスタンスに接続する

sa アカウントとこのサービスの外部 IP アドレスを使用して、Azure 仮想ネットワークの外部からアプリケーションに接続できます。 OpenShift シークレットとして構成したパスワードを使います。

次のアプリケーションを使って、SQL Server インスタンスに接続できます。

sqlcmd を使用して接続する

sqlcmd を使って接続するには、次のコマンドを実行します。

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

次の値を置き換えます。

  • <External IP Address> は、mssql-deployment サービスの IP アドレスに
  • MyC0m9l&xP@ssw0rd は、自分の複雑なパスワードに

障害と復旧を検証する

障害と復旧を確認するには、次の手順でポッドを削除します。

  1. SQL Server が実行されているポッドの一覧を表示します。

    kubectl get pods

    SQL Server が実行されているポッドの名前を記録します。

  2. ポッドを削除します。

    kubectl delete pod mssql-deployment-0

    mssql-deployment-0 は、前のステップでポッド名に対して返された値です。

Kubernetes は、ポッドを自動的に再作成して SQL Server インスタンスを復旧し、永続ストレージに接続します。 新しいポッドが配置されたことを確認するには、kubectl get pods を使います。 新しいコンテナーの IP アドレスが同じであることを確認するには、kubectl get services を使います。

リソースをクリーンアップする

この後のチュートリアルを実行しない場合は、不要なリソースをクリーンアップしてください。 az group delete コマンドを使用して、リソース グループ、コンテナー サービス、およびすべての関連リソースを削除します。 <MyResourceGroup> を、お使いのクラスターを含むリソース グループの名前に置き換えます。

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

関連するコンテンツ