Re: [infinispan-dev] The future of Infinispan Docker image

That's a very good point Gustavo. Let me try to iterate on pros and cons of each approach: - Putting all bits into distribution: - Pros: - Unified approach for both project and product - Supporting all platforms with a single distribution - Cons: - Long turnaround from community to the product based bits (like Online Services) - Some work has already been done in Concreate-based approach (like Jolokia) and battle-tested (e.g. with EAP). - Putting all additional bits into integration layers (Concreate-based approach): - Pros: - Short turnaround, in most of the cases we need to patch the integration bits only - Some integration bits has already been implemented for us (Joloka, DB drivers etc) - Cons: - Some integrations bits needs to be reimplemented, e.g. KUBE_PING - Each integration layer needs to have its own code (e.g. community Docker image, xPaaS images, Online Services) I must admit that in the past I was a pretty big fan of putting all bits into community distribution and driving it forward from there. But this actually changed once Concreate tool appeared. It allows to externalize modules into separate repositories which promotes code reuse (e.g. we could easily use Jolokia integration implemented for EAP and at the same time provide our own custom configuration for it). Of course most of the bits assume that underlying OS is RHEL which is not true for the community (community images use CentOS) so there might be some mismatch there but it's definitely something to start with. The final argument that made me change my mind was turnaround loop. Going through all those releases is quite time-consuming and sometimes we just need to update micro version to fix something. A nice example of this is KUBE_PING which had a memory leak - with concreate-based approach we could fix it in one day; but as long as it is in distribution, we need to wait whole release cycle. Thanks, Sebastian On Tue, Nov 7, 2017 at 8:07 PM Gustavo Fernandes <gustavo(a)infinispan.org&gt; wrote: > 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&gt; > 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 >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev