Mysql: Google Cloud SQL en App Engine: ¿la cadena de conexión está obsoleta?

Creado en 25 sept. 2016  ·  35Comentarios  ·  Fuente: go-sql-driver/mysql

Descripcion del problema

En el archivo Léame de este controlador, la cadena de conexión para conectarse a Google Cloud SQL en App Engine es la siguiente:

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

Si bien la documentación del paquete cloudsql de Google también afirma esto para su controlador, hay publicaciones en Stack Overflow como esta que afirman que uno necesita usar projectid:regionname:instancename en lugar de projectid:instancename .

¿Cuál es la cadena de conexión correcta? Ninguno de estos está funcionando actualmente.

Código de ejemplo

Puede encontrar una publicación más detallada aquí: http://stackoverflow.com/questions/39668672/trouble-connecting-to-google-cloud-sql-server-from-deployed-app

Registro de errores

Mi servidor devuelve una respuesta 500 cada vez que hago una llamada a un punto final que usa la base de datos de Cloud SQL. La conexión a la base de datos funciona bien cuando me conecto al servidor desde una versión local de mi aplicación.

Probé una variedad de cadenas de conexión y aquí hay algunos errores que se registraron en 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)

(No se especificó ninguna contraseña en la cadena de conexión porque la documentación no especifica la necesidad de una contraseña. Esta publicación menciona que la contraseña de conexión debe ser nula cuando la aplicación intenta conectarse al servidor usando root@localhost ).

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

También intenté conectarme con un usuario que no sea el usuario raíz (nombre de usuario: nuevo usuario):

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

Configuración

_Versión del controlador (o git SHA):_ https://github.com/go-sql-driver/mysql/tree/3654d25ec346ee8ce71a68431025458d52a38ac0

_Ir a la versión:_ ir a la versión go1.6.2 linux/amd64

_Versión del servidor:_ La instancia de Google Cloud SQL ejecuta MySQL 5.7

_Sistema operativo del servidor:_ Desde la pestaña Compute Engine, parece que el servidor que aloja la versión más reciente de mi aplicación ejecuta Debian 7.11 (Wheezy)

documentation

Comentario más útil

@bagatelli Para aclarar, asegúrese de estar utilizando el formato de cadena de conexión mencionado en este comentario: http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- con-google-cloud-sql-2nd#comment65140499_38890022

Perdón por la brevedad anterior. Estamos usando la segunda generación en producción de Go en App Engine sin problemas. Simplemente omita el parámetro "tlsConfigName" ya que el proxy SQL lo agregará, pero de cualquier manera informan que TLS ahora es compatible de todos modos.

Todos 35 comentarios

usuario@cloudsql (id-proyecto:nombre-instancia)/nombrebd
es el viejo. Todavía funciona porque todavía lo uso.

Recientemente, gae también comenzó a categorizar la base de datos en regiones, de ahí el nuevo formato. Si su cloudsql está categorizado en una región, deberá usar el nuevo formato

Quizás este controlador no analice correctamente el nuevo formato. Ese puede ser el problema

En su caso, ¿está ejecutando un servidor Cloud SQL de segunda generación?

Sin primera generación

Sospecho que el controlador no está analizando el nuevo formato. Es posible que el código deba cambiar para que tome el contenido antes de los primeros dos puntos y el contenido después de los primeros dos puntos, independientemente de los nuevos dos puntos presentes.

Hay una solicitud de extracción que se está actualizando Léame

Gracias por el aviso. Acabo de dejar un comentario sobre ese PR.
Como solución temporal, configuraré un servidor de primera generación hasta que se solucione el problema del controlador.

Actualización: parece que hay un problema con el controlador cuando una aplicación de Google App Engine implementada intenta conectarse a un servidor Google Cloud SQL de segunda generación.

Creé un servidor SQL en la nube de primera generación y pude conectarme con éxito al servidor usando una aplicación de Google App Engine implementada con esta cadena de conexión:

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

No se requirió ningún nombre de región.

El análisis no debería ser un problema, el controlador toma todo entre los paréntesis: https://github.com/go-sql-driver/mysql/blob/master/dsn.go#L282
Solo se usa en https://github.com/go-sql-driver/mysql/blob/master/driver.go#L65

¿Puede alguien con una cuenta de cloudsql descargar el controlador, editar https://github.com/go-sql-driver/mysql/blob/master/appengine.go#L14 y reemplazar "appengine/cloudsql" con "google.golang.org/appengine/cloudsql" ?

