compose: Proposal: Don't build images
An even more aggressive step from #693, compose could entirely remove the ability to build images.
Rational: If compose is a tool for composing services, the process of building images for those services is distinct from the concerns of running services.
The docker images already provides a great interface for separating these concerns. The existing compose support for building an image is pretty primitive, and could be easily replaced.
There are many different build scenarios, each of which could be handled by a separate tool:
build from urls (#1209, #1369)- the naming of images (#1363, #2092)
- using builder containers (#1257)
- pushing images to a registry (#1126)
- tagging images (#974, #213)
- don’t build the same path twice (#963)
pulling base images (#726)- build ordering (#295, #610, #583, #663, #1548)
- building base images (https://github.com/docker/compose/issues/1661#issuecomment-146724163)
--build-argcommand line flag (https://github.com/docker/compose/issues/2111#issuecomment-174247444)
Some of these problems are already solved by existing build tools:
- https://github.com/6si/shipwright - building many containers from a git repo, where images extend each other
- https://github.com/openshift/source-to-image - creating minimal images using a builder container (There are probably other tools that I’m not aware of at this time.)
Backwards Compatibility
In order to preserve some form of backwards compatibility we could:
- in one release, warn if a
buildtag exists, and continue to build images - in the next release
- allow both build and image keys for a service
- ignore
buildanddockerfilekeys - provide a new command to build images in the way that compose does now (based on the same config)
- finally in some future release remove the
buildanddockerfilefields, and require a separate config for building images. Initially that config might be in a similar format, but likely it would evolve to support many of the scenarios described above
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 22 (2 by maintainers)
I think you will see a hard fork of this project if this happens as it completely destroys the use of it in development.
From its origin, fig was a tool for development environnement, and still today it’s the only (and the best !) CLI tool for that purpose.
Because I uses docker-compose intensively for development, I don’t agree with @dnephin that compose is a only tool for composing services. Kubernetes is for composing services in QA/production environnement and managing them. But docker-compose is for launching lightweight stacks for dev/QA or even non-critical production quickly.
In my dreams, only
git clone+docker-compose up [-d]should be required to start coding and live-testing a project.Building an image is one of the basic steps to learn Docker Building an image is the first step of developing with Docker. Building an image is one essential part of the
fig up’s magic !👎
I essentially agree with @josephpage on this: If a tool like
docker-composeis not going to be able to build directly anymore, then another tool must fill this gap – I need to be able to deliver a development environment with my code and have a single command for developers to get going on it. I have been able to do that with fig and compose, but am concerned about losing that ability.Again I would highly suggest just removing the implicit build triggered by
docker-compose upinstead which is the main source of confusion. (also the issue you linked doesn’t seem to be specific to docker-compose’s build.)Docker compose is right now a nice tool to manage all around my docker image groups which pretty much covers everything needed. While the build support is primitive, it still saves time and makes it easier to manage the whole thing including the necessary build step in one simple tool.
One important point why docker-compose should cover everything and not just the running non-build functionality is that the docker-compose.yml contains information how the images will be named as well. If you remove basic functionality from docker compose to limit its scope, you will force people to parse docker-compose.yml manually with other tools to get that information, or force people to have yet another configuration file lying around which holds it instead. That seems like a nonsensical idea to me.