Mysql: Google Cloud SQL sur App Engine - Chaîne de connexion obsolète ?

Créé le 25 sept. 2016  ·  35Commentaires  ·  Source: go-sql-driver/mysql

Description du problème

Dans le fichier Lisez-moi de ce pilote, la chaîne de connexion permettant de se connecter à Google Cloud SQL sur App Engine est la suivante :

user@cloudsql(project-id:instance-name)/dbname

Bien que la documentation du package cloudsql de Google l' affirme également pour votre pilote, il existe des articles sur Stack Overflow tels que celui-ci qui prétendent qu'il faut utiliser projectid:regionname:instancename plutôt que projectid:instancename .

Quelle est la chaîne de connexion correcte ? Aucun de ceux-ci ne fonctionne actuellement.

Exemple de code

Un article plus détaillé peut être trouvé ici : http://stackoverflow.com/questions/39668672/trouble-connecting-to-google-cloud-sql-server-from-deployed-app

Journal des erreurs

Mon serveur renvoie une réponse 500 chaque fois que j'appelle un point de terminaison qui utilise la base de données Cloud SQL. La connexion à la base de données fonctionne correctement lorsque je me connecte au serveur à partir d'une version locale de mon application.

J'ai essayé diverses chaînes de connexion, et voici quelques erreurs qui ont été consignées dans Google Cloud Console :

5447 [Warning] 'user' entry 'root<strong i="21">@localhost</strong>' ignored in --skip-name-resolve mode.

5447 [Warning] entry 'root'@'localhost' in mysql.user is ignored because it duplicates entry in mysql.system_user

14409 [Note] Aborted connection 14409 to db: 'User' user: 'root' host: 'xxx.xxx.xxx.xxx' (Got an error reading communication packets)