_Chicos, para referencia: _
La solución proporcionada por Google para conectarse a la segunda generación está aquí:
http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error-with-google-cloud-sql-2nd

La documentación publicada por Google era (y tal vez aún lo sea) incorrecta , pero la solución correcta se publica allí. Usamos Cloud SQL de segunda generación en producción sin problemas.

¿Hay una solución para esto? Definitivamente no funciona con CloudSQL Second Generation.

@bagatelli mira mi comentario sobre el tuyo

@benguild He visto tu comentario en varios lugares. Sin embargo, está asumiendo que todos usan SSL en sus conexiones, lo cual no es el caso para todos. Seguro que no es mío. El mensaje de error que recibo es "Controlador: mala conexión". Ni siquiera se llega a la base de datos porque el controlador no puede identificar correctamente los parámetros de conexión. Creo que el problema radica en algún lugar en el lío que ha existido con los paquetes "nuevo appengine" y "viejo appengine" que está causando que muchas cosas se rompan y Google no se molesta en documentar este cambio correctamente.

@bagatelli Para aclarar, asegúrese de estar utilizando el formato de cadena de conexión mencionado en este comentario: http://stackoverflow.com/questions/38890022/tls-requested-but-server-does-not-support-tls-error- con-google-cloud-sql-2nd#comment65140499_38890022

Perdón por la brevedad anterior. Estamos usando la segunda generación en producción de Go en App Engine sin problemas. Simplemente omita el parámetro "tlsConfigName" ya que el proxy SQL lo agregará, pero de cualquier manera informan que TLS ahora es compatible de todos modos.

@benguild . Gracias por todo su esfuerzo en ayudarme en todos estos temas.
¿Está utilizando el "nuevo motor de aplicaciones" o el "antiguo motor de aplicaciones"? Acabo de pasar el día convirtiendo todo mi código a esta nueva pesadilla que son los nuevos paquetes de Appengine y, como sabrás por mi otra publicación, ya no puedo implementar mi código y, por lo tanto, no puedo probar correctamente lo que habías sugerido anteriormente. . Lo intentaré de nuevo tan pronto como encuentre una solución para implementar mi aplicación.
¡Gracias!

@bagatelli Si tiene problemas para implementar, intente extraer su código en una VM o use Google Cloud Console.

@bagatelli Lo que estaba diciendo era... probarlo en una máquina nueva, o usar su consola en la nube (que ya tiene las herramientas de desarrollo) antes de descartar el hecho de que definitivamente no está relacionado con el entorno.

Actualmente no puedo implementar con macOS Sierra debido a un error que tiene 4 meses, pero podemos implementar bien desde una máquina virtual.

Estoy seguro de que es más trabajo para ti salir del entorno por completo, así que al menos me aseguraría de descartarlo antes de dejarlo por completo.

@pjebs . No estoy seguro de dónde sacaste esta suposición, pero no estoy usando un entorno flexible.

@pjebs Eso es incorrecto. Así es como se implementa actualmente en estándar.

@pjebs appcfg.py update también funciona.

@bagatelli Te escucho: generalmente tiendo a minimizar mis dependencias de terceros y también las dependencias de API, ya que lo que dices es cierto... Google no está obligado a brindar asistencia, aunque de lo contrario arriesgarían su reputación.

No estoy seguro de cuál es exactamente el problema para usted actualmente (además de usar API antiguas, ¿creo?), pero cada pieza de software que he desarrollado para App Engine también lo he desarrollado con la intención de salir de App Engine si y cuando sea necesario. Por ejemplo, para cada API de Google con la que interactúo, escribo un "ayudante" para que realmente llame a los métodos y proporcione los suyos propios al resto de la aplicación, de modo que solo eso deba ajustarse a un nuevo entorno cuando sea necesario y [ con suerte] sin romper el resto de la aplicación.

Para mí, App Engine es más conveniente, ya que es un entorno que requiere poca configuración además de la escalabilidad y las preferencias, y proporciona algunas API excelentes. Es molesto cuando algo sale mal, pero ofrecen soporte premium si tienes problemas como los que estás hablando.

@pjebs. Por lo que entiendo, goapp es solo un contenedor para appcfg.py. Terminará llamando a appcfg.py en algún momento.

