12:53 p.m.
Following some of the best practices for continuous Integration and
continuous delivery there needs to be environments for build, test,
and production. This would mean that following these practices would
require you to have multiple versions of keycloak at different stages
of development cycle. Some of these environments might not have
important persistent data while others might. In order to have builds
transition from one environment to another there may be configuration
changes required for a build to be valid. This is especially true when
new services (openid clients) are being added or "default" accounts.
I'm trying to come up with a scripted way of updating keycloak
instances that are backed up by an RDMS. This may include adding new
clients, adding new users, updating realm config, etc... Originally I
was planning on simply exporting the realm config and importing it
every time keycloak starts. If I enabled the OVERWRITE option I might
overwrite things that I do not want overridden. This is especially
true if there is some config that differ's based on whether it is a
build, test, or production instance. If I don't enable it then it is
only useful for new/blank keycloak environments. I considered using
liquibase but since I do not have control of schema changes created by
the keycloak team I might run into issues with my liquibase file not
being valid after a migration/liquibase update by the keycloak team as
my liquibase file would run after keycloak's does. There might also be
some other unknown issues our liquibase changes conflicting somehow
with keycloak's liquibase changes. I've also considered writing my own
updater tool using a scripting language (python/ruby) that calls
keycloak's rest api. The issues with this mechanism is it feels like I
am recreating the wheel as well as not being able to find good
documentation on keycloak's openid endpoints/url's used for different
oauth2 flows. Even if I did find this documentation it would also
require me to find a good openid client for the scripting language.
This doesn't matter for our normal clients as they simply use the
keycloak subsystems and adapters instead. I've also looked at commonly
used server configuration software such as chef, puppet, and ansible.
I don't see a good solution using any of those tools yet either. What
have other people done for cases like this? Please don't tell me there
is someone who is doing this all manually because that doesn't work in
modern software development.
- doesn't accidentally delete users
- doesn't accidentally delete clients
- doesn't invalidate sessions (optional)
- works to bring up new, correctly configured, keycloak instances
- handles applying updates to existing keycloak instances
- can handle minor differences between keycloak instances (build,
test, production) when updating
- preferably can work well in rolling deployment scenario's.
-- I hope the keycloak team is taking these into consideration when
doing database migration between 1-2 releases. It would be nice if
they set some specific rules for rolling updates between versions (aka
backwards breaking changes)