In Opensooq.com, it does not matter what is your base image, because we use ansible instead of Dockerfiles
it would bring any given base image into the desired state (wither it's a fresh bare base image, or latest milestone release of application) http://engineering.opensooq.com/manage-your-docker-image-layers-with-ansible/ On Thu, Sep 1, 2016 at 2:15 PM, Daniel J Walsh <[email protected]> wrote: > > > 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 >
_______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
