Container build manifests: what should they look like?
Agenda • Do we need declarative container builds? • If we do, what would that declaration look like? • Are there any tools/projects that meet or come close to these requirements?
Who am I and what am I selling? • Maintainer of Tern (github.com/vmware/tern): a container image inspection tool for OSS compliance • Made isolated development environments using Docker • 4 years in DevOps for embedded systems • Discuss good housekeeping
Declarative container builds: Who cares? Who needs Reproducible Builds? • Quick diff debugging • Software Provenance • Auditing: IP, Security, Standards and Processes Container builders are treated like package managers …except they aren’t very good at it.
Requirements for a manifest • • Human Readable Identifiers • Env vars • Project/Product name • filesystem • Version • Owner • • • Inputs • source code • binaries SCM tag • Outputs • tarball • changelog Conditions for Use and Distribution • License Compliance • Regulatory Compliance • Export Controls • Run time requirements • runtime env vars • runtime credentials • persistent Metadata • Inputs • Permissions • Output
Tools that meet or come close? Requirements Docker Habitat Jib Helm/Draft Buildkit Managed build env Yes (via Dockerfile) Yes Yes Yes Yes (provides LLB for config) Fixed dependency list No (apart from unionfs) Yes (plan.sh) Yes (Maven/Gradle) No No (‘dependencies’ are thought of as container images) Reproducible base image No Unsure No No No Software metadata (app and dependencies) Minimal Yes Yes Minimal Minimal Declarative inputs Minimal (only for base image) Yes Minimal (only for Some (mostly for java app) src and dst of containers) Unsure Machine readable outputs Maybe No (produces .hart files which are non-standard) Maybe (Docker container) Maybe (container image) No