Live data from Hacker News

Docker for Mac Without Docker Desktop

github.com

101–110 of 198 posts

Re: Docker for Mac Without Docker Desktop

#101

I've done most of my dev work on my physical Windows box using Docker Desktop, but have access to a robust cloud VM network where all my Unix work is done. The end result of a dev process is an image regardless of what tool you used, right? So how does Docker know if you've used Windows or Unix to write and test a given image? Is there metadata written into the image?

They probably don't know. And it's fine to use docker desktop without paying as long as you're a small business or a private person. They can't automatically know if you're in violation or not. They just assume people want to be in compliance. Same way I wouldn't misuse gpl code at my work.

I'm sure they just buy a list of $10million+ company ip reservations and let their lawyers go to town.

Re: Docker for Mac Without Docker Desktop

#103
post #18

Earlier quoted context omitted.

Huh, I thought kind was the spiritual successor to minikube (which I used fondly years ago). When should one reach for minikube over kind today?

I prefer Minikube over Kind, because Minikube supports a lot more options and features, and has integrated the same features as Kind. Kind has not had a new release for almost a year.

The kind binary is decoupled from the node images that make up your cluster. V1.23.3 published 3 days ago

https://hub.docker.com/r/kindest/node/tags

You can also provide any kubeadm config options you want, as kind bootstraps with upstream kubeadm

Re: Docker for Mac Without Docker Desktop

#104
post #5

I've been exploring 2 alternatives (podman and colima) to replace my normal docker workflow, which is just building and running containers locally, sometimes with docker-compose. I started with podman but had issues with 2 main pieces of my workflow: docker-compose (or podman-compose) and shared volumes (with `run -v`). Switched over to colima and those worked out of the box for me ("brew install docker; brew install…

Podman works with docker-compose 1.x only and needs some finagling to work. I have this wrapper script as podman-compose #!/bin/bash set -e tmpdir=$(mktemp -d) port=$(podman system connection ls | grep -Eo 'localhost:\d+' | head -1 | cut -d: -f2) [[ -n $port ]] || exit 1 ssh -fnNT -L"$tmpdir/podman.sock":/run/user/1000/podman/podman.sock -i ~/.ssh/podman-machine-default ssh://core@localhost:"$port" -o StreamLocalBind…

This is exactly why I ditched Podman.

I really wanted to use it badly, but lacking an alternative to Docker Compose or compatibility with it in 2022 is unacceptable. Yes, there is technically a way you can orchestrate containers through configuration, and I don't remember what it was called, but I found it both difficult to use and learn. It's crazy to me that people wanted to develop an alternative to Docker... without a way to just configure and network containers with YAML or JSON.

Re: Docker for Mac Without Docker Desktop

#105
post #55

Earlier quoted context omitted.

I have used the native launch agent system in macos to do what some people use docker containers for.

Do you have this written up anyplace sharable?

No, but basically this would apply to like little services that might run on docker locally on my mac. Say you have a Dockerfile that uses pip to install some stuff and run a python script. There are a few tools on github I use that are configured like this. To run it without docker, I would write up a simple launch agent plist file that calls up another script that just initializes a conda environment with the dependencies and runs the python. this might not be applicable to all docker use cases, though, but it works well enough for me.

Re: Docker for Mac Without Docker Desktop

#106
The favorite replacement that I have found for docker desktop is to run docker-ce in lima vm [1]. It’s only a couple of commands to get up and running with their docker example [2]. Basically:

brew install lima

limactl start docker.yaml

lima is built on qemu, which is always a solid choice for virtualization. It also supports M1 Macs, and even Intel on Arm emulation (at a pretty hefty performance cost).

One of nice features of lima is that it automatically forwards ports from the host vm to guest, so when you start up a container listening on port 5432, for example, you can access it at localhost:5432. This works nicely in particular for local development while using a VPN client, which I have found has a tendency to interfere with local network traffic (if split tunneling is disabled).

lima is used under the hood in rancher desktop, which is another great option if you would prefer to have a gui. But I have settled on lima as I prefer the CLI for scripted installations, and also find it to be more customizable.

I have also seen colima mentioned in the comments, which appears to wrap lima with some prebuilt configurations. I don’t really think this is necessary, and seems like something that could just as easily be done with a gist, but if you are looking for the absolute quickest way to get up and running with docker (and optionally kubernetes) on lima, then this could be it.

[1] https://github.com/lima-vm/lima

[2] https://github.com/lima-vm/lima/blob/master/examples/docker....

Re: Docker for Mac Without Docker Desktop

#107

Earlier quoted context omitted.

I agree, but currently Docker on Mac is more about building/testing your server infra on your macOS dev machine before deploying it to Linux where it actually runs as "lightweight" containers. Regardless, would still be great if we had native macOS container support!

Not if you run your entire dev setup through docker, though. I'm tired of python's craziness. Always someone on the team unable to do poetry install, because some variant of their system makes it not have a wheel, and suddenly a whole c++ toolchain needs to be installed. And if you maintain lots of projects with different versions it's such a hassle. Now I volume mount the git clone folder into a container that has e…

Wow, I hadn't thought of that use case. I agree Python's toolchain is just not easy to work with.

Re: Docker for Mac Without Docker Desktop

#108
post #37

I know people doing docker dev are generally targeting a Linux of some sort, but why the heck doesn't the macOS kernel support native containerization? Come on Apple. Microsoft can do it. edit: this seems like a new development since my last whine/complaint on this topic: https://macoscontainers.org/

> why the heck doesn't the macOS kernel support native containerization? Because Apple has no plans of growing their server OS marketshare. I know there are benefits of using namespaces (containers) in the desktop market, but they don't sell iMacs/MBPs. Exterior design and heavy marketing is their sales strategy.

"Exterior design and heavy marketing is their sales strategy" this is old, boring and not even true.

Re: Docker for Mac Without Docker Desktop

#109
post #69

Earlier quoted context omitted.

> why the heck doesn't the macOS kernel support native containerization? Because Apple has no plans of growing their server OS marketshare. I know there are benefits of using namespaces (containers) in the desktop market, but they don't sell iMacs/MBPs. Exterior design and heavy marketing is their sales strategy.

containerization won't just help in the server-space. It has use-cases in app development like CI.

Apple would like you to move to XCode Cloud[0] in the future, running CI pipelines on your local device is soooo last-century.

[0] https://developer.apple.com/xcode-cloud/

Re: Docker for Mac Without Docker Desktop

#110
post #108

Earlier quoted context omitted.

> why the heck doesn't the macOS kernel support native containerization? Because Apple has no plans of growing their server OS marketshare. I know there are benefits of using namespaces (containers) in the desktop market, but they don't sell iMacs/MBPs. Exterior design and heavy marketing is their sales strategy.

"Exterior design and heavy marketing is their sales strategy" this is old, boring and not even true.

[deleted]
Post reply on HN