Verbindung über den Cloud SQL Auth-Proxy herstellen

Auf dieser Seite wird gezeigt, wie Sie mithilfe des Cloud SQL Auth-Proxys eine Verbindung zu Ihrer Cloud SQL-Instanz herstellen.

Weitere Informationen über die Funktionsweise des Cloud SQL Auth-Proxys finden Sie unter Informationen zum Cloud SQL Auth-Proxy.

Überblick

Für die Verbindung mit einer Cloud SQL-Instanz wird die Verwendung des Cloud SQL Auth-Proxys empfohlen. Der Cloud SQL Auth-Proxy:

  • Funktioniert mit öffentlichen wie mit privaten IP-Endpunkten
  • Validiert Verbindungen mithilfe von Anmeldedaten für einen Nutzer oder ein Dienstkonto
  • Verpackt die Verbindung in einer SSL/TLS-Ebene, die für eine Cloud SQL-Instanz autorisiert ist

Einige Google Cloud-Dienste und -Anwendungen verwenden den Cloud SQL Auth-Proxy, um Verbindungen für öffentliche IP-Pfade mit Verschlüsselung und Autorisierung bereitzustellen, darunter:

In Google Kubernetes Engine ausgeführte Anwendungen können eine Verbindung über den Cloud SQL Auth-Proxy herstellen.

Eine kurze Einführung in die Verwendung des Cloud SQL Auth-Proxys finden Sie unter Kurzanleitung.

Sie können die Verbindung auch mit oder ohne den Cloud SQL Auth-Proxy über einen sqlcmd-Client von einem lokalen Computer oder von Compute Engine herstellen.

Hinweise

Bevor Sie eine Verbindung zu einer Cloud SQL-Instanz herstellen können, müssen Sie Folgendes tun:

    • Achten Sie darauf, dass das Konto für einen Nutzer oder ein Dienstkonto die Rolle "Cloud SQL-Client" hat. Diese Rolle enthält die Berechtigung cloudsql.instances.connect, mit der ein Hauptkonto autorisiert wird, zu allen Cloud SQL-Instanzen in einem Projekt eine Verbindung herzustellen.

      Zur IAM-Seite

    • Sie können optional eine IAM-Bedingung in die IAM-Richtlinienbindung aufnehmen, die dem Konto die Berechtigung erteilt, eine Verbindung nur zu einer bestimmten Cloud SQL-Instanz herzustellen.
  1. Cloud SQL Admin API aktivieren.

    Aktivieren Sie die API

  2. Installieren und initialisieren Sie die gcloud CLI.
  3. Optional. Installieren Sie den Cloud SQL Auth-Proxy-Docker-Client.

Laden Sie den Cloud SQL Auth-Proxy herunter

Linux 64-Bit

  1. Laden Sie den Cloud SQL Auth-Proxy herunter:
    curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.10.1/cloud-sql-proxy.linux.amd64
    
  2. Machen Sie den Cloud SQL Auth-Proxy ausführbar:
    chmod +x cloud-sql-proxy
    

Linux 32-Bit

  1. Laden Sie den Cloud SQL Auth-Proxy herunter:
    curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.10.1/cloud-sql-proxy.linux.386
    
  2. Wenn der Befehl curl nicht gefunden wird, führen Sie sudo apt install curl aus und wiederholen Sie den Downloadbefehl.
  3. Machen Sie den Cloud SQL Auth-Proxy ausführbar:
    chmod +x cloud-sql-proxy
    

macOS 64-Bit

  1. Laden Sie den Cloud SQL Auth-Proxy herunter:
    curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.10.1/cloud-sql-proxy.darwin.amd64
    
  2. Machen Sie den Cloud SQL Auth-Proxy ausführbar:
    chmod +x cloud-sql-proxy
    

Mac M1

  1. Laden Sie den Cloud SQL Auth-Proxy herunter:
      curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.10.1/cloud-sql-proxy.darwin.arm64
      
  2. Machen Sie den Cloud SQL Auth-Proxy ausführbar:
      chmod +x cloud-sql-proxy
      

Windows 64-Bit

Klicken Sie mit der rechten Maustaste auf https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.10.1/cloud-sql-proxy.x64.exe und wählen Sie Link speichern unter aus, um den Cloud SQL Auth-Proxy herunterzuladen. Benennen Sie die Datei in cloud-sql-proxy.exe um.

Windows 32-Bit

Klicken Sie mit der rechten Maustaste auf https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.10.1/cloud-sql-proxy.x86.exe und wählen Sie Link speichern unter aus, um den Cloud SQL Auth-Proxy herunterzuladen. Benennen Sie die Datei in cloud-sql-proxy.exe um.

Docker-Image des Cloud SQL Auth-Proxys

Der Cloud SQL Auth-Proxy hat verschiedene Container-Images, z. B. distroless, alpine und buster. Das standardmäßige Cloud SQL Auth-Proxy-Container-Image verwendet distroless, das keine Shell enthält. Wenn Sie eine Shell oder verwandte Tools benötigen, laden Sie ein auf alpine oder buster basierendes Image herunter. Weitere Informationen finden Sie unter Container-Images von Cloud SQL Auth-Proxy.

Sie können das neueste Image mithilfe von Docker mit dem folgenden Befehl auf Ihren lokalen Computer übertragen:

docker pull gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.10.1

Andere Betriebssysteme

Für andere Betriebssysteme, die hier nicht aufgeführt sind, können Sie den Cloud SQL Auth-Proxy aus der Quelle kompilieren.

Cloud SQL Auth-Proxy starten

