On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml(a)gmail.com&gt; wrote: I've been struggling with a clean way to initialize the keycloak docker container. I need to import a realm definition, and the only way I can find is it start the image with the import options, wait for this to complete so that the database is populated and then to Ctrl-C out and to restart the container proper, which is hardly automatable. With 1.8 this also needs to include defining the admin user. Is there a cleaner way of achieving this? For instance, with the postgres docker images you just put any initialisation *.sql or *.sh scripts in a specific directory and they get executed first time the server starts. Tim _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Edgar, Well, the way I'm doing it now (which I don't like at all, hence the original post), is to run the startup script in a separate container so that the database (Postgres in my case) is populated, and to do that once before the actual container is launched (so that the real container picks up the required configuration from the database). Importing the realm every time might be an alternative, as long is it doesn't over-write any user info. I'll look into that. But hoping that there are better suggestions for this out there! Tim On 15/02/2016 08:40, Edgar Vonk - Info.nl wrote: > Hi Tim, > > We also struggle with this. What we do at the moment is we _always_ import the realm on startup of our Keycloak Docker container. Our current idea is that we will not have any runtime configuration changes in our realm at all, apart from filling the Keycloak caches. The idea being that runtime configuration changes are not automatable. We store our users and groups in LDAP/Active Directory and all realm configuration is stored in the realm JSON file in Git and imported every time. > > I was wondering: if you do change your realm configuration runtime how do you deal with deployment automation? Is your idea to only import your realm definition once? If so, how would you deal with automating realm configuration changes? > > cheers > > Edgar > >> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml(a)gmail.com&gt; wrote: >> >> I've been struggling with a clean way to initialize the keycloak docker >> container. >> I need to import a realm definition, and the only way I can find is it >> start the image with the import options, wait for this to complete so >> that the database is populated and then to Ctrl-C out and to restart the >> container proper, which is hardly automatable. >> With 1.8 this also needs to include defining the admin user. >> >> Is there a cleaner way of achieving this? >> For instance, with the postgres docker images you just put any >> initialisation *.sql or *.sh scripts in a specific directory and they >> get executed first time the server starts. >> >> Tim >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Stian, Ok, thanks. Say that you would only import a realm once. How then would you typically deal with changes in the realm configuration in an automated deployment situation? We do not want any manual steps in our deployment and so we want all Keycloak realm changes managed from our Git repository. Does Keycloak support some kind of update/delta mechanism that we can use to automated realm configuration changes? cheers Edgar On 15 Feb 2016, at 10:45, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: We are planning on at some point to add an import directory. You can dump a realm json file in there and Keycloak will only import it once. It would use the hash of the file and add a marker to the db to make sure it's only done once, even if you delete the realm in the db. Not sure when or even if this will be added though. Another option is that it would be relatively easy to extend the Docker image to import a file only first time it's started. On 15 Feb 2016 10:06, "Tim Dudgeon" <tdudgeon.ml(a)gmail.com&gt; wrote: > Hi Edgar, > > Well, the way I'm doing it now (which I don't like at all, hence the > original post), is to run the startup script in a separate container so > that the database (Postgres in my case) is populated, and to do that > once before the actual container is launched (so that the real container > picks up the required configuration from the database). > Importing the realm every time might be an alternative, as long is it > doesn't over-write any user info. I'll look into that. > But hoping that there are better suggestions for this out there! > > Tim > > On 15/02/2016 08:40, Edgar Vonk - Info.nl <http://info.nl> wrote: > > Hi Tim, > > > > We also struggle with this. What we do at the moment is we _always_ > import the realm on startup of our Keycloak Docker container. Our current > idea is that we will not have any runtime configuration changes in our > realm at all, apart from filling the Keycloak caches. The idea being that > runtime configuration changes are not automatable. We store our users and > groups in LDAP/Active Directory and all realm configuration is stored in > the realm JSON file in Git and imported every time. > > > > I was wondering: if you do change your realm configuration runtime how > do you deal with deployment automation? Is your idea to only import your > realm definition once? If so, how would you deal with automating realm > configuration changes? > > > > cheers > > > > Edgar > > > >> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml(a)gmail.com&gt; wrote: > >> > >> I've been struggling with a clean way to initialize the keycloak docker > >> container. > >> I need to import a realm definition, and the only way I can find is it > >> start the image with the import options, wait for this to complete so > >> that the database is populated and then to Ctrl-C out and to restart > the > >> container proper, which is hardly automatable. > >> With 1.8 this also needs to include defining the admin user. > >> > >> Is there a cleaner way of achieving this? > >> For instance, with the postgres docker images you just put any > >> initialisation *.sql or *.sh scripts in a specific directory and they > >> get executed first time the server starts. > >> > >> Tim > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >