Colima with containerd runtime not exposing docker.sock

harel-e commented 10 months ago

Description

I started colima with containerd runtime. I cannot connect to it with docker since it didn't expose a docker socket When I performed the same with docker runtime, it works fine.

Version

colima version 0.6.7 git commit: ba1be00e9aec47f2c1ffdacfb7e428e465f0b58a

Operating System

[ ] macOS Intel <= 13 (Ventura)
[ ] macOS Intel >= 14 (Sonoma)
[ ] Apple Silicon <= 13 (Ventura)
[X] Apple Silicon >= 14 (Sonoma)
[ ] Linux

Output of `colima status`

INFO[0000] colima [profile=test] is running using macOS Virtualization.Framework INFO[0000] arch: aarch64 INFO[0000] runtime: containerd INFO[0000] mountType: virtiofs

Reproduction Steps

colima start --vm-type vz --runtime containerd --cpu 2 test
colima status

Expected behaviour

I expect colima to expose the docker.sock in the host OS and have it visible in colima status command, just like with docker runtime

Additional context

Sample output when using docker runtime

colima start --vm-type vz --runtime docker --cpu 2

colima status

INFO[0000] colima is running using macOS Virtualization.Framework INFO[0000] arch: aarch64 INFO[0000] runtime: docker INFO[0000] mountType: virtiofs INFO[0000] socket: unix:///Users/testing/.colima/default/docker.sock

tvh commented 9 months ago

I am having the same issue. Until this is resolved, it is still possible to talk to docker via SSH:

docker context create colima-ssh --docker "host=ssh://colima"

si458 commented 9 months ago

~~same here but im using an old macbook with osx 11, docker wont install so i have to use containerd~~ edit: ignore me i can indeed run colima with docker and it works perfectly fine!

user@Users-MacBook-Pro ~ % colima version
colima version 0.6.8
git commit: 9b0809d0ed9ad3ff1e57c405f27324e6298ca04f

runtime: containerd
arch: x86_64
client: v1.7.3
server: 1.6.28
user@Users-MacBook-Pro ~ % colima status -e
INFO[0000] colima is running using QEMU                 
INFO[0000] arch: x86_64                                 
INFO[0000] runtime: containerd                          
INFO[0000] mountType: sshfs                             
INFO[0000] cpu: 2                                       
INFO[0000] mem: 2GiB                                    
INFO[0000] disk: 60GiB                                  
user@Users-MacBook-Pro ~

tharwan commented 5 months ago

Same issue here with 0.6.9

binary-signal commented 4 months ago

Same issue here with 0.6.9, I suspect the issue occurs when using containerd + vz vm on mac os m1

shucking commented 3 months ago

Same issue: m3 macos, colima 0.6.10

abiosoft commented 3 months ago

This is actually the expected behaviour for containerd runtime. Do you still want to keep using docker for containerd runtime?

tvh commented 3 months ago

This is actually the expected behaviour for containerd runtime. Do you still want to keep using docker for containerd runtime?

Yes. If I'm using the docker runtime and some kubernetes, docker is full of the kubernetes containers, making it a bit hard to work with. And vz is necessary for virtiofs.

elaijuh commented 2 months ago

Maybe I am missing something here, but why do you want to use docker with containerd runtime? nerdctl is there

Raboo commented 2 months ago

Maybe I am missing something here, but why do you want to use docker with containerd runtime? nerdctl is there

Not cool man! Not cool! Why does people feel the need to go into questions like "Why do you need this? Why don't you do it my way?". These type of questions are neither helpful or meaningful. Sure, offering an alternative is good, but everyone that installed colima knows about nerdctl. The README clearly refers to it. But the README also shows a video of using the docker cli with colima. So clearly there is a use case for it, using ssh instead of docker socket is a work-around, not a solution.

But to humor you. There are literally dozens if not more of popular tools that use the docker socket and expect it, build tools, ci tools and a bunch of other dev tools. There are even more tools that rely on the docker cli.