Sie können den Cloud SQL Auth-Proxy mit TCP-Sockets oder dem Cloud SQL Auth Proxy-Docker-Image starten. Das Cloud SQL Auth-Proxy-Binärprogramm stellt eine Verbindung zu einer oder mehreren Cloud SQL-Instanzen her, die in der Befehlszeile angegeben sind, und öffnet eine lokale Verbindung als TCP-Socket. Andere Anwendungen und Dienste, wie z. B. Anwendungscode und Datenbankverwaltungs-Clienttools, können über diese TCP-Socket-Verbindung eine Verbindung zu Cloud SQL-Instanzen herstellen.

TCP-Sockets

Bei TCP-Verbindungen beobachtet der Cloud SQL Auth-Proxy standardmäßig localhost(127.0.0.1). Wenn Sie also --port PORT_NUMBER für eine Instanz angeben, befindet sich die lokale Verbindung auf 127.0.0.1:PORT_NUMBER.

Alternativ können Sie eine andere Adresse für die lokale Verbindung angeben. So können Sie zum Beispiel den Cloud SQL-Auth-Proxy dazu bringen, die lokale Verbindung auf 0.0.0.0:1234 zu beobachten:

./cloud-sql-proxy --address 0.0.0.0 --port 1234 INSTANCE_CONNECTION_NAME
  1. Kopieren Sie Ihren INSTANCE_CONNECTION_NAME. Sie finden ihn in der Google Cloud Console auf der Seite Übersicht für Ihre Instanz oder über den folgenden Befehl:

        gcloud sql instances describe INSTANCE_NAME --format='value(connectionName)'
    .

    Beispiel: myproject:myregion:myinstance.

  2. Wenn für die Instanz sowohl eine öffentliche als auch eine private IP-Adresse konfiguriert ist und der Cloud SQL Auth-Proxy die private IP-Adresse verwenden soll, müssen Sie beim Starten des Cloud SQL Auth-Proxys folgende Option angeben:
    --private-ip
  3. Wenn Sie ein Dienstkonto zur Authentifizierung des Cloud SQL Auth-Proxys verwenden, notieren Sie den Speicherort der Datei mit dem privaten Schlüssel, die zusammen mit dem Dienstkonto erstellt wurde, auf Ihrem Clientcomputer.
  4. Starten Sie den Cloud SQL Auth-Proxy.

    Einige mögliche Strings zum Aufrufen des Cloud SQL Auth-Proxys:

    • Mit Cloud SDK-Authentifizierung:
      ./cloud-sql-proxy --port 1433 INSTANCE_CONNECTION_NAME
      
      Der angegebene Port darf nicht belegt sein (etwa durch einen lokalen Datenbankserver).
    • Mit einem Dienstkonto und unter expliziter Angabe des Namens der Instanzverbindung (empfohlen für Produktionsumgebungen):
      ./cloud-sql-proxy \
      --credentials-file PATH_TO_KEY_FILE INSTANCE_CONNECTION_NAME &
      
      

    Weitere Informationen über Cloud SQL Auth-Proxyoptionen finden Sie unter Authentifizierungsoptionen für den Cloud SQL Auth-Proxy sowie Spezifikationsoptionen für Instanzen.

Docker

Verwenden Sie zum Ausführen des Cloud SQL Auth-Proxys in einem Docker-Container das Cloud SQL Auth-Proxy-Docker-Image, das in der Google Container Registry verfügbar ist.

Sie können den Cloud SQL Auth-Proxy entweder mit TCP-Sockets oder mit Unix-Sockets starten. Dafür werden die folgenden Befehle verwendet. Die Optionen verwenden einen INSTANCE_CONNECTION_NAME als Verbindungsstring, um eine Cloud SQL-Instanz zu identifizieren. Sie finden den INSTANCE_CONNECTION_NAME auf der Seite Übersicht Ihrer Instanz in der Google Cloud Console oder ermitteln ihn über folgenden Befehl:

gcloud sql instances describe INSTANCE_NAME
.

Beispiel: myproject:myregion:myinstance.

Je nach Ihrer Programmiersprache und Umgebung können Sie den Cloud SQL Auth-Proxy entweder mit TCP-Sockets oder mit Unix-Sockets starten. Allerdings werden Unix-Sockets nicht für Anwendungen unterstützt, die in der Programmiersprache Java oder für die Windows-Umgebung geschrieben sind.

TCP-Sockets verwenden

docker run -d \\
  -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \\
  -p 127.0.0.1:1433:1433 \\
  gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.10.1 \\
  --address 0.0.0.0 --port 1433 \\
  --credentials-file /path/to/service-account-key.json INSTANCE_CONNECTION_NAME

Wenn Sie die von Ihrer Compute Engine-Instanz bereitgestellten Anmeldedaten verwenden, geben Sie den Parameter --credentials-file und die Zeile -v PATH_TO_KEY_FILE:/path/to/service-account-key.json nicht an.

Geben Sie in -p immer das Präfix 127.0.0.1 an, damit der Cloud SQL Auth-Proxy nicht außerhalb des lokalen Hosts bereitgestellt wird. Die Angabe "0.0.0.0" im Instanzparameter ist erforderlich, damit von außerhalb des Docker-Containers auf den Port zugegriffen werden kann.

Unix-Sockets verwenden

docker run -d -v /cloudsql:/cloudsql \\
  -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \\
  gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.10.1 --unix-socket=/cloudsql \\
  --credentials-file /path/to/service-account-key.json INSTANCE_CONNECTION_NAME

Wenn Sie die von Ihrer Compute Engine-Instanz bereitgestellten Anmeldedaten verwenden, geben Sie den Parameter --credentials-file und die Zeile -v PATH_TO_KEY_FILE:/path/to/service-account-key.json nicht an.

Wenn Sie ein containeroptimiertes Image verwenden, ersetzen Sie /cloudsql durch ein beschreibbares Verzeichnis. Beispiel:

-v /mnt/stateful_partition/cloudsql:/cloudsql

