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 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