8:29 p.m.
Hello,
I was looking into google/cadvisor docker image that is only 47 megs
large and wondering how we can improve. To some extend it is so small
because of the Go lang, but not only.
Here are the results:
base image with JRE 8 and Alpine linux: 76.8 MB
wildfly 10.1.0.Final image 215 MB
hawkular-services 320 MB
Just for the record, here is status quo:
base CentOS image w/ JDK 8: 149 MB
wf image: 580 MB
hawkular-services image 672 MB
All the mini-images are based on Alpine (that itself is based on BusyBox),
so the price for it is less convenience when debugging the images.
I also removed
9.2M /opt/jboss/wildfly/docs
and wanted to remove
9.0M /opt/jboss/wildfly/modules/system/layers/base/org/hibernate
5.1M /opt/jboss/wildfly/modules/system/layers/base/org/apache/lucene
5.6M /opt/jboss/wildfly/modules/system/layers/base/org/apache/cxf
but from some reason the h-services fails to start because it didn't found
some class from that hibernate module, so I rather put it back.
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
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.
Oh and I haven't published it on dockerhub yet, but the repo is here [2]
jk
[1]: https://github.com/goldmann/docker-squash
[2]: https://github.com/Jiri-Kremser/hawkular-services-mini-dockerfiles
9:19 p.m.
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.
9:49 p.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
10:38 p.m.
----- Original Message -----
From: "Heiko W.Rupp" <hrupp(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Wednesday, 1 February, 2017 7:19:34 AM
Subject: Re: [Hawkular-dev] Docker image size does matter
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.
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.
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.
> 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
10:47 p.m.
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.
On Thu, Feb 2, 2017 at 1:38 PM, Matt Wringe <mwringe(a)redhat.com> wrote:
----- Original Message -----
> From: "Heiko W.Rupp" <hrupp(a)redhat.com>
> To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org>
> Sent: Wednesday, 1 February, 2017 7:19:34 AM
> Subject: Re: [Hawkular-dev] Docker image size does matter
>
> 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.
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.
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.
> > 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
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2657
days inactive
2658
days old
4 comments
4 participants
participants (4)
-
Gareth Healy -
Heiko W.Rupp -
Jiri Kremser -
Matt Wringe