Sie können mehrere durch Kommas getrennte Instanzen angeben. Außerdem haben Sie die Möglichkeit, mithilfe von Compute Engine-Metadaten dynamisch die Instanzen zu bestimmen, zu denen eine Verbindung hergestellt werden soll. Weitere Informationen zu Cloud SQL Auth-Proxy-Parametern

Mit dem sqlcmd-Client verbinden

Debian/Ubuntu

Für Debian/Ubuntu installieren Sie die entsprechenden SQL Server-Befehlszeilentools.

CentOS/RHEL

Für CentOS/RHEL installieren Sie die entsprechenden SQL Server-Befehlszeilentools.

openSUSE

Für openSUSE installieren Sie die entsprechenden SQL Server-Befehlszeilentools.

Andere Plattformen

Weitere Informationen finden Sie auf der Landingpage zur SQL Server-Installation und der SQL Server-Downloadseite.

Der zu verwendende Verbindungsstring hängt davon ab, ob Sie den Cloud SQL Auth-Proxy mit einem TCP-Socket oder Docker gestartet haben.

TCP-Sockets

  1. Starten Sie den sqlcmd-Client:
    sqlcmd -S tcp:127.0.0.1,1433 -U USERNAME -P PASSWORD
    

    Wenn Sie die Verbindung mithilfe von TCP-Sockets herstellen, greifen Sie über 127.0.0.1 auf den Cloud SQL Auth-Proxy zu.

  2. Geben Sie das Passwort ein, wenn Sie dazu aufgefordert werden.
  3. Die sqlcmd-Eingabeaufforderung wird angezeigt.

Benötigen Sie Hilfe? Informationen zur Fehlerbehebung für den Proxy finden Sie unter Fehlerbehebung bei Cloud SQL Auth-Proxyverbindungen oder auf der Seite Cloud SQL-Support.

Verbindung mit einer Anwendung herstellen

Sie können eine Verbindung mit dem Cloud SQL Auth-Proxy mit jeder Sprache herstellen, die eine Verbindung zu einem TCP-Socket ermöglicht. Unten finden Sie einige Code-Snippets aus vollständigen Beispielen auf GitHub, damit Sie verstehen, wie sie in Ihrer Anwendung zusammenarbeiten.

Verbindung mit TCP herstellen

Anweisung zum Aufrufen des Cloud SQL Auth-Proxys:

./cloud-sql-proxy INSTANCE_CONNECTION_NAME &

Python

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

import os

import sqlalchemy

def connect_tcp_socket() -> sqlalchemy.engine.base.Engine:
    """Initializes a TCP connection pool for a Cloud SQL instance of SQL Server."""
    # Note: Saving credentials in environment variables is convenient, but not
    # secure - consider a more secure solution such as
    # Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
    # keep secrets safe.
    db_host = os.environ[
        "INSTANCE_HOST"
    ]  # e.g. '127.0.0.1' ('172.17.0.1' if deployed to GAE Flex)
    db_user = os.environ["DB_USER"]  # e.g. 'my-db-user'
    db_pass = os.environ["DB_PASS"]  # e.g. 'my-db-password'
    db_name = os.environ["DB_NAME"]  # e.g. 'my-database'
    db_port = os.environ["DB_PORT"]  # e.g. 1433

    pool = sqlalchemy.create_engine(
        # Equivalent URL:
        # mssql+pytds://<db_user>:<db_pass>@<db_host>:<db_port>/<db_name>
        sqlalchemy.engine.url.URL.create(
            drivername="mssql+pytds",
            username=db_user,
            password=db_pass,
            database=db_name,
            host=db_host,
            port=db_port,
        ),
        # ...
    )

    return pool

Java

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

Hinweis:

  • CLOUD_SQL_CONNECTION_NAME sollte als <MY-PROJECT>:<INSTANCE-REGION>:<INSTANCE-NAME> dargestellt werden.
  • Die Verwendung des Arguments ipTypes=PRIVATE erzwingt, dass die SocketFactory eine Verbindung zur zugeordneten privaten IP-Adresse einer Instanz herstellen kann.
  • Die Anforderungen für die JDBC Socket Factory-Version der pom.xml-Datei finden Sie hier.


import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
import javax.sql.DataSource;

public class TcpConnectionPoolFactory extends ConnectionPoolFactory {

  // Note: Saving credentials in environment variables is convenient, but not
  // secure - consider a more secure solution such as
  // Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
  // keep secrets safe.
  private static final String DB_USER = System.getenv("DB_USER");
  private static final String DB_PASS = System.getenv("DB_PASS");
  private static final String DB_NAME = System.getenv("DB_NAME");

  private static final String INSTANCE_HOST = System.getenv("INSTANCE_HOST");
  private static final String DB_PORT = System.getenv("DB_PORT");

  public static DataSource createConnectionPool() {
    // The configuration object specifies behaviors for the connection pool.
    HikariConfig config = new HikariConfig();

    // Configure which instance and what database user to connect with.
    config.setJdbcUrl(
        String.format("jdbc:sqlserver://%s:%s;databaseName=%s", INSTANCE_HOST, DB_PORT, DB_NAME));
    config.setUsername(DB_USER); // e.g. "root", "sqlserver"
    config.setPassword(DB_PASS); // e.g. "my-password"

    // ... Specify additional connection properties here.
    // ...

    // Initialize the connection pool using the configuration object.
    return new HikariDataSource(config);
  }
}

Node.js

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

const mssql = require('mssql');

// createTcpPool initializes a TCP connection pool for a Cloud SQL
// instance of SQL Server.
const createTcpPool = async config => {
  // Note: Saving credentials in environment variables is convenient, but not
  // secure - consider a more secure solution such as
  // Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
  // keep secrets safe.
  const dbConfig = {
    server: process.env.INSTANCE_HOST, // e.g. '127.0.0.1'
    port: parseInt(process.env.DB_PORT), // e.g. 1433
    user: process.env.DB_USER, // e.g. 'my-db-user'
    password: process.env.DB_PASS, // e.g. 'my-db-password'
    database: process.env.DB_NAME, // e.g. 'my-database'
    options: {
      trustServerCertificate: true,
    },
    // ... Specify additional properties here.
    ...config,
  };
  // Establish a connection to the database.
  return mssql.connect(dbConfig);
};

