<div dir="ltr"><span style="font-size:12.8px">So what you say is true for the first download, but afterwards all</span><br style="font-size:12.8px"><span style="font-size:12.8px">the base layers of wf + jdk + ... are present. With stripping</span><br style="font-size:12.8px"><span style="font-size:12.8px">into 1 layer there is no chance of caching.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Situation of course changes when the base layer is updated.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Right, good point, I was optimizing more for the very first download, when people want to try it on their boxes or put the image id in the openshift and spin the h-services as fast as possible. While layers are useful in the long tern or when you have multiple containers based on the same image or the same image with multiple versions. But if squashing everything into one layer can actually make the image smaller, then there must be something strange happening like the 1st layer creating X and the 2nd layer removing X. In our case it's probably the wildfly image creating the standalone wildfly server while the h-services actually replacing it with our wf server + h-services.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">btw. there was good talk on the devconf about it <a href="https://www.youtube.com/watch?v=ZVX8aXJ-hV4">https://www.youtube.com/watch?v=ZVX8aXJ-hV4</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">jk</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 1:19 PM, Heiko W.Rupp <span dir="ltr"><<a href="mailto:hrupp@redhat.com" target="_blank">hrupp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1 Feb 2017, at 12:29, Jiri Kremser wrote:<br>
<br>
> base image with JRE 8 and Alpine linux: 76.8 MB<br>
<br>
</span>Yes, alpine is only 3-4 MB that is great.<br>
<span class=""><br>
> I also removed<br>
> 9.2M /opt/jboss/wildfly/docs<br>
<br>
</span>Makes sense.<br>
<span class=""><br>
<br>
> What also helped was squashing all the image layers into 1. This makes<br>
> the<br>
> download faster and possibly the image smaller. When applying<br>
> docker-squash<br>
> [1] to the current h-services image it saves ~50megs<br>
<br>
</span>This is a bit of a false friend as docker pull only transfers layers it<br>
does not yet have.<br>
<br>
E.g<br>
<br>
$ docker pull pilhuhn/hawkular-services:0.<wbr>30.0.Final<br>
0.30.0.Final: Pulling from pilhuhn/hawkular-services<br>
08d48e6f1cff: Already exists<br>
664e6a3041e6: Already exists<br>
2f8461e7022b: Already exists<br>
9500f4548bd3: Already exists<br>
69e2e5217a47: Already exists<br>
cf95509fd4ad: Downloading [======><br>
] 10.75 MB/89.61 MB<br>
<br>
So what you say is true for the first download, but afterwards all<br>
the base layers of wf + jdk + ... are present. With stripping<br>
into 1 layer there is no chance of caching.<br>
Situation of course changes when the base layer is updated<br>
<span class=""><br>
<br>
> I am aware that this probably wont fly with some RH policy that we<br>
> should<br>
> base our SW on Fedora/RHEL base OS images, but I am gonna use them for<br>
> development and because I often run out of space because of Docker.<br>
<br>
</span>I like those alpine images and use them for private stuff,<br>
but for Hawkular upstream I think we should use something<br>
that is close for downstream so minimise the moving parts.<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
</blockquote></div><br></div>