Stream: containers

Topic: ✔ Keycloak

Philip Durbin 🚀 (May 10 2023 at 20:09):

Talk to me about Keycloak. I'm reviewing PR #9532 and as suggested in the description, I'm adding the following to our docker compose dev file:

  dev_keycloak:
    container_name: "dev_keycloack"
    image: 'quay.io/keycloak/keycloak:19.0'
    hostname: keycloak
    environment:
      - KEYCLOAK_ADMIN=kcadmin
      - KEYCLOAK_ADMIN_PASSWORD=kcpassword
      - KEYCLOAK_LOGLEVEL=DEBUG
      - KC_HOSTNAME_STRICT=false
    networks:
      dataverse:
        aliases:
          - keycloak.mydomain.com #create a DNS alis within the network (add the same alias to your /etc/hosts to get a working OIDC flow)
    command: start-dev --import-realm --http-port=8090  # change port to 8090, so within the network and external the same port is used
    ports:
      - "8090:8090"
    volumes:
      - './conf/keycloak/oidc-realm.json:/opt/keycloak/data/import/oidc-realm.json'

If this works, maybe we should remove the older stuff (and related docs):

conf/keycloak
conf/keycloak/oidc-realm.json
conf/keycloak/rm-keycloak.sh
conf/keycloak/docker-compose.yml
conf/keycloak/run-keycloak.sh
conf/keycloak/oidc-keycloak-auth-provider.json

Heads up especially to @Guillermo Portas who added this in PR #9234.

Philip Durbin 🚀 (May 10 2023 at 20:29):

Oh, I see, he's reusing the old config:

    volumes:
      - './conf/keycloak/oidc-realm.json:/opt/keycloak/data/import/oidc-realm.json'

Philip Durbin 🚀 (May 10 2023 at 20:30):

But maybe we don't need conf/keycloak/docker-compose.yml anymore (and the stop and start scripts).

Oliver Bertuch (May 10 2023 at 21:33):

Sorry was talking with Leonid about version PIDs :-)

Oliver Bertuch (May 10 2023 at 21:35):

I'm not sure if we should add it to that file

Oliver Bertuch (May 10 2023 at 21:36):

On the other hand, maybe we can make it disabled/enabled in some way, so it doesn't sit around without doing anything

Oliver Bertuch (May 10 2023 at 21:37):

We should talk about https://github.com/IQSS/dataverse/pull/9273 as well to make it easier to integrate the app and the keycloak you're starting

Oliver Bertuch (May 10 2023 at 21:38):

You could of course add it to the bootstrapping thingy to load the provider as a model

Oliver Bertuch (May 10 2023 at 21:39):

I'm simply a fan of making these things deployable and changeable as easy as possible

Oliver Bertuch (May 10 2023 at 21:39):

No finicky "reload the provider as json" when a detail changes, like a new password etc

Guillermo Portas (May 11 2023 at 08:43):

We wanted Keycloak to be an optional dependency as opposed to the other dependencies, so I kept it in the original docker-compose file instead of adding it to docker-compose-dev.

In any case, we can achieve something similar, using the same docker compose file, omitting the service when executing the up command:

docker-compose -f docker-compose-dev.yml up -d --scale dev_keycloak=0

Guillermo Portas (May 11 2023 at 08:45):

Following this approach, we would handle only one docker-compose file, but running it may be less practical for most cases (where you don't need Keylcoak), because you need to append that arg to the command.

Oliver Bertuch (May 11 2023 at 08:49):

Another thought: leave Keycloak in the separate compose file, but make it appear on the same network. You'd need to run two commands when using compose, but that may be fine. I'd need to look into how to integrate this in the Maven run, but that might be achievable

Philip Durbin 🚀 (May 15 2023 at 12:16):

Just a heads up that the PR has been replaced by PR #9591.

Philip Durbin 🚀 (May 15 2023 at 12:18):

And it looks like my proposed change to edit the root docker compose file, adding Keycloak there, has been added. And a related note for the dev guide.

Philip Durbin 🚀 (Aug 11 2023 at 15:20):

We ended up merging #9591. Resolving.

Notification Bot (Aug 11 2023 at 15:20):

Philip Durbin has marked this topic as resolved.

Last updated: Oct 30 2025 at 05:14 UTC