Go

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

package cloudsql

import (
	"database/sql"
	"fmt"
	"log"
	"os"
	"strings"

	_ "github.com/denisenkom/go-mssqldb"
)

// connectTCPSocket initializes a TCP connection pool for a Cloud SQL
// instance of SQL Server.
func connectTCPSocket() (*sql.DB, error) {
	mustGetenv := func(k string) string {
		v := os.Getenv(k)
		if v == "" {
			log.Fatalf("Fatal Error in connect_tcp.go: %s environment variable not set.\n", k)
		}
		return v
	}
	// Note: Saving credentials in environment variables is convenient, but not
	// secure - consider a more secure solution such as
	// Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
	// keep secrets safe.
	var (
		dbUser    = mustGetenv("DB_USER")       // e.g. 'my-db-user'
		dbPwd     = mustGetenv("DB_PASS")       // e.g. 'my-db-password'
		dbTCPHost = mustGetenv("INSTANCE_HOST") // e.g. '127.0.0.1' ('172.17.0.1' if deployed to GAE Flex)
		dbPort    = mustGetenv("DB_PORT")       // e.g. '1433'
		dbName    = mustGetenv("DB_NAME")       // e.g. 'my-database'
	)

	dbURI := fmt.Sprintf("server=%s;user id=%s;password=%s;port=%s;database=%s;",
		dbTCPHost, dbUser, dbPwd, dbPort, dbName)

	// dbPool is the pool of database connections.
	dbPool, err := sql.Open("sqlserver", dbURI)
	if err != nil {
		return nil, fmt.Errorf("sql.Open: %w", err)
	}

	// ...

	return dbPool, nil
}

C#

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

using Microsoft.Data.SqlClient;
using System;

namespace CloudSql
{
    public class SqlServerTcp
    {
        public static SqlConnectionStringBuilder NewSqlServerTCPConnectionString()
        {
            // Equivalent connection string:
            // "User Id=<DB_USER>;Password=<DB_PASS>;Server=<INSTANCE_HOST>;Database=<DB_NAME>;"
            var connectionString = new SqlConnectionStringBuilder()
            {
                // Note: Saving credentials in environment variables is convenient, but not
                // secure - consider a more secure solution such as
                // Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
                // keep secrets safe.
                DataSource = Environment.GetEnvironmentVariable("INSTANCE_HOST"), // e.g. '127.0.0.1'
                // Set Host to 'cloudsql' when deploying to App Engine Flexible environment
                UserID = Environment.GetEnvironmentVariable("DB_USER"),         // e.g. 'my-db-user'
                Password = Environment.GetEnvironmentVariable("DB_PASS"),       // e.g. 'my-db-password'
                InitialCatalog = Environment.GetEnvironmentVariable("DB_NAME"), // e.g. 'my-database'

                // The Cloud SQL proxy provides encryption between the proxy and instance
                Encrypt = false,
            };
            connectionString.Pooling = true;
            // Specify additional properties here.
            return connectionString;
        }
    }
}

Ruby

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

tcp: &tcp
  adapter: sqlserver
  # Configure additional properties here.
  # Note: Saving credentials in environment variables is convenient, but not
  # secure - consider a more secure solution such as
  # Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
  # keep secrets safe.
  username: <%= ENV["DB_USER"] %>  # e.g. "my-database-user"
  password: <%= ENV["DB_PASS"] %> # e.g. "my-database-password"
  database: <%= ENV.fetch("DB_NAME") { "vote_development" } %>
  host: <%= ENV.fetch("INSTANCE_HOST") { "127.0.0.1" }%> # '172.17.0.1' if deployed to GAE Flex
  port: <%= ENV.fetch("DB_PORT") { 1433 }%> 

PHP

Wenn Sie dieses Snippet im Kontext einer Webanwendung sehen möchten, rufen Sie die README-Datei auf GitHub auf.

namespace Google\Cloud\Samples\CloudSQL\SQLServer;

use PDO;
use PDOException;
use RuntimeException;
use TypeError;

class DatabaseTcp
{
    public static function initTcpDatabaseConnection(): PDO
    {
        try {
            // Note: Saving credentials in environment variables is convenient, but not
            // secure - consider a more secure solution such as
            // Cloud Secret Manager (https://cloud.google.com/secret-manager) to help
            // keep secrets safe.
            $username = getenv('DB_USER'); // e.g. 'your_db_user'
            $password = getenv('DB_PASS'); // e.g. 'your_db_password'
            $dbName = getenv('DB_NAME'); // e.g. 'your_db_name'
            $instanceHost = getenv('INSTANCE_HOST'); // e.g. '127.0.0.1' ('172.17.0.1' for GAE Flex)

            // Connect using TCP
            $dsn = sprintf(
                'sqlsrv:server=%s;Database=%s',
                $instanceHost,
                $dbName
            );

            // Connect to the database
            $conn = new PDO(
                $dsn,
                $username,
                $password,
                # ...
            );
        } catch (TypeError $e) {
            throw new RuntimeException(
                sprintf(
                    'Invalid or missing configuration! Make sure you have set ' .
                        '$username, $password, $dbName, and $instanceHost (for TCP mode). ' .
                        'The PHP error was %s',
                    $e->getMessage()
                ),
                $e->getCode(),
                $e
            );
        } catch (PDOException $e) {
            throw new RuntimeException(
                sprintf(
                    'Could not connect to the Cloud SQL Database. Check that ' .
                        'your username and password are correct, that the Cloud SQL ' .
                        'proxy is running, and that the database exists and is ready ' .
                        'for use. For more assistance, refer to %s. The PDO error was %s',
                    'https://cloud.google.com/sql/docs/sqlserver/connect-external-app',
                    $e->getMessage()
                ),
                (int) $e->getCode(),
                $e
            );
        }

        return $conn;
    }
}

Weitere Informationen

Befehlszeilenargumente des Cloud SQL Auth-Proxys

Die obigen Beispiele decken die häufigsten Anwendungsfälle ab. Der Cloud SQL Auth-Proxy bietet aber auch weitere Konfigurationsoptionen, die mit Befehlszeilenargumenten festgelegt werden können. Wenn Sie Hilfe zu Befehlszeilenargumenten benötigen, rufen Sie mit dem Flag --help die aktuelle Dokumentation auf:

./cloud-sql-proxy --help

Weitere Beispiele zur Verwendung der Befehlszeilenoptionen des Cloud SQL Auth-Proxys finden Sie in der README-Datei im Cloud SQL Auth-Proxy-GitHub-Repository.

Authentifizierungsoptionen für Cloud SQL Auth-Proxy

Alle diese Optionen verwenden einen INSTANCE_CONNECTION_NAME als Verbindungsstring, um eine Cloud SQL-Instanz zu identifizieren. Sie finden den INSTANCE_CONNECTION_NAME auf der Seite Übersicht Ihrer Instanz in der Google Cloud Console oder ermitteln ihn über folgenden Befehl:

gcloud sql instances describe --project PROJECT_ID INSTANCE_CONNECTION_NAME

Beispiel: gcloud sql instances describe --project myproject myinstance .

Einige dieser Optionen verwenden eine JSON-Datei mit Anmeldedaten, die den privaten RSA-Schlüssel für das Konto enthält. Eine Anleitung zum Erstellen einer JSON-Datei mit Anmeldedaten für ein Dienstkonto finden Sie unter Dienstkonto erstellen und Schlüsseldatei generieren.

Der Cloud SQL Auth-Proxy bietet abhängig von der Umgebung mehrere alternative Authentifizierungsoptionen. Der Cloud SQL Auth-Proxy prüft das Vorhandensein der folgenden Elemente in der unten angeführten Reihenfolge und verwendet das erste Element, das er findet, für die Authentifizierung:

  1. Vom Flag credentials-file bereitgestellte Anmeldedaten

    Erstellen Sie mit einem Dienstkonto die zugehörige JSON-Datei, laden Sie sie herunter und setzen Sie das Flag --credentials-file auf den Pfad der Datei, wenn Sie den Cloud SQL Auth-Proxy starten. Das Dienstkonto muss die erforderlichen Berechtigungen für die Cloud SQL-Instanz haben.

    Wenn Sie diese Option in der Befehlszeile verwenden möchten, rufen Sie den Befehl cloud-sql-proxy auf, wobei das Flag --credentials-file auf den Pfad und den Dateinamen einer JSON-Anmeldedatendatei festgelegt ist. Der Pfad kann absolut oder relativ zum aktuellen Arbeitsverzeichnis sein. Beispiele:

    ./cloud-sql-proxy --credentials-file PATH_TO_KEY_FILE \
    INSTANCE_CONNECTION_NAME
      

    Eine ausführliche Anleitung zum Hinzufügen von IAM-Rollen zu einem Dienstkonto finden Sie unter Dienstkonten Rollen zuweisen.

    Weitere Informationen zu den von Cloud SQL unterstützten Rollen finden Sie unter IAM-Rollen für Cloud SQL.

  2. Von einem Zugriffstoken bereitgestellte Anmeldedaten

    Erstellen Sie ein Zugriffstoken und rufen Sie den Befehl cloud-sql-proxy mit dem auf ein OAuth 2.0-Zugriffstoken gesetzten Flag --token auf. Beispiele:
    ./cloud-sql-proxy --token ACCESS_TOKEN \
    INSTANCE_CONNECTION_NAME
      
  3. Von einer Umgebungsvariable bereitgestellte Anmeldedaten.

    Diese Option ähnelt der Verwendung des Flags --credentials-file, mit dem Unterschied, dass Sie die JSON-Anmeldedatendatei angeben, die Sie in der Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS festgelegt haben, anstatt das Befehlszeilenargument --credentials-file zu verwenden.
  4. Anmeldedaten eines authentifizierten gcloud CLI-Clients.

    Wenn Sie die gcloud CLI installiert und sich mit Ihrem persönlichen Konto authentifiziert haben, kann der Cloud SQL Auth-Proxy dieselben Anmeldedaten verwenden. Diese Methode ist besonders hilfreich, um eine Entwicklungsumgebung einzurichten und auszuführen.

    Damit der Cloud SQL Auth-Proxy Ihre gcloud CLI-Anmeldedaten verwenden kann, authentifizieren Sie die gcloud CLI mit folgendem Befehl:

    gcloud auth application-default login
  5. Zur Compute Engine-Instanz gehörende Anmeldedaten

    Wenn Sie eine Verbindung zu Cloud SQL von einer Compute Engine-Instanz herstellen, kann der Cloud SQL Auth-Proxy das Dienstkonto verwenden, das mit der Compute Engine-Instanz verknüpft ist. Wenn das Dienstkonto die erforderlichen Berechtigungen für die Cloud SQL-Instanz hat, wird der Cloud SQL Auth-Proxy erfolgreich authentifiziert.

    Wenn sich die Compute Engine-Instanz im selben Projekt wie die Cloud SQL-Instanz befindet, hat das standardmäßige Dienstkonto die erforderlichen Berechtigungen zur Authentifizierung des Cloud SQL Auth-Proxys. Wenn sich die beiden Instanzen in verschiedenen Projekten befinden, müssen Sie das Dienstkonto der Compute Engine-Instanz dem Projekt hinzufügen, das die Cloud SQL-Instanz enthält.

  6. Standarddienstkonto der Umgebung

    Wenn der Cloud SQL Auth-Proxy keine Anmeldedaten an einem der zuvor erwähnten Orte finden kann, folgt er der Vorgehensweise, die unter Authentifizierung für Server-zu-Server-Produktionsanwendungen einrichten dokumentiert ist. Einige Umgebungen (z. B. Compute Engine, App Engine und andere) bieten ein Standarddienstkonto, mit dem sich Ihre Anwendung standardmäßig authentifizieren kann. Wenn Sie ein Standarddienstkonto verwenden, muss es die Berechtigungen enthalten, die unter Rollen und Berechtigungen aufgeführt sind. Weitere Informationen über den Google Cloud-Authentifizierungsansatz finden Sie unter Authentifizierung – Übersicht.

