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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev