Compose: What is `docker-compose push` supposed to do?

[AndreKR]

I am running docker-compose version 1.9.0, build 2585387 and in the inline help there is an option "push - Push service images".

The lead me to think I could have a service defined in my docker-compose.yml that has build: and image: set. Then I could run docker-compose build and it would build the image locally and tag it with the registry and name I specified. Then I could run docker-compose push or docker-compose push web (for a single service) to push that service's freshly built image to my registry.

In reality, yes, I can build the image with docker-compose build and it is correctly tagged. I could then manually push it with docker push to my registry if I know the image tag. However, docker-compose push does nothing. It doesn't give any error, it just exits successfully after about one second but nothing arrives at the registry. Same when I specify a service name: docker-compose push web

Is docker-compose push meant for something else?

[shin-]

Hi @AndreKR ,

Yes - docker-compose push is specifically a command designed to be used in the context of application bundles. I understand this can be a bit misleading.

[romanlevin]

@shin- Are there plans to rename the command, or clarify the output of docker-compose push --help, or mention something in the documentation?

If not, would you accept a push request for that?

[danabrey]

push request

:)

[Headcult]

Same question here. What does docker-compose push do? It does nothing as of now. Or do we need to use docker-compose bundle --push-images to push our images to Docker Hub? Can we some clarity over this as the Official Docker documentation is not providing enough information.

[mkunissery]

the documentation for docker-compose push is pretty naive. It does let you know any details on whether you can push multiple services using comma seperated names or however.. it has been a year since the last comment which asked for more documentation and nothing in place yet... appropriate support is the key

[JerryGreen]

Agree. It's a weird command, with poorly documented --help & doc on website, it has weird arguments, you may not be sure what it expects

Though, if you know what it is and how to use it, everything is ok

1. If you'll use docker push not_a_service_name, you'll get error "No such service" - at least it prints error, but the message is misleading
2. If you'll use docker push actual_service_name it will do nothing, no error - weird
3. If you'll use docker push your.registry.com/your-service-name, then it'll work as expected

[braytonstafford]

I'm using docker-compose build to build all of my docker images and then using docker-compose push to then push all of those images to their repositories. The documentation may not be long but it does state

Pushes images for services.

Thats what its doing for me right now.

[MartinMuzatko]

I was also a little confused by the documentation. But it does what I expected. docker-compose push even tags the images accordingly. so less work than the manual docker tag work.

[costa]

@braytonstafford I wonder what you have done to make it work for you. For me, and for most people on this page, it does nothing (while docker push works in the same env) — with just a docker-compose.yml and image: within.

[MartinMuzatko]

@costa what docker/docker-compose version are you running?

[costa]

I've upgraded to the latest (1.22) before posting this, of course. Also, --verbose didn't reveal anything of interest.

[costa]

@shin- reopen please

[shin-]

https://github.com/docker/compose/issues/4283#issuecomment-270745283

[romanlevin]

@shin- Personally, the problem with the current situation is that the documentation and UI are misleading, as you said yourself in that comment.

[shin-]

Yes, we're going to look into deprecating it (along with bundles). As it is it definitely encourages people to try and use Compose to build and push image sets which is not the intended use.

[FernandoMiguel]

@shin-
We are some of those people.
By using our Docker-compose.yml file we build and push
It's the supreme form of automation it may not have been designed as such but it works really well as is.

Can i ask what is the scenario you are looking to deprecate this?

[MartinMuzatko]

Wowowow! Easy there @shin-.
We also have a set of 8 Images we let jenkins build and then comfortably push to our private registry. This happened to really make our workflow nice and easy!

[shin-]

We're not removing the command tomorrow or anything, but Compose is definitely the wrong tool to do this.

[FernandoMiguel]

@shin-
On your experience, what would be the best workflow and tooling to build and push a compose stack?
I would hate to invest on something the development team is no longer supporting

[MartinMuzatko]

I see a few problems.

docker stack - if I understand correctly - pushes a single image to the registry.

A Dockerfile can be built into an image, and containers can be created from that image. Similarly, a docker-compose.yml can be built into a distributed application bundle, and stacks can be created from that bundle. In that sense, the bundle is a multi-services distributable image format.

In that case, pushing stacks via docker is not what I want. I want to use docker-compose push to push individual images, without their service or bundle relation. It is just a tool for making it easier to push instead of