Dienstkonto erstellen

  1. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf:

    Zur Seite „Dienstkonten“

  2. Wählen Sie das Projekt aus, in dem sich die Cloud SQL-Instanz befindet.
  3. Klicken Sie auf Dienstkonto erstellen.
  4. Geben Sie im Feld Name des Dienstkontos einen Namen für das Dienstkonto ein.
  5. Ändern Sie die Dienstkonto-ID in einen eindeutigen, leicht erkennbaren Wert und klicken Sie dann auf Erstellen und fortfahren.
  6. Klicken Sie auf das Feld Rolle auswählen und wählen Sie eine der folgenden Rollen aus:
    • Cloud SQL > Cloud SQL-Client
    • Cloud SQL > Cloud SQL-Bearbeiter
    • Cloud SQL > Cloud SQL-Administrator
  7. Klicken Sie auf Fertig, um das Erstellen des Dienstkontos abzuschließen.
  8. Klicken Sie auf das Aktionsmenü für das neue Dienstkonto und wählen Sie Schlüssel verwalten aus.
  9. Klicken Sie auf das Drop-down-Menü Schlüssel hinzufügen und dann auf Neuen Schlüssel erstellen.
  10. Prüfen Sie, ob der Schlüsseltyp JSON ist, und klicken Sie dann auf Erstellen.

    Die Datei mit dem privaten Schlüssel wird auf Ihren Computer heruntergeladen. Sie können die Datei an einen anderen Speicherort verschieben. Bewahren Sie die Schlüsseldatei sicher auf.

Cloud SQL Auth-Proxy mit privater IP-Adresse verwenden

Wenn Sie eine Verbindung zu einer Cloud SQL-Instanz mithilfe einer privaten IP-Adresse herstellen möchten, muss sich der Cloud SQL Auth-Proxy auf einer Ressource befinden, die Zugriff auf dasselbe VPC-Netzwerk wie die Instanz hat.

Der Cloud SQL Auth-Proxy verwendet IP-Adressen, um eine Verbindung zu Ihrer Cloud SQL-Instanz herzustellen. Standardmäßig versucht der Cloud SQL Auth-Proxy eine Verbindung über eine öffentliche IPv4-Adresse herzustellen.

Wenn Ihre Cloud SQL-Instanz nur eine private IP-Adresse hat oder für die Instanz sowohl eine öffentliche als auch eine private IP konfiguriert ist und der Cloud SQL Auth-Proxy die private IP-Adresse verwenden soll, müssen Sie die folgende Option angeben, wenn Sie den Cloud SQL Auth-Proxy starten:

--private-ip

Cloud SQL Auth-Proxy mit Instanzen verwenden, für die Private Service Connect aktiviert ist

Sie können den Cloud SQL Auth-Proxy verwenden, um eine Verbindung zu einer Cloud SQL-Instanz mit aktiviertem Private Service Connect herzustellen.

Der Cloud SQL Auth-Proxy ist ein Connector, der einen sicheren Zugriff auf diese Instanz ermöglicht, ohne dass autorisierte Netzwerke erforderlich sind oder SSL konfiguriert werden muss.

Um Cloud SQL Auth-Proxy-Clientverbindungen zuzulassen, müssen Sie einen DNS-Eintrag einrichten, der dem empfohlenen DNS-Namen für die Instanz entspricht. Der DNS-Eintrag ist eine Zuordnung zwischen einer DNS-Ressource und einem Domainnamen.

Weitere Informationen zur Verwendung des Cloud SQL Auth-Proxys zum Herstellen einer Verbindung zu Instanzen mit aktiviertem Private Service Connect finden Sie unter Verbindung über den Cloud SQL Auth-Proxy herstellen.

Cloud SQL Auth-Proxy in einem separaten Prozess ausführen

Das Ausführen des Cloud SQL Auth-Proxys in einem separaten Cloud Shell-Terminal kann nützlich sein, um zu vermeiden, dass die Konsolenausgabe mit der Ausgabe anderer Programme vermischt wird. Verwenden Sie die unten dargestellte Syntax, um den Cloud SQL Auth-Proxy in einem separaten Prozess aufzurufen.

Linux

Verwenden Sie unter Linux oder macOS ein nachgestelltes & in der Befehlszeile, um den Cloud SQL Auth-Proxy in einem separaten Prozess zu starten:

./cloud-sql-proxy INSTANCE_CONNECTION_NAME
  --credentials-file PATH_TO_KEY_FILE &

Windows

Verwenden Sie in Windows PowerShell den Befehl Start-Process, um den Cloud SQL Auth-Proxy in einem separaten Prozess zu starten:

Start-Process --filepath "cloud-sql-proxy.exe"
  --ArgumentList "
  --credentials-file PATH_TO_KEY_FILEINSTANCE_CONNECTION_NAME"

Cloud SQL Auth-Proxy in einem Docker-Container ausführen

Verwenden Sie zum Ausführen des Cloud SQL Auth-Proxys in einem Docker-Container das Cloud SQL Auth-Proxy-Docker-Image, das in der Google Container Registry verfügbar ist. Sie können das Docker-Image des Cloud SQL Auth-Proxys mit diesem gcloud-Befehl installieren:

