Получение странного сообщения googleapi Err 400 при подключении к экземпляру postgresql CloudSQL

Я получаю странный параметр Err 400, отсутствующий в проекте, при попытке подключиться к экземпляру CloudSQL с использованием механизма cloud_sql_proxy.

У меня есть проект GCE с работающей базой данных CloudSQL postgres, мои приложения в API вычислений могут ее использовать, и я могу выполнять обычный psql с любой виртуальной машины, которую я настроил в своем проекте GCE.

Однако, когда я пытаюсь подключиться к базе данных со своего ноутбука с помощью cloud_sql_proxy, я получаю эту странную ошибку.

Я следую букве этой документации: https://cloud.google.com/sql/docs/postgres/connect-admin-proxy#install

Итак, после этой документации у меня есть:

  1. CloudSQL включен и работает, как я прокомментировал
  2. Прокси установлен
  3. У меня есть учетная запись службы, созданная, как указано в документации, с ролью администратора Cloud SQL следующим образом:
{
  "type": "service_account",
  "project_id": "my-proyect-21432",
  "private_key_id": "<hidden intentionally>",
  "private_key": "<hidden intentionally>",
  "client_email": "[email protected]",
  "client_id": "<hidden intentionally>",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/[email protected]"
}
  1. Я успешно запустил cloud_sql_proxy следующим образом:
user@hostname:~$ ./cloud_sql_proxy -instances=db1=tcp:15432 -credential_file=my-proyect-21432.json
2019/05/29 10:17:25 Rlimits for file descriptors set to {&{8500 65536}}
2019/05/29 10:17:25 using credential file for authentication; email=cloudsql-serviceaccount@my-proyect-21432.iam.gserviceaccount.com
2019/05/29 10:17:25 Listening on 127.0.0.1:15432 for db1
2019/05/29 10:17:25 Ready for new connections
  1. И, наконец, я запускаю клиент psql следующим образом:
psql "host=127.0.0.1 port=15432 sslmode=disable dbname=db1 user=dbuser"

Я вижу на cloud_sql_proxy следующую ошибку:

2019/05/29 10:17:33 New connection for "db1"
2019/05/29 10:17:34 couldn't connect to "db1": googleapi: Error 400: Missing parameter: project., required

И на стороне клиента я получаю:

psql: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

На этом этапе я должен успешно подключить мой клиент psql, и я не могу найти ничего об этой ошибке в Интернете или в документации Google.

Я понятия не имею, где мне нужно установить параметр проект, я пробовал сумасшедшие места, например, на стороне psql с -v или с использованием URL-адреса с ? в конце, но безуспешно, я также пробовал на стороне cloud_sql_proxy, используя флаг -проекты, также без везения.


Обновлено: Новые выводы!!!

Я думаю, что я близок к решению этой проблемы, первая настройка, которую я сделал (как указано выше), была на моем компьютере с Windows, который я использую дома, сегодня я в офисе, и я решил воспроизвести все это с помощью macos, я не думайте, что ОС вообще имеет значение, интересно то, что я скопировал все и создал маленькую вещь, которая заставляет меня двигаться вперед

Итак, я снова начал и выполняю пункты 1., 2., 3., 4. и ждать? в документации указано, что строка экземпляров выглядит следующим образом: мой проект: us-central1: мой экземпляр НЕ то, что я написал изначально, поэтому я изменил это и получил более разумную ошибку:

Я начал cloud_sql_proxy устанавливать соединение с psql и получил это:

user@hostname:~$ ./cloud_sql_proxy -instances=my-proyect-21432:us-east1:db1=tcp:15432 -credential_file=my-proyect-21432.json
2019/05/30 14:13:25 Rlimits for file descriptors set to {&{8500 65536}}
2019/05/30 14:13:25 using credential file for authentication; email=cloudsql-serviceaccount@my-proyect-21432.iam.gserviceaccount.com
2019/05/30 14:13:25 Listening on 127.0.0.1:15432 for db1
2019/05/30 14:13:25 Ready for new connections

<< when I run psql>>

2019/05/30 14:14:08 New connection for "my-proyect-21432:us-east1:db1"
2019/05/30 14:15:24 couldn't connect to "my-proyect-21432:us-east1:db1": dial tcp 10.26.112.3:3307: connect: operation timed out

Мой экземпляр db1 имеет только частный IP-адрес 10.26.112.3.

Я начал искать эту ошибку в Интернете и нашел предложение разрешить входящий трафик на порт 3307:

