hyperkit VS for-mac

The author uses a Mac and uses Docker Desktop or colima x Docker CLI to realize a Docker development environment. Dcoker Desktop uses an internal HyperKit (macOS hypervisor) to launch a Linux VM and run dockerd in it. Docker Desktop is based on Lima, and it generates Lima configuration files, and it is used to run Linux.

Sorry, I was misinformed. It seems MacOS still does use a tool called hyperkit to run a (presumably linux) VM as a backend for docker. I thought it was using something similar to jails.

You might try using HyperKit as the hypervisor with Kubernetes. It uses Apple's own hypervisor. Minikube, or rather docker, supports it. I would go with minicube as you can start and stop it as needed with ease.

I've been reading many forum posts: moby/hyperkit#149 docker/for-mac#900

What’s the magic behind docker working on macOS?. The answer is virtualization accomplished by the moby/hyperkit hypervisor (AFAIK), a toolkit for embedding hypervisor capabilities in your application, which means that dockerd works in a VM virtualized by the hyperkit. Why I’m telling you this is once you decide to work with containerd on your macOS environment to discover capabilities and more adapt to it because we assume you use containerd in your Kubernetes environment as a default container runtime, you had to have the same virtualization technology under the hood to let containerd working on macOS. Also, you need to have some client tooling to interact with containerd by keeping simplicity and usability in mind.

Docker on Mac is based on Hyperkit which is a lightweight VM. https://github.com/moby/hyperkit Crostini is running in a full KVM instance. You challenged me about the Termina shell. Type it in and see if I'm right. No need to debate this anymore when you can verify for yourself.

Docker Desktop doesn't use virtualbox behind the scenes. It uses hyperkit.

I use containers on Mac and Windows for development (and we deploy on linux). Docker for Mac is _unusably_ slow in my experience. The VM that it runs is a giant resource hog and a battery hog, and doesn't support ipv6 [0] Docker Desktop itself is (another) resource hog, wildly buggy, and painfully slow. It's the epitome of "shitty electron app".

On windows, docker desktop has all of the same issues as it does on mac. Docker's concept of volumes and file permissions on windows are nonsense. Windows updates and Docker Desktop regularly decide to disagree, [1] It's networking support interferes with other applications (like OpenVPN and the Xbox Game Center) [2].

[0] https://github.com/docker/for-mac/issues/1432

[1] https://github.com/docker/for-win/issues/599

[2] https://github.com/docker/for-win/issues/1976

version: '3' services: graph-node: image: graphprotocol/graph-node ports: - '8000:8000' - '8001:8001' - '8020:8020' - '8030:8030' - '8040:8040' depends_on: - ipfs - postgres extra_hosts: - host.docker.internal:host-gateway environment: postgres_host: postgres postgres_user: graph-node postgres_pass: let-me-in postgres_db: graph-node ipfs: 'ipfs:5001' matic: 'matic:http://localhost:8545/' GRAPH_LOG: info ipfs: image: ipfs/go-ipfs:v0.10.0 ports: - '5001:5001' volumes: - ./data/ipfs:/data/ipfs postgres: image: postgres ports: - '5432:5432' command: [ "postgres", "-cshared_preload_libraries=pg_stat_statements" ] environment: POSTGRES_USER: graph-node POSTGRES_PASSWORD: let-me-in POSTGRES_DB: graph-node # FIXME: remove this env. var. which we shouldn't need. Introduced by # , maybe as a # workaround for https://github.com/docker/for-mac/issues/6270? PGDATA: "/var/lib/postgresql/data" POSTGRES_INITDB_ARGS: "-E UTF8 --locale=C" volumes: - ./data/postgres:/var/lib/postgresql/data

This bug has been around years and still not fixed as far as I know - see https://github.com/docker/for-mac/issues/3926

You're not wrong, and not the first to raise this https://github.com/docker/for-mac/issues/6061

https://github.com/docker/for-mac/issues/6867 This github issue might help. What worked for me was deleting the ~/.docker/buildx folder

There has been an outstanding bug [Docker Github] for years with the Docker team who do not seem to be able (or want to) address this - they have closed more than one issue but its still there.. The latest bug report is this one [Docker Github] but I honestly would not bother following it - no idea why they are not fixing this.

Have you checked if any of your other Docker containers become unresponsive at the same time? If so, it could be Docker. I had this issue on Docker for months until they finally came out with an update that works for me (Docker Desktop 4.19.0 for Mac).

It might have something to do with Docker? I was having issues a few months ago with all my containers becoming unreachable or very slow many times per day. I finally upgraded to Docker Desktop 4.19.0 (I’m on a Mac) and everything resolved. There were a few GitHub issues about it, too. You could try running a speedtest within different Docker containers and seeing if there’s a discrepancy. You could also check your RAM and CPU usage for different containers using something like Glances; it could lead to a clue.