shucking commented 2 months ago

Maybe I am missing something here, but why do you want to use docker with containerd runtime? nerdctl is there

Not cool man! Not cool! Why does people feel the need to go into questions like "Why do you need this? Why don't you do it my way?". These type of questions are neither helpful or meaningful. Sure, offering an alternative is good, but everyone that installed colima knows about nerdctl. The README clearly refers to it. But the README also shows a video of using the docker cli with colima. So clearly there is a use case for it, using ssh instead of docker socket is a work-around, not a solution.

But to humor you. There are literally dozens if not more of popular tools that use the docker socket and expect it, build tools, ci tools and a bunch of other dev tools. There are even more tools that rely on the docker cli.

Maybe I am missing something here, but why do you want to use docker with containerd runtime? nerdctl is there

Not cool man! Not cool! Why does people feel the need to go into questions like "Why do you need this? Why don't you do it my way?". These type of questions are neither helpful or meaningful. Sure, offering an alternative is good, but everyone that installed colima knows about nerdctl. The README clearly refers to it. But the README also shows a video of using the docker cli with colima. So clearly there is a use case for it, using ssh instead of docker socket is a work-around, not a solution.

But to humor you. There are literally dozens if not more of popular tools that use the docker socket and expect it, build tools, ci tools and a bunch of other dev tools. There are even more tools that rely on the docker cli.

Where is this aggression coming from? In OSS and industry, it's important to understand the reason behind feature requests because time isn't cheap. The why is essential. I'm surprised so much offence was taken.

Raboo commented 2 months ago

The aggression comes from the fact that @abiosoft already asked:

Do you still want to keep using docker for containerd runtime?

After someone already answered yes to that, @elaijuh is is then questioning that answer and basically in nicer words stupidifying the person that answered yes and indirectly saying that he shouldn't use docker cli... At least that is how it felt to me with the comment "nerdctl is there". It is a snide comment and there is where the aggression started.

I've seen this behavior before, and it discourages people. So after seeing that I just wanted to shoot it down directly. But you are right in understanding the why, and ignoring the snide comment would have been the best course of action.

With that said, I won't continue this discussion any more in this issue to avoid hijacking it. If you feel the need to have a last word or discussing further in this topic, then I'm on Kubernetes slack. But really, I don't want to bother.

I apologize for falling into the troll trap.

binary-signal commented 1 month ago

Lots of software, for better or worse, expects a docker.sock file to work with, even though we are using containerd. One good example of this is JetBrains IDEs.

lloeki commented 2 days ago

One reason would be tooling that squarely relies on the docker command.

Docker itself can make use of containerd as an image store†, which brings the possibility to build multi-arch images (docker buildx build --platform linux/x86_64,linux/aarch64 ...), via this in /etc/docker/daemon.json:

    "features": {
      "containerd-snapshotter": true
    }

I'd argue that not only should a Docker context for colima be exposed by default, but that containerd should be the image store for Docker by default as well:

† The default is the docker image store and prevents one from building those locally, you either set up the containerd image store or switch to a buildx builder with the docker-container (which comes with its own limitations like complete inability to use local images as FROM + have to push the result to a registry):

$ docker buildx build --platform linux/x86_64,linux/aarch64 -f Dockerfile .
ERROR: Multi-platform build is not supported for the docker driver.
Switch to a different driver, or turn on the containerd image store, and try again.

EDIT: Out of dumb luck I tried this with both and neither made containerd the image store for Docker.

$ colima start --vm-type=vz --vz-rosetta --edit
$ colima start --vm-type=vz --vz-rosetta --runtime containerd --edit

# Colima default behaviour: buildkit enabled
# Default: {}
docker:
  features:
    containerd-snapshotter: true

When it works one should see this in docker info:

   Storage Driver: overlayfs
    driver-type: io.containerd.snapshotter.v1

abiosoft / colima