Zum Hauptinhalt springen

Cloud SQL

Cloud SQL ist ein Dienst der Google Cloud Platform (GCP) der es Kunden ermöglicht MySQL- oder Postgres-Datenbanken zu betreiben.

Details​

Kunden, die eine verwaltete Datenbank benötigen um ihre Applikationsdaten zu speichern, können Cloud SQL als skalierbaren Dienst beziehen und diesen voll integriert in ihrem nine Managed GKE Cluster nutzen.

Verfügbarkeit​

Um eine Cloud SQL-Datenbank zu beziehen melden Sie sich bitte per E-Mail bei info@nine.ch.

Nutzung​

Sobald Sie eine Cloud SQL zur Nutzung in Ihrem Cluster bereitgestellt bekommen haben, finden Sie die Zugangsdaten auf runway. Mit Zugriff auf den Cloud SQL-Dienst können Sie Ihre Anwendung regulär konfigurieren.

Datensicherung und Wartungsfenster​

Die Backups werden in der gleichen Region wie der Cluster abgespeichert. Beispielsweise, wenn der Cluster in Zürich ist, bleiben die Backups in Zürich. Zusätzlich werden die Backups auf die Zonen (z.B. a, b und c) über die Region verteilt.

Die Daten in Ihrem Cloud SQL-Dienst werden wie folgt gesichert:

  • Das Zeitfenster für die Datensicherung beginnt täglich um 00:00 UTC.
  • Das Wartungsfenster beginnt jeden Montag um 02:00 UTC.
  • Die Wiederherstellung kann vie E-Mail unter support@nine.ch beauftragt werden.
  • Die Wiederherstellung kann entweder direkt erfolgen, indem die bestehenden Daten überschrieben werden, oder durch Bereitstellung der Daten unter einem neuen Datenbank-Namen, was eine selektive und manuelle Wiederherstellung durch den Kunden erlaubt.
  • automatisch erstellte Backups werden 7 Tage lang gespeichert

Zugriff auf Ihre Cloud SQL Instanz​

Da alle unsere Cloud SQL Instanzen lediglich private IPs besitzen, können Sie standardmässig nicht direkt von Ihrem Computer auf die Instanz zugreifen (lediglich Zugriffe vom nine Managed GKE Cluster sind möglich). Es existieren jedoch einige Möglichkeiten um einen externen Zugriff zu gewährleisten:

  • Starten Sie eine Web Applikation in ihrem nine Managed GKE Cluster, mit welcher Sie Ihre Cloud SQL Instanz managen können (bspw. phpmyadmin, pgadmin, etc).
  • Wir können eine VPN Verbindung von ihrem Standort zur google VPC für Sie errichten. Mit diesem VPN können Sie die Cloud SQL Instanzen direkt erreichen. Bitte beachten Sie, dass dafür entsprechende VPN Hardware an Ihrem Standort verfügbar sein muss.
  • Sie können auch eine Reverse Proxy Applikation in Ihrem nine Managed GKE Cluster deployen um mittels dieser und kubectl port-forward ihre Cloud SQL Instanz zu erreichen.
  • Wir können Ihrer Instanz eine Öffentliche IPv4 Adresse vergeben und falls erwünscht den Zugriff auf gewisse Netzwerke einschränken. Bitte kontaktieren Sie uns, falls wir das konfigurieren sollten.

Proxy Pod Beispiel​

Durch die Verwendung eines TCP Reverse Proxies und kubectl's Port Forwarding Feature (welche die Verbindung zum Proxy Pod automatisch verschlüsselt) können Sie ihre Cloud SQL Instanz auch ausserhalb der google VPC erreichen. Im folgenden finden Sie ein Beispiel Kubernetes Manifest. Dieses beinhaltet ein Reverse Proxy Deployment welches Traffic auf 2 Cloud SQL mysql DBMS Instanzen weiterleitet (Staging und Produktion). Im Beispiel nutzen wir dafür die Software Gobetween, aber andere TCP Reverse Proxies können ebenfalls genutzt werden. Bitte passen Sie die entsprechenden Werte im "discovery" Bereich der Konfiguration an. Die dort aufgeführten Binding Ports sind lediglich Beispiele. Diese können geändert werden, sollten aber grösser als 1024 sein. Bitte vergessen Sie auch nicht die entsprechenden Container Ports im Deployment anzupassen, falls Sie Änderungen vornehmen. Sie können die privaten IP Adressen ihrer Cloud SQL Instanzen auf runway einsehen. Falls Sie Cloud SQL postgresql DBMS Instanzen einsetzen, so sollten Sie die Zielports in der "discovery" Sektion der Konfiguration anpassen.

  • Erstellen Sie eine Datei manifest.yaml mit folgendem Inhalt
apiVersion: v1
kind: ConfigMap
metadata:
  name: sql-connect-cm
data:
  config.toml: |-
    [servers.db-prod]
    bind = "0.0.0.0:9991"
    protocol = "tcp"

    [servers.db-prod.discovery]
    kind = "static"
    static_list = [
        "<cloudsql_private_ip_db1>:3306",
    ]
    [servers.db-staging]
    bind = "0.0.0.0:9992"
    protocol = "tcp"

    [servers.db-staging.discovery]
    kind = "static"
    static_list = [
        "<cloudsql_private_ip_db2>:3306",
    ]
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sql-connect
  labels:
    app: sql-connect
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sql-connect
  template:
    metadata:
      labels:
        app: sql-connect
    spec:
      containers:
        - name: sql-connect
          ports:
            - containerPort: 9991
            - containerPort: 9992
          volumeMounts:
            - name: config-volume
              mountPath: /etc/gobetween/conf
          image: yyyar/gobetween
      volumes:
        - name: config-volume
          configMap:
            name: sql-connect-cm
            items:
              - key: config.toml
                path: gobetween.toml
---
apiVersion: v1
kind: Service
metadata:
  name: access-db-prod
spec:
  selector:
    app: sql-connect
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 9991
---
apiVersion: v1
kind: Service
metadata:
  name: access-db-staging
spec:
  selector:
    app: sql-connect
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 9992
  • Applizieren Sie diese Datei in einem Namespace ihrer Wahl
   kubectl create ns <namespace>
   kubectl create -f manifest.yaml -n <namespace>
  • Konfigurieren Sie eine lokale Port Weiterleitung
# prod DB:
kubectl port-forward -n <namespace> svc/access-db-prod 3306 &
# staging DB:
kubectl port-forward -n <namespace> svc/access-db-staging 3307:3306 &

Bitte beachten Sie, dass das Port Forwarding nicht persistiert ist. Nach einem Reboot muss es wiederhergestellt werden.

  • Sie können nun auf das Produktions DBMS zugreifen
   mysql -u <user> --host 127.0.0.1 -p
  • Das staging DBMS kann wie folgt erreicht werden
   mysql -u <user> --port 3307 --host 127.0.0.1 -p