[HN Gopher] Docker for Mac Without Docker Desktop
___________________________________________________________________
Docker for Mac Without Docker Desktop
Author : robfig
Score : 197 points
Date : 2022-01-28 16:07 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| AceJohnny2 wrote:
| I find it hilarious that their solution to Docker (which is
| supposed to be virtualization-light: containers) bloatedness is
| to use a full-fledged virtual machine.
|
| Something's gone deeply wrong somewhere.
| zenlikethat wrote:
| Not that I disagree about something being deeply wrong, but
| VM's your only option. Docker is more or less hardcoded to
| Linux, so you need a Linux kernel somewhere. Docker Desktop
| just runs a light one for you that you don't worry about
| managing much.
| daveidol wrote:
| 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!
| matsemann wrote:
| 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 everything set up. And that setup works for everyone, on
| all OSes and not depending on local environments.
|
| PyCharm uses that image as a remote interpreter, so pressing
| play in pycharm just works.
| daveidol wrote:
| Wow, I hadn't thought of that use case. I agree Python's
| toolchain is just not easy to work with.
| tluyben2 wrote:
| I use only arm images with Docker but I get 100% CPU on my m1 ;
| on top it says Docker - 100%. Usually it takes a while (few
| hours) to go from 5% to 100% but it always gets there and the
| only way to stop it is shutdown Docker desktop and starting it
| again. It also crashes quite a lot (docker ps will then say
| Docker is not running and I have to restart Docker desktop to get
| it back as well). I really like the hardware on this machine but
| I'm contemplating selling it and getting a Frame.work with Linux
| just to get rid of this pain. It is a far faster & smoother
| experience on my 11 year old X220 with Linux than on this m1. I
| am not sure why this happens; I see many more people have it but
| there seems to be no clear reason?
|
| Does this help or is the issue lower level?
| surfer7837 wrote:
| No company is going to touch Virtualbox without a 10ft barge
| pole. The licensing is so easy to get wrong and before you know
| it you're writing a cheque to Oracle's legal department
| papito wrote:
| When I work on Linux as my OS, I just install CTOP, and it's all
| I need to work with Docker.
|
| https://github.com/bcicen/ctop
| jedahan wrote:
| I wrote a dumb shell script that wraps Canonical's multipass to
| do what Docker Desktop used to. Its limited but reliable on my M1
| mac.
|
| https://github.com/jedahan/podman-desktop
| oplav wrote:
| 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 docker-compose; brew install
| colima; colima start; docker run ...")
| peter_l_downs wrote:
| I just switched to Colima and found it worked perfectly out of
| the box, according to the documentation. Once I had brought up
| a new machine with `colima start --cpu 2 --memory 8 --disk 10
| --with-kubernetes`, `docker compose` worked perfectly and I
| could see the colima-backed kubernetes cluster available to
| control via `kubectl config get-contexts`.
| rgoomar wrote:
| +1 to Colima. Works seamlessly. Made the switch not too long
| ago.
| essem wrote:
| What drew you to switch up your workflow?
|
| I am on a m1 macbook air and I've been using Docker + Docker
| Desktop without much issue, and my use-case is a little simpler
| than yours (only running single containers at a time).
|
| I'm genuinely curious to learn more about what these tools
| (Colima, podman) help enable. If I'm missing out on a
| performance boost, I'd definitely check them out.
| peter_l_downs wrote:
| I switched because of licensing changes and because I find
| the docker desktop UI to be laggy, frequently updating with
| no discernible benefit to me, and superfluous -- I would
| rather interact with my containers via the CLI, but had to
| use the desktop app to start the daemon.
| dankirberger wrote:
| qbasic_forever wrote:
| In case you missed it the license terms for Docker Desktop
| have changed and require companies with ~250 employees to
| start paying for it: https://www.docker.com/blog/updating-
| product-subscriptions/
| Macha wrote:
| And in those larger companies, just paying for the "coffee
| a month" may not be an option, since they insist all
| licenses are company owned and it's less effort to change
| my docker VM wrapper than get shit past my company's
| purchasing department in a reasonable amount of time.
| qbasic_forever wrote:
| Exactly, I think this is really going to backfire for the
| bean counters that took over Docker. It should either be
| free or $100k+ agreements for extremely large companies.
| They're way underestimating the inertia and pain with
| trying to nickle-and-dime small and medium business
| users.
| essem wrote:
| gotcha. i was aware, but doesn't apply to my current
| circumstance.
|
| is that the motivator for most, then?
| salzig wrote:
| podman: https://podman.io/ colima:
| https://github.com/abiosoft/colima
| amarshall wrote:
| 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
| StreamLocalBindUnlink=yes export
| DOCKER_HOST="unix:///$tmpdir/podman.sock" docker-
| compose "$@" rm -r "$tmpdir"
| matsemann wrote:
| Afaik podman-compose doesn't support "docker compose run" to
| do one-off stuff in a new container? Is there some
| alternative?
|
| I do it all the time now, have the entire dev flow
| dockerized. So I run tests, lints, fixers, migration etc all
| through docker compose.
| MonaroVXR wrote:
| > Afaik podman-compose doesn't support "docker compose run"
| to do one-off stuff in a new container? Is there some
| alternative?
|
| Minikube, no sarcasm. I'm also going to use Minikube.
| amarshall wrote:
| To be clear: this isn't the actual podman-compose project,
| just a wrapper to make docker-compose work with podman-
| machine. That said, I just tried to do a run and it didn't
| work. It's not part of my workflow though so I haven't
| encountered it before and thus haven't really looked into
| it.
| als0 wrote:
| Is this a short term issue or is nobody working on docker-
| compose 3.x compatibility?
| amarshall wrote:
| I assume you meant 2.x; Compose 2.x is only ~4 months old.
| I believe the intention of the Podman team is to abandon
| their podman-compose and work on compatibility with docker-
| compose 2.x going forward.
| ravenstine wrote:
| 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.
| didip wrote:
| For the life of me, I could not make podman working to replace
| Docker. I keep getting various errors.
|
| I just made the switch to colima. Thanks for mentioning it!
| rckrd wrote:
| One of the past maintainers of minikube here. Minikube, while
| targeted towards Kubernetes developers, also provides all the
| features you'd want here. It also takes away most of the pain
| from virtual machine management w/ native hypervisors.
|
| If you're looking for customizability (boot image, docker
| version, container runtime), minikube is probably your best bet.
| It even comes with some rudimentary file-sharing and port-
| forwarding primitives, but it isn't as batteries-included as
| Docker desktop. On the other hand, you have full ssh access to
| the VM to do whatever you want (+startup scripts, etc.)
|
| Awhile back, I wrote up a comparison of all the Docker Desktop
| Alternatives. [1]
|
| [1] https://matt-rickard.com/docker-desktop-alternatives/
| xtracto wrote:
| I use kubernetes for pushing stuff to AWS EKS, and it is great.
| The problem I found with minikube and other Kubernetes based
| "alternatives" to Docker Desktop (including podman) is that
| they are not compatible with Docker Compose. There are a * a
| lot * of "solved problems" via docker-compose.yml files, and
| all of my past companies have used it. I've tried some docker-
| compose to k8s migration tools, but the amount of crap files
| they generate was not feasible for me.
| sangnoir wrote:
| Nerdctl[1] (for containerd) works fine with docker-
| compose.yml for my purposes (which are not much). The only
| issue I encountered was with environment variable
| substitution not working the same as docker-compose, but I
| didn't look hard for a solution and edited my compose file
|
| 1. https://github.com/containerd/nerdctl mine came bundled
| with Rancher desktop, and 'nerdctl compose up' is all I've
| needed
| freetime2 wrote:
| The issue that I had with Minikube is that I couldn't get it to
| work with my employer's VPN enabled. I realize that this is
| more the fault of my employer's strict no-split-tunneling
| configuration than Minikube's, but sadly that is the reality I
| live in.
|
| I ended up using lima vm, which has an elegant port forwarding
| solution to make everything running on the VM appear as if it
| is running on localhost.
|
| Having made the switch, I also prefer the simplicity and
| transparency of know exactly how the VM is configured, and
| being able to make tweaks to the provisioning script if
| necessary. Minikube on the other hand felt a bit automagical at
| times.
| shepardrtc wrote:
| It should be noted that minikube does not work on the M1. Sadly
| we started switching devs over to M1 at the same time we
| finished up switching our local environment over to minikube.
| mfer wrote:
| There's one big difference between Docker Desktop and minikube
| and the ones referenced in the docker desktop alternatives
| link. Docker Desktop is a desktop app (GUI and all) while all
| the listed alternatives are terminal apps.
|
| For some this might not matter but for others it does.
|
| Rancher Desktop[1] has the desktop app install experience, the
| GUI, and the the tools (Docker CLI/nerdctl, Kubernetes (k3s),
| etc), and more.
|
| [1] https://rancherdesktop.io/
|
| Disclaimer, I started Rancher Desktop.
| JeremyNT wrote:
| I agree, I think the GUI is important for the kinds of users
| who feel lost without Docker Desktop. There have been plenty
| of other ways for technical users to run their containers all
| along (really, you could just run your own VM with vagrant if
| nothing else) but the people who want a "point and click"
| turnkey experience will appreciate the GUI.
|
| Another kind of nice thing about Rancher Desktop is it's
| cross platform, so even Linux users can use it. That could be
| nice if you have a mix of Linux and Mac devs and want to use
| the same tooling here. It also makes sure you don't "mess up"
| your real Linux system or run into any distro-specific
| version incompatibilities (since it's all in a disposable VM
| controlled by Rancher Desktop).
|
| I've tinkered with Rancher Desktop periodically and I think
| it's a promising tool. For now I keep going back to running
| Docker directly, only because it's my existing workflow (I'm
| a Linux user so the Docker Desktop changes don't apply to
| me).
| gkop wrote:
| 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?
| encryptluks2 wrote:
| 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.
| moondev wrote:
| 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
| rckrd wrote:
| kind (Kubernetes-in-Docker) still requires Docker, so its not
| a replacement for Docker Desktop (Windows/macOS). You'll need
| to run kind in minikube or kind in Docker Desktop.
| mfer wrote:
| From the kind readme[1]...
|
| > kind was primarily designed for testing Kubernetes itself,
| but may be used for local development or CI.
|
| minikube was designed for those who want a local kubernetes
| environment for development. It didn't work well for testing
| Kubernetes itself which led to kind. They had two different,
| though slightly overlapping, goals.
|
| [1] https://github.com/kubernetes-sigs/kind
| jrockway wrote:
| minikube is good where you have to have a VM, which is
| development on Windows and OS X. Linux containers need Linux,
| much to the dismay of laptop buyers I guess.
|
| I personally don't bother. I use Windows but just have a pet
| Linux VM where I actually do work, and then use kind (with
| podman; Docker seems to be turning the screws and I'm getting
| out ahead of that).
| CubsFan1060 wrote:
| Has anyone done any filesystem speed comparisons on any of these?
| Mounting volumes on Mac in Docker Desktop is... not great. Anyone
| found any good comparisons?
| lordelph wrote:
| FWIW, I recently switched from an Intel to an M1 Macbook, and
| found shared volumes with Docker Desktop were unusably slow
| (previously, I'd used VirtualBox host docker and shared files
| into it via NFS).
|
| However, using https://mutagen.io/ to keep the container in
| sync has worked remarkably well - it's greatly improved the
| speed of the container.
| CubsFan1060 wrote:
| Awesome. I'll try it out. Thanks!
| vhsdev wrote:
| The proper way to develop with docker on Mac is using a Linux
| dual-boot.
| ggregoire wrote:
| > Motivation: Docker for Mac was proving to be a workflow pain
| rather than a workflow gain. It was slowing down my 16" Macbook
| Pro (32GB RAM, 6 CPUs), draining the battery, and causing the
| fans to constantly spin at full speed.
|
| A performance comparison between this solution and Docker for Mac
| would have been great.
| kristjansson wrote:
| It's not local docker, but export
| DOCKER_HOST=ssh://user@some.nix.box
|
| does the trick for like 90 percent of my local docker workflows.
| Big gaps are local volumes, remembering to look for ports exposed
| on the remote box instead of localhost, and VPN access (if the
| remote box box isn't on the right network)
|
| Otherwise its a treat. No local storage eaten up, no cores pinned
| to 100%, no reserved memory, no (additional) VM layer, ...
| matsemann wrote:
| I'd rather (my company) pay than having to deal with all this
| myself. My Docker workflow works. Spending time on everyone
| moving away is actually a negative ROI.
| chrisjc wrote:
| 5. Install Docker Machine docker-machine
|
| The last time one of these discussions came up and a similar
| solution was provided, someone pointed out that 'docker-machine'
| is not a dependable solution. I can't remember the exact reason,
| nor can I find the link, but it was something along the lines of
| Docker making it proprietary or abandoning the project.
|
| Can anyone provide any more detail about the state of 'docker-
| machine' or help clarify any issues with hitching your wagon to
| these 'docker-machine' solutions?
| qbasic_forever wrote:
| Just visit the repo: https://github.com/docker/machine It is
| archived and hasn't had a commit in almost 2.5 years. See also:
| https://github.com/docker/roadmap/issues/245
| mrinterweb wrote:
| In my experience, Docker for Mac has always had significant
| performance problems primarily because of its built in host <->
| volume sync strategy. The problem has persisted for many years.
| Different 3rd party (open source) solutions can relieve this
| performance bottleneck like docker-sync and mutagen. It just
| blows my mind that after all these years, the docker for mac team
| hasn't found a decent file sync strategy to include by default.
| If you're working on a project with a lot of files, docker for
| mac's built-in sync strategy is likely crushing your CPU.
| therealmarv wrote:
| We also need an M1 compatible UTM version of that. To bad it
| seems UTM cannot be automated with vagrant like VirtualBox.
| saagarjha wrote:
| UTM is just QEMU under the hood, which should be easy to
| automate.
| user3939382 wrote:
| The heart of this is docker-machine which is deprecated
| lioeters wrote:
| Yup..
|
| > Docker Machine has been deprecated. Please use Docker Desktop
| instead.
|
| https://docs.docker.com/machine/
| vanpythonista wrote:
| Gitlab maintains a fork of docker-machine with critical bug
| fixes that I've been using recently since Docker deprecated it:
| https://gitlab.com/gitlab-org/ci-cd/docker-machine
| freetime2 wrote:
| 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.
|
| [1] https://github.com/lima-vm/lima
|
| [2] https://github.com/lima-
| vm/lima/blob/master/examples/docker....
| riffic wrote:
| 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/
| asdff wrote:
| I have used the native launch agent system in macos to do what
| some people use docker containers for.
| whartung wrote:
| Do you have this written up anyplace sharable?
| asdff wrote:
| 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.
| conradludgate wrote:
| Because most people want to run Linux containers (to get the
| same environment as their servers)
| musicale wrote:
| > why the heck doesn't the macOS kernel support native
| containerization
|
| It doesn't seem like a huge leap from sandboxing to
| containerization.
|
| They also might consider supporting BSD-style jails.
| minerva23 wrote:
| > 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.
| Langdal wrote:
| Also creating their own SoC that outperforms others in the
| space.
| sjtindell wrote:
| I never understood this, because surely some huge percentage
| of developers use Macs. Enterprises buy stacks of them
| nonstop. Just making that group happy would get you the
| reputation of being a developers machine, for serious
| computer people, which could translate into laymen purchases
| too.
| riffic wrote:
| containerization won't just help in the server-space. It has
| use-cases in app development like CI.
| smoldesu wrote:
| 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/
| Toine wrote:
| "Exterior design and heavy marketing is their sales strategy"
| this is old, boring and not even true.
| [deleted]
| [deleted]
| CubsFan1060 wrote:
| That URL got me excited, but didn't seem to be a lot of
| progress on it in the last 6 months or s.
| 0xedd wrote:
| macOS is mainly targeted at secretaries, managers and artists.
| Tech work isn't designed to be compatible with a mac.
|
| Take for example using netcat. The version available to Mac is
| 17 years old and lacking some useful flags like keep alive and
| redirect to executable.
| http://www.opensource.apple.com/source/netcat/netcat-7/netca...
|
| Something as simple as assigning shift+insert as another
| shortcut for clipboard paste requires hacking. A strong signal
| to "not do anything outside the pretty buttons we gave you".
|
| The target audience isn't interested in containerization. Those
| who use containers for work or daily drive don't use mac. Iirc,
| a 2018 stackoverflow survey of what devs use had 50% on
| windows, 40% on Linux and 10% on mac.
|
| Unrelated to the above, windows containers still depend on
| hyper-v for networking and container images must run on the
| same kernel version they were built for. Expensive constraints
| for what they deem as production ready. Sounds more like "fake
| it until you make it" as you can't use it to build artifacts
| for different windows versions. Leaving windows dev and its ops
| as expensive as it was before.
| kelnos wrote:
| > _macOS is mainly targeted at secretaries, managers and
| artists. Tech work isn 't designed to be compatible with a
| mac._
|
| I don't think this is true at all. Despite not developing Mac
| applications, we've (Twilio) been a Mac shop since day one,
| 14 years ago. This was driven by our three founders, who, at
| the time, were all engineers. These days our IT department
| offers Windows machines for employees who need it for some
| reason, but uptake is likely in the single-digit percentages.
|
| And I know a lot of people who do technical work at various
| companies whose primary work machine is a MacBook Pro.
|
| This might be a Silicon Valley startup thing. I would expect
| the Stack Overflow survey is skewed pretty hard toward
| Windows due to big corporate enterprises that aren't tech
| companies. It seems to me that most "tech companies" prefer
| Macs.
|
| > _Take for example using netcat. The version available to
| Mac is 17 years old and lacking some useful flags_
|
| I run Linux, so I don't have firsthand experience with much
| of this, but everyone I know who uses macOS for development
| has something like Homebrew installed, so they can get up-to-
| date versions of the various tools that are outdated in the
| default macOS install.
| darrenf wrote:
| > _Iirc, a 2018 stackoverflow survey of what devs use had 50%
| on windows, 40% on Linux and 10% on mac._
|
| You needn't rely on your memory, the survey is still
| available [0]. FWIW, it doesn't seem to contain a question
| about the OS where development takes place, only about the
| _targets_ [1]. The top answers were:
|
| Linux 48.3%
|
| Windows Desktop or Server 35.4%
|
| Android 29.0%
|
| AWS 24.1%
|
| Mac OS 17.9%
|
| [0] https://insights.stackoverflow.com/survey/2018/
|
| [1] "Linux and Windows Desktop or Server are the most common
| choices that our respondents say they have done development
| work _for_ this year. " (emphasis mine)
| jdpedrie wrote:
| It does have stats for Developers' Primary Operating
| System[0]:
|
| Windows 49.9%
|
| MacOS 26.7%
|
| Linux-based 23.2%
|
| BSD/Unix 0.2%
|
| [0] https://insights.stackoverflow.com/survey/2018/#technol
| ogy-_...
| darrenf wrote:
| Wow. I have no idea how I missed that. Mea culpa. Albeit
| those numbers are still radically different to the poster
| I replied to.
| viro wrote:
| oh wow he completely misrepresented that stat.
| skrtskrt wrote:
| I have worked at 4 small-to-mid-sized tech companies now and
| only one didn't have every software engineer on Macs with
| Docker.
|
| I don't disagree that the built-in tools on Mac leave a lot
| to be desired, but you can also just brew install things and
| clearly Docker has gone to a lot of effort to make this all
| work on Mac, so the demand is there.
|
| I switched to Linux for the current company, and was
| expecting fewer Docker oddities and better battery life, but
| I seem to actually have way _more_ issues now, which -
| without sinking a week or more into investigating transient
| issues - I attribute to it _not_ being isolated in a VM.
|
| I often have to reboot my machine just to get basic DNS
| resolution working from inside a container
| viro wrote:
| I have a simple one for ya... Use docker and Vmware on the
| same windows machine.
| ideologysec wrote:
| Are you talking about the old problem of VMware and Hyper-V
| not playing well together, or suggesting that using both
| together solves Windows development woes?
| kstrauser wrote:
| > macOS is mainly targeted at secretaries, managers and
| artists.
|
| Counterpoint: I've never seen someone in the Bay Area
| developing on a Windows machine, in any company I've worked
| at. In my experience, locally, it's more like 95% Mac, 5%
| Linux, and 0% Windows.
|
| Now, I know that neither of our anecdotes represent the state
| of the world in general, but the notion that "Macs are for
| non-techies" is laughable on the face of it.
| jokethrowaway wrote:
| Indeed, with windows' linux subsystem I have to say working
| from M$ sounds reasonable, maybe even better than dealing with
| Mac OS X half-baked package managers and subpar docker
| experience.
|
| It used to be that Windows had a better UX than OS X (imho at
| least), but nowadays they're equally crap and they can't
| compare with what's available on linux.
|
| With two machines, I'd still pick Windows for gaming dev and
| linux for everything else.
|
| With three machines, I'd add a screen-less mac mini to do iOS
| related builds.
| pjmlp wrote:
| Although just today I was having some Windows containers
| hiccups, I am looking forward to the day that Microsoft doesn't
| require installing a third party solution (Docker) to use them.
| zamalek wrote:
| Install a WSL machine. Install docker (or containerd, or
| whatever) in it. Install docker-cli on your host, then use
| `docker context` to use the server in WSL. 20min of effort if
| your Google fu is good.
|
| If you need something like the docker desktop UI, check out
| portainer.
| snuxoll wrote:
| Unfortunately this like other alternatives still misses some key
| features of Docker Desktop for Mac like utilizing VPNKit
| (https://github.com/moby/vpnkit) to make networking not
| constantly break when on a VPN without split tunneling, etc.
|
| I've started using minikube myself as I stopped constantly
| needing to use Cisco AnyConnect for work as we switched to using
| a Zscaler product instead - but this is a huge bugbear for many
| users I'd like to see _somebody_ address.
| explaingarlic wrote:
| I suppose peeps are starting to notice this because they're no
| longer able to use Docker Desktop on their corporate machines and
| are scrambling for alternatives?
|
| We got lucky where I work, and already had a RHEL license which
| gives us Docker Desktop Enterprise too, I think.
| tallytarik wrote:
| As others have pointed out, Virtualbox doesn't work on ARM (M1).
|
| A few months ago I switched to a new setup on my M1 Max: running
| a Ubuntu VM in UTM (https://mac.getutm.app/), and installing
| Docker there.
|
| I use Mutagen (https://mutagen.io/) for syncing files between
| macOS and the VM, which works really well.
|
| There is a 10x-20x speed improvement running a large PHP (Drupal)
| project through the VM than Docker for Mac.
| tomrod wrote:
| Podman or minikube are the solutions I've gone with. Great
| software!
| may13noon wrote:
| what about lima? it seems more easier to get.
|
| https://github.com/lima-vm/lima
| cpressland wrote:
| I'm in the process of changing our local development
| containerisation strategy within the business from Docker for
| Desktop to Lima. So far it's been absolutely flawless.
| tpoindex wrote:
| Lima absolutely rocks. For me, there are a few small nits, but
| overall probably the best to replace Docker. Out of the box
| ("brew install lima; limactl start") lima gives you an Ubuntu
| VM with containerd and nerdctl. Nerdctl is mostly compatible
| with the docker cli as others on this thread have mentioned.
| The examples/ directory also has configs for starting up k3s or
| k8s. Rancher Desktop is also using Lima.
|
| Minikube also works, but I can't get host directories mounted
| in the VM; running nfsd on the Mac is a reasonable work-around.
| It does start up k8s containers, so if you just want a docker-
| like environment, it might be overkill.
| hoofhearthed wrote:
| Uhm I'm not a sys-admin nor an extreme senior engineer, but you
| have to admit. The current setup for running docker on macOS,
| with the current virtualization, is completely broken.
| freetime2 wrote:
| We have been using it for years with few major issues, so I
| would definitely not call it completely broken. "Suboptimal",
| maybe.
|
| But we made the decision that the benefits of containerization
| outweigh the cost of having to run containers in a VM during
| development, and have been mostly happy with that decision.
| We're certainly not considering going back to the old way of
| having to manage application runtime dependencies separately
| across hundreds of different servers.
| grishka wrote:
| This is x86-only, right?
| navbaker wrote:
| 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?
| matsemann wrote:
| 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.
| stjohnswarts wrote:
| I'm sure they just buy a list of $10million+ company ip
| reservations and let their lawyers go to town.
| speedgoose wrote:
| I use Rancher Desktop as an alternative to Docker Desktop. It's
| alright.
| bproven wrote:
| I just pulled it (and switched to dockerd as default container
| runtime to use 'docker') - it seems to work as a great swap for
| docker desktop on mac. I like that volumes work well vs podman.
| Nice that you an trivy scan an image, etc.
|
| Have you hit any sharp edges yet? I imagine there might be a
| few. Anything you can share would be great
| speedgoose wrote:
| Port forwarding is currently broken if you use dockerd but it
| will be fixed in the next release or you can run a command to
| fix it yourself. See https://github.com/rancher-
| sandbox/rancher-desktop/issues/12...
|
| It fails to setup some filesystem links because of Unix
| permissions. You can fix it in command line. See
| https://github.com/rancher-sandbox/rancher-
| desktop/issues/11...
|
| If you put your computer into sleep, the VM time will be out
| of sync. It's going to be fixed in the next release I
| believe. It's an old classic bug that happened to me with WSL
| so it was nice to see it again. https://github.com/rancher-
| sandbox/rancher-desktop/issues/83...
| bproven wrote:
| thanks!
|
| Looks like the first and last issue is fixed in 1.0.0
| (released 2 days ago). So only that second issue remains
| for now.
| yebyen wrote:
| I have just started using it, and I stopped short of telling
| people it was a great alternative because I don't have enough
| experience with it yet to say one way or another.
|
| But so far it's pretty muchliving up to my expectations, with a
| few quirks: (1) I can use the buildkit plugin, at least it
| seems to work so far, but (2) things are not strictly
| compatible, for example the `kuby build` command has an issue
| and will need to be updated to support rancher desktop... it's
| refusing to log in right now, even though I logged into my
| registry already, with an error about not doing interactive
| logins without a TTY. I'm assuming there's an easy workaround,
| (but this part works fine with Docker Desktop already.)
|
| By your "it's alright" I suspect you've seen other things I'll
| bump into that made you say "alright" rather than "great."
| Anything interesting you're able to share?
| speedgoose wrote:
| I indeed did bump into a few things. You can check my other
| comment about that :
| https://news.ycombinator.com/item?id=30118961
| InsaneOstrich wrote:
| This won't work on the new M1 macs since it uses VirtualBox
| jedisct1 wrote:
| Yeah :(
|
| Ever since I switched to an M1, I haven't found a way to
| reliably build and run x86_64 containers on it.
|
| Docker desktop with Qemu is not just painfully slow, it's also
| very buggy and some containers just can't be built without
| crashing.
|
| Is there any alternative?
| InsaneOstrich wrote:
| My organization decided to hold off on purchasing M1 MacBooks
| for developers until they're better supported by third party
| software. Too much stuff just crashes or doesn't work well,
| even with QEMU and Rosetta.
| rvz wrote:
| Exactly.
|
| After the November 2020 release of the M1 Macs, Docker and
| many developer tools were still not available and you would
| have to wait 6 - 8 months for Docker to be fully supported
| and out of beta for M1 Macs.
|
| Not quite ideal to wait for your tools to be available on
| your machine for more months in order to do any work on it.
|
| The smartest thing anyone would have done to save
| themselves from disappointment and frustration as a
| developer is by simply using your existing Intel Macs and
| 'waiting' for the software ecosystem to catch up with the
| Apple Silicon Macs.
| bbatsell wrote:
| I haven't tested it, but Lima purports to support it:
|
| https://github.com/lima-vm/lima/blob/master/docs/multi-
| arch....
| jbreiding wrote:
| Give https://github.com/abiosoft/colima
|
| A try, I've been using it for a few months on both m1 and
| x64.
|
| It works really well.
| therealmarv wrote:
| Try UTM https://mac.getutm.app/
|
| Run x86 Linux of your choice there, install Docker inside
| there. Run it there.
| PolCPP wrote:
| You'll get the same issues, since utm uses qemu. Tried it a
| few days ago with x64 linux only to have the os crash while
| copying stuff over smb
| navels wrote:
| FWIW I switched from Docker Desktop to UTM+Ubuntu+Docker
| a few months ago and it has been great.
| PolCPP wrote:
| ARM Ubuntu or X86?
| c7DJTLrn wrote:
| I don't have anything of substance to add but I can
| definitely echo your experience. I'm still in love with the
| M1 chips but it is definitely not a seamless transition if
| you work with Docker a lot. I've had containers behave really
| strangely and unreproducibly.
| Rucadi wrote:
| Have you tried https://threedots.ovh/blog/2021/01/huawei-
| exagear-x86_64-app...
|
| maybe it works faster than qemu for a chrooted environment.
| rubyist5eva wrote:
| When they changed the docker desktop terms, I switched to Podman.
| Now with Rancher Desktop and kubernetes swallowing the
| world...what really is the point of docker at all?
| blakesterz wrote:
| "Motivation: Docker for Mac was proving to be a workflow pain
| rather than a workflow gain."
|
| I feel that pain. I switched from a Linux box to a Mac Mini for
| ALMOST all the work I do. I just couldn't take the pain, now when
| I need to do my Docker work, I just flip back to my Linux box. I
| have a Logi keyboard and Mouse with that 3 device button option,
| and a monitor with a few inputs, so I just turn on the ol' Linux
| box, press a few buttons, and I'm there. I do the same thing for
| Windows, for the rare occasion I need Windows (mostly for testing
| stuff).
|
| I could probably find ways around the pain points, but I just
| can't be bothered when it's so easy to just use the other machine
| sitting right here. No point in wasting any more time on it.
| [deleted]
| graftak wrote:
| I was thinking to do the same but with Linux in a VM on top of
| MacOS, figuring that docker runs like crap on it anyway so I
| might as well.
|
| Edit: upon inspection I see that is what the link is about, so
| it probably has some merit.
| Ramiro wrote:
| @blakesterz what kind of pain are you feeling when developing
| with containers on a Mac vs using your Linux box? I know perf
| is worse, but are you hitting other things?
| neurostimulant wrote:
| > I have a Logi keyboard and Mouse with that 3 device button
| option, and a monitor with a few inputs, so I just turn on the
| ol' Linux box, press a few buttons, and I'm there.
|
| Install Barrier on both Mac and Linux, get an extra monitor,
| and then you can seamlessly work on both system at once as if
| it's a single computer with multiple monitors. Don't even need
| to press that switch button on your keyboard and mouse.
|
| https://github.com/debauchee/barrier
| toppy wrote:
| As an alternative one can also consider Rancher Desktop
| (https://www.suse.com/c/rancher_blog/rancher-desktop-1-0-0-ha...)
| mentioned here few days ago.
| superdug wrote:
| +1 for Rancher Desktop. [ https://rancherdesktop.io/ ] you can
| alias the `docker` command with `nerdctl` as a one:one
| replacement.
| zamalek wrote:
| I tried it out to today after struggling for more than a
| month with Docker for Mac with problem after problem. I know
| how exactly many turtles there are all the way down. Rancher
| fixed _everything_ first try. Containerd /nerdctl doesn't
| work for us (too tired to figure out why), but Rancher can
| run Moby/docker.
| twsted wrote:
| I'm using Multipass [https://multipass.run], docker cli,
| configured with a docker context.
| steviedotboston wrote:
| Should this be faster than Docker Desktop?
| cmiles74 wrote:
| YMMV but my big pain point is sharing a large project between
| my Mac and the VM running Docker Desktop. I don't think this
| will make the file sharing bit any faster.
| nunez wrote:
| This is a very heavy alternative. It is also not viable for those
| with ARM machines, as Virtualbox is x86 only.
|
| Minikube is a popular alternative. Colima is an up-and-coming one
| that's can run both raw containerd and Docker engine on top of
| containerd. I prefer Colima since I'd rather not have Kubernetes
| running full-time (consumes resources).
| ConanRus wrote:
| TameAntelope wrote:
| Is there anything complex about setting this up that you'd want
| to use this, or is this more of a time saver?
|
| I was thinking about doing this, and still might on my own,
| unless there's some hard problem solved here. Nothing wrong at
| all with using this, though, very cool!
| c7DJTLrn wrote:
| The Docker/virtualisation stuff on macOS really needs fixing up.
| The x86 to ARM transition has made things worse but it was
| pitiful even before. Virtualization.framework doesn't seem to
| live up to the hype. Docker has an experimental mode for it - if
| you try enabling it you'll quickly realise why it's experimental.
| Your computer will go into meltdown and performance will feel a
| hundred times slower. M1 MacBooks are no good for Docker/VMs
| unless you have a Parallels license.
|
| Apple needs to do what Microsoft did surrounding Linux on
| Windows. Allocate some engineers for a few years to make life
| easier for developers on their platform.
| musicale wrote:
| > Apple needs to do what Microsoft did surrounding Linux on
| Windows. Allocate some engineers for a few years to make life
| easier for developers on their platform.
|
| Apple will most likely continue to do what it always does: make
| billions of dollars while largely ignoring Linux.
|
| iOS and macOS developers will continue to use Xcode the way
| they always have. (And perhaps Swift Playgrounds on iOS.)
| c7DJTLrn wrote:
| Maybe, but that's what we all said about Microsoft ten years
| ago.
___________________________________________________________________
(page generated 2022-01-28 23:00 UTC)