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.
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
curldemonstrates 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
rpm -qf /lib64/libssl.so.10 rpm -qf /lib64/libssl3.so
Exit the rhel-tools container:
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.
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