我对 Google Cloud 和运行应用程序很陌生。我目前有一个 Django 应用程序在 Google 灵活应用引擎上的 Docker 容器中运行，该应用程序连接到同一项目中的 Google Cloud SQL (PostgreSQL) 实例。最新版本已经运行了大约 3 天没有问题。

问题：

今天我开始OperationalError: server closed the connection unexpectedly从应用程序中反复收到错误。我可以运行 Cloud SQL 代理并正常启动 ( Ready for new connections)，但是如果我尝试与 psql 连接，则会收到错误消息：

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

代理报告：

couldn't connect to "<instance_name>:us-central1:<instance_name>": 
dial tcp <ip address>:3307: connect: connection refused

在通过 SSH 连接到我正在运行的 flex 应用程序实例并运行时sudo docker logs <cloud proxy container>，最后几行类似： …

我正在尝试使用 cloudsql-proxy docker 容器将应用程序（docker 容器）连接到 Google Cloud SQL 数据库。因此，我使用以下 cloudsql-proxy 容器创建了一个 docker-compose 文件：（XXX 替换为我的云 sql 实例 ID）

version: "3"

volumes:
  sqlproxy:

services:

  cloudsql-proxy:
    container_name: cloudsql-proxy
    image: gcr.io/cloudsql-docker/gce-proxy:1.11
    command: /cloud_sql_proxy --dir=/cloudsql -instances=XXX=tcp:0.0.0.0:3306 -credential_file=/config/credentials.json
    ports:
      - "3306:3306"
    volumes:
      - /usr/share/service-accounts/cloudsql-client.json:/config/credentials.json
      - sqlproxy:/cloudsql
      - /etc/ssl/certs:/etc/ssl/certs
    restart: always

每当我尝试从同一台机器上运行的另一个容器（例如 docker-compose 文件中的第二个容器）连接到 cloudsql mysql 数据库时，我都会收到错误消息

“错误 2003 (HY000)：无法连接到 '127.0.0.1' 上的 MySQL 服务器（111“连接被拒绝”）”

我尝试使用三种不同的方法连接到 cloudsql-proxy，但仍然出现相同的错误。所有容器（要连接的云 sql 代理和测试容器）都在一个 google 计算引擎实例上：

a) mysql-client: mysql --host 127.0.0.1

b) jdbc url: jdbc:mysql://127.0.0.1:3306/test

c) jdbc url: jdbc:mysql://cloudsql-proxy:3306/test

在我的 gc 防火墙中，为了测试目的，我为 0.0.0.0/0 …

我目前正在从事ETL Dataflow作业（使用Apache Beam Python SDK），该作业从CloudSQL查询数据（带有psycopg2和自定义ParDo）并将其写入BigQuery。我的目标是创建一个数据流模板，该模板可以使用Cron作业从AppEngine开始。

我有一个使用DirectRunner在本地工作的版本。为此，我使用CloudSQL（Postgres）代理客户端，以便可以连接到127.0.0.1上的数据库。

当将DataflowRunner与自定义命令一起使用来在setup.py脚本中启动代理时，该作业将不会执行。它坚持重复此日志消息：

Setting node annotation to enable volume controller attach/detach

我的setup.py的一部分看起来如下：

CUSTOM_COMMANDS = [
['echo', 'Custom command worked!'],
['wget', 'https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64', '-O', 'cloud_sql_proxy'],
['echo', 'Proxy downloaded'],
['chmod', '+x', 'cloud_sql_proxy']]

