À propos du proxy Cloud SQL

Vous trouverez sur cette page une présentation du proxy Cloud SQL et une description de ses options.

Pour obtenir des instructions détaillées concernant l'utilisation du proxy Cloud SQL, suivez le lien correspondant à votre environnement :

Vous n'avez pas besoin d'utiliser le proxy ni de configurer SSL pour vous connecter à Cloud SQL depuis l'environnement standard App Engine ou vous connecter à Cloud SQL depuis l'environnement flexible App Engine.

Caractéristiques du proxy

Le proxy Cloud SQL fournit un accès sécurisé à vos instances sans besoin de réseaux autorisés ni de configuration SSL.

L'accès à votre instance Cloud SQL à l'aide du proxy Cloud SQL offre les avantages suivants :

  • Connexions sécurisées : le proxy chiffre automatiquement le trafic vers et depuis la base de données à l'aide de TLS 1.2 avec un algorithme AES 128 bits. Les certificats SSL permettent de valider les identités du client et du serveur.
  • Gestion simplifiée des connexions : le proxy gère l'authentification auprès de Cloud SQL. Ainsi, il n'est plus nécessaire de fournir des adresses IP statiques.

Le proxy ne procure pas de nouveau chemin de connectivité. Il repose sur la connectivité IP existante. Pour permettre la connexion à une instance Cloud SQL à l'aide d'une adresse IP privée, le proxy doit se trouver sur une ressource ayant accès au même réseau VPC que l'instance.

Fonctionnement du proxy Cloud SQL

Le proxy Cloud SQL fonctionne avec un client local, appelé proxy, qui s'exécute dans l'environnement local. Pour communiquer avec le proxy, votre application utilise le protocole de base de données standard de votre base de données. Le proxy se sert d'un tunnel sécurisé pour communiquer avec son processus associé, exécuté sur le serveur.

Bien que le proxy puisse écouter sur n'importe quel port, il ne crée que des connexions sortantes vers votre instance Cloud SQL sur le port 3307. Si vous avez mis en place une règle de pare-feu sortante, assurez-vous qu'elle autorise les connexions au port 3307 sur l'adresse IP de votre instance Cloud SQL.

Le diagramme suivant montre comment le proxy se connecte à Cloud SQL :

Diagramme du proxy connectant un logiciel client à une instance SQL

Conditions requises pour utiliser le proxy Cloud SQL

Pour utiliser le proxy, vous devez répondre aux exigences suivantes :

  • L'API Cloud SQL Admin doit être activée.
  • Vous devez fournir au proxy des identifiants d'authentification Google Cloud.
  • Vous devez indiquer au proxy un compte utilisateur et un mot de passe valides pour la base de données.
  • L'instance doit avoir une adresse IPv4 publique ou doit être configurée pour utiliser une adresse IP privée.

    L'adresse IP publique n'a pas besoin d'être accessible à une adresse externe (elle n'a pas besoin d'être ajoutée en tant qu'adresse réseau autorisée).

Options de démarrage du proxy

Lorsque vous démarrez le proxy, vous devez lui fournir les informations suivantes :

  • Instances Cloud SQL avec lesquelles établir des connexions
  • Où écouter les données provenant de l'application à envoyer à Cloud SQL
  • Où trouver les identifiants pour authentifier l'application auprès de Cloud SQL
  • Quel type d'adresse IP utiliser, le cas échéant

Les options de démarrage du proxy que vous spécifiez déterminent si le proxy écoute un port TCP ou un socket Unix. Dans le cas d'un socket Unix, celui-ci est créé à l'emplacement de votre choix, généralement dans le répertoire /cloudsql/. Dans le cas d'un port TCP, le proxy écoute localhost par défaut.

Exécutez l'exécutable cloud_sql_proxy avec l'argument --help pour afficher la liste complète des options de démarrage.

Vous pouvez installer le proxy n'importe où dans votre environnement local. L'emplacement des fichiers binaires du proxy n'a pas d'incidence sur l'endroit d'où il écoute les données de votre application.

Utiliser un compte de service pour l'authentification

