What is `docker-compose push` supposed to do?
AndreKR opened this issue · comments
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?
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.
@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?
push request
:)
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.
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
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
- 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 - If you'll use
docker push actual_service_name
it will do nothing, no error - weird - If you'll use
docker push your.registry.com/your-service-name
, then it'll work as expected
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.
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.
@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.
@costa what docker/docker-compose version are you running?
@shin- reopen please
@shin- Personally, the problem with the current situation is that the documentation and UI are misleading, as you said yourself in that comment.
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.
@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?
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!
We're not removing the command tomorrow or anything, but Compose is definitely the wrong tool to do this.
@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
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.
-
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 overdocker
. I use it for development, and I was under impression it was intended for that (while serious prod. deployments are in K8s-land). -
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 |
- |
- You will have to deprecate having both
image:
andbuild:
with the same service too.
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?
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?
Guys I need help, can anyone guide me on how to push in the docker hub? I am using docker-compose.yml and building a full-stack react + flask web app
two images are built in docker-compose build but I can't seem to push them. docker-compose push does nothing.
Do I need to create a repo for each image with the name as the image name already before pushing it to Docker Hub,?