diff --git a/docs/examples/mssqlserver/reconfigure-tls/issuer.yaml b/docs/examples/mssqlserver/reconfigure-tls/issuer.yaml new file mode 100644 index 0000000000..b001fb7268 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/issuer.yaml @@ -0,0 +1,8 @@ +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mg-issuer + namespace: demo +spec: + ca: + secretName: mongo-ca diff --git a/docs/examples/mssqlserver/reconfigure-tls/mg-replicaset.yaml b/docs/examples/mssqlserver/reconfigure-tls/mg-replicaset.yaml new file mode 100644 index 0000000000..b271b8a5f2 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/mg-replicaset.yaml @@ -0,0 +1,17 @@ +apiVersion: kubedb.com/v1 +kind: MongoDB +metadata: + name: mg-rs + namespace: demo +spec: + version: "4.4.26" + replicas: 3 + replicaSet: + name: rs0 + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi diff --git a/docs/examples/mssqlserver/reconfigure-tls/mops-add-tls.yaml b/docs/examples/mssqlserver/reconfigure-tls/mops-add-tls.yaml new file mode 100644 index 0000000000..25ed1b09e4 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/mops-add-tls.yaml @@ -0,0 +1,21 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MongoDBOpsRequest +metadata: + name: mops-add-tls + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + issuerRef: + name: mg-issuer + kind: Issuer + apiGroup: "cert-manager.io" + certificates: + - alias: client + subject: + organizations: + - mongo + organizationalUnits: + - client diff --git a/docs/examples/mssqlserver/reconfigure-tls/mops-change-issuer.yaml b/docs/examples/mssqlserver/reconfigure-tls/mops-change-issuer.yaml new file mode 100644 index 0000000000..3543909617 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/mops-change-issuer.yaml @@ -0,0 +1,14 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MongoDBOpsRequest +metadata: + name: mops-change-issuer + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + issuerRef: + name: mg-new-issuer + kind: Issuer + apiGroup: "cert-manager.io" diff --git a/docs/examples/mssqlserver/reconfigure-tls/mops-remove.yaml b/docs/examples/mssqlserver/reconfigure-tls/mops-remove.yaml new file mode 100644 index 0000000000..06245506d9 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/mops-remove.yaml @@ -0,0 +1,11 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MongoDBOpsRequest +metadata: + name: mops-remove + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + remove: true diff --git a/docs/examples/mssqlserver/reconfigure-tls/mops-rotate.yaml b/docs/examples/mssqlserver/reconfigure-tls/mops-rotate.yaml new file mode 100644 index 0000000000..7530796118 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/mops-rotate.yaml @@ -0,0 +1,11 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MongoDBOpsRequest +metadata: + name: mops-rotate + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: mg-rs + tls: + rotateCertificates: true diff --git a/docs/examples/mssqlserver/reconfigure-tls/ms-standalone.yaml b/docs/examples/mssqlserver/reconfigure-tls/ms-standalone.yaml new file mode 100644 index 0000000000..e9ab5d95b7 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/ms-standalone.yaml @@ -0,0 +1,32 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-ag-apply.yaml b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-ag-apply.yaml new file mode 100644 index 0000000000..b93d450d54 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-ag-apply.yaml @@ -0,0 +1,16 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-ag-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mssqlserver-ag-cluster + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-ag.yaml b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-ag.yaml new file mode 100644 index 0000000000..86d2b8283d --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-ag.yaml @@ -0,0 +1,14 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-ag + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mssqlserver-ag-cluster + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-standalone-apply.yaml b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-standalone-apply.yaml new file mode 100644 index 0000000000..0199028a1b --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-standalone-apply.yaml @@ -0,0 +1,16 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-standalone.yaml b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-standalone.yaml new file mode 100644 index 0000000000..5c0f52531a --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/msops-reconfigure-standalone.yaml @@ -0,0 +1,14 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure-tls/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/reconfigure-tls/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..8407bb6fcf --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/mssqlserver-ag-cluster.yaml @@ -0,0 +1,40 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Developer + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure-tls/new-issuer.yaml b/docs/examples/mssqlserver/reconfigure-tls/new-issuer.yaml new file mode 100644 index 0000000000..066cbce511 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure-tls/new-issuer.yaml @@ -0,0 +1,8 @@ +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mg-new-issuer + namespace: demo +spec: + ca: + secretName: mongo-new-ca diff --git a/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml b/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml new file mode 100644 index 0000000000..a6760b97d0 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml @@ -0,0 +1,34 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-standalone + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag-apply.yaml b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag-apply.yaml new file mode 100644 index 0000000000..b93d450d54 --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag-apply.yaml @@ -0,0 +1,16 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-ag-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mssqlserver-ag-cluster + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag.yaml b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag.yaml new file mode 100644 index 0000000000..86d2b8283d --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag.yaml @@ -0,0 +1,14 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-ag + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mssqlserver-ag-cluster + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml new file mode 100644 index 0000000000..0199028a1b --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml @@ -0,0 +1,16 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml new file mode 100644 index 0000000000..5c0f52531a --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone.yaml @@ -0,0 +1,14 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/reconfigure/mssqlserver-ag-cluster.yaml b/docs/examples/mssqlserver/reconfigure/mssqlserver-ag-cluster.yaml new file mode 100644 index 0000000000..8407bb6fcf --- /dev/null +++ b/docs/examples/mssqlserver/reconfigure/mssqlserver-ag-cluster.yaml @@ -0,0 +1,40 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Developer + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/update-version/msops-update-ag-cluster.yaml b/docs/examples/mssqlserver/update-version/msops-update-ag-cluster.yaml new file mode 100644 index 0000000000..78a9ad9653 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/msops-update-ag-cluster.yaml @@ -0,0 +1,13 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-ag-cluster + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-ag-cluster + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml b/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml new file mode 100644 index 0000000000..3f4c51368d --- /dev/null +++ b/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml @@ -0,0 +1,13 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-standalone + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-standalone + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady \ No newline at end of file diff --git a/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml b/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml new file mode 100644 index 0000000000..bad6f7bb95 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml @@ -0,0 +1,44 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut diff --git a/docs/examples/mssqlserver/update-version/mssql-standalone.yaml b/docs/examples/mssqlserver/update-version/mssql-standalone.yaml new file mode 100644 index 0000000000..512bbeb784 --- /dev/null +++ b/docs/examples/mssqlserver/update-version/mssql-standalone.yaml @@ -0,0 +1,32 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/examples/mssqlserver/volume-expansion/mops-volume-exp-std.yaml b/docs/examples/mssqlserver/volume-expansion/mops-volume-exp-std.yaml new file mode 100644 index 0000000000..c1112e2709 --- /dev/null +++ b/docs/examples/mssqlserver/volume-expansion/mops-volume-exp-std.yaml @@ -0,0 +1,12 @@ +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-volume-exp-std + namespace: demo +spec: + type: VolumeExpansion + databaseRef: + name: mssql-standalone + volumeExpansion: + mode: "Offline" # Online + mssqlserver: 2Gi diff --git a/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml b/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml new file mode 100644 index 0000000000..b9392192c8 --- /dev/null +++ b/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml @@ -0,0 +1,38 @@ +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + memory: "2Gi" + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut \ No newline at end of file diff --git a/docs/guides/mongodb/reconfigure/overview.md b/docs/guides/mongodb/reconfigure/overview.md index 4975e7588a..50683c37a9 100644 --- a/docs/guides/mongodb/reconfigure/overview.md +++ b/docs/guides/mongodb/reconfigure/overview.md @@ -45,7 +45,7 @@ The Reconfiguring MongoDB process consists of the following steps: 6. When it finds a `MongoDBOpsRequest` CR, it halts the `MongoDB` object which is referred from the `MongoDBOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MongoDB` object during the reconfiguring process. -7. Then the `KubeDB` Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the `MogoDBOpsRequest` CR. +7. Then the `KubeDB` Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the `MongoDBOpsRequest` CR. 8. Then the `KubeDB` Ops-manager operator will restart the related PetSet Pods so that they restart with the new configuration defined in the `MongoDBOpsRequest` CR. diff --git a/docs/guides/mssqlserver/README.md b/docs/guides/mssqlserver/README.md index 6c5ab86ccc..ebd1502f8c 100644 --- a/docs/guides/mssqlserver/README.md +++ b/docs/guides/mssqlserver/README.md @@ -20,30 +20,30 @@ Microsoft SQL Server is one of the most popular relational database management s ## Supported Microsoft SQL Server Features -| Features | Availability | -|---------------------------------------------------------------------|:------------:| -| Standalone and Availability Group Cluster (HA configuration) | ✓ | -| Synchronous Replication | ✓ | -| Automatic Failover | ✓ | -| Custom Configuration | ✓ | -| Authentication & Authorization | ✓ | -| Externally manageable Auth Secret | ✓ | -| Instant and Scheduled Backup ([KubeStash](https://kubestash.com/)) | ✓ | -| Continuous Archiving using `wal-g` | ✓ | -| Initialization from WAL archive | ✓ | -| Initializing from Snapshot ([KubeStash](https://kubestash.com/)) | ✓ | -| Reconfigurable Health Checker | ✓ | -| Persistent volume | ✓ | -| Builtin Prometheus Discovery | ✓ | -| Using Prometheus operator | ✓ | -| Automated Version Update | ✓ | -| Automated Vertical Scaling, Volume Expansion | ✓ | -| Automated Horizontal Scaling | ✓ | -| Autoscaler for Compute and Storage Resources | ✓ | -| Reconfiguration | ✓ | -| TLS | ✓ | -| Grafana Dashboards | ✓ | -| Autoscaling (vertically) | ✓ | +| Features | Availability | +|--------------------------------------------------------------------|:------------:| +| Standalone and Availability Group Cluster (HA configuration) | ✓ | +| Synchronous Replication | ✓ | +| Automatic Failover | ✓ | +| Custom Configuration | ✓ | +| Authentication & Authorization | ✓ | +| Externally manageable Auth Secret | ✓ | +| Instant and Scheduled Backup ([KubeStash](https://kubestash.com/)) | ✓ | +| Continuous Archiving using `wal-g` | ✓ | +| Initialization from WAL archive | ✓ | +| Initializing from Snapshot ([KubeStash](https://kubestash.com/)) | ✓ | +| Reconfigurable Health Checker | ✓ | +| Persistent Volume | ✓ | +| Builtin Prometheus Discovery | ✓ | +| Using Prometheus operator | ✓ | +| Automated Version Update | ✓ | +| Automated Vertical Scaling, Volume Expansion | ✓ | +| Automated Horizontal Scaling | ✓ | +| Autoscaling Compute and Storage Resources | ✓ | +| Reconfiguration | ✓ | +| TLS | ✓ | +| Reconfigure TLS | ✓ | +| Grafana Dashboards | ✓ | ## Supported Microsoft SQL Server Versions diff --git a/docs/guides/mssqlserver/autoscaler/_index.md b/docs/guides/mssqlserver/autoscaler/_index.md index b6fdc08188..a6694c0b45 100644 --- a/docs/guides/mssqlserver/autoscaler/_index.md +++ b/docs/guides/mssqlserver/autoscaler/_index.md @@ -5,6 +5,6 @@ menu: identifier: ms-autoscaling name: Autoscaling parent: guides-mssqlserver - weight: 46 + weight: 70 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/monitoring/_index.md b/docs/guides/mssqlserver/monitoring/_index.md index a7c806c4cc..f13e64bc7b 100755 --- a/docs/guides/mssqlserver/monitoring/_index.md +++ b/docs/guides/mssqlserver/monitoring/_index.md @@ -5,6 +5,6 @@ menu: identifier: ms-monitoring name: Monitoring parent: guides-mssqlserver - weight: 50 + weight: 90 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/pitr/_index.md b/docs/guides/mssqlserver/pitr/_index.md index 8f53fdd34e..2e4e0b2004 100644 --- a/docs/guides/mssqlserver/pitr/_index.md +++ b/docs/guides/mssqlserver/pitr/_index.md @@ -5,6 +5,6 @@ menu: identifier: pitr-mssqlserver name: Point-in-time Recovery parent: guides-mssqlserver - weight: 42 + weight: 45 menu_name: docs_{{ .version }} --- \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure-tls/_index.md b/docs/guides/mssqlserver/reconfigure-tls/_index.md new file mode 100644 index 0000000000..2d27c475d3 --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure-tls/_index.md @@ -0,0 +1,10 @@ +--- +title: Reconfigure MSSQLServer TLS/SSL +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-tls + name: Reconfigure TLS/SSL + parent: guides-mssqlserver + weight: 80 +menu_name: docs_{{ .version }} +--- diff --git a/docs/guides/mssqlserver/reconfigure-tls/overview.md b/docs/guides/mssqlserver/reconfigure-tls/overview.md new file mode 100644 index 0000000000..fed48c1742 --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure-tls/overview.md @@ -0,0 +1,54 @@ +--- +title: Reconfiguring TLS of MSSQLServer Database +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-tls-overview + name: Overview + parent: ms-reconfigure-tls + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfiguring TLS of MSSQLServer Database + +This guide will give an overview on how KubeDB Ops-manager operator reconfigures TLS configuration i.e. add TLS, remove TLS, update issuer/cluster issuer or Certificates and rotate the certificates of a `MSSQLServer` database. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + +## How Reconfiguring MSSQLServer TLS Configuration Process Works + +The following diagram shows how KubeDB Ops-manager operator reconfigures TLS of a `MSSQLServer` database. Open the image in a new tab to see the enlarged version. + +
+  Reconfiguring TLS process of MSSQLServer +
Fig: Reconfiguring TLS process of MSSQLServer
+
+ +The Reconfiguring MSSQLServer TLS process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource Object (CRO). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CRO. + +3. When the operator finds a `MSSQLServer` CR, it creates required number of `PetSets` and related necessary stuff like secrets, services, etc. + +4. Then, in order to reconfigure the TLS configuration of the `MSSQLServer` database the user creates a `MSSQLServerOpsRequest` CR with desired information. + +5. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +6. When it finds a `MSSQLServerOpsRequest` CR, it pauses the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the reconfiguring TLS process. + +7. Then the `KubeDB` Ops-manager operator will add, remove, update or rotate TLS configuration based on the Ops Request yaml. + +8. Then the `KubeDB` Ops-manager operator will restart all the Pods of the database so that they restart with the new TLS configuration defined in the `MSSQLServerOpsRequest` CR. + +9. After the successful reconfiguring of the `MSSQLServer` TLS, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator resumes its usual operations. + +In the next docs, we are going to show a step-by-step guide on reconfiguring TLS configuration of a MSSQLServer database using `MSSQLServerOpsRequest` CRD. \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure-tls/reconfigure-tls.md b/docs/guides/mssqlserver/reconfigure-tls/reconfigure-tls.md new file mode 100644 index 0000000000..39dc3c25b9 --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure-tls/reconfigure-tls.md @@ -0,0 +1,1030 @@ +--- +title: Reconfigure MSSQLServer TLS/SSL Encryption +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-tls-standalone + name: Standalone + parent: ms-reconfigure-tls + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfigure Standalone MSSQLServer TLS/SSL (Transport Encryption) + +KubeDB supports reconfigure i.e. add, remove, update and rotation of TLS/SSL certificates for existing MSSQLServer database via a MSSQLServerOpsRequest. This tutorial will show you how to use KubeDB to reconfigure TLS/SSL encryption. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- To keep things isolated, this tutorial uses a separate namespace called `demo` throughout this tutorial. + + ```bash + $ kubectl create ns demo + namespace/demo created + ``` + +> Note: YAML files used in this tutorial are stored in [docs/examples/mssqlserver](https://github.com/kubedb/docs/tree/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls) folder in GitHub repository [kubedb/docs](https://github.com/kubedb/docs). + +## Add TLS to a MSSQLServer database + +Here, We are going to create a MSSQLServer database without TLS and then reconfigure the database to use TLS. + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +### Deploy MSSQLServer without TLS + +In this section, we are going to deploy a MSSQLServer Standalone database without TLS. In the next few sections we will reconfigure TLS using `MSSQLServerOpsRequest` CRD. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/ms-standalone.yaml +mssqlserver.kubedb.com/ms-standalone created +``` + +Now, wait until `ms-standalone` has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +ms-standalone 2022-cu12 Ready 4m3s + +$ kubectl describe ms -n demo ms-standalone +Name: ms-standalone +Namespace: demo +Labels: +Annotations: +API Version: kubedb.com/v1alpha2 +Kind: MSSQLServer +Metadata: + Creation Timestamp: 2024-11-14T12:45:36Z + Finalizers: + kubedb.com + Generation: 2 + Resource Version: 438804 + UID: 83ebe191-3754-41af-8d86-ed211bf9c31c +Spec: + Auth Secret: + Name: ms-standalone-auth + Deletion Policy: WipeOut + Health Checker: + Failure Threshold: 1 + Period Seconds: 10 + Timeout Seconds: 10 + Pod Template: + Controller: + Metadata: + Spec: + Containers: + Env: + Name: ACCEPT_EULA + Value: Y + Name: MSSQL_PID + Value: Evaluation + Name: mssql + Resources: + Limits: + Memory: 4Gi + Requests: + Cpu: 500m + Memory: 4Gi + Security Context: + Allow Privilege Escalation: false + Capabilities: + Add: + NET_BIND_SERVICE + Drop: + ALL + Run As Group: 10001 + Run As Non Root: true + Run As User: 10001 + Seccomp Profile: + Type: RuntimeDefault + Init Containers: + Name: mssql-init + Resources: + Limits: + Memory: 512Mi + Requests: + Cpu: 200m + Memory: 512Mi + Security Context: + Allow Privilege Escalation: false + Capabilities: + Drop: + ALL + Run As Group: 10001 + Run As Non Root: true + Run As User: 10001 + Seccomp Profile: + Type: RuntimeDefault + Pod Placement Policy: + Name: default + Security Context: + Fs Group: 10001 + Replicas: 1 + Storage: + Access Modes: + ReadWriteOnce + Resources: + Requests: + Storage: 1Gi + Storage Class Name: standard + Storage Type: Durable + Tls: + Certificates: + Alias: server + Secret Name: ms-standalone-server-cert + Subject: + Organizational Units: + server + Organizations: + kubedb + Alias: client + Secret Name: ms-standalone-client-cert + Subject: + Organizational Units: + client + Organizations: + kubedb + Client TLS: false + Issuer Ref: + API Group: cert-manager.io + Kind: Issuer + Name: mssqlserver-ca-issuer + Version: 2022-cu12 +Status: + Conditions: + Last Transition Time: 2024-11-14T12:45:36Z + Message: The KubeDB operator has started the provisioning of MSSQLServer: demo/ms-standalone + Observed Generation: 1 + Reason: DatabaseProvisioningStartedSuccessfully + Status: True + Type: ProvisioningStarted + Last Transition Time: 2024-11-14T12:46:36Z + Message: All replicas are ready for MSSQLServer demo/ms-standalone + Observed Generation: 2 + Reason: AllReplicasReady + Status: True + Type: ReplicaReady + Last Transition Time: 2024-11-14T12:46:46Z + Message: database demo/ms-standalone is accepting connection + Observed Generation: 2 + Reason: AcceptingConnection + Status: True + Type: AcceptingConnection + Last Transition Time: 2024-11-14T12:46:46Z + Message: database demo/ms-standalone is ready + Observed Generation: 2 + Reason: AllReplicasReady + Status: True + Type: Ready + Last Transition Time: 2024-11-14T12:47:06Z + Message: The MSSQLServer: demo/ms-standalone is successfully provisioned. + Observed Generation: 2 + Reason: DatabaseSuccessfullyProvisioned + Status: True + Type: Provisioned + Phase: Ready +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Successful 4m20s KubeDB Ops-manager Operator Successfully created MSSQLServer server certificates + Normal Successful 4m20s KubeDB Ops-manager Operator Successfully created MSSQLServer client certificates + +``` + +Now, connect to this database by exec into a pod and verify the TLS is disabled. + +> when we connect using the sqlcmd tool, the -N option is available with [s|m|o] parameters, where 's' stands for strict, 'm' for mandatory, and 'o' for optional. The default setting is mandatory. + + +```bash +$ kubectl get secrets -n demo ms-standalone-auth -o jsonpath='{.data.\username}' | base64 -d +sa + +$ kubectl get secrets -n demo ms-standalone-auth -o jsonpath='{.data.\password}' | base64 -d +b1HLv9EV4CaSalX6 + +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "b1HLv9EV4CaSalX6" -N +Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : SSL Provider: [error:0A000086:SSL routines::certificate verify failed:self-signed certificate]. +Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Client unable to establish connection. + + +So Now, we have to connect with -C [Trust Server Certificate] +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P "b1HLv9EV4CaSalX6" -N -C +1> +``` + +We can verify from the above output that TLS is disabled for this database, `mssql.conf` file has no tls configuration. + +Now we will enable tls configuration using MSSQLServerOpsRequest +### Create MSSQLServerOpsRequest + +In order to add TLS to the database, we have to create a `MSSQLServerOpsRequest` CRO with our issuer. Below is the YAML of the `MSSQLServerOpsRequest` CRO that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-add-tls + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: ms-standalone + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + certificates: + - alias: client + subject: + organizations: + - mssqlserver + organizationalUnits: + - client + clientTLS: true + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `ms-standalone` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.issuerRef` specifies the issuer name, kind and api group. +- `spec.tls.certificates` specifies the certificates. You can learn more about this field from [here](/docs/guides/mssqlserver/concepts/mssqlserver.md#spectls). + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/msops-add-tls.yaml +mssqlserveropsrequest.ops.kubedb.com/msops-add-tls created +``` + +#### Verify TLS Enabled Successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ watch kubectl get msops -n demo +Every 2.0s: kubectl get msops -n demo + +NAME TYPE STATUS AGE +msops-add-tls ReconfigureTLS Successful 115s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-add-tls +Name: msops-add-tls +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-15T11:48:03Z + Generation: 1 + Resource Version: 491162 + UID: 007ad725-0a3f-4290-8814-d85592cfc247 +Spec: + Apply: IfReady + Database Ref: + Name: ms-standalone + Timeout: 5m + Tls: + Certificates: + Alias: client + Subject: + Organizational Units: + client + Organizations: + mssqlserver + Client TLS: true + Issuer Ref: + API Group: cert-manager.io + Kind: Issuer + Name: mssqlserver-ca-issuer + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2024-11-15T11:48:03Z + Message: MSSQLServer ops-request has started to reconfigure tls for mssqlserver nodes + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2024-11-15T11:48:06Z + Message: Successfully paused database + Observed Generation: 1 + Reason: DatabasePauseSucceeded + Status: True + Type: DatabasePauseSucceeded + Last Transition Time: 2024-11-15T11:48:16Z + Message: Successfully synced all certificates + Observed Generation: 1 + Reason: CertificateSynced + Status: True + Type: CertificateSynced + Last Transition Time: 2024-11-15T11:48:11Z + Message: get certificate; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetCertificate + Last Transition Time: 2024-11-15T11:48:11Z + Message: check ready condition; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: CheckReadyCondition + Last Transition Time: 2024-11-15T11:48:11Z + Message: issuing condition; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: IssuingCondition + Last Transition Time: 2024-11-15T11:48:21Z + Message: successfully reconciled the MSSQLServer with tls configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-15T11:49:06Z + Message: Successfully restarted all nodes + Observed Generation: 1 + Reason: RestartNodes + Status: True + Type: RestartNodes + Last Transition Time: 2024-11-15T11:48:26Z + Message: get pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--ms-standalone-0 + Last Transition Time: 2024-11-15T11:48:26Z + Message: evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--ms-standalone-0 + Last Transition Time: 2024-11-15T11:49:01Z + Message: check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--ms-standalone-0 + Last Transition Time: 2024-11-15T11:49:07Z + Message: Successfully completed reconfigureTLS for mssqlserver. + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +``` + +Now, Let's exec into a database node + + + +```bash +$ kubectl exec -it ms-standalone-0 -n demo -c mssql -- bash +mssql@ms-standalone-0:/$ ls /var/opt/mssql/tls +ca.crt client.crt client.key server.crt server.key +mssql@ms-standalone-0:/$ openssl x509 -in /var/opt/mssql/tls/client.crt -inform PEM -subject -nameopt RFC2253 -noout +subject=CN=mssql,OU=client,O=mssqlserver +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[network] +forceencryption = 1 +tlscert = /var/opt/mssql/tls/server.crt +tlskey = /var/opt/mssql/tls/server.key +tlsprotocols = 1.2,1.1,1.0 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P l2mGQRMETAS96QRb -N +1> +``` + +We can verify from the above output that TLS is enabled for this database, `mssql.conf` file has tls configurations. So, TLS is enabled successfully to this database. + + +## Rotate Certificate + +Now we are going to rotate the certificate of this database. First let's check the current expiration date of the certificate. + +```bash +$ kubectl exec -it ms-standalone-0 -n demo -c mssql -- bash +mssql@ms-standalone-0:/$ openssl x509 -in /var/opt/mssql/tls/client.crt -inform PEM -enddate -nameopt RFC2253 -noout +notAfter=Feb 13 12:28:39 2025 GMT +mssql@ms-standalone-0:/$ +``` + +So, the certificate will expire on this time `Feb 13 12:28:39 2025 GMT`. + + +-start from here. .... + + +### Create MSSQLServerOpsRequest + +Now we are going to increase it using a MSSQLServerOpsRequest. Below is the yaml of the ops request that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-rotate + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: ms-standalone + tls: + rotateCertificates: true +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `ms-standalone` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.rotateCertificates` specifies that we want to rotate the certificate of this database. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-rotate.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-rotate created +``` + +#### Verify Certificate Rotated Successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-rotate ReconfigureTLS Successful 112s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-rotate +Name: mops-rotate +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T16:17:55Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:rotateCertificates: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T16:17:55Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T16:17:55Z + Resource Version: 521643 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-rotate + UID: 6d96ead2-a868-47d8-85fb-77eecc9a96b4 +Spec: + Database Ref: + Name: ms-standalone + Tls: + Rotate Certificates: true + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T16:17:55Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T16:17:55Z + Message: Successfully Added Issuing Condition in Certificates + Observed Generation: 1 + Reason: IssuingConditionUpdated + Status: True + Type: IssuingConditionUpdated + Last Transition Time: 2021-03-11T16:18:00Z + Message: Successfully Issued New Certificates + Observed Generation: 1 + Reason: CertificateIssuingSuccessful + Status: True + Type: CertificateIssuingSuccessful + Last Transition Time: 2021-03-11T16:19:45Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T16:19:45Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal CertificateIssuingSuccessful 2m10s KubeDB Ops-manager operator Successfully Issued New Certificates + Normal RestartReplicaSet 25s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal Successful 25s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, let's check the expiration date of the certificate. + +```bash +$ kubectl exec -it ms-standalone-2 -n demo bash +root@ms-standalone-2:/# openssl x509 -in /var/run/mssqlserver/tls/client.pem -inform PEM -enddate -nameopt RFC2253 -noout +notAfter=Jun 9 16:17:55 2021 GMT +``` + +As we can see from the above output, the certificate has been rotated successfully. + +## Change Issuer/ClusterIssuer + +Now, we are going to change the issuer of this database. + +- Let's create a new ca certificate and key using a different subject `CN=ca-update,O=kubedb-updated`. + +```bash +$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=ca-updated/O=kubedb-updated" +Generating a RSA private key +..............................................................+++++ +......................................................................................+++++ +writing new private key to './ca.key' +----- +``` + +- Now we are going to create a new ca-secret using the certificate files that we have just generated. + +```bash +$ kubectl create secret tls mongo-new-ca \ + --cert=ca.crt \ + --key=ca.key \ + --namespace=demo +secret/mongo-new-ca created +``` + +Now, Let's create a new `Issuer` using the `mongo-new-ca` secret that we have just created. The `YAML` file looks like this: + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: ms-new-issuer + namespace: demo +spec: + ca: + secretName: mongo-new-ca +``` + +Let's apply the `YAML` file: + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/new-issuer.yaml +issuer.cert-manager.io/ms-new-issuer created +``` + +### Create MSSQLServerOpsRequest + +In order to use the new issuer to issue new certificates, we have to create a `MSSQLServerOpsRequest` CRO with the newly created issuer. Below is the YAML of the `MSSQLServerOpsRequest` CRO that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-change-issuer + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: ms-standalone + tls: + issuerRef: + name: ms-new-issuer + kind: Issuer + apiGroup: "cert-manager.io" +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `ms-standalone` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.issuerRef` specifies the issuer name, kind and api group. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-change-issuer.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-change-issuer created +``` + +#### Verify Issuer is changed successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-change-issuer ReconfigureTLS Successful 105s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-change-issuer +Name: mops-change-issuer +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T16:27:47Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:issuerRef: + .: + f:apiGroup: + f:kind: + f:name: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T16:27:47Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T16:27:47Z + Resource Version: 523903 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-change-issuer + UID: cdfe8a7d-52ef-466c-a5dd-97e74ad598ca +Spec: + Database Ref: + Name: ms-standalone + Tls: + Issuer Ref: + API Group: cert-manager.io + Kind: Issuer + Name: ms-new-issuer + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T16:27:47Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T16:27:52Z + Message: Successfully Issued New Certificates + Observed Generation: 1 + Reason: CertificateIssuingSuccessful + Status: True + Type: CertificateIssuingSuccessful + Last Transition Time: 2021-03-11T16:29:37Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T16:29:37Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal CertificateIssuingSuccessful 2m27s KubeDB Ops-manager operator Successfully Issued New Certificates + Normal RestartReplicaSet 42s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal Successful 42s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, Let's exec into a database node and find out the ca subject to see if it matches the one we have provided. + +```bash +$ kubectl exec -it ms-standalone-2 -n demo bash +root@ms o-rs-tls-2:/$ openssl x509 -in /var/run/mssqlserver/tls/ca.crt -inform PEM -subject -nameopt RFC2253 -noout +subject=O=kubedb-updated,CN=ca-updated +``` + +We can see from the above output that, the subject name matches the subject name of the new ca certificate that we have created. So, the issuer is changed successfully. + +## Remove TLS from the Database + +Now, we are going to remove TLS from this database using a MSSQLServerOpsRequest. + +### Create MSSQLServerOpsRequest + +Below is the YAML of the `MSSQLServerOpsRequest` CRO that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-remove + namespace: demo +spec: + type: ReconfigureTLS + databaseRef: + name: ms-standalone + tls: + remove: true +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing reconfigure TLS operation on `ms-standalone` database. +- `spec.type` specifies that we are performing `ReconfigureTLS` on our database. +- `spec.tls.remove` specifies that we want to remove tls from this database. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure-tls/mops-remove.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-remove created +``` + +#### Verify TLS Removed Successfully + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CRO, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-remove ReconfigureTLS Successful 105s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo mops-remove +Name: mops-remove +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2021-03-11T16:35:32Z + Generation: 1 + Managed Fields: + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:metadata: + f:annotations: + .: + f:kubectl.kubernetes.io/last-applied-configuration: + f:spec: + .: + f:databaseRef: + .: + f:name: + f:tls: + .: + f:remove: + f:type: + Manager: kubectl-client-side-apply + Operation: Update + Time: 2021-03-11T16:35:32Z + API Version: ops.kubedb.com/v1alpha1 + Fields Type: FieldsV1 + fieldsV1: + f:status: + .: + f:conditions: + f:observedGeneration: + f:phase: + Manager: kubedb-enterprise + Operation: Update + Time: 2021-03-11T16:35:32Z + Resource Version: 525550 + Self Link: /apis/ops.kubedb.com/v1alpha1/namespaces/demo/mssqlserveropsrequests/mops-remove + UID: 99184cc4-1595-4f0f-b8eb-b65c5d0e86a6 +Spec: + Database Ref: + Name: ms-standalone + Tls: + Remove: true + Type: ReconfigureTLS +Status: + Conditions: + Last Transition Time: 2021-03-11T16:35:32Z + Message: MSSQLServer ops request is reconfiguring TLS + Observed Generation: 1 + Reason: ReconfigureTLS + Status: True + Type: ReconfigureTLS + Last Transition Time: 2021-03-11T16:35:37Z + Message: Successfully Updated PetSets + Observed Generation: 1 + Reason: TLSRemoved + Status: True + Type: TLSRemoved + Last Transition Time: 2021-03-11T16:37:07Z + Message: Successfully Restarted ReplicaSet nodes + Observed Generation: 1 + Reason: RestartReplicaSet + Status: True + Type: RestartReplicaSet + Last Transition Time: 2021-03-11T16:37:07Z + Message: Successfully Reconfigured TLS + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal PauseDatabase 2m5s KubeDB Ops-manager operator Pausing MSSQLServer demo/ms-standalone + Normal PauseDatabase 2m5s KubeDB Ops-manager operator Successfully paused MSSQLServer demo/ms-standalone + Normal TLSRemoved 2m5s KubeDB Ops-manager operator Successfully Updated PetSets + Normal RestartReplicaSet 35s KubeDB Ops-manager operator Successfully Restarted ReplicaSet nodes + Normal ResumeDatabase 35s KubeDB Ops-manager operator Resuming MSSQLServer demo/ms-standalone + Normal ResumeDatabase 35s KubeDB Ops-manager operator Successfully resumed MSSQLServer demo/ms-standalone + Normal Successful 35s KubeDB Ops-manager operator Successfully Reconfigured TLS +``` + +Now, Let's exec into the database primary node and find out that TLS is disabled or not. + +```bash +$ kubectl exec -it -n demo ms-standalone-1 -- mongo admin -u root -p 'U6(h_pYrekLZ2OOd' +rs0:PRIMARY> db.adminCommand({ getParameter:1, sslMode:1 }) +{ + "sslMode" : "disabled", + "ok" : 1, + "$clusterTime" : { + "clusterTime" : Timestamp(1615480817, 1), + "signature" : { + "hash" : BinData(0,"CWJngDTQqDhKXyx7WMFJqqUfvhY="), + "keyId" : NumberLong("6938294279689207810") + } + }, + "operationTime" : Timestamp(1615480817, 1) +} +``` + +So, we can see from the above that, output that tls is disabled successfully. + +## Cleaning up + +To cleanup the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete mssqlserver -n demo ms-standalone +kubectl delete issuer -n demo ms-issuer ms-new-issuer +kubectl delete mssqlserveropsrequest msops-add-tls mops-remove mops-rotate mops-change-issuer +kubectl delete ns demo +``` + +## Next Steps + +- Detail concepts of [MSSQLServer object](/docs/guides/mssqlserver/concepts/mssqlserver.md). +- Initialize [MSSQLServer with Script](/docs/guides/mssqlserver/initialization/using-script.md). +- Monitor your MSSQLServer database with KubeDB using [out-of-the-box Prometheus operator](/docs/guides/mssqlserver/monitoring/using-prometheus-operator.md). +- Monitor your MSSQLServer database with KubeDB using [out-of-the-box builtin-Prometheus](/docs/guides/mssqlserver/monitoring/using-builtin-prometheus.md). +- Use [private Docker registry](/docs/guides/mssqlserver/private-registry/using-private-registry.md) to deploy MSSQLServer with KubeDB. +- Use [kubedb cli](/docs/guides/mssqlserver/cli/cli.md) to manage databases like kubectl for Kubernetes. +- Detail concepts of [MSSQLServer object](/docs/guides/mssqlserver/concepts/mongodb.md). +- Want to hack on KubeDB? Check our [contribution guidelines](/docs/CONTRIBUTING.md). diff --git a/docs/guides/mssqlserver/reconfigure/_index.md b/docs/guides/mssqlserver/reconfigure/_index.md new file mode 100644 index 0000000000..923c470deb --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/_index.md @@ -0,0 +1,10 @@ +--- +title: Reconfigure +menu: + docs_{{ .version }}: + identifier: ms-reconfigure + name: Reconfigure + parent: guides-mssqlserver + weight: 75 +menu_name: docs_{{ .version }} +--- \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure/ag_cluster.md b/docs/guides/mssqlserver/reconfigure/ag_cluster.md new file mode 100644 index 0000000000..1ce0a35ffa --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/ag_cluster.md @@ -0,0 +1,569 @@ +--- +title: Reconfigure MSSQLServer Availability Group +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-ag-cluster + name: Availability Group + parent: ms-reconfigure + weight: 30 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfigure MSSQLServer Availability Group + +This guide will show you how to use `KubeDB` Ops-manager operator to reconfigure a SQL Server Availability Group cluster. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [Availabilty Group](/docs/guides/mssqlserver/clustering/ag_cluster.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Reconfigure Overview](/docs/guides/mssqlserver/reconfigure/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/reconfigure) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. + +Now, we are going to deploy a `MSSQLServer` Availability Group using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to reconfigure its configuration. + +### Prepare MSSQLServer Availability Group + +Now, we are going to deploy a `MSSQLServer` Availability Group with version `2022-cu12`. + +### Deploy MSSQLServer Availability Group Cluster + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` +Now, we will create `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2048 +``` +Here, `memorylimitmb` is set to `2048`, whereas the default value is `12280`. + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo ms-custom-config --from-file=./mssql.conf +secret/ms-custom-config created +``` + +In this section, we are going to create a MSSQLServer object specifying `spec.configSecret` field to apply this custom configuration. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssqlserver-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/mssqlserver-ag-cluster.yaml +MSSQLServer.kubedb.com/mssqlserver-ag-cluster created +``` + +Now, wait until `mssqlserver-ag-cluster` has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +mssqlserver-ag-cluster 2022-cu12 Ready 5m47s +``` + +Now, we will check if the database has started with the custom configuration we have provided. + +First we need to get the username and password to connect to a MSSQLServer instance, +```bash +$ kubectl get secrets -n demo mssqlserver-ag-cluster-auth -o jsonpath='{.data.\username}' | base64 -d +sa + +$ kubectl get secrets -n demo mssqlserver-ag-cluster-auth -o jsonpath='{.data.\password}' | base64 -d +gkBGX7RE0ap4yjHt +``` + +Now let's connect to the SQL Server instance and run internal command to check the configuration we have provided. + +```bash +$ kubectl exec -it -n demo mssqlserver-ag-cluster-0 -c mssql -- bash +mssql@mssqlserver-ag-cluster-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 2048 +mssql@mssqlserver-ag-cluster-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P gkBGX7RE0ap4yjHt +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 2048 + +(1 rows affected) +``` + +As we can see from the configuration of running MSSQLServer, the value of `physical_memory_mb` has been set to `2048`. + +### Reconfigure using new config secret + +Now we will reconfigure this database to set `memorylimitmb` to `2560`. + +Now, we will edit the `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2560 +``` + +Then, we will create a new secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo new-custom-config --from-file=./mssql.conf +secret/new-custom-config created +``` + +#### Create MSSQLServerOpsRequest + +Now, we will use this secret to replace the previous secret using a `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-ag + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mssqlserver-ag-cluster + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `mssqlserver-ag-cluster` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.customConfig.replicaSet.configSecret.name` specifies the name of the new secret. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag.yaml +MSSQLServeropsrequest.ops.kubedb.com/msops-reconfigure-ag created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will update the `configSecret` of `MSSQLServer` object. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +NAME TYPE STATUS AGE +msops-reconfigure-ag Reconfigure Successful 4m1s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo msops-reconfigure-ag +Name: msops-reconfigure-ag +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-11T13:07:49Z + Generation: 1 + Resource Version: 272883 + UID: 2bbc64b6-9d88-4adc-854e-de444c716f57 +Spec: + Apply: IfReady + Configuration: + Config Secret: + Name: new-custom-config + Database Ref: + Name: mssqlserver-ag-cluster + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2024-11-11T13:07:49Z + Message: MSSQLServer ops-request has started to reconfigure MSSQLServer nodes + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2024-11-11T13:07:58Z + Message: successfully reconciled the mssqlserver with new configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-11T13:08:03Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-11-11T13:08:03Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-11-11T13:08:38Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-11-11T13:08:43Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-11-11T13:08:43Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-11-11T13:09:18Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-11-11T13:09:23Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-11-11T13:09:23Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-11-11T13:09:58Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-11-11T13:10:03Z + Message: Successfully Restarted Pods after reconfiguration + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-11T13:10:03Z + Message: Successfully completed reconfiguring for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +``` + +Now let's connect to SQL Server instance and run internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -it -n demo mssqlserver-ag-cluster-0 -c mssql -- bash +mssql@mssqlserver-ag-cluster-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 2560 +mssql@mssqlserver-ag-cluster-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P gkBGX7RE0ap4yjHt +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 2560 + +(1 rows affected) +``` + +As we can see from the configuration of running SQL Server, the value of `physical_memory_mb` has been changed from `2048` to `2560`. So the reconfiguration of the database is successful. + +### Reconfigure using apply config + +Now we will reconfigure this database again to set `memorylimitmb` to `3072`. This time we won't use a new secret. We will use the `applyConfig` field of the `MSSQLServerOpsRequest`. This will merge the new config in the existing secret. + +#### Create MSSQLServerOpsRequest + +Now, we will use the new configuration in the `applyConfig` field in the `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-ag-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: mssqlserver-ag-cluster + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `mssqlserver-ag-cluster` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.configuration.applyConfig` specifies the new configuration that will be merged in the existing secret. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/msops-reconfigure-ag-apply.yaml +MSSQLServeropsrequest.ops.kubedb.com/msops-reconfigure-ag-apply created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will merge this new config with the existing configuration. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +---- + + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +msops-reconfigure-ag-apply Reconfigure Successful 3m34s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo msops-reconfigure-ag-apply +Name: msops-reconfigure-ag-apply +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-11T13:16:11Z + Generation: 1 + Resource Version: 273846 + UID: 434d35ef-89e5-4d1a-aac2-22941346d77e +Spec: + Apply: IfReady + Configuration: + Apply Config: + mssql.conf: [memory] +memorylimitmb = 3072 + Database Ref: + Name: mssqlserver-ag-cluster + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2024-11-11T13:16:11Z + Message: MSSQLServer ops-request has started to reconfigure MSSQLServer nodes + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2024-11-11T13:16:14Z + Message: Successfully prepared user provided custom config secret + Observed Generation: 1 + Reason: PrepareCustomConfig + Status: True + Type: PrepareCustomConfig + Last Transition Time: 2024-11-11T13:16:19Z + Message: successfully reconciled the mssqlserver with new configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-11T13:16:24Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-11-11T13:16:24Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-11-11T13:16:59Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-0 + Last Transition Time: 2024-11-11T13:17:04Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-11-11T13:17:04Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-11-11T13:17:39Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-1 + Last Transition Time: 2024-11-11T13:17:44Z + Message: get pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-11-11T13:17:44Z + Message: evict pod; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: EvictPod--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-11-11T13:18:19Z + Message: check pod running; ConditionStatus:True; PodName:mssqlserver-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssqlserver-ag-cluster-2 + Last Transition Time: 2024-11-11T13:18:24Z + Message: Successfully Restarted Pods after reconfiguration + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-11T13:18:24Z + Message: Successfully completed reconfiguring for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +``` + +Now let's connect to the SQL Server instance and run a internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -it -n demo mssqlserver-ag-cluster-0 -c mssql -- bash +mssql@mssqlserver-ag-cluster-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 3072 +mssql@mssqlserver-ag-cluster-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P gkBGX7RE0ap4yjHt +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 3072 + +(1 rows affected) +``` + +As we can see from the configuration of running SQL Server, the value of `physical_memory_mb` has been changed from `2560` to `3072`. So the reconfiguration of the database using the `applyConfig` field is successful. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo mssqlserver-ag-cluster +kubectl delete msops -n demo msops-reconfigure-ag msops-reconfigure-ag-apply +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure/overview.md b/docs/guides/mssqlserver/reconfigure/overview.md new file mode 100644 index 0000000000..d24dd5e899 --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/overview.md @@ -0,0 +1,54 @@ +--- +title: Reconfiguring MSSQLServer +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-overview + name: Overview + parent: ms-reconfigure + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfiguring SQL Server + +This guide will give an overview on how KubeDB Ops-manager operator reconfigures `MSSQLServer` database. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + +## How Reconfiguring MSSQLServer Process Works + +The following diagram shows how KubeDB Ops-manager operator reconfigures `MSSQLServer` database. Open the image in a new tab to see the enlarged version. + +
+  Reconfiguring process of MSSQLServer +
Fig: Reconfiguring process of MSSQLServer
+
+ +The Reconfiguring MSSQLServer process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource (CR). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CR. + +3. When the operator finds a `MSSQLServer` CR, it creates required number of `PetSets` and related necessary stuff like secrets, services, etc. + +4. Then, in order to reconfigure the `MSSQLServer` database the user creates a `MSSQLServerOpsRequest` CR with desired information. + +5. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +6. When it finds a `MSSQLServerOpsRequest` CR, it halts the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the reconfiguring process. + +7. Then the `KubeDB` Ops-manager operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the `MSSQLServerOpsRequest` CR. + +8. Then the `KubeDB` Ops-manager operator will restart the related PetSet Pods so that they restart with the new configuration defined in the `MSSQLServerOpsRequest` CR. + +9. After the successful reconfiguring of the `MSSQLServer`, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator resumes its usual operations. + +In the next docs, we are going to show a step-by-step guide on reconfiguring MSSQLServer database using `MSSQLServerOpsRequest` CR. \ No newline at end of file diff --git a/docs/guides/mssqlserver/reconfigure/standalone.md b/docs/guides/mssqlserver/reconfigure/standalone.md new file mode 100644 index 0000000000..72dc0440ec --- /dev/null +++ b/docs/guides/mssqlserver/reconfigure/standalone.md @@ -0,0 +1,526 @@ +--- +title: Reconfigure Standalone MSSQLServer Database +menu: + docs_{{ .version }}: + identifier: ms-reconfigure-standalone + name: Standalone + parent: ms-reconfigure + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Reconfigure MSSQLServer Standalone Database + +This guide will show you how to use `KubeDB` Ops-manager operator to reconfigure a MSSQLServer standalone database. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Reconfigure Overview](/docs/guides/mssqlserver/reconfigure/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/reconfigure) directory of [kubedb/docs](https://github.com/kubedb/docs) repository. + +Now, we are going to deploy a `MSSQLServer` standalone using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to reconfigure its configuration. + +### Prepare MSSQLServer Standalone Database + +Now, we are going to deploy a `MSSQLServer` standalone database with version `2022-cu12`. + +### Deploy MSSQLServer standalone + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +Now, we will create `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2048 +``` +Here, `memorylimitmb` is set to `2048`, whereas the default value is `12280`. + +Now, we will create a secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo ms-custom-config --from-file=./mssql.conf +secret/ms-custom-config created +``` + +In this section, we are going to create a MSSQLServer object specifying `spec.configSecret` field to apply this custom configuration. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: ms-standalone + namespace: demo +spec: + version: "2022-cu12" + configSecret: + name: ms-custom-config + replicas: 1 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/ms-standalone.yaml +MSSQLServer.kubedb.com/ms-standalone created +``` + +Now, wait until `ms-standalone` has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +ms-standalone 4.4.26 Ready 23s +``` + +Now, we will check if the database has started with the custom configuration we have provided. + +First we need to get the username and password to connect to a MSSQLServer instance, +```bash +$ kubectl get secrets -n demo ms-standalone-auth -o jsonpath='{.data.\username}' | base64 -d +sa + +$ kubectl get secrets -n demo ms-standalone-auth -o jsonpath='{.data.\password}' | base64 -d +SERtEyH1RMMEsvE0 +``` + +Now let's connect to the SQL Server instance and run internal command to check the configuration we have provided. + +```bash +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 2048 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SERtEyH1RMMEsvE0 +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 2048 + +(1 rows affected) +1> +``` + +As we can see from the configuration of running MSSQLServer, the value of `physical_memory_mb` has been set to `2048`. + +### Reconfigure using new secret + +Now we will reconfigure this database to set `memorylimitmb` to `2560`. + +Now, we will edit the `mssql.conf` file containing required configuration settings. + +```ini +$ cat mssql.conf +[memory] +memorylimitmb = 2560 +``` + +Then, we will create a new secret with this configuration file. + +```bash +$ kubectl create secret generic -n demo new-custom-config --from-file=./mssql.conf +secret/new-custom-config created +``` + +#### Create MSSQLServerOpsRequest + +Now, we will use this secret to replace the previous secret using a `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + configSecret: + name: new-custom-config + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `ms-standalone` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.configuration.configSecret.name` specifies the name of the new secret. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/mops-reconfigure-standalone.yaml +MSSQLServeropsrequest.ops.kubedb.com/mops-reconfigure-standalone created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will update the `configSecret` of `MSSQLServer` object. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +Every 2.0s: kubectl get MSSQLServeropsrequest -n demo + +NAME TYPE STATUS AGE +msops-reconfigure-standalone Reconfigure Successful 2m42s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo mops-reconfigure-standalone +Name: msops-reconfigure-standalone +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-07T12:46:35Z + Generation: 1 + Resource Version: 160710 + UID: a3859b47-575c-40a5-84d4-38fb9f37a8ef +Spec: + Apply: IfReady + Configuration: + Config Secret: + Name: new-custom-config + Database Ref: + Name: ms-standalone + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2024-11-07T12:46:35Z + Message: MSSQLServer ops-request has started to reconfigure MSSQLServer nodes + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2024-11-07T12:46:49Z + Message: successfully reconciled the mssqlserver with new configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-07T12:46:54Z + Message: get pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:46:54Z + Message: evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:47:34Z + Message: check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--ms-standalone-0 + Last Transition Time: 2024-11-07T12:47:39Z + Message: Successfully Restarted Pods after reconfiguration + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-07T12:47:39Z + Message: Successfully completed reconfiguring for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 3m45s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-reconfigure-standalone + Normal Starting 3m45s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/ms-standalone + Normal Successful 3m45s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone + Normal UpdatePetSets 3m31s KubeDB Ops-manager Operator successfully reconciled the mssqlserver with new configuration + Warning get pod; ConditionStatus:True; PodName:ms-standalone-0 3m26s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:ms-standalone-0 3m26s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:ms-standalone-0 3m21s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:ms-standalone-0 2m46s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Normal RestartPods 2m41s KubeDB Ops-manager Operator Successfully Restarted Pods after reconfiguration + Normal Starting 2m41s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/ms-standalone + Normal Successful 2m41s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone +``` + +Now let's connect to SQL Server instance and run a internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 2560 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SERtEyH1RMMEsvE0 +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 2560 + +(1 rows affected) +1> +``` + +As we can see from the configuration of running SQL Server, the value of `physical_memory_mb` has been changed from `2048` to `2560`. So the reconfiguration of the database is successful. + + +### Reconfigure using apply config + +Now we will reconfigure this database again to set `memorylimitmb` to `3072`. This time we won't use a new secret. We will use the `applyConfig` field of the `MSSQLServerOpsRequest`. This will merge the new config in the existing secret. + +#### Create MSSQLServerOpsRequest + +Now, we will use the new configuration in the `applyConfig` field in the `MSSQLServerOpsRequest` CR. The `MSSQLServerOpsRequest` yaml is given below, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-reconfigure-standalone-apply + namespace: demo +spec: + type: Reconfigure + databaseRef: + name: ms-standalone + configuration: + applyConfig: + mssql.conf: |- + [memory] + memorylimitmb = 3072 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are reconfiguring `ms-standalone` database. +- `spec.type` specifies that we are performing `Reconfigure` on our database. +- `spec.configuration.applyConfig` specifies the new configuration that will be merged in the existing secret. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/reconfigure/msops-reconfigure-standalone-apply.yaml +MSSQLServeropsrequest.ops.kubedb.com/msops-reconfigure-standalone-apply created +``` + +#### Verify the new configuration is working + +If everything goes well, `KubeDB` Ops-manager operator will merge this new config with the existing configuration. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get MSSQLServeropsrequest -n demo +Every 2.0s: kubectl get MSSQLServeropsrequest -n demo + +NAME TYPE STATUS AGE +msops-reconfigure-standalone-apply Reconfigure Successful 2m2s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to reconfigure the database. + +```bash +$ kubectl describe MSSQLServeropsrequest -n demo msops-reconfigure-standalone-apply +Name: msops-reconfigure-standalone-apply +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-07T12:57:43Z + Generation: 1 + Resource Version: 161738 + UID: e9da170c-5d6b-41fd-ae05-b39c6c5f3029 +Spec: + Apply: IfReady + Configuration: + Apply Config: + mssql.conf: [memory] +memorylimitmb = 3072 + Database Ref: + Name: ms-standalone + Timeout: 5m + Type: Reconfigure +Status: + Conditions: + Last Transition Time: 2024-11-07T12:57:43Z + Message: MSSQLServer ops-request has started to reconfigure MSSQLServer nodes + Observed Generation: 1 + Reason: Reconfigure + Status: True + Type: Reconfigure + Last Transition Time: 2024-11-07T12:57:46Z + Message: Successfully prepared user provided custom config secret + Observed Generation: 1 + Reason: PrepareCustomConfig + Status: True + Type: PrepareCustomConfig + Last Transition Time: 2024-11-07T12:57:51Z + Message: successfully reconciled the mssqlserver with new configuration + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-07T12:57:56Z + Message: get pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:57:56Z + Message: evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--ms-standalone-0 + Last Transition Time: 2024-11-07T12:58:31Z + Message: check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--ms-standalone-0 + Last Transition Time: 2024-11-07T12:58:36Z + Message: Successfully Restarted Pods after reconfiguration + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-07T12:58:36Z + Message: Successfully completed reconfiguring for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 2m40s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-reconfigure-standalone-apply + Normal Starting 2m40s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/ms-standalone + Normal Successful 2m40s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone-apply + Normal UpdatePetSets 2m32s KubeDB Ops-manager Operator successfully reconciled the mssqlserver with new configuration + Warning get pod; ConditionStatus:True; PodName:ms-standalone-0 2m27s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:ms-standalone-0 2m27s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:ms-standalone-0 2m22s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:ms-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:ms-standalone-0 112s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:ms-standalone-0 + Normal RestartPods 107s KubeDB Ops-manager Operator Successfully Restarted Pods after reconfiguration + Normal Starting 107s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/ms-standalone + Normal Successful 107s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/ms-standalone for MSSQLServerOpsRequest: msops-reconfigure-standalone-apply +``` + +Now let's connect to the SQL Server instance and run a internal command to check the new configuration we have provided. + +```bash +$ kubectl exec -it -n demo ms-standalone-0 -c mssql -- bash +mssql@ms-standalone-0:/$ cat /var/opt/mssql/mssql.conf +[language] +lcid = 1033 +[memory] +memorylimitmb = 3072 +mssql@ms-standalone-0:/$ /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P SERtEyH1RMMEsvE0 +1> SELECT physical_memory_kb / 1024 AS physical_memory_mb FROM sys.dm_os_sys_info; +2> go +physical_memory_mb +-------------------- + 3072 + +(1 rows affected) +1> +``` + +As we can see from the configuration of running SQL Server, the value of `physical_memory_mb` has been changed from `2560` to `3072`. So the reconfiguration of the database using the `applyConfig` field is successful. + + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo ms-standalone +kubectl delete MSSQLServeropsrequest -n demo mops-reconfigure-standalone msops-reconfigure-standalone-apply +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/restart/_index.md b/docs/guides/mssqlserver/restart/_index.md index cbd526b865..afdebf6a84 100644 --- a/docs/guides/mssqlserver/restart/_index.md +++ b/docs/guides/mssqlserver/restart/_index.md @@ -5,6 +5,6 @@ menu: identifier: ms-restart name: Restart parent: guides-mssqlserver - weight: 46 + weight: 85 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/scaling/_index.md b/docs/guides/mssqlserver/scaling/_index.md index fcf648eaf6..e2c492a678 100644 --- a/docs/guides/mssqlserver/scaling/_index.md +++ b/docs/guides/mssqlserver/scaling/_index.md @@ -5,6 +5,6 @@ menu: identifier: ms-scaling name: Scaling Microsoft SQL Server parent: guides-mssqlserver - weight: 43 + weight: 55 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/tls/_Index.md b/docs/guides/mssqlserver/tls/_Index.md index bf62d65dd1..84c6852db5 100644 --- a/docs/guides/mssqlserver/tls/_Index.md +++ b/docs/guides/mssqlserver/tls/_Index.md @@ -5,6 +5,6 @@ menu: identifier: ms-tls name: TLS/SSL Encryption parent: guides-mssqlserver - weight: 45 + weight: 65 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/update-version/_index.md b/docs/guides/mssqlserver/update-version/_index.md new file mode 100644 index 0000000000..e386d1eec4 --- /dev/null +++ b/docs/guides/mssqlserver/update-version/_index.md @@ -0,0 +1,10 @@ +--- +title: Updating MSSQLServer +menu: + docs_{{ .version }}: + identifier: mssql-updating + name: UpdateVersion + parent: guides-mssqlserver + weight: 50 +menu_name: docs_{{ .version }} +--- \ No newline at end of file diff --git a/docs/guides/mssqlserver/update-version/ag_cluster.md b/docs/guides/mssqlserver/update-version/ag_cluster.md new file mode 100644 index 0000000000..25fa4408e9 --- /dev/null +++ b/docs/guides/mssqlserver/update-version/ag_cluster.md @@ -0,0 +1,352 @@ +--- +title: Updating MSSQLServer Availability Group +menu: + docs_{{ .version }}: + identifier: ms-updating-ag-cluster + name: Availability Group (HA Cluster) + parent: mssql-updating + weight: 30 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Update version of MSSQLServer Availability Group + +This guide will show you how to use `KubeDB` Ops-manager operator to update the version of `MSSQLServer` Availability Group Cluster. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [Availability Group Cluster](/docs/guides/mssqlserver/clustering/ag_cluster.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Updating Overview](/docs/guides/mssqlserver/update-version/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/update-version) directory of [kubedb/docs](https://github.com/kube/docs) repository. + +## Prepare MSSQLServer Availability Group Database + +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/ag-cluster/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +Now, we are going to deploy a `MSSQLServer` availability group with version `2022-cu12`. + +### Deploy MSSQLServer AG Cluster + +In this section, we are going to deploy a MSSQLServer availability group cluster. Then, in the next section we will update the version of the database using `MSSQLServerOpsRequest` CR. + +Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-ag-cluster + namespace: demo +spec: + version: "2022-cu12" + replicas: 3 + topology: + mode: AvailabilityGroup + availabilityGroup: + databases: + - agdb1 + - agdb2 + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + memory: "2Gi" + storageType: Durable + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/mssql-ag-cluster.yaml +mssqlserver.kubedb.com/mssql-ag-cluster created +``` + +Now, wait until `mssql-ag-cluster` created has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +mssql-ag-cluster 2022-cu12 Ready 4m +``` + +We are now ready to apply the `MSSQLServerOpsRequest` CR to update this database. + +### Update MSSQLServer Version + +Here, we are going to update `MSSQLServer` ag cluster from `2022-cu12` to `2022-cu14`. + +#### Create MSSQLServerOpsRequest: + +In order to update the version of the mssql server ag cluster database, we have to create a `MSSQLServerOpsRequest` CR with your desired version that is supported by `KubeDB`. +Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-ag-cluster + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-ag-cluster + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-ag-cluster` MSSQLServer database. +- `spec.type` specifies that we are going to perform `UpdateVersion` on our database. +- `spec.updateVersion.targetVersion` specifies the expected version of the database `2022-cu14`. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/msops-update-ag-cluster .yaml +mssqlserveropsrequest.ops.kubedb.com/msops-update-ag-cluster created +``` + +#### Verify MSSQLServer version updated successfully + +If everything goes well, `KubeDB` Ops-manager operator will update the image of `MSSQLServer` object and related `PetSets` and `Pods`. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-update-ag-cluster UpdateVersion Successful 2m33s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to update the database version. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-update-ag-cluster +Name: msops-update-ag-cluster +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-12T13:38:04Z + Generation: 1 + Resource Version: 333751 + UID: f4977424-0ddc-40bc-a3b7-bc69f5ac6e82 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-ag-cluster + Timeout: 5m + Type: UpdateVersion + Update Version: + Target Version: 2022-cu14 +Status: + Conditions: + Last Transition Time: 2024-11-12T13:38:05Z + Message: MSSQLServer ops-request has started to update version + Observed Generation: 1 + Reason: UpdateVersion + Status: True + Type: UpdateVersion + Last Transition Time: 2024-11-12T13:38:28Z + Message: successfully reconciled the MSSQLServer with updated version + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-12T13:38:33Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-0 + Last Transition Time: 2024-11-12T13:38:33Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-0 + Last Transition Time: 2024-11-12T13:39:08Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-0 + Last Transition Time: 2024-11-12T13:39:13Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-1 + Last Transition Time: 2024-11-12T13:39:13Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-1 + Last Transition Time: 2024-11-12T13:39:48Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-1 + Last Transition Time: 2024-11-12T13:39:53Z + Message: get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-ag-cluster-2 + Last Transition Time: 2024-11-12T13:39:53Z + Message: evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-ag-cluster-2 + Last Transition Time: 2024-11-12T13:40:28Z + Message: check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-ag-cluster-2 + Last Transition Time: 2024-11-12T13:40:33Z + Message: Successfully Restarted MSSQLServer pods + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-12T13:40:33Z + Message: Successfully updated MSSQLServer + Observed Generation: 1 + Reason: UpdateDatabase + Status: True + Type: UpdateDatabase + Last Transition Time: 2024-11-12T13:40:33Z + Message: Successfully updated MSSQLServer version + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 7m49s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-update-ag-cluster + Normal Starting 7m49s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 7m49s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-update-ag-cluster + Normal UpdatePetSets 7m26s KubeDB Ops-manager Operator successfully reconciled the MSSQLServer with updated version + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m21s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 7m21s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-0 7m16s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-0 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 6m46s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-0 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m41s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m41s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-1 6m36s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-1 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 6m6s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-1 + Warning get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 6m1s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 6m1s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Warning check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-2 5m56s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-ag-cluster-2 + Warning check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 5m26s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-ag-cluster-2 + Normal RestartPods 5m21s KubeDB Ops-manager Operator Successfully Restarted MSSQLServer pods + Normal Starting 5m21s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-ag-cluster + Normal Successful 5m21s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-ag-cluster for MSSQLServerOpsRequest: msops-update-ag-cluster +``` + +Now, we are going to verify whether the `MSSQLServer` and the related `PetSets` and their `Pods` have the new version image. Let's check, + +```bash +$ kubectl get ms -n demo mssql-ag-cluster -o=jsonpath='{.spec.version}{"\n"}' +2022-cu14 + +$ kubectl get petset -n demo mssql-ag-cluster -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04@sha256:c1aa8afe9b06eab64c9774a4802dcd032205d1be785b1fd51e1c0151e7586b74 + +$ kubectl get pods -n demo mssql-ag-cluster-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 +``` + +You can see from above, our `MSSQLServer` ag database cluster has been updated with the new version. So, the updateVersion process is successfully completed. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo mssql-ag-cluster +kubectl delete msops -n demo msops-update-ag-cluster +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/update-version/overview.md b/docs/guides/mssqlserver/update-version/overview.md new file mode 100644 index 0000000000..db2847c9b1 --- /dev/null +++ b/docs/guides/mssqlserver/update-version/overview.md @@ -0,0 +1,54 @@ +--- +title: Updating MSSQLServer Overview +menu: + docs_{{ .version }}: + identifier: ms-updating-overview + name: Overview + parent: mssql-updating + weight: 10 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Updating MSSQLServer version Overview + +This guide will give you an overview on how KubeDB Ops-manager operator update the version of `MSSQLServer` database. + +## Before You Begin + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + +## How update version Process Works + +The following diagram shows how KubeDB Ops-manager operator update the version of `MSSQLServer`. Open the image in a new tab to see the enlarged version. + +
+  updating Process of MSSQLServer +
Fig: Updating Process of MSSQLServer
+
+ +The updating process consists of the following steps: + +1. At first, a user creates a `MSSQLServer` Custom Resource (CR). + +2. `KubeDB` Provisioner operator watches the `MSSQLServer` CR. + +3. When the operator finds a `MSSQLServer` CR, it creates `PetSets` and related necessary resources like secrets, services, etc. + +4. Then, in order to update the version of the `MSSQLServer` the user creates a `MSSQLServerOpsRequest` CR with the desired version. + +5. `KubeDB` Ops-manager operator watches the `MSSQLServerOpsRequest` CR. + +6. When it finds a `MSSQLServerOpsRequest` CR, it halts the `MSSQLServer` object which is referred from the `MSSQLServerOpsRequest`. So, the `KubeDB` Provisioner operator doesn't perform any operations on the `MSSQLServer` object during the updating process. + +7. By looking at the target version from `MSSQLServerOpsRequest` CR, `KubeDB` Ops-manager operator updates the images of the `PetSet`. + +8. After successfully updating the `PetSet` and their `Pods` images, the `KubeDB` Ops-manager operator updates the image of the `MSSQLServer` object to reflect the updated state of the database. + +9. After successfully updating of `MSSQLServer` object, the `KubeDB` Ops-manager operator resumes the `MSSQLServer` object so that the `KubeDB` Provisioner operator can resume its usual operations. + +In the next doc, we are going to show a step-by-step guide on updating of a MSSQLServer using UpdateVersion operation. \ No newline at end of file diff --git a/docs/guides/mssqlserver/update-version/standalone.md b/docs/guides/mssqlserver/update-version/standalone.md new file mode 100644 index 0000000000..3fa059fd55 --- /dev/null +++ b/docs/guides/mssqlserver/update-version/standalone.md @@ -0,0 +1,306 @@ +--- +title: Updating MSSQLServer Standalone +menu: + docs_{{ .version }}: + identifier: ms-updating-standalone + name: Standalone + parent: mssql-updating + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# Update Version of MSSQLServer Standalone + +This guide will show you how to use `KubeDB` Ops-manager operator to update the version of `MSSQLServer` standalone. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Updating Overview](/docs/guides/mssqlserver/update-version/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +> **Note:** YAML files used in this tutorial are stored in [docs/examples/mssqlserver](/docs/examples/mssqlserver/update-version) directory of [kubedb/docs](https://github.com/kube/docs) repository. + +### Prepare MSSQLServer Standalone Database + +Now, we are going to deploy a `MSSQLServer` standalone database with version `2022-cu12`. + +### Deploy MSSQLServer Standalone + +In this section, we are going to deploy a MSSQLServer standalone database. Then, in the next section we will update the version of the database using `MSSQLServerOpsRequest` CR. + +At first, we need to create an Issuer/ClusterIssuer which will be used to generate the certificate used for TLS configurations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + + +### Create MSSSQLServer + +Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + storage: + storageClassName: "standard" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/mssql-standalone.yaml +mssqlserver.kubedb.com/mssql-standalone created +``` + +Now, wait until `mssql-standalone` created has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo +NAME VERSION STATUS AGE +mssql-standalone 2022-cu12 Ready 3m8s +``` + +We are now ready to apply the `MSSQLServerOpsRequest` CR to update this database. + +### Update MSSQLServer Version + +Here, we are going to update `MSSQLServer` standalone from `2022-cu12` to `2022-cu14`. + +#### Create MSSQLServerOpsRequest: + +In order to update the standalone database, we have to create a `MSSQLServerOpsRequest` CR with our desired version that is supported by `KubeDB`. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: msops-update-standalone + namespace: demo +spec: + type: UpdateVersion + databaseRef: + name: mssql-standalone + updateVersion: + targetVersion: 2022-cu14 + timeout: 5m + apply: IfReady +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing operation on `mssql-standalone` database. +- `spec.type` specifies that we are going to perform `UpdateVersion` on our database. +- `spec.updateVersion.targetVersion` specifies the expected version of the database `2022-cu14`. +- Have a look [here](/docs/guides/mssqlserver/concepts/opsrequest.md#spectimeout) on the respective sections to understand the `timeout` & `apply` fields. + + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/update-version/msops-update-standalone.yaml +mssqlserveropsrequest.ops.kubedb.com/msops-update-standalone created +``` + +#### Verify MSSQLServer version updated successfully : + +If everything goes well, `KubeDB` Ops-manager operator will update the image of `MSSQLServer` object and related `PetSets` and `Pods`. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ watch kubectl get mssqlserveropsrequest -n demo +Every 2.0s: kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +msops-update-standalone UpdateVersion Successful 2m28s +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to update the database. + +```bash +$ kubectl describe mssqlserveropsrequest -n demo msops-update-standalone +Name: msops-update-standalone +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-12T12:46:07Z + Generation: 1 + Resource Version: 328223 + UID: 7038611f-8ebe-4fb9-8f79-1d73e9669445 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-standalone + Timeout: 5m + Type: UpdateVersion + Update Version: + Target Version: 2022-cu14 +Status: + Conditions: + Last Transition Time: 2024-11-12T12:46:07Z + Message: MSSQLServer ops-request has started to update version + Observed Generation: 1 + Reason: UpdateVersion + Status: True + Type: UpdateVersion + Last Transition Time: 2024-11-12T12:46:16Z + Message: successfully reconciled the MSSQLServer with updated version + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-12T12:46:21Z + Message: get pod; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: GetPod--mssql-standalone-0 + Last Transition Time: 2024-11-12T12:46:21Z + Message: evict pod; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: EvictPod--mssql-standalone-0 + Last Transition Time: 2024-11-12T12:48:16Z + Message: check pod running; ConditionStatus:True; PodName:mssql-standalone-0 + Observed Generation: 1 + Status: True + Type: CheckPodRunning--mssql-standalone-0 + Last Transition Time: 2024-11-12T12:48:21Z + Message: Successfully Restarted MSSQLServer pods + Observed Generation: 1 + Reason: RestartPods + Status: True + Type: RestartPods + Last Transition Time: 2024-11-12T12:48:21Z + Message: Successfully updated MSSQLServer + Observed Generation: 1 + Reason: UpdateDatabase + Status: True + Type: UpdateDatabase + Last Transition Time: 2024-11-12T12:48:21Z + Message: Successfully updated MSSQLServer version + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Starting 2m42s KubeDB Ops-manager Operator Start processing for MSSQLServerOpsRequest: demo/msops-update-standalone + Normal Starting 2m42s KubeDB Ops-manager Operator Pausing MSSQLServer database: demo/mssql-standalone + Normal Successful 2m42s KubeDB Ops-manager Operator Successfully paused MSSQLServer database: demo/mssql-standalone for MSSQLServerOpsRequest: msops-update-standalone + Normal UpdatePetSets 2m33s KubeDB Ops-manager Operator successfully reconciled the MSSQLServer with updated version + Warning get pod; ConditionStatus:True; PodName:mssql-standalone-0 2m28s KubeDB Ops-manager Operator get pod; ConditionStatus:True; PodName:mssql-standalone-0 + Warning evict pod; ConditionStatus:True; PodName:mssql-standalone-0 2m28s KubeDB Ops-manager Operator evict pod; ConditionStatus:True; PodName:mssql-standalone-0 + Warning check pod running; ConditionStatus:False; PodName:mssql-standalone-0 2m23s KubeDB Ops-manager Operator check pod running; ConditionStatus:False; PodName:mssql-standalone-0 + Warning check pod running; ConditionStatus:True; PodName:mssql-standalone-0 33s KubeDB Ops-manager Operator check pod running; ConditionStatus:True; PodName:mssql-standalone-0 + Normal RestartPods 28s KubeDB Ops-manager Operator Successfully Restarted MSSQLServer pods + Normal Starting 28s KubeDB Ops-manager Operator Resuming MSSQLServer database: demo/mssql-standalone + Normal Successful 28s KubeDB Ops-manager Operator Successfully resumed MSSQLServer database: demo/mssql-standalone for MSSQLServerOpsRequest: msops-update-standalone +``` + +Now, we are going to verify whether the `MSSQLServer` and the related `PetSets` their `Pods` have the new version image. Let's check, + +```bash +$ kubectl get ms -n demo mssql-standalone -o=jsonpath='{.spec.version}{"\n"}' +2022-cu14 + +$ kubectl get petset -n demo mssql-standalone -o=jsonpath='{.spec.template.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04@sha256:c1aa8afe9b06eab64c9774a4802dcd032205d1be785b1fd51e1c0151e7586b74 + +$ kubectl get pods -n demo mssql-standalone-0 -o=jsonpath='{.spec.containers[0].image}{"\n"}' +mcr.microsoft.com/mssql/server:2022-CU14-ubuntu-22.04 +``` + +You can see from above, our `MSSQLServer` standalone database has been updated with the new version. So, the update process is successfully completed. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + +```bash +kubectl delete ms -n demo mssql-standalone +kubectl delete msops -n demo msops-update-standalone +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` \ No newline at end of file diff --git a/docs/guides/mssqlserver/volume-expansion/_index.md b/docs/guides/mssqlserver/volume-expansion/_index.md index 899484bfd1..e8ef67d309 100644 --- a/docs/guides/mssqlserver/volume-expansion/_index.md +++ b/docs/guides/mssqlserver/volume-expansion/_index.md @@ -5,6 +5,6 @@ menu: identifier: ms-volume-expansion name: Volume Expansion parent: guides-mssqlserver - weight: 42 + weight: 60 menu_name: docs_{{ .version }} --- diff --git a/docs/guides/mssqlserver/volume-expansion/volume-expansion.md b/docs/guides/mssqlserver/volume-expansion/ag_cluster.md similarity index 97% rename from docs/guides/mssqlserver/volume-expansion/volume-expansion.md rename to docs/guides/mssqlserver/volume-expansion/ag_cluster.md index 4bf7d105e2..fc8ba8a0fe 100644 --- a/docs/guides/mssqlserver/volume-expansion/volume-expansion.md +++ b/docs/guides/mssqlserver/volume-expansion/ag_cluster.md @@ -1,11 +1,11 @@ --- -title: MSSQLServer Volume Expansion +title: Availability Group (HA Cluster) Volume Expansion menu: docs_{{ .version }}: - identifier: mssqlserver-volume-expansion-guide - name: MSSQLServer Volume Expansion + identifier: volume-expansion-guide-ag-cluster + name: Availability Group (HA Cluster) parent: ms-volume-expansion - weight: 20 + weight: 30 menu_name: docs_{{ .version }} section_menu_id: guides --- @@ -14,7 +14,7 @@ section_menu_id: guides # MSSQLServer Volume Expansion -This guide will show you how to use `KubeDB` Ops-manager operator to expand the volume of a MSSQLServer. +This guide will show you how to use `KubeDB` Ops-manager operator to expand the volume of a SQL Server Availability Group Cluster. ## Before You Begin @@ -38,11 +38,11 @@ $ kubectl create ns demo namespace/demo created ``` -## Expand Volume of MSSQLServer +## Expand Volume of MSSQLServer Availability Group Cluster Here, we are going to deploy a `MSSQLServer` cluster using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to expand its volume. The process of expanding MSSQLServer `standalone` is same as MSSQLServer Availability Group cluster. -### Prepare MSSQLServer +### Prepare MSSQLServer Availability Group Cluster At first verify that your cluster has a storage class, that supports volume expansion. Let's check, diff --git a/docs/guides/mssqlserver/volume-expansion/standalone.md b/docs/guides/mssqlserver/volume-expansion/standalone.md new file mode 100644 index 0000000000..8cc2596a8a --- /dev/null +++ b/docs/guides/mssqlserver/volume-expansion/standalone.md @@ -0,0 +1,381 @@ +--- +title: Standalone Volume Expansion +menu: + docs_{{ .version }}: + identifier: volume-expansion-guide-standalone + name: Standalone + parent: ms-volume-expansion + weight: 20 +menu_name: docs_{{ .version }} +section_menu_id: guides +--- + +> New to KubeDB? Please start [here](/docs/README.md). + +# MSSQLServer Volume Expansion + +This guide will show you how to use `KubeDB` Ops-manager operator to expand the volume of a SQL Server Standalone. + +## Before You Begin + +- You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using [kind](https://kind.sigs.k8s.io/docs/user/quick-start/). + +- Now, install KubeDB cli on your workstation and KubeDB operator in your cluster following the steps [here](/docs/setup/README.md). Make sure install with helm command including `--set global.featureGates.MSSQLServer=true` to ensure MSSQLServer CRD installation. + +- To configure TLS/SSL in `MSSQLServer`, `KubeDB` uses `cert-manager` to issue certificates. So first you have to make sure that the cluster has `cert-manager` installed. To install `cert-manager` in your cluster following steps [here](https://cert-manager.io/docs/installation/kubernetes/). + +- You must have a `StorageClass` that supports volume expansion. + +- You should be familiar with the following `KubeDB` concepts: + - [MSSQLServer](/docs/guides/mssqlserver/concepts/mssqlserver.md) + - [MSSQLServerOpsRequest](/docs/guides/mssqlserver/concepts/opsrequest.md) + - [Volume Expansion Overview](/docs/guides/mssqlserver/volume-expansion/overview.md) + +To keep everything isolated, we are going to use a separate namespace called `demo` throughout this tutorial. + +```bash +$ kubectl create ns demo +namespace/demo created +``` + +## Expand Volume of MSSQLServer + +Here, we are going to deploy a `MSSQLServer` standalone using a supported version by `KubeDB` operator. Then we are going to apply `MSSQLServerOpsRequest` to expand its volume. The process of expanding MSSQLServer `standalone` is same as MSSQLServer Availability Group cluster. + +### Prepare MSSQLServer Standalone + +At first verify that your cluster has a storage class, that supports volume expansion. Let's check, + +```bash +$ kubectl get storageclass +NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE +local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 2d +longhorn (default) driver.longhorn.io Delete Immediate true 3m25s +longhorn-static driver.longhorn.io Delete Immediate true 3m19s +``` + +We can see from the output that `longhorn (default)` storage class has `ALLOWVOLUMEEXPANSION` field as true. So, this storage class supports volume expansion. We will use this storage class. + + +Now, we are going to deploy a `MSSQLServer` in `AvailabilityGroup` Mode with version `2022-cu12`. + +### Deploy MSSQLServer Standalone + +First, an issuer needs to be created, even if TLS is not enabled for SQL Server. The issuer will be used to configure the TLS-enabled Wal-G proxy server, which is required for the SQL Server backup and restore operations. + +### Create Issuer/ClusterIssuer + +Now, we are going to create an example `Issuer` that will be used throughout the duration of this tutorial. Alternatively, you can follow this [cert-manager tutorial](https://cert-manager.io/docs/configuration/ca/) to create your own `Issuer`. By following the below steps, we are going to create our desired issuer, + +- Start off by generating our ca-certificates using openssl, +```bash +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./ca.key -out ./ca.crt -subj "/CN=MSSQLServer/O=kubedb" +``` +- Create a secret using the certificate files we have just generated, +```bash +$ kubectl create secret tls mssqlserver-ca --cert=ca.crt --key=ca.key --namespace=demo +secret/mssqlserver-ca created +``` +Now, we are going to create an `Issuer` using the `mssqlserver-ca` secret that contains the ca-certificate we have just created. Below is the YAML of the `Issuer` CR that we are going to create, + +```yaml +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: mssqlserver-ca-issuer + namespace: demo +spec: + ca: + secretName: mssqlserver-ca +``` + +Let’s create the `Issuer` CR we have shown above, +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/standalone/mssqlserver-ca-issuer.yaml +issuer.cert-manager.io/mssqlserver-ca-issuer created +``` + +In this section, we are going to deploy a MSSQLServer Standalone with 1GB volume. Then, in the next section we will expand its volume to 2GB using `MSSQLServerOpsRequest` CRD. Below is the YAML of the `MSSQLServer` CR that we are going to create, + +```yaml +apiVersion: kubedb.com/v1alpha2 +kind: MSSQLServer +metadata: + name: mssql-standalone + namespace: demo +spec: + version: "2022-cu12" + replicas: 1 + storageType: Durable + tls: + issuerRef: + name: mssqlserver-ca-issuer + kind: Issuer + apiGroup: "cert-manager.io" + clientTLS: false + podTemplate: + spec: + containers: + - name: mssql + env: + - name: ACCEPT_EULA + value: "Y" + - name: MSSQL_PID + value: Evaluation + resources: + requests: + cpu: "500m" + memory: "1.5Gi" + limits: + memory: "2Gi" + storage: + storageClassName: "longhorn" + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + deletionPolicy: WipeOut +``` + +Let's create the `MSSQLServer` CR we have shown above, + +```bash +$ kubectl create -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/examples/mssqlserver/volume-expansion/mssql-standalone.yaml +mssqlserver.kubedb.com/mssql-standalone created +``` + +Now, wait until `mssql-standalone` has status `Ready`. i.e, + +```bash +$ kubectl get ms -n demo mssql-standalone +NAME VERSION STATUS AGE +mssql-standalone 2022-cu12 Ready 5m +``` + +Let's check volume size from petset, and from the persistent volume, + +```bash +$ kubectl get petset -n demo mssql-standalone -o json | jq '.spec.volumeClaimTemplates[].spec.resources.requests.storage' +"1Gi" + +$ kubectl get pv -n demo +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE +pvc-7e7ed996-b682-4d84-8450-4c06fe92b11f 1Gi RWO Delete Bound demo/data-mssql-standalone-0 longhorn 5m29s +``` + +You can see the petset has 1GB storage, and the capacity of all the persistent volumes are also 1GB. + +We are now ready to apply the `MSSQLServerOpsRequest` CR to expand the volume of this database. + +### Volume Expansion + +Here, we are going to expand the volume of the MSSQLServer Standalone. + +#### Create MSSQLServerOpsRequest + +In order to expand the volume of the database, we have to create a `MSSQLServerOpsRequest` CR with our desired volume size. Below is the YAML of the `MSSQLServerOpsRequest` CR that we are going to create, + +```yaml +apiVersion: ops.kubedb.com/v1alpha1 +kind: MSSQLServerOpsRequest +metadata: + name: mops-volume-exp-std + namespace: demo +spec: + type: VolumeExpansion + databaseRef: + name: mssql-standalone + volumeExpansion: + mode: "Offline" # Online + mssqlserver: 2Gi +``` + +Here, + +- `spec.databaseRef.name` specifies that we are performing volume expansion operation on `mssql-standalone` database. +- `spec.type` specifies that we are performing `VolumeExpansion` on our database. +- `spec.volumeExpansion.mssqlserver` specifies the desired volume size. +- `spec.volumeExpansion.mode` specifies the desired volume expansion mode (`Online` or `Offline`). Storageclass `longhorn` supports `Offline` volume expansion. + +> **Note:** If the Storageclass you are using support `Online` Volume Expansion, Try Online volume expansion by using `spec.volumeExpansion.mode:"Online"`. + +During `Online` VolumeExpansion KubeDB expands volume without deleting the pods, it directly updates the underlying PVC. And for Offline volume expansion, the database is paused. The Pods are deleted and PVC is updated. Then the database Pods are recreated with updated PVC. + + +Let's create the `MSSQLServerOpsRequest` CR we have shown above, + +```bash +$ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/example/mssqlserver/volume-expansion/mops-volume-exp-std.yaml +mssqlserveropsrequest.ops.kubedb.com/mops-volume-exp-std created +``` + +#### Verify MSSQLServer volume expanded successfully + +If everything goes well, `KubeDB` Ops-manager operator will update the volume size of `MSSQLServer` object and related `PetSet` and `Persistent Volumes`. + +Let's wait for `MSSQLServerOpsRequest` to be `Successful`. Run the following command to watch `MSSQLServerOpsRequest` CR, + +```bash +$ kubectl get mssqlserveropsrequest -n demo +NAME TYPE STATUS AGE +mops-volume-exp-std VolumeExpansion Successful 9m +``` + +We can see from the above output that the `MSSQLServerOpsRequest` has succeeded. If we describe the `MSSQLServerOpsRequest` we will get an overview of the steps that were followed to expand the volume of the database. + +```bash +$ kubectl describe msops -n demo mops-volume-exp-std +Name: mops-volume-exp-std +Namespace: demo +Labels: +Annotations: +API Version: ops.kubedb.com/v1alpha1 +Kind: MSSQLServerOpsRequest +Metadata: + Creation Timestamp: 2024-11-13T05:13:02Z + Generation: 1 + Resource Version: 2235347 + UID: e9d3733d-f472-406f-ade4-c92eea771d61 +Spec: + Apply: IfReady + Database Ref: + Name: mssql-standalone + Type: VolumeExpansion + Volume Expansion: + Mode: Offline + Mssqlserver: 2Gi +Status: + Conditions: + Last Transition Time: 2024-11-13T05:13:02Z + Message: MSSQLServer ops-request has started to expand volume of mssqlserver nodes. + Observed Generation: 1 + Reason: VolumeExpansion + Status: True + Type: VolumeExpansion + Last Transition Time: 2024-11-13T05:13:40Z + Message: get petset; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPetset + Last Transition Time: 2024-11-13T05:13:40Z + Message: delete petset; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: DeletePetset + Last Transition Time: 2024-11-13T05:13:50Z + Message: successfully deleted the petSets with orphan propagation policy + Observed Generation: 1 + Reason: OrphanPetSetPods + Status: True + Type: OrphanPetSetPods + Last Transition Time: 2024-11-13T05:19:00Z + Message: get pod; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPod + Last Transition Time: 2024-11-13T05:13:55Z + Message: patch ops request; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: PatchOpsRequest + Last Transition Time: 2024-11-13T05:13:55Z + Message: delete pod; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: DeletePod + Last Transition Time: 2024-11-13T05:19:00Z + Message: get pvc; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPvc + Last Transition Time: 2024-11-13T05:19:00Z + Message: patch pvc; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: PatchPvc + Last Transition Time: 2024-11-13T05:19:20Z + Message: compare storage; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: CompareStorage + Last Transition Time: 2024-11-13T05:19:20Z + Message: create pod; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: CreatePod + Last Transition Time: 2024-11-13T05:19:25Z + Message: running mssql server; ConditionStatus:False + Observed Generation: 1 + Status: False + Type: RunningMssqlServer + Last Transition Time: 2024-11-13T05:19:45Z + Message: successfully updated node PVC sizes + Observed Generation: 1 + Reason: UpdateNodePVCs + Status: True + Type: UpdateNodePVCs + Last Transition Time: 2024-11-13T05:19:50Z + Message: successfully reconciled the MSSQLServer resources + Observed Generation: 1 + Reason: UpdatePetSets + Status: True + Type: UpdatePetSets + Last Transition Time: 2024-11-13T05:19:55Z + Message: get pet set; ConditionStatus:True + Observed Generation: 1 + Status: True + Type: GetPetSet + Last Transition Time: 2024-11-13T05:19:55Z + Message: PetSet is recreated + Observed Generation: 1 + Reason: ReadyPetSets + Status: True + Type: ReadyPetSets + Last Transition Time: 2024-11-13T05:19:55Z + Message: Successfully completed volumeExpansion for MSSQLServer + Observed Generation: 1 + Reason: Successful + Status: True + Type: Successful + Observed Generation: 1 + Phase: Successful +``` + +Now, we are going to verify from the `Petset`, and the `Persistent Volumes` whether the volume of the database has expanded to meet the desired state, Let's check, + +```bash +$ kubectl get petset -n demo mssql-standalone -o json | jq '.spec.volumeClaimTemplates[].spec.resources.requests.storage' +"2Gi" + +$ kubectl get pv -n demo +NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE +pvc-7e7ed996-b682-4d84-8450-4c06fe92b11f 2Gi RWO Delete Bound demo/data-mssql-standalone-0 longhorn 26m +``` + +The above output verifies that we have successfully expanded the volume of the MSSQLServer Standalone database. + +## Cleaning Up + +To clean up the Kubernetes resources created by this tutorial, run: + + +```bash +$ kubectl patch -n demo ms/mssql-standalone -p '{"spec":{"deletionPolicy":"WipeOut"}}' --type="merge" +mssqlserver.kubedb.com/mssql-standalone patched + +$ kubectl delete -n demo mssqlserver mssql-standalone +mssqlserver.kubedb.com "mssql-standalone" deleted + +$ kubectl delete -n demo mssqlserveropsrequest mops-volume-exp-std +mssqlserveropsrequest.ops.kubedb.com "mops-volume-exp-std" deleted + +kubectl delete issuer -n demo mssqlserver-ca-issuer +kubectl delete secret -n demo mssqlserver-ca +kubectl delete ns demo +``` + +## Next Steps + +- Detail concepts of [MSSQLServer object](/docs/guides/mssqlserver/concepts/mssqlserver.md). +- [Backup and Restore](/docs/guides/mssqlserver/backup/overview/index.md) MSSQLServer databases using KubeStash. \ No newline at end of file diff --git a/docs/images/day-2-operation/mssqlserver/ms-reconfigure.png b/docs/images/day-2-operation/mssqlserver/ms-reconfigure.png new file mode 100644 index 0000000000..af8b0b93f6 Binary files /dev/null and b/docs/images/day-2-operation/mssqlserver/ms-reconfigure.png differ diff --git a/docs/images/day-2-operation/mssqlserver/ms-update-version.png b/docs/images/day-2-operation/mssqlserver/ms-update-version.png new file mode 100644 index 0000000000..94888b6355 Binary files /dev/null and b/docs/images/day-2-operation/mssqlserver/ms-update-version.png differ