<div dir="ltr">Agreed than. We'll stick with plan Dockerfile.<div><br></div><div>Thanks everyone for good discussion and putting good arguments on the table.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 20, 2017 at 10:28 AM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I tend to agree with Gustavo.<br>
The docker image should be as straightforward as possible. All the fancy<br>
build tools and layerings just create multiple levels of indirection. It<br>
also makes things more brittle.<br>
<br>
So -1 from me.<br>
<br>
Tristan<br>
<br>
On 11/10/17 6:31 PM, Gustavo Fernandes wrote:<br>
> IMHO the cons are much more significant than the pros, here's a few more:<br>
><br>
> - Increase the barrier to users/contributors, forcing them to learn a<br>
> new tool if they need to customize the image;<br>
> - Prevents usage of new/existent features in the Dockerfile, such as<br>
> [1], at least until the generator supports it;<br>
> - Makes the integration with Dockerhub harder.<br>
><br>
> Furthermore, integrating Jolokia and DB drivers are trivial tasks, it<br>
> hardly justifies migrating the image completely just to be able to<br>
> re-use some external scripts to patch the server at Docker build time.<br>
><br>
> With relation to the release cycle, well, this is another discussion. As<br>
> far as Infinispan is concerned, it takes roughly 1h to release both the<br>
> project and the docker image :)<br>
><br>
> So my vote is -1<br>
><br>
> [1]<br>
> <a href="https://docs.docker.com/engine/userguide/eng-image/multistage-build/#before-multi-stage-builds" rel="noreferrer" target="_blank">https://docs.docker.com/engine/userguide/eng-image/multistage-build/#before-multi-stage-builds</a><br>
> <<a href="https://docs.docker.com/engine/userguide/eng-image/multistage-build/#before-multi-stage-builds" rel="noreferrer" target="_blank">https://docs.docker.com/engine/userguide/eng-image/multistage-build/#before-multi-stage-builds</a>><br>
><br>
> Thanks,<br>
> Gustavo<br>
><br>
> On Thu, Nov 9, 2017 at 11:33 AM, Sebastian Laskawiec<br>
> <<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a> <mailto:<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a>>> wrote:<br>
><br>
> That's a very good point Gustavo.<br>
><br>
> Let me try to iterate on pros and cons of each approach:<br>
><br>
> * Putting all bits into distribution:<br>
> o Pros:<br>
> + Unified approach for both project and product<br>
> + Supporting all platforms with a single distribution<br>
> o Cons:<br>
> + Long turnaround from community to the product based bits<br>
> (like Online Services)<br>
> + Some work has already been done in Concreate-based<br>
> approach (like Jolokia) and battle-tested (e.g. with EAP).<br>
> * Putting all additional bits into integration layers<br>
> (Concreate-based approach):<br>
> o Pros:<br>
> + Short turnaround, in most of the cases we need to patch<br>
> the integration bits only<br>
> + Some integration bits has already been implemented for<br>
> us (Joloka, DB drivers etc)<br>
> o Cons:<br>
> + Some integrations bits needs to be reimplemented, e.g.<br>
> KUBE_PING<br>
> + Each integration layer needs to have its own code (e.g.<br>
> community Docker image, xPaaS images, Online Services)<br>
><br>
> I must admit that in the past I was a pretty big fan of putting all<br>
> bits into community distribution and driving it forward from there.<br>
> But this actually changed once Concreate tool appeared. It allows to<br>
> externalize modules into separate repositories which promotes code<br>
> reuse (e.g. we could easily use Jolokia integration implemented for<br>
> EAP and at the same time provide our own custom configuration for<br>
> it). Of course most of the bits assume that underlying OS is RHEL<br>
> which is not true for the community (community images use CentOS) so<br>
> there might be some mismatch there but it's definitely something to<br>
> start with. The final argument that made me change my mind was<br>
> turnaround loop. Going through all those releases is quite<br>
> time-consuming and sometimes we just need to update micro version to<br>
> fix something. A nice example of this is KUBE_PING which had a<br>
> memory leak - with concreate-based approach we could fix it in one<br>
> day; but as long as it is in distribution, we need to wait whole<br>
> release cycle.<br>
><br>
> Thanks,<br>
> Sebastian<br>
><br>
> On Tue, Nov 7, 2017 at 8:07 PM Gustavo Fernandes<br>
> <<a href="mailto:gustavo@infinispan.org" target="_blank">gustavo@infinispan.org</a> <mailto:<a href="mailto:gustavo@infinispan.org" target="_blank">gustavo@infinispan.org</a>>> wrote:<br>
><br>
> IMHO we should ship things like scripts, external modules,<br>
> drivers, etc with the server itself, leaving the least amount of<br>
> logic in the Docker image.<br>
><br>
> What you are proposing is the opposite: introducing a templating<br>
> engine that adds a level of indirection to the Docker image (the<br>
> Dockerfile is generated) plus<br>
> it grabs jars, modules, scripts, xmls, etc from potentially<br>
> external sources and does several patches to the server at<br>
> Docker image creation time.<br>
><br>
> WRT the docker hub, I think it could be used with Concreate by<br>
> using hooks, I did a quick experiment of a Dockerhub automated<br>
> build having a dynamically generating a Dockerfile in [1], but I<br>
> guess<br>
> the biggest question is if the added overall complexity is worth<br>
> it. I'm leaning towards a -1, but would like to hear more<br>
> opinions :)<br>
><br>
> [1] <a href="https://hub.docker.com/r/gustavonalle/dockerhub-test/" rel="noreferrer" target="_blank">https://hub.docker.com/r/gustavonalle/dockerhub-test/</a><br>
> <<a href="https://hub.docker.com/r/gustavonalle/dockerhub-test/" rel="noreferrer" target="_blank">https://hub.docker.com/r/gustavonalle/dockerhub-test/</a>><br>
><br>
> Thanks,<br>
> Gustavo<br>
><br>
> On Tue, Nov 7, 2017 at 3:14 PM, Sebastian Laskawiec<br>
> <<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a> <mailto:<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a>>> wrote:<br>
><br>
> Hey!<br>
><br>
> Together with Ryan we are thinking about the future of<br>
> Infinispan Docker image [1].<br>
><br>
> Currently we use a single Dockerfile and a bootstrap script<br>
> which is responsible for setting up memory limits and<br>
> creating/generating (if necessary) credentials. Our build<br>
> pipeline uses Docker HUB integration hooks, so whenever we<br>
> push a new commit (or a tag) our images are being rebuilt.<br>
> This is very simple to understand and very powerful setup.<br>
><br>
> However we are thinking about bringing product and project<br>
> images closer together and possibly reusing some bits (a<br>
> common example might be Jolokia - those bits could be easily<br>
> reused without touching core server distribution). This<br>
> however requires converting our image to a framework called<br>
> Concreate [2]. Concreate divides setup scripts into modules<br>
> which are later on assembled into a single Dockerfile and<br>
> built. Modules can also be pulled from other public git<br>
> repository and I consider this as the most powerful option.<br>
> It is also worth to mention, that Concreate is based on YAML<br>
> file - here's an example of JDG image [3].<br>
><br>
> As you can see, this can be quite a change so I would like<br>
> to reach out for some opinions. The biggest issue I can see<br>
> is that we will lose our Docker HUB build pipeline and we<br>
> will need to build and push images on our CI (which already<br>
> does this locally for Online Services).<br>
><br>
> WDYT?<br>
><br>
> Thanks,<br>
> Sebastian<br>
><br>
> [1]<br>
> <a href="https://github.com/jboss-dockerfiles/infinispan/tree/master/server" rel="noreferrer" target="_blank">https://github.com/jboss-dockerfiles/infinispan/tree/master/server</a><br>
> <<a href="https://github.com/jboss-dockerfiles/infinispan/tree/master/server" rel="noreferrer" target="_blank">https://github.com/jboss-dockerfiles/infinispan/tree/master/server</a>><br>
> [2] <a href="http://concreate.readthedocs.io/en/latest/" rel="noreferrer" target="_blank">http://concreate.readthedocs.io/en/latest/</a><br>
> <<a href="http://concreate.readthedocs.io/en/latest/" rel="noreferrer" target="_blank">http://concreate.readthedocs.io/en/latest/</a>><br>
> [3]<br>
> <a href="https://github.com/jboss-container-images/jboss-datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml" rel="noreferrer" target="_blank">https://github.com/jboss-container-images/jboss-datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml</a><br>
> <<a href="https://github.com/jboss-container-images/jboss-datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml" rel="noreferrer" target="_blank">https://github.com/jboss-container-images/jboss-datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml</a>><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a>><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a>><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> <<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
><br>
<br>
--<br>
Tristan Tarrant<br>
Infinispan Lead<br>
JBoss, a division of Red Hat<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div>