for-mac VS cargo-chef

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.

CI time. Do you want to micromanage your own docker images for all your CI? Great! If not, yes you do. In fact, you want to manage a docker image to build a docker image to use for CI. Use cargo-chef to prepare a build image with your dependencies pre-built if you want to do fine-grained build/test pipelines. Oh also, there's no jUnit test report generation, that was killed off today. (YES, SORRY, I'm still salty.)

Have you looked at cargo-chef? It supposedly speeds up compilation times if you're using Docker.

A tool already exists for this called Cargo-chef, and it works extremely well.

At work I've use Dockerfile and cargo-chef to improve build times. You can also look into buildkit cache mounts, but this approach is rarely super effective on hosted CI because they start from scratch on most runs. In the context of Rust specifically you may also see the target directory reflect unbounded data growth if it's reused over and over across revisions. because cargo by default won't expire older intermediate artifacts. Cargo-sweep can help with that but I wouldn't pursue this in a CI effort. This will affect both "native" builds and buildkit cache mounts if you're persisting the target directory.

We create an empty Rust binary with cargo new, this is a simple way to get Docker layer caching to work. For a more robust solution, you may want to check out cargo-chef.

If this ends up being a cleaner/easier way to having to workaround super expensive rebuilds for Rust given cache + deps compared to this https://github.com/LukeMathWalker/cargo-chef , reading this thread will have been a huge win for me (and hopefully others).

Whether introducing Bazel is easier/worth it, subjective I guess.

I did a talk (slides here) about this a few years ago, it took a bit of work to get the build caching working with cargo. As others have pointed out, there is now cargo chef to solve this problem so you probably don't have to deal with the issues I saw, but I thought it still might be helpful context.

I'm curious if you've tried out cargo-chef, I've had some decent improvements with it but I wonder how it stacks up to the sccache approach (don't have the time to try it out myself right now).

for CI have you tried to use buildkit persistent runners with caching + https://github.com/LukeMathWalker/cargo-chef ?

If you're deploying Rust with Docker I can tell you that cargo-chef is invaluable. With zero work it caches the dependency fetch and compilation steps. Most of the time the ens Docker deploy is closer to an incremental compile than full.