Internals
Introduction
In this exercise we will take a look at what's inside the container image. Java is particularly interesting because it uses glibc
, even though most people don't realize it. To prove it, we will use the ldd
command which shows you all of the libraries that a binary is linked against.
Image Internals
When a binary is dynamically linked (libraries loaded when the binary starts), these libraries have to be installed on the system, or the binary will not run. In this example, in particular, you can see that getting a JVM to run with the exact same behavior requires compiling and linking in the same way. Stated another way, all Java images are not created equal:
podman run -it registry.access.redhat.com/jboss-eap-7/eap70-openshift ldd -v -r /usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
podman run -it registry.access.redhat.com/ubi7/ubi ldd /usr/bin/python
curl
demonstrates how many libraries are used from the operating system. First, start the RHEL Tools container. This is a special image which Red Hat releases with all of the tools necessary for troubleshooting in a containerized environment. It's rather large, but quite convenient:
podman run -it registry.access.redhat.com/rhel7/rhel-tools bash
ldd /usr/bin/curl
rpm -qf /lib64/libssl.so.10
rpm -qf /lib64/libssl3.so
Exit the rhel-tools container:
exit
What does this all mean? Well, it means you need to be ready to rebuild all of your container images, any time there is a security vulnerability in one of the libraries inside it.
Wrapping Up
Congratulations! In this lesson you learned:
- Understand what the Open Containers Initiative and why this standard is important for your container images
- Internalize the difference between base images and multi-layered images
- Understand the full URL to an image/repository
- Command a complete understanding of what is inside of a container image