Skip to content

volumes: support for api-socket volume type #12746

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

stevvooe
Copy link

What I did

The api-socket volume type allows an easy path to run containers that need access to the Docker API socket with a simple configuration on the service definition:

service:
  foo:
    ...
    volumes:
      - type: api-socket

The bind mount and credentials are automatically injected using existing service infrastructure. Some work is still needed to make this a bit more robust.

Related issue

docker/cli#5858
compose-spec/compose-go#770
compose-spec/compose-spec#587

(not mandatory) A picture of a cute animal, if possible in relation to what you did

The `api-socket` volume type allows an easy path to run containers that
need access to the Docker API socket with a simple configuration on the
service definition:

    service:
      foo:
        ...
        volumes:
          - type: api-socket

The bind mount and credentials are automatically injected using existing
service infrastructure. Some work is still needed to make this a bit
more robust.

Signed-off-by: Stephen Day <stephen.day@docker.com>
@stevvooe stevvooe force-pushed the sjd/api-socket-support branch from 0108788 to 12e92fe Compare April 15, 2025 02:01
@ndeloof
Copy link
Contributor

ndeloof commented Apr 22, 2025

For better alignment with docker CLI UX, we should b introduce a use_api_socket attribute in the compose spec.
I also wonder this is limited to unix socket. As implementation relies on DockerEndpoint().Host, running on Docker Desktop Windows the npipe:// URL will prevent use of this feature, while the actual engine in VM can expose a docker.sock to containers. Same applies to a remote docker engine accessed over ssh or http. I agree with docker/cli#5858 (comment) this should be a feature exposed by docker engine, not a hack by client code. At least this should be considered a temporary solution until engine has support for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants