[keycloak-dev] Running custom scripts in Keycloak container image

[Sebastian Laskawiec]

Yes, that's the idea how this can work.

On Tue, Feb 12, 2019 at 4:19 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Regarding the PR from Wouter. Instead of extending the image would be
> possible to attach a volume with the scripts that need to be run on
> startup? That would avoid the burden of creating a new image to only add a
> few files into a directory.
>
> On Tue, Feb 12, 2019 at 12:37 PM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello,
>>
>> I'm one of the maintainers of the Keycloak helm chart:
>> https://github.com/helm/charts/tree/master/stable/keycloak
>> Since a lot of our users need to adjust the default configuration that is
>> provided by the Keycloak docker images, we currently generate a
>> keycloak.cli file that we apply during start. However, some of this
>> configuration is again overridden by the defaults from the Keycloak docker
>> image.
>>
>> See:
>>
>> https://github.com/helm/charts/blob/master/stable/keycloak/templates/configmap.yaml#L12
>> Configuration:
>>
>> https://github.com/helm/charts/blob/master/stable/keycloak/values.yaml#L121
>>
>> Having dedicated support for config customizations at bootstrap in the
>> stock Keycloak image would make things much easier here :)
>>
>> Cheers,
>> Thomas
>>
>> Am Di., 12. Feb. 2019 um 14:42 Uhr schrieb Sebastian Laskawiec <
>> slaskawi at redhat.com>:
>>
>> > Hey guys,
>> >
>> > A while ago, one of our contributors, Wouter, sent an interesting pull
>> > request: https://github.com/jboss-dockerfiles/keycloak/pull/176
>> >
>> > The aim is to allow running custom scripts just before Keycloak boots up
>> > and after the main configuration is done. This allows a user to inject
>> his
>> > own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
>> > execute them automatically.
>> >
>> > This is somewhat related to what the Integrately Team is doing. They
>> > basically use an InitContainer [1] to put additional extensions into our
>> > image. Perhaps with the proposed approach, they could embed a custom
>> script
>> > that would download whatever extensions they need and put them into the
>> > deployments directory?
>> >
>> > After thinking about this for a while, and besides really good
>> advantages
>> > of the Pull Request, I have some doubts. The biggest one is about our
>> > guarantees with regard the Keycloak distribution (by saying
>> distribution I
>> > mean the binaries, their structure and Keycloak server location in the
>> > image). If we accept this approach, it will be pretty hard for us to
>> change
>> > any major thing (even some trivial things like the location of the
>> Keycloak
>> > Server) without breaking the client scripts.
>> >
>> > Personally, I'm slightly leaning towards accepting this feature, but
>> with a
>> > description in README, that the user scripts may break at any time and
>> in
>> > any version (maybe even we should print this message in our logs). This
>> way
>> > we'll make the contract for such scripts very clear.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Sebastian
>> >
>> > [1] https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>