Open mmurto opened 5 months ago
or some other IaC solution.
I'd like to throw https://github.com/VirtuslabRnD/pulumi-kotlin into the ring.
I'd like to throw https://github.com/VirtuslabRnD/pulumi-kotlin into the ring.
Let me file an issue for that 😁
Let me file an issue for that 😁
They've implemented it already 😃
Nice!
Should we try it, or stick to some proven solution? They lay out it as experimental and proof of concept, but the use case is quite simple, so it's totally possible it works well enough. Any thoughts?
Should we try it, or stick to some proven solution?
The implementation is not released just yet in any case, but personally I think we're still in a situation where we could experiment a bit and give Pulumi generally and Pulumi-Kotlin specifically a try.
@sschu, IIRC you were recommending Pulumi over Terraform to me once. Any opinion here?
What I like about Pulumi is the fact that you can write unit tests since you are using a real programming language in contrast to Terraform. An upside for Terraform is that there is already an OSS fork of it in form of OpenTofu (https://opentofu.org), not sure how the license situation will evolve for Pulumi. On the Keycloak providers themselves I cannot really comment, I don't have any experience with either of them. Keycloak itself has an operator that also allows to provision in-Keycloak entities as K8s custom resources. But this is probably not helpful if you want to support other environments as well. If you are already using Terraform or Pulumi, I would probably go with whatever you are currently using to not introduce too many technologies. If you are just introducing an IaC tool, it might make sense to also look at other use cases that might come up in the future.
I agree that it would be nice to have configuration as code for the Keycloak demo instances used in the Docker Compose setup. @mmurto Do you already have an idea how to run Terraform (or Pulumi) as part of the Docker Compose setup to configure Keycloak? That's something I have not done before.
Currently I found it the easiest to just use the Keycloak UI to make the required changes and then export the realm.
I agree that it would be nice to have configuration as code for the Keycloak demo instances used in the Docker Compose setup. @mmurto Do you already have an idea how to run Terraform (or Pulumi) as part of the Docker Compose setup to configure Keycloak? That's something I have not done before.
Currently I found it the easiest to just use the Keycloak UI to make the required changes and then export the realm.
Haven't tried it, but automatic way could be to have a service in Docker Compose that runs Terraform after the services are up.
This could be useful: https://github.com/adorsys/keycloak-config-cli
keycloak-config-cli is a Keycloak utility to ensure the desired configuration state for a realm based on a JSON/YAML file. The format of the JSON/YAML file based on the export realm format. Store and handle the configuration files inside git just like normal code. A Keycloak restart isn't required to apply the configuration.
There is currently a community survey running asking the community about their preferred tooling to configure Keycloak (see https://www.keycloak.org/2024/06/realm-config-manamagemtn-tools-survey). The results will be published, this might be interesting here.
LOL, I thought you made a typo in the URL, but it's really "manamagemtn" (sic)!
Do you actually read URLs before you click on them? ;)
The current management of the Keycloak instance for development with realm JSON makes modifications, such as adding new clients a little complicated, partly due to things like organization specific roles being visible in the JSON when it is exported from Keycloak.
For ease of management and having a better visibility for what is required from Keycloak, it would be good to maintain the required Keycloak settings with Terraform or some other IaC solution.