Docker-compose with --context

I can’t really find any information on how docker-compose work with --context
All I’ve found is this blog post
If I have a docker-compose.yml on my server I can run docker-compose up -d etc. and it works just as it should.

If I take this exact docker-compose.yml file and put it on my local computer then add a docker context to my server like this:

docker context create remote --docker "host=ssh://username@servername"

Note: The username here is the same I use when SSH to the server.

Then try to run for example

docker --context remote ps

I will get the information from my remote server. I can also create containers and everything.

However, if I have run docker-compose up -d on the server already and try to take it down from my computer like this:

docker-compose --context remote down

It doesn’t work. I don’t get any information at all.
No matter what I do it wont work. However if I try to up it again from my local computer I will get an error saying the container name is in use but if I run docker-compose --context remote ps it won’t show anything.

If I go back to the server and take the container down and then from my computer again try to run up it will work…

So it seems like docker-compose --context is somehow getting it’s own “session” per user even though it’s the same user that started it locally on the server as the context logs in to. This is also true if I do the exact same on a different computer with the same username and everything.

Does anyone know if this is by desing, a bug or can be fixed with a Docker config or an entry in the docker-compose.yml?

What I wanted to accomplish was to let a group of users from their local computers up/down a set of containers with docker-compose with context being logged in with the same username…

We have a “stage” service that a groups of 3 people need to be able to up/down/restart etc. to do some testing and --context would make is so much easier for them to use than use SSH to the server and run the commands from there.

So I did a little more digging and found some stuff that got me closer to understanding why it wasn’t working.
The server is running Linux (Debian 10) and the clients are running Windows 10 and Docker Desktop so at first I thought there was something about this that made in incompatible somehow. That was not the case.

This part I found when running docker inspect <containername>

"Labels": {
  "com.docker.compose.config-hash": "30abce7983c6fdedd487415ebf1acc52d6e68ecbf727b85b5fab8d88bd89f24d",
  "com.docker.compose.container-number": "1",
  "com.docker.compose.oneoff": "False",
  "com.docker.compose.project": "nginx-docker",
  "com.docker.compose.service": "nginx",
  "com.docker.compose.version": "1.21.0",
  "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
},

So this got me thinking about the project name (nginx-docker in this case). By default the project name is the name of the folder that docker-compose.yml is in. The folder name on the clients are not the same so therefore the project names where different.

So on the clients I tried to run it like this instead:

docker-compose --context remote -p nginx-docker down

And it worked.
In this case nginx-docker is the project name. It can be whatever you want.
So it was the project name that made it not work in the first place.

I hope this helps someone in the future.

Hello guys. I updated to the docker/docker-compose version (Docker version 20.10.8, build 3967b7d, Docker Compose version v2.0.0) and now I get error messages when I try to use the “-c” or “–context” flags:

unknown flag: --context

A couple of weeks ago, I got the messge “unknown flag: -c” but I could go on with --context, now this option is gone also. Does anyone have information about this?

It was about another issue which was solved. I answered your question here:

1 Like