On 08/31/2016 08:10 PM, Josh Berkus wrote: > CT team: > > I was talking to some enterprise container builders at LinuxCon, and one > thing which came up as a tooling request was some way to > encourage/enforce making developers re-use shared container layers, and > track if they had. > > The basic idea is that it's a "best practice" to make reusable layered > containers with foundational technology and re-use them -- among other > things, to simplify security updates. So for example, this would be > good inherited container heirarchy for a GeoDjango container: > > > Fedora24 > | > Python27 > | > Django > | > GeoDjango > | > MyGeoDjangoApplication > > And this would be a poor one: > > Fedora24 > | > MyGeoDjangoApplication > > > But AFAIK, there aren't any tools to encourage or check for the first > over the second. > Yes I agree this would be good, but not sure how you would do this automatically. The problem is every app could want to use a different set of middle layers. Currently developers pick which layer they want to base on, but they might not even know that the GeoDjango layer exists. Tools like OpenShift could build some business sense into this. Or at least give developers a list of images to select from and a description of the content in each image.
atomic diff GeoDjango MyGeoDjangoApplication Theoretically would give you only the RPMs/packages that are different between the two builds so if you did the second, you might be able to determine you could have done the first. _______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