docker pull gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.10.1

Sie können den Cloud SQL Auth-Proxy entweder mit TCP-Sockets oder mit Unix-Sockets starten. Dafür werden die folgenden Befehle verwendet.

TCP-Sockets

    docker run -d \
      -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \
      -p 127.0.0.1:1433:1433 \
      gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.10.1 \
      --credentials-file /path/to/service-account-key.json \
      INSTANCE_CONNECTION_NAME

Unix-Sockets

    docker run -d \
      -v /PATH_TO_HOST_TARGET:/PATH_TO_GUEST_TARGET \
      -v PATH_TO_KEY_FILE:/path/to/service-account-key.json \
      gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.10.1 --unix-socket /cloudsql \
      --credentials-file /path/to/service-account-key.json/PATH_TO_KEY_FILE \
      INSTANCE_CONNECTION_NAME

Wenn Sie ein containeroptimiertes Image verwenden, ersetzen Sie /cloudsql durch ein beschreibbares Verzeichnis. Beispiel:

v /mnt/stateful_partition/cloudsql:/cloudsql

Wenn Sie die von Ihrer Compute Engine-Instanz bereitgestellten Anmeldedaten verwenden, geben Sie den Parameter credential_file und die Zeile -v PATH_TO_KEY_FILE:/path/to/service-account-key.json nicht an.

Cloud SQL Auth-Proxy als Dienst ausführen

Die Ausführung des Cloud SQL Auth-Proxys als Hintergrunddienst ist eine Option für lokale Entwicklungs- und Produktionsarbeitslasten. Wenn Sie in der Entwicklung auf Ihre Cloud SQL-Instanz zugreifen müssen, können Sie den Dienst im Hintergrund starten und beenden, wenn Sie fertig sind.

Der Cloud SQL Auth-Proxy bietet derzeit keine integrierte Unterstützung für die Ausführung als Windows-Dienst. Es können aber Drittanbieter-Dienstmanager verwendet werden, um ihn als Dienst auszuführen. Beispielsweise können Sie NSSM verwenden, um den Cloud SQL Auth-Proxy als Windows-Dienst zu konfigurieren. NSSM überwacht dann den Cloud SQL Auth-Proxy und startet ihn automatisch neu, wenn er nicht mehr reagiert. Weitere Informationen finden Sie in der NSSM-Dokumentation.

Verbindung herstellen, wenn SSL erforderlich ist

Verwendung des Cloud SQL Auth-Proxys erzwingen

Aktivieren Sie die Verwendung des Cloud SQL Auth-Proxys in Cloud SQL mit ConnectorEnforcement.

gcloud

Der folgende Befehl erzwingt die Verwendung von Cloud SQL-Connectors

    gcloud sql instances patch INSTANCE_NAME \
    --connector-enforcement REQUIRED
  

Verwenden Sie die folgende Codezeile, um die Erzwingung zu deaktivieren: --connector-enforcement NOT_REQUIRED Das Update löst keinen Neustart aus.

REST Version 1

Der folgende Befehl erzwingt die Verwendung von Cloud SQL-Connectors

Ersetzen Sie dabei folgende Werte für die Anfragedaten:

  • project-id: die Projekt-ID
  • instance-id: Die Instanz-ID.

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings": {
    "connectorEnforcement": "REQUIRED"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Verwenden Sie stattdessen "connectorEnforcement": "NOT_REQUIRED", um die Erzwingung zu deaktivieren. Das Update löst keinen Neustart aus.

REST v1beta4

Der folgende Befehl erzwingt die Verwendung von Cloud SQL-Connectors

Ersetzen Sie dabei folgende Werte für die Anfragedaten:

  • project-id: die Projekt-ID
  • instance-id: Die Instanz-ID.

HTTP-Methode und URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON-Text anfordern:

{
  "settings": {
    "connectorEnforcement": "REQUIRED"
  }
}

Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:

Sie sollten eine JSON-Antwort ähnlich wie diese erhalten:

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Verwenden Sie stattdessen "connectorEnforcement": "NOT_REQUIRED", um die Erzwingung zu deaktivieren. Das Update löst keinen Neustart aus.

Tipps für die Arbeit mit dem Cloud SQL Auth-Proxy

Cloud SQL Auth-Proxy für das Herstellen von Verbindungen zu mehreren Instanzen verwenden

Sie können mithilfe eines lokalen Cloud SQL Auth-Proxy-Clients eine Verbindung zu mehreren Cloud SQL-Instanzen herstellen. Die Vorgehensweise hängt dabei davon ab, ob Sie Unix-Sockets oder TCP verwenden.

TCP-Sockets

Wenn Sie eine Verbindung zu TCP herstellen, geben Sie einen Port auf Ihrem Computer an, der vom Cloud SQL-Auth-Proxy auf jede Cloud SQL-Instanz überwacht werden soll. Wenn Sie eine Verbindung zu mehreren Cloud SQL-Instanzen herstellen, muss jeder angegebene Port eindeutig und auf Ihrem Computer verfügbar sein.

Beispiel:

    # Start the Cloud SQL Auth Proxy to connect to two different Cloud SQL instances.
    # Give the Cloud SQL Auth Proxy a unique port on your machine to use for each Cloud SQL instance.

    ./cloud-sql-proxy "myProject:us-central1:myInstance?port=1433" \
    "myProject:us-central1:myInstance2?port=1234"

    # Connect to "myInstance" using port 1433 on your machine:
    sqlcmd -U myUser -S "127.0.0.1,1433"

    # Connect to "myInstance2" using port 1234 on your machine:
    sqlcmd -U myUser -S "127.0.0.1,1234"
  

Fehlerbehebung bei Cloud SQL-Auth-Proxy-Verbindungen

