search

jboss-dockerfiles / wildfly

Docker image for WildFly project
https://quay.io/repository/wildfly/wildfly
MIT License
280 stars 237 forks source link

Size of Docker Image is very large maybe use Wildfly based on a distroless Image #108

Closed xlf12 closed 1 year ago

xlf12 commented 4 years ago

The Size of the Docker Wildfly Image is very large and far from what is expected / recommended for a Docker image.

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
jboss/wildfly       latest              91a3300bd328        7 weeks ago         749MB
λ docker history jboss/wildfly
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
91a3300bd328        7 weeks ago         /bin/sh -c #(nop)  CMD ["/opt/jboss/wildfly/…   0B
<missing>           7 weeks ago         /bin/sh -c #(nop)  EXPOSE 8080                  0B
<missing>           7 weeks ago         /bin/sh -c #(nop)  USER jboss                   0B
<missing>           7 weeks ago         /bin/sh -c #(nop)  ENV LAUNCH_JBOSS_IN_BACKG…   0B
<missing>           7 weeks ago         /bin/sh -c cd $HOME     && curl -O https://d…   219MB
<missing>           7 weeks ago         /bin/sh -c #(nop)  USER root                    0B
<missing>           7 weeks ago         /bin/sh -c #(nop)  ENV JBOSS_HOME=/opt/jboss…   0B
<missing>           7 weeks ago         /bin/sh -c #(nop)  ENV WILDFLY_SHA1=eaef7a87…   0B
<missing>           7 weeks ago         /bin/sh -c #(nop)  ENV WILDFLY_VERSION=17.0.…   0B
<missing>           6 months ago        /bin/sh -c #(nop)  ENV JAVA_HOME=/usr/lib/jv…   0B
<missing>           6 months ago        /bin/sh -c #(nop)  USER jboss                   0B
<missing>           6 months ago        /bin/sh -c yum -y install java-11-openjdk-de…   228MB
<missing>           6 months ago        /bin/sh -c #(nop)  USER root                    0B
<missing>           6 months ago        /bin/sh -c #(nop)  MAINTAINER Marek Goldmann…   0B
<missing>           6 months ago        /bin/sh -c #(nop)  USER jboss                   0B
<missing>           6 months ago        /bin/sh -c #(nop) WORKDIR /opt/jboss            0B
<missing>           6 months ago        /bin/sh -c groupadd -r jboss -g 1000 && user…   296kB
<missing>           6 months ago        /bin/sh -c yum update -y && yum -y install x…   99.4MB
<missing>           6 months ago        /bin/sh -c #(nop)  MAINTAINER Marek Goldmann…   0B
<missing>           9 months ago        /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
<missing>           9 months ago        /bin/sh -c #(nop)  LABEL org.label-schema.sc…   0B
<missing>           9 months ago        /bin/sh -c #(nop) ADD file:6f877549795f4798a…   202MB

Modern Java programs should IMHO skip the Linux distro layer because they are in general not used by native java apps. For distroless images see distroless. This would reduce the image size by 300MB.

The 400 MB left over might also be worth an investigation. Why does a modern app server already need this without having placed an application on it?

guykatz commented 3 years ago

i am getting push backs from customer regarding image size limits... my customer wants a 150M image max while my runtime, which is wildfly, formal image, starts at 350M any idea what I can do still or are my hands tied? (i am not an expert in this) thanks

davinkevin commented 3 years ago

For information, we have successfully switched our keycloak, using wildfly, to a distroless/java-debian10:nonroot image.

We just have to define the entrypoint of our image to the java command executed in your context to launch wildfly (can be dumped from the standalone.sh by adding the set -x flag in the script before launching…).

guykatz commented 3 years ago

@davinkevin what is the impact on the image size? thanks

xlf12 commented 3 years ago

One problem is security, there are potentially many things in this image that are not needed and could have security vulnerabilities. Customers just scan images and decide what is in it, no matter what is used in the specific case. That forces updates or hard discussions and merci.

Well, when you are dealing with "many" µServices and many different versions of the same service, handling all these images is even more painful when they are large. We install offline on site and have to feed many image registries to archive, deploy and ship these images. On the customer side it is less painful because they only have to deal with limited versions, but the first security point more or less turns out to be a showstopper.

davinkevin commented 3 years ago

image

For the same binary inside the image.

Some extra layers may exist in the centos version due to the update of packages increasing the size of the image (because the centos image is not patched very often by redhat sadly…).

But at the end, our focus is, like @xlf12 described, we would like to reduce at most our list of images used in our micro services applications. We are mainly in a java world, so distroless do the job and thank to it, we have an official java (gcc) distribution with the minimum viable packages and maintained by Google. What else ?

danielochoaglobant commented 3 years ago

This is somehow more important now that red hat is dropping support for centos, any plans to move away from this distro?

debashish1976 commented 3 years ago

For information, we have successfully switched our keycloak, using wildfly, to a distroless/java-debian10:nonroot image.

We just have to define the entrypoint of our image to the java command executed in your context to launch wildfly (can be dumped from the standalone.sh by adding the set -x flag in the script before launching…).

I am struggling with a similar challenge. Do you have any how to write up available that I may use to build and run a distroless image?

davinkevin commented 3 years ago

I will try to see if we can publish it as an open source project.

In which part are you struggling with ?

debashish1976 commented 3 years ago

I will try to see if we can publish it as an open source project.

In which part are you struggling with ?

I am struggling with launching keycloak. Would you be able to share the dockerfile? It's fine if there are hardcoding and you may mask some values if you don't wish to reveal.

davinkevin commented 3 years ago

We are launching keycloak inside kubernetes, so there is nothing relative to this inside our Dockerfile.

To deal with the launch process without using the standalone.sh, I've started a standard Keycloak with a simple modification in the standalone.sh to reveal the final java command executed. You can do that by adding set -x inside the standalone.sh.

Then, I copied the java command and use it from my Deployement file in kubernetes, but you can do the same for any other orchestrator.

BTW, I will write an article about that very soon, so I will post the link here as soon as possible.

davinkevin commented 3 years ago

@debashish1976 https://dev.to/stack-labs/keycloak-on-distroless-12ng

I think it would be helpful for you 😇

jmesnil commented 1 year ago

I'm closing this as it has been superseded by https://github.com/jboss-dockerfiles/wildfly/pull/161