class CustomCommands(setuptools.Command):
  """A setuptools Command class able to run arbitrary commands."""

  def initialize_options(self):
    pass

  def finalize_options(self):
    pass

  def RunCustomCommand(self, command_list):
    print('Running command: %s' % command_list)
    logging.info("Running custom commands")
    p = subprocess.Popen(
        command_list,
        stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
    # Can use communicate(input='y\n'.encode()) if the command run …

我在一个吊舱内有两个容器。一个是我的应用程序容器，第二个是 CloudSQL 代理容器。基本上我的应用程序容器依赖于这个 CloudSQL 容器。

问题是，当 pod 终止时，CloudSQL 代理容器首先终止，并且仅在几秒钟后我的应用程序容器才会终止。

因此，在我的容器终止之前，它不断向 CloudSQL 容器发送请求，从而导致错误：

could not connect to server: Connection refused Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432

这就是为什么，我认为指定终止顺序是一个好主意，以便我的应用程序容器首先终止，然后才是 cloudsql 一个。

我在文档中找不到任何可以做到这一点的东西。但也许有一些方法。

我正在尝试在 之间建立连接Google Cloud Postgres并Google Kubernetes Engine使用CloudSQL proxy. 如果我检查两个工作负载的日志：

我正进入（状态：

2021-02-02T11:42:09.748706102Z2021/02/02 11:42:09 dial tcp 127.0.0.1:5432: connect: connection refused

我正在写下我使用所有真实文件关键字或文件名执行的所有步骤。

脚步

1. 设置google cloud cluster3 个节点。
2. 设置Postgres的实例Google Cloud SQL。添加新用户gothamuser和密码是gothampass：在 5432 端口上运行
3. I am service通过设置帐户gothamcity-gke@miles-789.iam.gserviceaccount.com并保存config.json文件。
4. Docker file[.1]的链接
5. 使用构建容器gcloud builds submit --tag gcr.io/miles-789/gothamcity:0.10 .
6. Deployment.yaml[.2]的链接
7. 使用执行部署文件kubectl create -f deployment.yaml
8. service.yaml[3]的链接
9. 使用执行服务文件kubectl create -f service.yaml
10. 使用创建的云 SQL 实例kubectl …

这是我在 shell 中运行的命令：./cloud_sql_proxy -instaces=[my_project_id:europe-west3:my_project_name]=tcp=5432。

有时我收到以下错误消息：

• 情况1：flag provided but not defined: -instaces;

• 案例2：2021/11/19 17:50:12 errors parsing config:

   mkdir my_project_id:europe-west3:my_project_name: The syntax of the file, directory, or volume name is incorrect.
   mkdir my_project_id:europe-west3:my_project_name-copy: The syntax of the file, directory, or volume name is incorrect.
  

  Run Code Online (Sandbox Code Playgroud)

在我的Composer Airflow DAG 中，我一直在使用 CloudSqlProxyRunner连接到我的 Cloud SQL 实例。

然而，在将 Google Cloud Composer 从 v1.18.4 更新到 1.18.6 后，我的 DAG 开始遇到一个奇怪的错误：

[2022-04-22, 23:20:18 UTC] {cloud_sql.py:462} INFO - Downloading cloud_sql_proxy from https://dl.google.com/cloudsql/cloud_sql_proxy.linux.x86_64 to /home/airflow/dXhOYoU_cloud_sql_proxy.tmp
[2022-04-22, 23:20:18 UTC] {taskinstance.py:1702} ERROR - Task failed with exception
Traceback (most recent call last):
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/models/taskinstance.py", line 1330, in _run_raw_task
    self._execute_task_with_callbacks(context)
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/models/taskinstance.py", line 1457, in _execute_task_with_callbacks
    result = self._execute_task(context, self.task)
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/models/taskinstance.py", line 1513, in _execute_task
    result = execute_callable(context=context)
  File "/opt/python3.8/lib/python3.8/site-packages/airflow/decorators/base.py", line 134, in …

使用 Python 连接到 Cloud SQL 并不总是那么简单。

根据上下文，有时您必须连接到 Unix 域套接字、将 TCP 连接的 IP 地址列入允许列表、在本地运行 Cloud SQL Auth 代理。确保这些连接安全是另一个挑战：您可能必须管理 SSL 证书、防火墙规则、IP 地址等。

是否有推荐的方法使用 Python以安全且简单的方式连接到 Cloud SQL ？

我正在使用启用了 istio 附加组件的 GKE。使用 websocket 时，Myapp 以某种方式给出了 503 错误。我开始认为 websocket 可能正在工作，但数据库连接没有工作，这会导致 503，因为 cloudsql-proxy 日志给出了错误：

$ kubectl logs myapp-54d6696fb4-bmp5m cloudsql-proxy
2019/01/04 21:56:47 using credential file for authentication; email=proxy-user@myproject.iam.gserviceaccount.com
2019/01/04 21:56:47 Listening on 127.0.0.1:5432 for myproject:europe-west4:mydatabase
2019/01/04 21:56:47 Ready for new connections
2019/01/04 21:56:51 New connection for "myproject:europe-west4:mydatabase"
2019/01/04 21:56:51 couldn't connect to "myproject:europe-west4:mydatabase": Post https://www.googleapis.com/sql/v1beta4/projects/myproject/instances/mydatabase/createEphemeral?alt=json: oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: read tcp 10.44.11.21:60728->108.177.126.95:443: read: connection reset by peer
2019/01/04 22:14:56 New connection for "myproject:europe-west4:mydatabase"
2019/01/04 22:14:56 couldn't connect to "myproject:europe-west4:mydatabase": …

在尝试评估如何从 Google Kubernetes Engine pod 连接到 Cloud SQL 数据库时，有几种方法可以做到这一点。一种是使用sidecar云代理。另一种方法是使用私有 IP 并在两者之间使用 SSL 连接。两者都有明确的案例吗？或者它们都提供相同的功能？有没有一种被认为是“最佳实践”？

Cloud SQL 代理边车

该云SQL代理三轮建立一个TCP连接到被谷歌的基础设施托管的代理服务。然后，这会将您连接到 Google 网络上的云 SQL 实例。

优点

• 无需管理应用程序中的加密材料即可建立安全连接
• 连接到实例，您无需管理 DNS 记录或 IP 地址

缺点

• 您必须创建一个密钥来存储服务帐户密钥。
• 您必须在 pod 旁边管理一个 sidecar 实例，如果失败，您将无法再连接到您的数据库
• 由于您拥有代理层的层数而增加了延迟

私有IP + SSL

使用私有 IP并将实例连接到您的 VPC 允许您使用内部 IP 地址，该地址未公开路由，并将流量保持在您的 VPC 实例中。最重要的是，设置到您的数据库的仅SSL连接以确保点对点的流量安全。

优点

• 与数据库的低延迟连接，因为它是点对点连接
• 您管理服务之间的密钥
• 无需外部依赖项或系统即可在两者之间进行连接

缺点

• 您必须在连接内管理 SSL 证书
• 您必须验证集群中的 IP 和 DNS 记录设置是否正确

我错过了什么吗？这两个确实提供相同的东西吗？两者之间没有绝对明确的赢家，您可以选择最适合您风格的那个吗？