Le proxy nécessite une authentification. Lorsque vous utilisez un compte de service à cette fin, cette méthode présente l'avantage de vous permettre de créer un fichier d'identifiants spécifiquement pour le proxy. Ce fichier est associé au proxy de manière explicite et permanente tant que celui-ci est en cours d'exécution. Pour cette raison, l'utilisation d'un compte de service est la méthode recommandée pour les instances de production qui ne s'exécutent pas sur une instance Compute Engine.

Si vous devez appeler le proxy Cloud SQL à partir de plusieurs machines, le fichier d'identifiants peut être dupliqué dans une image système.

Pour utiliser cette méthode, vous devez créer et gérer le fichier d'identifiants. Seuls les utilisateurs disposant de l'autorisation resourcemanager.projects.setIamPolicy (par exemple, les propriétaires de projet) peuvent créer le compte de service. Si votre utilisateur Google Cloud ne dispose pas de cette autorisation, vous devez demander à une autre personne de créer le compte de service ou bien authentifier le proxy via une autre méthode.

Pour obtenir de l'aide concernant la création d'un fichier d'identifiants, consultez la section Créer un compte de service.

Autorisations requises pour les comptes de service

Lorsque vous utilisez un compte de service pour fournir les identifiants du proxy, vous devez le créer avec des autorisations suffisantes. Si vous gérez vos autorisations Cloud SQL à l'aide des rôles IAM (Identity and Access Management), qui sont plus précis, vous devez attribuer au compte de service un rôle qui inclut l'autorisation cloudsql.instances.connect. Voici les rôles Cloud SQL prédéfinis qui incluent cette autorisation :

  • Client Cloud SQL
  • Éditeur Cloud SQL
  • Administrateur Cloud SQL

Si vous utilisez les anciens rôles de projet (Lecteur, Éditeur, Propriétaire), le compte de service doit disposer au minimum du rôle Éditeur.

Options de spécification d'instances Cloud SQL

Vous pouvez indiquer au proxy les instances auxquelles vous souhaitez vous connecter de plusieurs façons. Certaines sont explicites, d'autres sont implicites. Dans certaines configurations, vous n'avez pas besoin d'indiquer à l'avance au proxy les instances auxquelles vous souhaitez vous connecter, car il se connecte en fonction des demandes de connexion.

Les options de spécification d'instances varient selon le système d'exploitation et l'environnement :

Option Avantages Mises en garde et conditions requises Linux/macOS
(sockets Unix)
Java Windows Remarques
Détection automatique d'instances Pas besoin de spécifier d'instances. Des sockets sont créés pour toutes les instances dans le projet par défaut. L'utilisation de l'API du proxy augmente. Le SDK Cloud doit être installé et authentifié, et un projet par défaut doit être défini. Besoin de redémarrer le proxy pour ajouter une nouvelle instance. Compatible Non Non Option déconseillée pour les instances de production.
Détection de projets Pas besoin de spécifier des instances. Des sockets sont créés pour toutes les instances dans les projets indiqués. L'utilisation de l'API du proxy augmente. Le SDK Cloud doit être installé et authentifié. Besoin de redémarrer le proxy pour ajouter une nouvelle instance. Compatible Non Non Utilisez le paramètre -projects. Option déconseillée pour les instances de production.
Instances spécifiées lors de l'appel du proxy La liste des instances est connue et statique. Besoin de redémarrer le proxy pour ajouter une nouvelle instance. Compatible Compatible avec les sockets TCP Compatible avec les sockets TCP Utilisez le paramètre -instances. En cas d'instances multiples, séparez-les par une virgule, sans inclure d'espaces. En savoir plus
Instances spécifiées à l'aide de métadonnées Compute Engine Liste des instances modifiable en modifiant la valeur des métadonnées, sans avoir à redémarrer le proxy. Cette option n'est disponible que sur Compute Engine. Compatible Compatible avec les sockets TCP Compatible avec les sockets TCP Utilisez l'option -instances_metadata. En savoir plus

Voir des exemples d'appels et de chaînes de connexion

Maintenir le proxy Cloud SQL à jour

