Yup, more of a customized distribution than one from completely from scratch, thinking if I can understand how debian:latest is created, will (better) understand the decisions and compromises made for how that image or build as defined.
Thanks for the link, i think that is the starting point for what I want to do. I still need to spend some real, serious time with docker, before I get down to the actual attempt to create a OS template, or image from scratch.
As for the vulnerabilities, that is my past career, now retired, shadowing my proposed effort. I was an Enterprise IT Virtualization Architect, and often had to research and resolve CVE issues, incorporating the fixes and updates for CVEs into my designs. So, I tend to want to create things completely from scratch when I can, because I need to understand the assumptions required. When you use a canned docker image/creation file, you inherit the mindset and thinking of the author, is not necessarily an issue, but does mean you are blindly accepting the goals and objectives of the author.
Just to illustrate my point above…
An example, is netboot/dhcpd, I reference this only because a few minutes ago I was looking at it. It is based on Ubuntu, assumes DHCP server will be standalone. So it works, but I need DHCP server based on Debian, and I need a primary and secondary (fail over) implementation.
So, a few design questions result, do I create a single DHCP server docker image, and just run two instances, with a shared mount point for the shared configuration file that has the host reservations? I let one docker instance effective sleep until the primary fails? Or do I create a true docker DHCP server primary and secondary using OMAPI keys and true DHCP failover, and a shared mount for the common configuration file? Or do I create two DHCP docker images, with no shared storage, and use incron to do triggered cascade copy of the configuration file only when changed on the primary, like is common with DHCP servers run on hardware or VMs?
So even a simple design goal, has many design implementation questions. When someone pulls my DHCP server docker image (if I ever publish it) will only see what I finally implemented, and never be aware of the trade offs I made to arrive at the final image.