Не удается подключиться через прокси-сервер Cloud SQL из Cloud Shell через проксиhttps://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/164

Поэтому я добавил следующее правило:

allow-cloudsqlproxy | Ingress | Apply to all | IP Ranges 0.0.0.0/0 | tcp,udp 3307 | allow | default | 1000

Но это не имело никакого значения, потому что после этого я все еще получаю то же сообщение об ошибке :(


Обновлено: с виртуальной машины в том же проекте

Я создал виртуальную машину в этом проекте и реплицировал все это, я смог подключиться, сообщение об отказе в подключении к порту 3307 не было.

Я понятия не имею, кто блокирует этот трафик...

см. мой ответ здесь sackoverflow sql proxy auth 400 неверный запрос

yehonatan yehezkel 21.02.2022 17:40
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
5
1
1 314
4
Перейти к ответу Данный вопрос помечен как решенный

Ответы 4

Ответ принят как подходящий

Хорошо, очевидно, что cloud_sql_proxy не работает, если адрес вашего экземпляра БД имеет только частный ip, мне пришлось добавить общедоступный, чтобы прокси-сервер имел доступ к моему экземпляру.

Я понимаю определенные ограничения, но если Google предоставляет cloud_sql_proxy, он должен поддерживать все случаи клиентов, я имею в виду, что я использую сеть по умолчанию, эта сеть управляется Google, сеть должна каким-то образом позволять прокси-серверу получать доступ к моим экземплярам базы данных. Я не знаю ...

Во-вторых, я добавил общедоступный IP-адрес, во-вторых, он начал работать ... но я, честно говоря, не хочу, чтобы публичный IP-адрес был в моих экземплярах базы данных.

На самом деле cloudsql-proxy работает, когда ваш экземпляр Cloud SQL имеет только внутренний IP-адрес. В этом сценарии вы используете доступ к частным службам, чтобы установить соединение между cloudsql-proxy и экземпляром Cloud SQL. Также рекомендуется запускать прокси-сервер с параметром --ip_address_types=PRIVATE, чтобы заставить его использовать внутренний IP-адрес вместо общедоступного при подключении к экземпляру Cloud SQL.

Подробнее см. здесь и здесь.

Надеюсь, это поможет.

Первая ссылка гласит: «Чтобы подключиться к экземпляру Cloud SQL с использованием частного IP-адреса, прокси-сервер должен находиться на ресурсе с доступом к той же сети VPC, что и экземпляр». Итак, я предполагаю, что это означает, что невозможно использовать прокси для подключения к экземпляру базы данных, который имеет только частный IP-адрес с вашей локальной машины?

Matt Browne 29.04.2020 17:05

Я только что попробовал это с другого сервера, к которому у меня есть доступ (VPS, работающий на Linode), где я временно отключил брандмауэр. Та же проблема, что и у меня локально.

Matt Browne 29.04.2020 17:19

Спасибо, что держите нас в курсе своих находок. Я столкнулся с той же проблемой. Я только что решил это - ваше первое редактирование подсказало мне.

Следуя процессу документации Google CloudSQL для подключения к CloudSQL из внешнего приложения, я запустил прокси следующим образом:

`./cloud_sql_proxy -instances=<instance_name>=tcp:5433`

Это не дало мне подключиться. я получал эту ошибку

`couldn't connect to "xxxxxxx": googleapi: Error 400: Missing parameter: project., required`

Прочитав ваше редактирование, я изменил команду, чтобы использовать полное имя экземпляра, как указано на странице сведений об экземпляре, и это сработало. Это новая команда, которая заставила его работать.

`./cloud_sql_proxy -instances=myproject:us-central1:instancename=tcp:5433`

Надеюсь, это сэкономит кому-то несколько часов.

Спасибо за это! Для прохожих вот ссылка на документы cloud.google.com/sql/docs/mysql/sql-proxy#tips

Rob Kielty 25.07.2019 17:11

Как бы тривиально это ни звучало, для меня обновление с gcr.io/cloudsql-docker/gce-proxy:1.05 до gcr.io/cloudsql-docker/gce-proxy:latest* прокси-образа CloudSQL в файле развертывания Kubernetes решило проблему.

Принимая во внимание окончательные комментарии автора вопроса, я полагаю, что это может быть ошибка CloudSQL, которая требует от вас запуска чего-то, что полностью перезапустит его экземпляр. Хотя это всего лишь предположение.


* Я пробовал это на версии 1.16. Если вы не уверены в стабильности будущих выпусков, вы можете указать версию вместо тега latest.

Другие вопросы по теме