Unix Socket is not generated for Goggle's SQL Auth Proxy using docker-compose

Question

I suspect that I have some issue related to the volume where I intend to have Google's SQL Auth Proxy generate its socket.

While running the SQL Auth Proxy locally...

~/cloud-sql-proxy --unix-socket ~/.cloudsql --credentials-file ~/.cloud-sql.credentials.json project:region:instance

A file (I assume some sort of socket file) is created in the .cloudsql directory.

However, when running the docker-compose.yml below...

volumes:
  socket:

services:
  proxy:
    container_name: proxy
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.8.2
    command: --unix-socket /cloudsql project:region:instance?port=3307 --credentials-file /secrets/cloudsql/credentials.json
    ports:
      - 3307:3307
    volumes:
      - ./cloud-sql.credentials.json:/secrets/cloudsql/credentials.json
      - socket:/cloudsql
    restart: always

  web-api:
    container_name: web-api
    build:
      context: .
      dockerfile: ./apps/web-api/Dockerfile
    ports:
      - 3333:3333
    volumes:
      - socket:/cloudsql
    depends_on:
      - proxy
    env_file:
      - .env
    restart: always

  data-api:
    # Basically the same as web-api. Ommitted for brevity

I get the following logs showing that the proxy is up and running...

> Authorizing with the credentials file at "/secrets/cloudsql/credentials.json"
> [project:region:instance] Listening on 127.0.0.1:3307
> The proxy has started successfully and is ready for new connections!

...but the socket file is not generated in the mounted volume (or anywhere else that I can find) and my API applications fail to connect with the error:

Error: connect ENOENT /cloudsql/project:region:instance at PipeConnectWrap.afterConnect [as oncomplete]

What I've tried/confirmed

Database Credentials - I've confirmed that my connection credentials work because this worked with the TCP equivalent

socketPath configuration - I've confirmed that the API applications can connect to my local MySQL instance via Unix connection so the socketPath is implemented properly

Some doubts I have

• Volumes are writable by default, no? According to the proxy instructions I had to make the target directory writable, but I don't think that applied here.
• Unix connections are only possible on the same machine. Since there are 3 different containers, can I not connect in this way?
• Have I simply configured something incorrectly or mounted the volume improperly?

Answer 1

I had to rework the command and piggyback on the /tmp directory because a custom /cloudsql directory was failing to bind for some reason.

services:
  proxy:
    container_name: proxy
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.8.2
    command: project:region:instance --unix-socket /tmp --credentials-file /secrets/cloudsql/credentials.json
    volumes:
      - ./cloud-sql.credentials.json:/secrets/cloudsql/credentials.json
      - socket:/tmp
    restart: always

  web-api:
    container_name: web-api
    build:
      context: .
      dockerfile: ./apps/web-api/Dockerfile
    ports:
      - 3333:3333
    volumes:
      - socket:/tmp
    depends_on:
      - proxy
    env_file:
      - .env
    restart: always

  data-api:
    # Basically the same as web-api. Omitted for brevity