Some related reading material on container standards (both de facto and burgeoning) that illustrates their separation of concerns and overlap.

https://coreos.com/blog/making-sense-of-standards.html

Also, it's probably worth pointing out at this point that 'manifest' is not really the right word for what we're talking about here; a manifest as it's defined in all of the existing specifications is actually a bundled filesystem image (agnostic to how it was built) and runtime metadata about how to set up the container and how to invoke some application binary. What we've been discussing is a slightly higher level abstraction that covers the metadata but also system level package dependencies. The manifest + image will be a product of our build step.

Kubernetes supports parametrizing various runtime variables per container instance: https://kubernetes.io/docs/resources-reference/v1.5/#container-v1

• entrypoint and args
• probes (readyness & liveness)
• image & pull policy
• volume mounts

Many of these depend on the deployment environment, and can't necessarily be statically determined at build time. It would however be great if the standardized build process discussed here could produce containers that provide a uniform interface to work against, by enforcing uniform conventions for

• entrypoints (run, test)
• argument handling and config management (env var conventions, config templating)
• logging
• in-container paths for source and data (important for dev environments, bind-mounted data volumes)

Over the past few days I've been experimenting with a general build configuration format and wrote a build tool in Go—because, well, I unabashedly wanted to learn something new while experimenting; please don't judge my awful Go code :)—codenamed Blubber that spits out a Dockerfile.

It doesn't cover all of the currently held requirements, but it does showcase what I think might be a couple of useful constructs related to handling different environments (image variants) and producing optimized production images. I would love feedback if anyone has a moment to take a look. Again, it's just one possible starting point and a thought experiment more than anything.

In T158812#3107628, @GWicke wrote:

Many of these depend on the deployment environment, and can't necessarily be statically determined at build time. It would however be great if the standardized build process discussed here could produce containers that provide a uniform interface to work against, by enforcing uniform conventions for

• argument handling and config management (env var conventions, config templating)

Support for argument and env var conventions should be simple enough but I'm not sure whether config templates can be interpolated at build time due to them containing secrets. So this bears much more discussion and developed use cases.

• logging

Are you talking about a standard set of exposed ports or something more elaborate?