bocker VS for-mac

A (joke?) one-liner I came up with while thinking about solutions to centralized container management across multiple SSH hosts. Shame on me.

The name is inspired by bocker [0], albeit this doesn't re-implement docker-compose in bash, I found it to be fitting enough.

I'd love to see someone come up with a smarter and/or shorter way to do this.

[0] https://github.com/p8952/bocker

When I did a talk about docker I also wanted to show a bit of what it does under the hood without going through all the layers and without too much details. This ~120 lines of shell script is really good in providing just an intro into what's needed for containers: https://github.com/p8952/bocker/blob/master/bocker

i tried it and like the concnpt, but until it can be launched via a systemd userspace service (without previously manually booting it) among other problems i will keep using docker (or bocker)

> But you couldn't reimplement podman in a few hundred lines of code.

You don't even need a few hundred: https://github.com/p8952/bocker

And then there's 'dokku' which IIRC, started as a bash version of Heroku.

> Not all ideas have the same quality.

They really do. I've heard all kinds of things in my career, but almost none I would want to dedicate a portion of my life building. Not because they are bad ideas or won't work, but because of the person with the idea or it just didn't interest me. Those people went on to be moderately successful (like hundreds of millions worth) but I'm glad I wasn't on that ride.

Bocker is in this same category...docker clone in bash that's helpful in seeing what's really happening underneath with nsenter, namespaces, network bridging, cgroups, etc.

https://github.com/p8952/bocker

Docker implemented in around 100 lines of bash: https://github.com/p8952/bocker

This is the most mindblowing example for enterprise security teams that think Docker is a new threat on a single tenant Linux host.

No, buddies, all this stuff is already there. If you were fine with your visibility before*, you're still fine. Go find a real problem while we play with our developer dopamine.

* NARRATOR: They shouldn't have been.

Bocker[1] does a reasonably good job of showing the value of Docker was mostly in Docker hub.

[1] https://github.com/p8952/bocker

There is a cool project I've seen called "bocker" (https://github.com/p8952/bocker) which is something of a proof of concept of implementing Docker with bash, which speaks a bit to how Docker is indeed in many ways an amalgam of lower level primitives (such as chroot as you mentioned). Pretty neat!

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.