@bagatelli Claro, envíame un correo electrónico. No hay problema

@benguild . Finalmente logré implementar mi aplicación, sin embargo, todavía no tuve suerte al conectarme a CloudSQL.
Actualicé toda mi aplicación para usar los paquetes "nuevo appengine" y configuré la importación de clousql a google.golang.org/appengine/clousql en "appengine.go" en el paquete mysql-driver.
Luego creé un certificado de cliente desde el Panel de control de CloudSQL y actualicé mi código en consecuencia usando RegisterTLSConfig como se describe en la documentación de los controladores que proporciona la configuración de tls como un parámetro como se indica en sus publicaciones en stackoverflow. Mi conexión URL se ve así:

root:contraseña@cloudsql (nombre-de-conexión-de-instancia-copiado-de-la-consola-en-la-nube)/myDatabase?tls=customTls

Todavía no hay suerte. Error:

Conductor: mala conexión

@arnehormann . Esto responde a su pregunta de su publicación anterior.

@bagatelli Pruébelo sin TLS.

@benguild . Probado sin tls. Sin suerte.

Conductor: mala conexión

@pjebs . No estoy seguro si entiende completamente el problema aquí. El controlador ni siquiera llega a la base de datos. Entiendo que lo que mencionó anteriormente puede ser cierto en un entorno de producción, pero ni siquiera puedo establecer una conexión única a la base de datos, por lo que en mi caso, lo anterior no se aplica en absoluto.

@bagatelli Lo que haría sería publicar en Stack Overflow como lo hice y etiquetarlo con: google-cloud-sql ... Espero que alguien de Google responda.

Si tiene este problema, querrán indexarlo para otras personas que tengan el mismo problema. Responda aquí con un enlace a la pregunta una vez resuelta.

Lo más probable es que todavía tenga que ver con su implementación porque, como dije, la gente está usando la segunda generación en producción y está fuera de beta.

@bagatelli ¿Recordó desactivar la configuración "Se requiere TLS" para la instancia en Cloud Console?

Gracias @benguild y @pjebs . Publicaré en SO y daré una actualización aquí si encuentro la causa.

@benguild . No veo ninguna mención a TLS en Cloud Console

Creo que te refieres a "Permitir solo conexión SSL". Si esto es de lo que estás hablando, entonces sí, está apagado.

Ok chicos, he encontrado el problema. Y no fue ni el controlador, ni mi aplicación ni CloudSQL. El proyecto en el que estoy implementando la aplicación se creó hace muchos años a través de la antigua consola de desarrolladores.
En la pestaña Control de acceso en Cloud Console, hay una etiqueta que dice "Aplicaciones en este proyecto: todas autorizadas". y cuando se crea un proyecto, también crea las cuentas predeterminadas de Appengine y Compute Engine. El problema es que este proyecto en particular no tenía ambas cuentas predeterminadas y estoy bastante seguro de que ese es el problema. Lo que probablemente sucedió es que Google no creó esas cuentas cuando migraron appengine a la consola en la nube, que usa IAM y administración para administrar las cuentas de acceso.
Supongo que porque cuando me di cuenta de que faltaban las cuentas predeterminadas, creé un nuevo proyecto y una nueva base de datos en la nube e implementé exactamente el mismo código en este nuevo proyecto y _voila_... Todo funciona bien.
@benguild @pjebs Realmente aprecio todo su esfuerzo por ayudarme a abordar este problema.
@benguild Eliminé todos los comentarios no relacionados de nuestra conversación anterior porque creo que estamos en la misma página relacionada con AppEngine/Google. Le enviaré un correo electrónico sobre eso más tarde.
He publicado esta pregunta en StackOverflow y la responderé con este descubrimiento para que otras personas con el mismo problema puedan beneficiarse.
http://stackoverflow.com/questions/40020782/connect-to-google-sql-cloud-2nd-generation-with-go-on-appengine

¡Gracias de nuevo!

Sí, si App Engine no tiene acceso a la instancia de SQL, tendrás un problema. 👍🏻

Reparado por # 485

¡Todo lo que puedo decir es gracias @benguild ! ¡Me ayudaste a dejar de golpearme la cabeza contra el teclado después de 500 pestañas de Chrome abiertas y 5 horas de búsqueda en Google! ¡¡¡Aleluya!!!

¿Fue útil esta página
0 / 5 - 0 calificaciones