docker build Dockerfile-1 -t label1
docker build Dockerfile-2 -t label2
docker build Dockerfile-3 -t label3

But I guess its for the better to upgrade to docker stack, if this still supports the same workflow.
I have two differnt compose files, one for the containers I build and push, and one for running the main container which loads the other apps on demand.

[costa]

1. I see docker-compose as a thin (as in: I can always understand what's going on under the hood, and it's not much) wrapper convenience ("porcelain") utility over docker. I use it for development, and I was under impression it was intended for that (while serious prod. deployments are in K8s-land).

2. Consider:

docker | docker-compose
------- | -----------------
attach Attach local standard input, output, and error streams to a running container | -
build Build an image from a Dockerfile | build Build or rebuild services
- | bundle Generate a Docker bundle from the Compose file
commit Create a new image from a container's changes | -
- | config Validate and view the Compose file
cp Copy files/folders between a container and the local filesystem | -
create Create a new container | create Create services
deploy Deploy a new stack or update an existing stack | -
- | down Stop and remove containers, networks, images, and volumes
diff Inspect changes to files or directories on a container's filesystem | -
events Get real time events from the server | events Receive real time events from containers
exec Run a command in a running container | exec Execute a command in a running container
export Export a container's filesystem as a tar archive | -
history Show the history of an image | -
images List images | images List images
import Import the contents from a tarball to create a filesystem image |
inspect Return low-level information on Docker objects | -
kill Kill one or more running containers | kill Kill containers
load Load an image from a tar archive or STDIN | -
logs Fetch the logs of a container | logs View output from containers
pause Pause all processes within one or more containers | pause Pause services
port List port mappings or a specific mapping for the container | port Print the public port for a port binding
ps List containers | ps List containers
pull Pull an image or a repository from a registry | pull Pull service images
push Push an image or a repository to a registry | push Push service images
rename Rename a container | -
restart Restart one or more containers | restart Restart services
rm Remove one or more containers | rm Remove stopped containers
rmi Remove one or more images | -
run Run a command in a new container | run Run a one-off command
save Save one or more images to a tar archive (streamed to STDOUT by default) | -
- | scale Set number of containers for a service
start Start one or more stopped containers | start Start services
stats Display a live stream of container(s) resource usage statistics |
stop Stop one or more running containers | stop Stop services
tag Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE | -
top Display the running processes of a container | top Display the running processes
unpause Unpause all processes within one or more containers | unpause Unpause services
- | up Create and start containers
update Update configuration of one or more containers | -
wait Block until one or more containers stop, then print their exit codes | -

1. You will have to deprecate having both image: and build: with the same service too.

[escalonn]

We're not removing the command tomorrow or anything, but Compose is definitely the wrong tool to do this.

@shin- The documentation (for one-foot-in-the-grave Docker Swarm, at least) explicitly says to do exactly that.
https://docs.docker.com/engine/swarm/stack-deploy/#push-the-generated-image-to-the-registry

If those docs are wrong, that still puts the onus on this team to point people to the right tool. So if Compose isn't the right tool anymore to push multiple images, then what is?

If Compose isn't the right tool anymore to build and push multiple images, then what is Compose for at all?

[MartinMuzatko]

Kubernetes is not possible for us, because we do deploys to industrial IoT gateways that are not always online (GDPR, security, etc), so they control updates themselves - you guess it - by using docker-compose.
docker-compose has been our go-to tool for building, pushing, pulling and running (up) our services.

And not much is missing to properly deploy with compose. Like #2945

The other more problematic thing that is tedious, is the setup for manifests for different architectures. Where everybody is brewing their own thing. For that, docker-compose was not as suitable yet. There only exist one or two inofficial tools used by docker hub to build multi-manifest images. (Earlier stackbrew, now deprecated in favor of bashbrew) IMHO compose could make this a lot easier. But docker is also sleeping a lot here, still marking it as "experimental" API, when a good 80% (citation needed) of official docker hub images already are served as arm, x64_86 and more.

To follow up on @escalonn question. What _is_ supposed to be the tooling for that job? If not Compose?

[Akashmathwani]

You need to involve images tag in your docker-compose.yml as mentioned in

AND Then do docker-compose push and check your repo :)