Why can we only push images and no docker-compose.yml to dockerhub

Question

Why can we only put images on Docker hub and no docker-compose files. I mean there are a lot of applications using multiple containers which might be reusable, maybe with slight configurations.

Or is there a way to do exactly that? For now I use Docker hub for my images and a git repository for the compose files. However I feel like it would be nicer to have only one place to store all this.

So the question is, can one store docker-compose files the way one stores images? If no, is there an explanation to why the people at Docker think it is a bad idea? Finally, is there a library of docker-compose files? I mean one finds images on docker hub in a high quality but the docker-compose files I found where on github and not very reliable.

Answer 1

In theory, one can store Docker-compose files & Dockerfiles in source control, so something like github.

The reason images are preferred, and why there is a Docker hub, is because the image is the unit that bundles together the app and the environment - which is what helps ensure that the app will run the same way wherever.

Dockerfiles are the instructions to build images, and they do so with limitations; from a given image, one can only make so many modifications (see answer here: Number of commands in Dockerfile).

There is not as strong a guarantee that someone else can build an image from a Dockerfile/docker-compose script that will behave the same - dependencies could be different, packages changing, etc. A docker image should be stand alone, testable, and will most likely run the same in successive uses (not guaranteed, but usually).

Answer 2

Short answer: I believe this would be seen as a security vulnerability.

A registry server stores images, and Docker Hub is just an implementation of a registry server. The docker-compose.yml file is a definition of how to run the image. How to run that image includes things like volume mounts, ports to publish, namespaces to disable, each of which are a potential to inject a security vulnerability. If instead of running an image with secure defaults, you were to run a remote compose file with unknown security settings, with a file hosted by docker, you would be opening yourself up to an easy remote attack vector that would likely be associated with docker rather than the private repo owner. So with Docker's high priority to security, I doubt you'll see this hosted by them.

The standard approach where you include a Dockerfile and docker-compose.yml in a github repo is the traditional single location for everything. The docker hub registry becomes a prebuilt cache for the image. That can be recreated using the compose file to define the build options, and the Dockerfile with the rest of the repo to define everything needed to create the image. In fact, the docker build command allows you to point directly to a public github repo instead of requiring you to first clone it locally.