(Aucun mot de passe n'a été spécifié dans la chaîne de connexion car la documentation ne précise pas la nécessité d'un mot de passe. Ce message mentionne que le mot de passe de connexion doit être nul lorsque l'application tente de se connecter au serveur en utilisant root@localhost .)

6170 [Note] Access denied for user 'root'@'cloudsqlproxy~xx.xxx.xxx.xx' (using password: NO) 

J'ai également essayé de me connecter avec un utilisateur autre que l'utilisateur root (nom d'utilisateur : newuser) :

5447 [Warning] 'user' entry 'newuser<strong i="30">@localhost</strong>' ignored in --skip-name-resolve mode.

Configuration

_Version du pilote (ou git SHA) :_ https://github.com/go-sql-driver/mysql/tree/3654d25ec346ee8ce71a68431025458d52a38ac0

_Go version :_ go version go1.6.2 linux/amd64

_Version du serveur :_ l'instance Google Cloud SQL exécute MySQL 5.7

_Server OS :_ Dans l'onglet Compute Engine, il semble que le serveur hébergeant la version la plus récente de mon application exécute Debian 7.11 (Wheezy).

documentation

Commentaire le plus utile

@bagatelli Pour clarifier, assurez-vous que vous utilisez le format de chaîne de connexion mentionné dans ce commentaire : http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- avec-google-cloud-sql-2nd#comment65140499_38890022

Désolé pour la brièveté précédente. Nous utilisons la 2e génération en production à partir de Go sur App Engine sans problème. Laissez simplement de côté le paramètre "tlsConfigName" car le proxy SQL l'ajoutera, mais dans tous les cas, ils signalent que TLS est désormais pris en charge de toute façon.

Tous les 35 commentaires

user@cloudsql (project-id:instance-name)/dbname
Est l'ancien. Il fonctionne toujours car je l'utilise toujours.

Récemment, gae a également commencé à catégoriser la base de données en régions, d'où le nouveau format. Si votre cloudsql est classé dans une région, vous devrez utiliser le nouveau format

Peut-être que ce pilote n'analyse pas correctement le nouveau format. C'est peut-être le problème

Dans votre cas, utilisez-vous un serveur Cloud SQL de deuxième génération ?

Pas de première génération

Je soupçonne que le pilote n'analyse pas le nouveau format. Le code peut avoir besoin de changer pour qu'il prenne le contenu avant le premier deux-points et le contenu après le premier deux-points indépendamment du nouveau deux-points présent

Il y a une pull request en cours de mise à jour lisez-moi

Merci pour l'information. Je viens de laisser un commentaire sur ce PR.
Comme solution de contournement temporaire, je vais configurer un serveur de première génération jusqu'à ce que le problème du pilote soit résolu.

Mise à jour : il semble qu'il y ait un problème avec le pilote lorsqu'une application Google App Engine déployée tente de se connecter à un serveur Google Cloud SQL de deuxième génération.

J'ai créé un serveur Cloud SQL de première génération et j'ai réussi à me connecter au serveur à l'aide d'une application Google App Engine déployée avec cette chaîne de connexion :

user@cloudsql(project-id:instance-name)/dbname

Aucun nom de région n'était requis.

L'analyse ne devrait pas poser de problème, le pilote prend tout entre les parenthèses : https://github.com/go-sql-driver/mysql/blob/master/dsn.go#L282
Il n'est utilisé que dans https://github.com/go-sql-driver/mysql/blob/master/driver.go#L65

Est-ce que quelqu'un avec un compte cloudsql peut télécharger le pilote, modifier https://github.com/go-sql-driver/mysql/blob/master/appengine.go#L14 et remplacer "appengine/cloudsql" par "google.golang.org/appengine/cloudsql" , essayez-le avec l'ancienne et la nouvelle version avec et sans la région et signalez ce qui fonctionne ? Merci!

_Les gars, pour référence : _
La solution fournie par Google pour se connecter à la 2e génération est ici :
http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error-with-google-cloud-sql-2nd

La documentation publiée par Google était (et est peut-être toujours) erronée , mais la bonne solution y est publiée. Nous utilisons Cloud SQL de 2e génération en production sans problème.

Existe-t-il une solution à cela? Ne fonctionne certainement pas avec CloudSQL deuxième génération.

@bagatelli voir mon commentaire au dessus du vôtre

@benguild J'ai vu votre commentaire à plusieurs endroits. Cependant, vous supposez que tout le monde utilise SSL dans ses connexions, ce qui n'est pas le cas pour tout le monde. Ce n'est certainement pas le mien. Le message d'erreur que j'obtiens est "Pilote : Mauvaise connexion". La base de données n'est même pas atteinte car le pilote ne peut pas identifier correctement les paramètres de connexion. Je pense que le problème se situe quelque part dans le désordre qui existe avec les packages "new appengine" et "old appengine", ce qui provoque la rupture de beaucoup de choses et Google ne prend pas la peine de documenter correctement ce changement.

@bagatelli Pour clarifier, assurez-vous que vous utilisez le format de chaîne de connexion mentionné dans ce commentaire : http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- avec-google-cloud-sql-2nd#comment65140499_38890022

Désolé pour la brièveté précédente. Nous utilisons la 2e génération en production à partir de Go sur App Engine sans problème. Laissez simplement de côté le paramètre "tlsConfigName" car le proxy SQL l'ajoutera, mais dans tous les cas, ils signalent que TLS est désormais pris en charge de toute façon.

@benguild . Merci pour tous vos efforts pour m'aider sur tous ces problèmes.
Utilisez-vous le "nouveau moteur d'application" ou l'"ancien moteur d'application" ? Je viens de passer la journée à convertir tout mon code vers ce nouveau cauchemar qu'est les nouveaux packages appengine et comme vous le savez peut-être de mon autre post je ne peux plus déployer mon code et donc je ne peux pas tester correctement ce que vous m'aviez suggéré plus haut . Je réessaierai dès que j'aurai trouvé une solution pour déployer mon application.
Merci!

@bagatelli Si vous rencontrez des problèmes de déploiement, essayez d'extraire votre code sur une machine virtuelle ou utilisez Google Cloud Console.

@bagatelli Ce que je disais était ... de l'essayer sur une nouvelle machine ou d'utiliser leur console cloud (qui dispose déjà des outils de développement) avant de supprimer le fait que ce n'est certainement pas lié à l'environnement.

Je ne peux actuellement pas déployer avec macOS Sierra en raison d'un bogue vieux de 4 mois, mais nous pouvons déployer correctement à partir d'une machine virtuelle.

Je suis sûr que c'est plus de travail pour vous de vous éloigner complètement de l'environnement, donc je serais au moins sûr d'exclure cela avant d'arrêter complètement.

@pjebs . Je ne sais pas d'où vient cette hypothèse, mais je n'utilise pas d'environnement flexible.

@pjebs C'est incorrect. C'est actuellement ainsi que vous déployez en standard.

@pjebs appcfg.py update fonctionne aussi.

@bagatelli Je vous entends - J'ai généralement tendance à minimiser mes dépendances tierces et aussi les dépendances API puisque ce que vous dites est vrai... Google n'est pas obligé de fournir une assistance, même s'ils risqueraient leur réputation autrement.

Je ne sais pas quel est exactement le problème pour vous actuellement (en plus d'utiliser d'anciennes API, je pense ?), Mais chaque logiciel que j'ai développé pour App Engine, j'ai également développé avec l'intention de quitter App Engine si et au besoin. Par exemple, pour chaque API Google avec laquelle je m'interface, j'écris un "helper" pour qui appelle réellement les méthodes et fournit les siennes au reste de l'application afin que et seulement cela doive être ajusté à un nouvel environnement si nécessaire et [ espérons-le] sans casser le reste de l'application.

Pour moi, App Engine est plus pratique car il s'agit d'un environnement qui nécessite peu de configuration en plus de la mise à l'échelle et des préférences, et qui fournit d'excellentes API. C'est ennuyeux quand quelque chose ne va pas, mais ils offrent un support premium si vous avez des problèmes comme ce dont vous parlez ?

@pjebs. Autant que je sache, goapp n'est qu'un wrapper pour appcfg.py. Il finira par appeler appcfg.py à un moment donné.

@bagatelli Bien sûr, envoyez-moi un e-mail. Aucun problème

@benguild . J'ai finalement réussi à déployer mon application, mais toujours pas de chance de me connecter à CloudSQL.
J'ai mis à jour l'intégralité de mon application pour utiliser les packages "new appengine" et défini l'importation de clousql sur google.golang.org/appengine/clousql dans "appengine.go" sur le package mysql-driver.
J'ai ensuite créé un certificat client à partir du panneau de configuration CloudSQL et mis à jour mon code en conséquence à l'aide de RegisterTLSConfig, comme décrit dans la documentation des pilotes fournissant la configuration tls en tant que paramètre, comme indiqué dans vos messages sur stackoverflow. Ma connexion URL ressemble à ceci:

root:password@cloudsql (instance-connection-name-copied-from-cloud-console)/myDatabase?tls=customTls

Toujours pas de chance. Erreur:

Pilote : mauvaise connexion

@arnehormann . Cela répond à votre question de votre message ci-dessus.

@bagatelli Essayez-le sans TLS.

@benguild . Essayé sans tls. Pas de chance.

Pilote : mauvaise connexion

@pjebs . Je ne sais pas si vous comprenez parfaitement le problème ici. Le pilote n'atteint même pas la base de données. Je comprends que ce que vous avez mentionné ci-dessus peut être vrai dans un environnement de production, mais je ne suis même pas en mesure d'établir une seule connexion à la base de données, donc dans mon cas, ce qui précède ne s'applique pas du tout.

@bagatelli Ce que je ferais, c'est publier sur Stack Overflow comme je l'ai fait et le taguer avec : google-cloud-sql ... Quelqu'un de Google devrait répondre, j'espère.

Si vous rencontrez ce problème, ils voudront le faire indexer pour les autres qui ont le même problème. Répondez ici avec un lien vers la question une fois résolue.

Très probablement, cela a encore à voir avec votre implémentation car, comme je l'ai dit, les gens utilisent la 2e génération en production et elle n'est plus en version bêta.

@bagatelli Avez-vous pensé à désactiver le paramètre "TLS requis" pour l'instance dans Cloud Console ?

Merci @benguild et @pjebs . Je publierai sur SO et donnerai une mise à jour ici si je trouve la cause.

@benguild . Je ne vois aucune mention de TLS dans Cloud Console

Je pense que vous voulez dire "Autoriser uniquement la connexion SSL". Si c'est ce dont vous parlez, alors oui, c'est éteint.

Ok les gars, j'ai trouvé le problème. Et ce n'était ni le pilote, ni mon application, ni CloudSQL. Le projet sur lequel je déploie l'application a été créé il y a de nombreuses années via l'ancienne console des développeurs.
Dans l'onglet Contrôle d'accès de Cloud Console, une étiquette indique " Applications dans ce projet : Toutes autorisées". et lorsqu'un projet est créé, il crée également les comptes AppEngine et Compute Engine par défaut. Le problème est que ce projet particulier n'avait pas les deux comptes par défaut et c'est à peu près sûr que c'est le problème. Ce qui s'est probablement passé, c'est que Google n'a pas créé ces comptes lors de la migration d'appengine vers la console cloud qui utilise IAM & Admin pour gérer les comptes d'accès.
Je suppose que parce que lorsque j'ai remarqué que les comptes par défaut manquaient, j'ai créé un nouveau projet et une nouvelle base de données cloud sql et déployé exactement le même code sur ce nouveau projet et _voila_... Tout fonctionne très bien.
@benguild @pjebs J'apprécie vraiment tous vos efforts pour m'aider à résoudre ce problème.
@benguild J'ai supprimé tous les commentaires sans rapport de notre conversation précédente car je pense que nous sommes sur la même page concernant AppEngine/Google. Je vous enverrai un e-mail à ce sujet plus tard.
J'ai posté cette question sur StackOverflow et j'y répondrai avec cette découverte afin que d'autres personnes ayant le même problème puissent en bénéficier.
http://stackoverflow.com/questions/40020782/connect-to-google-sql-cloud-2nd-generation-with-go-on-appengine

Merci encore!

Oui, si App Engine n'a pas accès à l'instance SQL, vous allez avoir un problème. 👍🏻

Corrigé par #485

Tout ce que je peux dire c'est merci @benguild ! Vous m'avez aidé à arrêter de me cogner la tête contre le clavier après 500 onglets chromés ouverts et 5 heures de recherche sur Google ! Alléluia!!!

Cette page vous a été utile?
0 / 5 - 0 notes