7:53 a.m.
Yes, that's the idea how this can work.
On Tue, Feb 12, 2019 at 4:19 PM Pedro Igor Silva <psilva(a)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(a)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/conf...
> 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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>