[infinispan-dev] The future of Infinispan Docker image

[Gustavo Fernandes]

IMHO we should ship things like scripts, external modules, drivers, etc
with the server itself, leaving the least amount of logic in the Docker
image.

What you are proposing is the opposite: introducing a templating engine
that adds a level of indirection to the Docker image (the Dockerfile is
generated) plus
it grabs jars, modules, scripts, xmls, etc from potentially external
sources and does several patches to the server at Docker image creation
time.

WRT the docker hub, I think it could be used with Concreate by using hooks,
I did a quick experiment of a Dockerhub automated build having a
dynamically generating a Dockerfile in [1], but I guess
the biggest question is if the added overall complexity is worth it. I'm
leaning towards a -1, but would like to hear more opinions :)

[1] https://hub.docker.com/r/gustavonalle/dockerhub-test/

Thanks,
Gustavo

On Tue, Nov 7, 2017 at 3:14 PM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Hey!
>
> Together with Ryan we are thinking about the future of Infinispan Docker
> image [1].
>
> Currently we use a single Dockerfile and a bootstrap script which is
> responsible for setting up memory limits and creating/generating (if
> necessary) credentials. Our build pipeline uses Docker HUB integration
> hooks, so whenever we push a new commit (or a tag) our images are being
> rebuilt. This is very simple to understand and very powerful setup.
>
> However we are thinking about bringing product and project images closer
> together and possibly reusing some bits (a common example might be Jolokia
> - those bits could be easily reused without touching core server
> distribution). This however requires converting our image to a framework
> called Concreate [2]. Concreate divides setup scripts into modules which
> are later on assembled into a single Dockerfile and built. Modules can also
> be pulled from other public git repository and I consider this as the most
> powerful option. It is also worth to mention, that Concreate is based on
> YAML file - here's an example of JDG image [3].
>
> As you can see, this can be quite a change so I would like to reach out
> for some opinions. The biggest issue I can see is that we will lose our
> Docker HUB build pipeline and we will need to build and push images on our
> CI (which already does this locally for Online Services).
>
> WDYT?
>
> Thanks,
> Sebastian
>
> [1] https://github.com/jboss-dockerfiles/infinispan/tree/master/server
> [2] http://concreate.readthedocs.io/en/latest/
> [3] https://github.com/jboss-container-images/jboss-
> datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20171107/e31cf4f9/attachment.html