6:49 a.m.
So what you say is true for the first download, but afterwards all
the base layers of wf + jdk + ... are present. With stripping
into 1 layer there is no chance of caching.
Situation of course changes when the base layer is updated.
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.
btw. there was good talk on the devconf about it
https://www.youtube.com/watch?v=ZVX8aXJ-hV4
jk
On Wed, Feb 1, 2017 at 1:19 PM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
On 1 Feb 2017, at 12:29, Jiri Kremser wrote:
> base image with JRE 8 and Alpine linux: 76.8 MB
Yes, alpine is only 3-4 MB that is great.
> I also removed
> 9.2M /opt/jboss/wildfly/docs
Makes sense.
> What also helped was squashing all the image layers into 1. This makes
> the
> download faster and possibly the image smaller. When applying
> docker-squash
> [1] to the current h-services image it saves ~50megs
This is a bit of a false friend as docker pull only transfers layers it
does not yet have.
E.g
$ docker pull pilhuhn/hawkular-services:0.30.0.Final
0.30.0.Final: Pulling from pilhuhn/hawkular-services
08d48e6f1cff: Already exists
664e6a3041e6: Already exists
2f8461e7022b: Already exists
9500f4548bd3: Already exists
69e2e5217a47: Already exists
cf95509fd4ad: Downloading [======>
] 10.75 MB/89.61 MB
So what you say is true for the first download, but afterwards all
the base layers of wf + jdk + ... are present. With stripping
into 1 layer there is no chance of caching.
Situation of course changes when the base layer is updated
> I am aware that this probably wont fly with some RH policy that we
> should
> base our SW on Fedora/RHEL base OS images, but I am gonna use them for
> development and because I often run out of space because of Docker.
I like those alpine images and use them for private stuff,
but for Hawkular upstream I think we should use something
that is close for downstream so minimise the moving parts.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev