No access to Keycloak container

Open Source Projects Compose
1

I have decided to convert my infrastructure at home to Docker containers. Right now I’m using a stack of Intel NUC computers for the purpose. But several of them do virtually nothing, so they are obvious candidates to be replaced. My first attempt is to get Keycloak running in a container, along with an Nginx reverse proxy. The next step will be to change my web server that hosts a number of websites. But something is wrong as I can’t access Keycloak.
I have created two different Docker composer files for the purpose. One for Keycloak and one for Nginx. The first one for Nginx reverse proxy looks like this:

version: "3.9"

services:
  nginx-proxy:
    container_name: nginx-proxy
    image: jwilder/nginx-proxy:latest
    restart: unless-stopped
    ports:
      - 8080:80
      - 8443:443
    networks:
      - proxynet
    volumes:
      - html:/usr/share/nginx/html
      - dhparam:/etc/nginx/dhparam
      - vhost:/etc/nginx/vhost.d
      - certs:/etc/nginx/certs
      - /run/docker.sock:/tmp/docker.sock:ro
    logging:
      options:
        max-size: "10m"
        max-file: "3"

  letsencrypt:
    container_name: letsencrypt-helper
    image: jrcs/letsencrypt-nginx-proxy-companion:latest
    restart: unless-stopped
    networks:
      - proxynet
    volumes_from:
      - nginx-proxy
    environment:
      NGINX_PROXY_CONTAINER: nginx-proxy
      DEFAULT_EMAIL: webmaster@example.dk
    depends_on:
      - nginx-proxy

volumes:
  certs:
  html:
  vhost:
  dhparam:

networks:
  proxynet:
    external: true

The next composer file for Keycloak looks like this:

version: "3.9"

services:
  postgres:
    image: postgres:latest
    restart: unless-stopped
    container_name: postgresql
    environment:
      POSTGRES_DB: ${PG_DB}
      POSTGRES_USER: ${PG_DB_USERNAME}
      POSTGRES_PASSWORD: ${PG_DB_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data

  keycloak:
    depends_on:
      - postgres
    container_name: keycloak
    environment:
      KC_DB_URL: jdbc:postgresql://localhost:5432/keycloak
      KC_DB: ${PG_DB}
      KC_DB_USERNAME: ${PG_DB_USERNAME}
      KC_DB_PASSWORD: ${PG_DB_PASSWORD}
      KEYCLOAK_ADMIN: ${KC_ADMIN}
      KEYCLOAK_ADMIN_PASSWORD: ${KC_ADMIN_PASSWORD}
      KC_EDGE: proxy
      KC_PROXY: edge
      KC_LOG_LEVEL: info
      KC_HOSTNAME: ${KC_HOST}
      LETSENCRYPT_HOST: ${LETSENCRYPT_HOST}
      LETSENCRYPT_EMAIL: ${LETSENCRYPT_EMAIL}
      VIRTUAL_HOST: ${LETSENCRYPT_HOST}
      VIRTUAL_PORT: ${KC_PORTS}
    image: quay.io/keycloak/keycloak:${KC_VERSION}
    networks:
      - proxynet
    restart: unless-stopped

volumes:
  postgres_data:

#Use this configuration in production with nginx-proxy container
networks:
  proxynet:
    external: true

There is also an .env file:

KC_VERSION=20.0.2
KC_PORTS=8090     
PG_DB_USERNAME=keycloak
PG_DB_PASSWORD=passw0rd1
PG_DB=keycloak
KC_ADMIN=admin
KC_ADMIN_PASSWORD=passw0rd2
KC_HOST=auth.example.dk
LETSENCRYPT_HOST=auth.example.dk
LETSENCRYPT_EMAIL=webmaster@example.dk

Hope someone can figure out what it takes to get it running :slightly_smiling_face:

2

Observations:

  • the postgres service does not define a network and as such is attached to the default network of the compose project (${project_name}_default)
  • the keycloak service declares a network, which afaik requires the default network to be specifically added to be attached to it (I could be mistaken here).
  • the jdbc connection string (KC_DB_URL) can’t be right: localhost in a container is not the same localhost of the host or the localhost of another container. You need to replace localhost with the service name of the container, in your case postgres (as this is how you named the service for your postgres container).

Just declare another network underneath the top-level networks section and assign both services to it. Fix the jdbc connections string and you should be good.

If things still don’t play nice, it will be helpful to see container logs.

Note: I strongly suggest to not use the latest tag for the postgres image, as upgrades between major versions will require data migration, you will want to have full control about when this happens.