Does docker-compose support docker plugins?

General
1

I’ve create docker plugin: docker myplugin run ...

Is there any way to tell docker-compose to use that myplugin plugin when starting containers?

Thanks.

2

No. But why do you need that? Compose has a run command too, but if you create your own run command, why do you need compose to use that? Even if you could do that, compose would not use it when you run docker compose up. If you don’t need that, you can just use your command.

3

The plugin adds our corporate proxy’s man-in-the-middle TLS certs to /etc/ssl/certs by inserting a --mount param into the docker run ... parameters. This is only needed when running docker locally. Our CICD system is not behind this proxy.

I currently need 2 different docker-compose.yml files:

  1. local docker-compose.yml with the proxy certs volume mounted on the containers
  2. cicd docker-compose.yml with no proxy cert volumes

I’d like to be able to do something like docker-compose myplugin up when running locally rather than having multiple copies of the docker-compose.yml file.

4

I see. Have you considered using second compose file which is not a copy but it contains only the additional mount?

docker-compose.yml (or just compose.yml)

services:
   app:
     image: ...
     # any configuration you need

certs.yml

services:
  app:
    volumes:
      - ./certs:/etc/ssl/certs

In this case you could change the main compose file without changing certs.yml.

Your plugin could just add the two compose files (not avalid plugin, just an example):

docker compose -f docker-compose.yml -f certs.yml "$@"

So the idea is to implement all the subcommands of compose in your plugin and add the compose files as an argument. The downside is that this way you can’t add new arguments between “compose” and for example “run” or “up”. It could be solved with a more advanced script.

I always just use compose with a base compose file and other files with additional parameters (not copies) and sometimes I use a script (not plugin) in the project, version controlled

1 Like
5

On the first look, it might be a good case for Using profiles with Compose | Docker Documentation
On a second look, @rimelek’s solution appears cleaner, as it may require longer commands (which could be wrapped in bash scripts or make files), but does not result in boilerplate configurations in the compose file.

6

That was my first idea too, then I relaized, you would still need to duplicate services with different profiles.

7

This seems like a good approach!