Das Docker-Image des Cloud SQL Auth-Proxys basiert auf einer bestimmten Version des Cloud SQL Auth-Proxys. Wenn eine neue Version des Cloud SQL Auth-Proxys verfügbar ist, rufen Sie die neue Version des zugehörigen Docker-Image ab, damit Ihre Umgebung auf dem neuesten Stand ist. Die aktuelle Version des Cloud SQL Auth-Proxys finden Sie auf der GitHub-Seite mit Cloud SQL Auth-Proxyversionen.

Wenn Sie Probleme damit haben, über den Cloud SQL Auth-Proxy eine Verbindung mit der Cloud SQL-Instanz herzustellen, versuchen Sie Folgendes, um die Problemursache zu ermitteln.

  • Prüfen Sie die Ausgabe des Cloud SQL Auth-Proxys.

    Die Ausgabe des Cloud SQL Auth-Proxys ist häufig hilfreich, um die Ursache des Problems zu ermitteln und um eine Lösung dafür zu finden. Leiten Sie die Ausgabe in eine Datei oder beobachten Sie das Cloud Shell-Terminal, in dem Sie den Cloud SQL Auth-Proxy gestartet haben.

  • Wenn Sie den Fehler 403 notAuthorized erhalten und das Dienstkonto zum Authentifizieren des Cloud SQL Auth-Proxys verwenden, müssen Sie dafür sorgen, dass das Dienstkonto die richtigen Berechtigungen hat.

    Sie können das Dienstkonto überprüfen. Suchen Sie dazu auf der IAM-Seite nach seiner ID. Das Konto muss die Berechtigung cloudsql.instances.connect haben. Die vordefinierten Rollen Cloud SQL Admin, Client und Editor haben diese Berechtigung.

  • Wenn Sie eine Verbindung von App Engine aus herstellen und einen 403 notAuthorized-Fehler erhalten, prüfen Sie den app.yaml-Wert cloud_sql_instances auf einen falsch geschriebenen oder falschen Instanzverbindungsnamen. Namen von Instanzverbindungen haben immer das Format PROJECT:REGION:INSTANCE.

    Überprüfen Sie außerdem, ob das App Engine-Dienstkonto (z. B. $PROJECT_ID@appspot.gserviceaccount.com) die Cloud SQL-Client-IAM-Rolle hat.

    Wenn sich der App Engine-Dienst in einem Projekt (Projekt A) und die Datenbank in einem anderen Projekt (Projekt B) befindet, weist dieser Fehler darauf hin, dass dem App Engine-Dienstkonto nicht die Cloud SQL-Client-IAM-Rolle zugewiesen wurde im Projekt mit der Datenbank (Projekt B)

  • Achten Sie darauf, dass die Cloud SQL Admin API aktiviert ist.

    Ist dies nicht der Fall, wird in Ihren Cloud SQL-Proxy-Logs eine Meldung wie z. B. Error 403: Access Not Configured ausgegeben.

  • Wenn Sie in der Instanzliste mehrere Instanzen angeben, achten Sie darauf, ein Komma als Trennzeichen zu verwenden. Wenn Sie TCP verwenden, geben Sie für alle Instanzen unterschiedliche Ports an.

  • Wenn Sie eine Verbindung über UNIX-Sockets herstellen, prüfen Sie, ob die Sockets erstellt wurden. Rufen Sie dazu das Verzeichnis auf, das Sie beim Start des Cloud SQL Auth-Proxys angegeben haben.

  • Wenn Sie eine Firewallrichtlinie für ausgehende Verbindungen haben, müssen Sie darauf achten, dass sie Verbindungen zu Port 3307 auf der Ziel-Cloud SQL-Instanz zulässt.

  • Sie können prüfen, ob der Cloud SQL Auth-Proxy ordnungsgemäß gestartet wurde. Sehen Sie sich dazu in den Logs im Abschnitt Vorgänge > Logging > Log-Explorer der Google Cloud Console die Logs an. Ein erfolgreicher Vorgang sieht so aus:

    2021/06/14 15:47:56 Listening on /cloudsql/$PROJECT_ID:$REGION:$INSTANCE_NAME/1433 for $PROJECT_ID:$REGION:$INSTANCE_NAME
    2021/06/14 15:47:56 Ready for new connections
    
  • Kontingentprobleme: Wenn das Kontingent für die Cloud SQL Admin API überschritten wird, wird der Cloud SQL Auth-Proxy mit der folgenden Fehlermeldung gestartet:

    There was a problem when parsing a instance configuration but ignoring due
    to the configuration. Error: googleapi: Error 429: Quota exceeded for quota
    metric 'Queries' and limit 'Queries per minute per user' of service
    'sqladmin.googleapis.com' for consumer 'project_number:$PROJECT_ID.,
    rateLimitExceeded
    

    Sobald eine Anwendung die Verbindung zum Proxy herstellt, meldet der Proxy den folgenden Fehler:

    failed to refresh the ephemeral certificate for $INSTANCE_CONNECTION_NAME:
    googleapi: Error 429: Quota exceeded for quota metric 'Queries' and limit
    'Queries per minute per user' of service 'sqladmin.googleapis.com' for
    consumer 'project_number:$PROJECT_ID., rateLimitExceeded
    

    Lösung: Identifizieren Sie entweder die Quelle des Kontingentproblems, z. B. wenn eine Anwendung den Connector missbraucht und unnötigerweise neue Verbindungen erstellt, oder wenden Sie sich an den Support, um eine Erhöhung des Cloud SQL Admin API-Kontingents zu beantragen. Wenn der Kontingentfehler beim Start angezeigt wird, müssen Sie die Anwendung noch einmal bereitstellen, um den Proxy neu zu starten. Wenn der Kontingentfehler nach dem Start angezeigt wird, ist eine erneute Bereitstellung nicht erforderlich.

Nächste Schritte