Code exists in a branch of rpm-ostree:
https://github.com/cgwalters/rpm-ostree/commits/libhif-next-compose-dockerimages
Dockerfile is an imperative format that allows doing anything, and as a consequence the tooling around it (docker itself, rel-eng tools) are unable to accurately optimize.
This tool is like rpm-ostree in creating a declarative and rigorous binding between Docker and just RPM packages.
This allows a number of optimizations, critical bug fixes, and user experience improvements for the subset of users who want to make Docker containers out of pure RPM packages. It allows release engineering for RPM-based distributions to be much simpler.
- Write in Python (probably) because hawkey/librepo have bindings
- Would like to transfer the ideas
- Pick up by one of: dnf/packaging, RCM, Dock?
- Extend to support config?: See coreos/rpm-ostree#96
{
"repos": ["fedora-rawhide"],
"images": {
"baseimage": {
"packages": ["yum"]
},
"freeipa": {
"packages": ["freeipa"],
"entrypoint": "/usr/libexec/freeipa-server",
"expose": "80"
}
"nodejs": {
"packages": ["nodejs"]
},
"django": {
"packages": ["django"]
}
}
}
- Derive from an image created this way using a regular
DockerfileFROMdirective. That's a nice part about Docker - images generated in different ways interoperate via simple layering. - Create a binary-only RPM (really, it's not hard!)
One thing that is quite easy for this tool to achieve is to regenerate an image if and only if its set of input RPMs change. It can do that without doing an expensive re-install + throw away, by doing a dependency resolution and comparing that versus the target state.
Because of that, rather than having "Docker builds" being something that humans log in and initiate by hand, this could become part of a background infrastructure that is ensuring the Docker images for apps are always continually up to date.
(And of course, once we enable upstream git -> RPM, things get more exciting...)
Have you ever had to choose between this
RUN yum update #nocache20150110.0
or using docker build --no-cache? Right.
This tool only downloads metadata for the specified
repositories once, and supports caching it on the host
where it can be reused by multiple generations of containers.
What we currently call the "base image" here could also simply fall out of this tool by specifying an image which contains yum.
Of course, it's also easily possible to generate images without yum inside them at all. That leads to much more minimal containers, and dovetails with the "automatic updates" model above - you treat images as immutable on the client.
For app authors that maintain multiple apps, it's not uncommon for them to have a "midlayer" tier of say their favorite logging library or whatever. With Docker they have to manually re-create the layering that's already implicit in the RPM dependency set.
This tool can simply compute a constantly optimal chain from the RPM dependencies alone, without repeating things.
Ideally, can replace:
- https://github.com/stackforge/kolla/blob/master/docker/fedora-rdo-base/Dockerfile
- https://github.com/openshift/ruby-20-centos/blob/master/Dockerfile
- https://github.com/openshift/nodejs-0-10-centos/blob/master/Dockerfile
- :sadface: https://github.com/openshift/wildfly-8-centos/blob/master/Dockerfile#L14
Mixing docker metadata in has disadvantages - might be better to omit that from the spec, then layer it on top as necessary.
It would be nice to be able to use systemd unit metadata to define the image metadata, rather than Dockerfile style input. Could also be layered on top.