<div dir="ltr">From experience in the field, i've not had any customers complain / comment on the size of images as of yet - been on OpenShift engagements for over a year now.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 1:38 PM, Matt Wringe <span dir="ltr"><<a href="mailto:mwringe@redhat.com" target="_blank">mwringe@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="">----- Original Message -----<br>
> From: "Heiko W.Rupp" <<a href="mailto:hrupp@redhat.com">hrupp@redhat.com</a>><br>
> To: "Discussions around Hawkular development" <<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>><br>
> Sent: Wednesday, 1 February, 2017 7:19:34 AM<br>
> Subject: Re: [Hawkular-dev] Docker image size does matter<br>
><br>
> 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>
> Yes, alpine is only 3-4 MB that is great.<br>
<br>
</span>Please also take into consideration that minimal docker images do not contain common commands and can be a pain if you need to go into the container and run commands.<br>
<br>
Trying to debug issues when you don't have access to basic commands can be a bit frustrating. Especially if you are not root and cannot just install binaries in the container.<br>
<div class="HOEnZb"><div class="h5"><br>
> > I also removed<br>
> > 9.2M /opt/jboss/wildfly/docs<br>
><br>
> Makes sense.<br>
><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>
> 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>
><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>
> 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>
><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>
</div></div></blockquote></div><br></div>