Design Docker images with a heirarchy in mind.
Over the past few years, I’ve had the need to create Docker images for various applications/microservices. In my case, the most predominant use cases were Java and Python. Of course, there are a myriad of Java and Python images available on Docker Hub, and often these images can be used as a good basis for applications. However, as time goes on, I found myself having to manage multiple applications requiring different versions of these platforms.
It’s easy enough to reuse and customize a base image, but it tends to lead to repetitive work in configuration. Over time, like many open source projects, Docker Hub images evolve. That is to be expected. However, challenges arise when that change breaks the way dependent images are assembled or required versions aren’t available. In addition, I have also worked in environments where regulatory considerations were a priority and pulling images from Docker Hub tended to generate questions regarding the source and assurances of meeting specified guidelines. Anyone whose been involved in compliance and security audits understands that the use of external resources always requires some type of additional validation demonstrating the authenticity of the source. It can be done, but, with audits, the fewer questions raised are and the more straightforward the process.
