Customer Impact: Imagine production environment with 1000 microservices built by s2i. 820MB * 1000 = 820GB of disk space for registry will be needeed to keep one version of all microservices.
The issue is not with builder image itself but the result of s2i build. This builder "image with binary artifacts" is stored to registry and later with runtime image to produce final image with compiled artefact.
Problem is that new layer in builder "image with binary artifacts" has 800+MB. Note that this layer will not be shared with other images and each new build will consume 800+MB in registry which can leads to out of disk space issues really quickly (especially in Openshift internal registry)
Looking at the image using dive command there are following changes:
As only content of s2i-output is copied into runtime image. All other changes should be cleaned up after s2i build so they do not take space.
For example there is /tmp directory with maven repo of built application. Directories /opt/eap and /opt/jboss are no longer necessary as well. Removing those 3 dirs will free ~500MB.
Note:
There is used naming convention from following diagram:
- is caused by
-
CLOUD-3505 Provisioned server is not deleted once installed
- Verified
- is related to
-
CLOUD-3516 Avoid copying JBOSS_HOME content during s2i
- Verified
-
JBEAP-18998 (7.3.z) Chained s2i builder image with binary artifact is taking too much space
- Closed