Dockerfile v3
This is written as a response to @erikh/@tiborvass dockerfile2 ideas.
Dockerfile defines how an image is built:
First line defines if we're using v1 or v3. Shebang header means v3.
Shebang shows what tool is used to make the build. Bash, Node.js etc.
#!/usr/bin/env bash
....
In the next non empty line there can be a definition for the start point of the default image used during build process. Marked clearly in a way that it works inside all kinds of comments. With this definition you can say where you want your context to be placed(and cwd).
#!/usr/bin/env bash
# @dockerbase: ubuntu:trusty/src/files
....
This file has access to the docker binary. For security some of the features are forbidden. This is done in the API level. The docker binary connects through a proxy that doesn't allow privileged usage(run privileged, add-caps, volumes from host etc).
#!/usr/bin/env bash
# @dockerbase: ubuntu:trusty/src/files
container=$(docker run -v /src/files/app:/src debian:jessie /src/run.build)
$(docker cp /src/files/foo.txt $(container):/bar/) # <- this does not currently work but there is aPR
result=$(docker commit $(container))
docker tag $(result) $BUILD_TAG
The quirks of this method can be resolved by a library that gives convenient functions for common operations.
In the dev setup one could even just run the Dockerfile script in a local machine.
Node.js sample:
#!/usr/bin/env node
// @dockerbase: nodejs:latest
var docker = require('docker-builder')
var container = docker.New()
// Some of these calls should probably be async, but I'm keeping thing simple for people not familiar with node-isms.
container.copy('/context/foo', '/bar')
container.commit() // also sets itself to next
container.env('FOO', 'bar')
container.workdir('/foo/bar')
container.commit()
docker.tag(container)
Nested builds are supported because whole docker build is exposed.
Best part of this is that this all could be implemented as a 3rd party tool. Only problem is that trusted build services would not be supported in this case.
Nothing in here is really new. I'm sure there are people already using something like this (or will be after docker commit --change). This just provides a common entrypoint known to docker client and out of the box security.
Further reading:
@erikh: https://gist.github.com/erikh/0e791230c72a2c71baa5
@dqminh: https://gist.github.com/dqminh/536d03bc1d2cddac31f2
Other use case is for people who just need a simple macro functionality or some custom command(like current nested build for example). They can just base the Dockerfile at