Google publie occasionnellement de nouvelles versions du proxy. Pour savoir quelle est la version actuelle, consultez la page GitHub relative aux versions du proxy Cloud SQL. Les futures versions du proxy seront également indiquées sur le forum des annonces concernant Cloud SQL sur Google Groupes.

Utilisation de l'API

Le proxy Cloud SQL envoie des requêtes à l'API Cloud SQL, lesquelles sont comptabilisées dans le quota d'API du projet.

L'utilisation de l'API atteint son niveau le plus élevé lorsque vous démarrez le proxy, en particulier si vous utilisez la détection automatique d'instances ou le paramètre -projects. Lorsque le proxy est en cours d'exécution, il émet 2 appels d'API par heure et par instance connectée.

Paramètres et indicateurs du proxy Cloud SQL

Le proxy Cloud SQL accepte plusieurs indicateurs et paramètres lors de son démarrage. Ces options déterminent où et comment le proxy Cloud SQL crée les sockets qu'il utilise pour communiquer avec Cloud SQL, et comment il s'authentifie.

Pour obtenir de l'aide concernant les options du proxy, consultez les sources d'information suivantes :

Utiliser le proxy Cloud SQL dans un environnement de production

Lorsque vous utilisez le proxy Cloud SQL dans un environnement de production, vous devez suivre certaines étapes afin de vous assurer qu'il offre la disponibilité requise pour l'application.

Vérifier que le proxy Cloud SQL est exécuté en tant que service persistant

Si le processus de proxy est arrêté, toutes les connexions associées sont interrompues et l'application ne peut plus créer de connexions avec l'instance Cloud SQL via le proxy. Pour éviter ce cas de figure, veillez à exécuter le proxy en tant que service persistant. Ainsi, s'il s'arrête pour une raison quelconque, il redémarre automatiquement. Pour ce faire, vous pouvez utiliser un service tel que systemd, upstart ou supervisor. Pour le système d'exploitation Windows, exécutez le proxy en tant que service Windows. En général, assurez-vous que le proxy présente les mêmes exigences de disponibilité que votre processus d'application.

De combien de copies du proxy Cloud SQL l'application a-t-elle besoin ?

Il n'est pas nécessaire de créer un processus de proxy pour chaque processus d'application. En effet, de nombreux processus d'application peuvent en partager un seul. Exécutez un processus client proxy par poste de travail ou machine virtuelle.

Si vous employez l'autoscaling pour les machines virtuelles, assurez-vous que le proxy est inclus dans la configuration de ces dernières afin que, chaque fois qu'une nouvelle machine virtuelle est démarrée, elle dispose de son propre processus de proxy.

Il vous appartient de gérer le nombre de connexions requises par l'application, que ce soit en limitant ou en regroupant les connexions. Le proxy n'impose aucune limite concernant le taux de nouvelles connexions ou le nombre de connexions persistantes.

Réduire la sortie du proxy Cloud SQL

Si vous devez réduire la taille du journal du proxy, vous pouvez le faire en définissant -verbose=false lorsque vous démarrez le proxy. Cependant, n'oubliez pas que cela réduit l'efficacité de la sortie du proxy pour le diagnostic de problèmes de connexion.

Proxy Cloud SQL et processus de basculement

Si vous exécutez le proxy sur une instance configurée pour la haute disponibilité et qu'un basculement a lieu, les connexions via proxy sont affectées de la même manière que les connexions sur IP : toutes les connexions existantes sont perdues et l'application doit en établir de nouvelles. Cependant, aucune intervention manuelle n'est requise, l'application peut continuer à utiliser les mêmes chaînes de connexion qu'auparavant.

Maintenir l'image Docker du proxy à jour

L'image Docker du proxy est basée sur une version spécifique du proxy Cloud SQL. Lorsqu'une nouvelle version du proxy Cloud SQL est disponible, vous devez extraire la nouvelle version de l'image Docker du proxy afin de maintenir votre environnement à jour. Pour savoir quelle est la version actuelle du proxy Cloud SQL, consultez la page GitHub relative aux versions du proxy Cloud SQL.

Étape suivante