https://supertokens.com/
Join Discord
Menu
Home
Archive
Hey y'all. Firstly, thanks for this awesome support channel. I'm having an issue setting up Supert...
# support-questions-legacy
m
Hey y'all. Firstly, thanks for this awesome support channel. I'm having an issue setting up Supertokens with Docker (using a Postgres container and Docker Compose). I've followed the guide but the Supertokens container is having trouble connecting to the Postgres db. The error that I'm getting is:
Copy code
Setting up PostgreSQL connection pool.
30 Jan 2023 23:59:43:477 +0000 | ERROR | pid: 36ab325a-c7ca-4472-bdc1-985af741e6be | [main] thread | io.supertokens.storage.postgresql.HikariLoggingAppender.doAppend(HikariLoggingAppender.java:132) | SuperTokens - Exception during pool initialization.

30 Jan 2023 23:59:43:478 +0000 | INFO | pid: 36ab325a-c7ca-4472-bdc1-985af741e6be | [main] thread | io.supertokens.storage.postgresql.ConnectionPool.initPool(ConnectionPool.java:150) | Error connecting to PostgreSQL instance. Please make sure that PostgreSQL is running and that you have specified the correct values for ('postgresql_host' and 'postgresql_port') or for 'postgresql_connection_uri'
My Docker Compose file is looking like this >>
Copy code
version: "3.9"
services:
  db:
    image: postgres:15.1-alpine
    container_name: isoflow_v2_db
    restart: unless-stopped
    ports:
      - ${DB_PORT}:5432
    networks:
      - app_network
    environment:
      POSTGRES_USER: "${DB_USER}"
      POSTGRES_PASSWORD: "${DB_PASSWORD}"
    volumes:
      - db:/var/lib/postgresql/data
  auth_db:
    image: postgres:15.1-alpine
    container_name: isoflow_v2_auth_db
    restart: unless-stopped
    ports:
      - ${AUTH_DB_PORT}:5432
    networks:
      - app_network
    environment:
      POSTGRES_USER: "${AUTH_DB_USER}"
      POSTGRES_PASSWORD: "${AUTH_DB_PASSWORD}"
    volumes:
      - auth_db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready"]
      interval: 5s
      timeout: 5s
      retries: 5
  supertokens:
    image: registry.supertokens.io/supertokens/supertokens-postgresql
    container_name: isoflow_v2_auth_app
    depends_on:
      auth_db:
        condition: service_healthy
    ports:
      - ${AUTH_APP_PORT}:3567
    environment:
      POSTGRESQL_CONNECTION_URI: "postgresql://${AUTH_DB_USER}:${AUTH_DB_PASSWORD}@auth_db:5432/${AUTH_DB_USER}"
    networks:
      - app_network
    restart: unless-stopped
    healthcheck:
      test: >
        bash -c 'exec 3<>/dev/tcp/127.0.0.1/3567 && echo -e "GET /hello HTTP/1.1\r\nhost: 127.0.0.1:3567\r\nConnection: close\r\n\r\n" >&3 && cat <&3 | grep "Hello"'
      interval: 10s
      timeout: 5s
      retries: 5
volumes:
  db:
  auth_db:
networks:
  app_network:
    driver: bridge
If I run 
bash
within the Supertokens Docker container, I can see the 
POSTGRESQL_CONNECTION_URI
env variable is set correctly. I've even tried installing 
psql
in the container and trying to connect to the db using the URI, which works fine. Any ideas?
There's no clear resolution in that thread, but in my case the database 
supertokens
does exist. I can connect to it via TablePlus (on the exposed container port).
r
the issue is that the db service name is 
db
in the file above, but in the 
POSTGRESQL_CONNECTION_URI
config, you have used 
auth_db
m
@rp_st sorry I should have been clearer with this snippet and omitted that db config for simplicity. There are 2 db containers, one is the main 
db
, one is 
auth_db
r
hmm
whats the resolved value of 
postgresql://${AUTH_DB_USER}:${AUTH_DB_PASSWORD}@auth_db:5432/${AUTH_DB_USER}
?
m
in the container it's resolved to 
POSTGRESQL_CONNECTION_URI=postgresql://supertokens:password@auth_db:5432/supertokens
r
that seems about right
m
yep, I can connect to the URI directly from within the container if I install 
postgres
r
there isn't anything obvious wrong with it
m
yes, it's got me stumped 🤷‍♂️
r
maybe try the docker config on our site first and see if that works.. and then iteratively make it closer to your config
m
yes, good point, I'll try that
thanks
@rp_st So I tried it with the default 
docker-compose
config. It works, but I found an unrelated issue. It looks like the db healthcheck fails because of the 
-U supertokens_user
flag, I found I can get round it by omitting that flag, i.e.:
Copy code
healthcheck:
  test: ['CMD', 'pg_isready']
It's still a mystery to me why my previous config wasn't working, my first thought is that I'm using the 
alpine
version of Postgres.
Maybe that has something to do with it
@rp_st The service name has something to do with it. I originally called the db service 
auth_db
in my docker-compose file, and the Supertokens service would fail to start. Renaming the service to 
db
makes it work 🤷‍♂️ You can try this with the vanilla docker-compose config as well:
Copy code
version: "3"

services:
  auth_db:
    image: "postgres:latest"
    environment:
      POSTGRES_USER: supertokens_user
      POSTGRES_PASSWORD: somePassword
      POSTGRES_DB: supertokens
    ports:
      - 5432:5432
    networks:
      - app_network
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "pg_isready"]
      interval: 5s
      timeout: 5s
      retries: 5

  supertokens:
    image: registry.supertokens.io/supertokens/supertokens-postgresql:4.3
    depends_on:
      auth_db:
        condition: service_healthy
    ports:
      - 3567:3567
    environment:
      POSTGRESQL_CONNECTION_URI: "postgresql://supertokens_user:somePassword@auth_db:5432/supertokens"
    networks:
      - app_network
    restart: unless-stopped
    healthcheck:
      test: >
        bash -c 'exec 3<>/dev/tcp/127.0.0.1/3567 && echo -e "GET /hello HTTP/1.1\r\nhost: 127.0.0.1:3567\r\nConnection: close\r\n\r\n" >&3 && cat <&3 | grep "Hello"'
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  app_network:
    driver: bridge
This fails for me, the only difference being the service name 👆
I think the underscore in the service name is throwing it off
this function does not handle underscores in URIs
there were some discussions around this function being based off an old RFC in which URIs did not allow underscores, but now that RFC has been updated to allow, but this function apparantly never followed suit or at least the version being used. https://bugs.openjdk.org/browse/JDK-8221675
I've submitted a PR that adds a note to the docs to avoid underscores in service names here >> https://github.com/supertokens/docs/pull/587/files
r
@markmanx thanks for the PR - but instead of changing the docs, should we change the java code to take care of underscores as well?
m
That would be ideal. I'm not a Java guy so the docs change is the most I could contribute for the moment. I might take a crack at it if I can find some time, but first I would need to work out how to build the project.
r
"work out how to build the project" -> you mean the java core or something else?
305 Views
PreviousNext
Powered by

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

Powered by