"Specifically, small businesses (fewer than 250 employees AND less than $10 million in revenue) may continue to use Docker Desktop with Docker Personal for free. The use of Docker Desktop in large businesses, however, requires a Pro, Team, or Business paid subscription, starting at $5 per user per month."
well it is AND: "AND less than $10 million in revenue"
basically most companies with ~50 people probably has 10 million in revenue (annually).
considering wages and buildings and stuff you need for 50 people...
Maybe this is common knowledge, but I saw an ad recently for a company that offers money to snitch on your employer for using unlicensed software, or not paying for free-for-personal-use" software
I don't think it's 250 seats, but 250 employees. Lots of fairly low tech businesses (such as restaurant or retail chain or universities) may have less than a dozen docker users but still cross that total threshold.
Businesses that would unknowingly risk this because some engineer just went and installed Docker Desktop because they couldn't be bothered chasing this through management and procurement? Well..
If you're doing $10M in ARR, how much engineering time are you going to spend to switch compared to paying Docker a few thousand dollars a month? Your spend on cloud and Slack (or other comms) is likely far higher. You're probably spending more on mobile/cell business service.
"Docker attempting to monetize users of its product who can easily afford the cost." I mean, the terms seems reasonable, and wouldn't you rather support Docker vs IBM (Redhat->Podman)?
Nothing changes for users who aren't making money using Docker, but I suppose you could still spend your time switching to podman on principal.
I'm part of a large company and I have no influence over what most other people do. My projects within the company are small so whenever these sorts of things happen, it rarely translates into the company spending a bunch of money to provide the product across the company. At best, I may be able to convince a manager to buy it for 2-10 people on my team.
Licensing isn't perfect. On the contrary, it is the least worst implementation of attempting to extract a reasonable amount of revenue from the user of your software, who is realizing value creation or benefit themselves from its use. SaaS is popular because the exchange of value between producer and consumer (and the ownership and responsibility model) is much more clear (imho). Open source tooling might be a better fit based on your org's needs and your use case.
Solving for the intersection of building and maintaining tools people desire and those building said tools eating and paying rent is hard.
I'll preface this by saying I'm an IBM employee. That being said your comment rubbed me the wrong way...
> wouldn't you rather support Docker vs IBM (Redhat->Podman)?
Podman is an open source product and Docker is not. I'd much rather support an open source project. And what's wrong with "supporting" IBM anyways? Did they hurt you in some way???
> And what's wrong with "supporting" IBM anyways? Did they hurt you in some way???
They are a dysfunctional consultancy masquerading as a technology firm, running on inertia. They are not to be supported. (Also, my genuine condolences)
FWIW, we've divested/spun off the "consultancy" part. And not every part of IBM is bad, there are a ton of great developers and teams that work here, no condolences needed. I quite enjoy doing what I do here. Lots of innovation in multiple areas, but I guess if you have to drink the startup koolaid prevalent here on HN, be my guest.
I'm not at a startup nor drink the koolaid [1]. I am a consultant, so I get to see how the sausage is made across a wide variety of orgs. In my long tenure in tech (20+ years), I have arrived at evangelizing and encouraging engineering first and data driven organizations; in my experience, that provides the best environment for technologists to have autonomy, while pursuing mastery and purpose (which, hopefully, enables some amount of fulfillment alongside financial compensation). IBM is not such an org, hence my comment(s), but there are startups, enterprises, and a fat middle of SMB businesses that truly are innovative and can demonstrate results to back up that description of themselves.
TLDR I want the best experience for my fellow technologists and engineers.
Looks like you've had problems with IBM consultants, I'll grant you that, but I don't dabble in that side of the business. In my 20+ years of professional experience I have seen it all when it comes to software development and IT service management. From small startup shops barely knowing how to manage Java dependencies, to ecommerce shops doing millions of dollars a day in sales, to large enterprises being among the first adopters of Kubernetes. To lump all of one company into a single disparaging statement is disingenuous.
Docker Desktop is not open source, but the Docker container engine is. Also, runc, which is the actual container runtime, is not only open source, but was created by docker but is also what gets used by podman. podman is very nearly just a fork with the daemon and socket removed, which would not have been possible if docker hadn't been open source.
My tiny part of a division of my last company made $40 million USD per year in revenue. We had ~40 employees. Getting the funding for using something like this came from a few levels up and would be in no way guaranteed.
I admit Docker will likely have to tweak their licensing model while also building relationships where there is some wiggle room for how licensing is handled (perhaps accept credit card payments from corporate users that they can expense to sidestep procurement). "Call Us For Pricing"
We do accept credit card payments. All our pricing is on the website https://docker.com/pricing - the Business plan will be available by credit card soon as well.
At my institution the "adapt open source" vs "buy" balance is also affected by the high effort of making a purchase happen. My bet is that things will get hung up on an exclusive acquisition justification, at which point the IBM/RHEL sales team will come in with "solution" using podman, buildah, etc. I've quit DD just now to try those tools out.
This seems like a false economy. Docker adds insane value for us (similar number of tech employees), and while I don't like price hikes based on things other than value add features, I certainly want Docker to exist in five years. Or get bought by Hashicorp, perhaps.
why do you need the Docker Desktop? Can't you just use the command line? I mostly use Docker on Linux and even then I've almost switched everything over to Podman.
It's not great, at all. But at least on Mac it's a lot easier to get going with Docker for Mac than it is to roll your own with e.g. VirtualBox. I assume it's the same on Windows.
I just use whatever `brew install docker` gives me. They don't call that Docker Desktop, right? I thought that was some kind of GUI thing of theirs—I do all my dockering from the command line, which looks the same across Mac and Linux except when (rarely, these days) the virtualization the Mac implementation uses leaks through.
The key is the virtualization. I think (!) with `brew install docker` you've got to set up a VM and get Docker running inside it, yourself. Docker Desktop for Mac does that, and implements filesystem and networking integration for you.
Most people like the convenience of that, if not the performance or (now) the cost.
Closest I've come to having to manually set up anything with a simple `brew install docker` making sure my shell sets the env vars correctly. It automatically sets up the VM, and has since I started using it years ago.
(but, it's possible that what I'm using is also considered Docker Desktop—I just associated that term with their GUI thingy [and I think it includes some kind of sys tray widget?], which I've never used)
[EDIT] oh no you're kinda right, I think I recall having to run one command, post-install, on older versions, to set up the VM, though I don't think you still have to and that was all still handled for you, you just had to tell it to do it. `docker-machine create default` or something like that, was enough for 99% of use cases. Don't have to even do that, now, though, IIRC.
Meh, it's just for the headline. If someone shared the article and the title is scraped, "we're" isn't as self-explanatory and required you to look at the URL for context.
Note that Docker Desktop and Docker Engine are separate products. Docker Desktop is the desktop application package that makes Docker user-friendly on macOS and Windows. Docker Engine, the container runtime itself, remains free:
> No changes to Docker Engine or any upstream open source Docker or Moby project.
Yes, but you'd have to connect the Docker CLI running in Windows to the engine inside Ubuntu (not hard), and then you wouldn't be able to mount stuff in Windows into Docker containers via relative paths (you'd have to start them with /mnt/c/...). If neither of those things matter for you (like if all of your project code is inside your WSL VM), then it's totally fine.
Enable WSL2, then you can just install the docker provided by your distro package manager. For example, I am using docker packaed by Arch Linux, and it works as expected.
If you need to use `docker` command under Powershell, maybe exposing docker socket to Windows host would probably work. I didn't try it as I don't need it.
Not a trivial thing to run Docker natively inside of a WSL2 environment - at least my attempts to install straight docker strictly inside Ubuntu running in WSL2 always resulted in Ubuntu’s attempts to reach some .exe with regard to Docker. I did learn some fun facts WRT Linux in WSL2 - it doesn’t have systemd installed by default.
Sorry it is a bit confusing, the overall terms and conditions update is as of now, but the part about paying has a grace period but obviously we want people to know now what will apply. The terms are not very different from previous terms (although I did get the old no benchmarking clause removed, I don't know why we had that there).
> I did get the old no benchmarking clause removed, I don't know why we had that there
Your company is probably not going to fare well in this thread, but thanks for this! No benchmarking clauses are gross. Glad to see someone with the means to remove one do so.
Curious how bound I'd be to these terms if I just don't upgrade Docker Desktop. I'm not even signed in to dockerhub and most of our containers are on an Azure private registry.
It'll be interesting to see how well this works out for Docker, I have a feeling they'll lose quite a bit of custom but convert some to this model.
I'd guess a lot of people will just use Docker engine on a Linux VM with the CLI on Windows/Mac as that'll work just fine and is open source.
This was kind of inevitable though, ultimately Docker had to find a revenue stream somewhere. Docker Hub must be massively expensive to run and developing docker's product isn't free either...
There has been a huge push in the community to switch away from docker anyway. The warning signs from the company have been there for awhile and there are several container engine's, systems, UI's and other management tools not built on docker.
My original comment was not just about Docker Desktop. Their Shenanigans around the Docker Desktop commercial product has cost them alot of good will, and support for their other offerings.
This is why podman, and others are looking to replace the docker engine which while still open source is tainted by the actions of the parent company
Overall if they want to charge for their product that's fine. I just hate the model of release free or really permissible application, wait for widespread adoption, then tighten clamp. For what it's worth they've lost my business there.
Same with Telerik Fiddler recently. Good piece of software for debugging network requests on Windows.
Was free for as long as I've known it existed. Telerik recently bought by 'Progress' (ironic), software re-written in Electron and now charges a subscription to use it.
I'm the author of HTTP Toolkit! Just ran into this by chance, glad you like it :-D
I should mention here: not only is the core product all free, it's also completely open source, even including the paid bits (https://github.com/httptoolkit). And those Pro features are completely free for all contributors to the project.
I've tried to set it up so I couldn't run off with it and force everybody to start paying even if I wanted to, but any suggestions for further improvements there very welcome.
Docker desktop was never really free, as in free software, was it? If so, then it was always a proprietary app and they were always in control. IE. the clamp was always tight.
I often get laughed at when I say we should backup every tools/repositories/packages through a proxy and use only that in our internal processes. I also get scolded at making use our Dockerfiles only calls scripts a developer can use on his own machine or any other container manager once the "too good to be free" tech of the decade goes full Oracle on us.
Then everyone panics when a critical build stops working because some apt repository of some decades old distros is unplugged or some shell script piped directly to bash goes dark (or someone with a bit of security common sense rightfully has a panic attack) and we have to salvage it using some ex-employees backup images.
This is also why I just don't say I do devops because it just gets to a point where the "devops guys" are just the people you give the dirty jobs nobody wanna do.
I think you wrote the announced and effective dates twice. Effective date being 31 of January as far as I can tell. The whole point of Docker monetizing Docker Desktop is so that they can continue to be funded to maintain the base images themselves. That's the primary sell point of DockerHub.
This appears to be cutting of their nose to spite their face. We have a team of 50+ engineers that all use Docker for Mac for daily development tasks, but I suspect that will no longer be true in a rather short amount of time. Frankly, I don’t really know if anybody actually uses the UI components for it outside of starting and stopping the engine and for basic configuration of the VM. Everything else that comes with it is just useless cruft for our use cases.
As soon as there is a viable alternative (and I’d be happy to contribute to the effort), I’ll be moving away from Docker for Mac.
I tried getting podman working pointing at a Linux server and ram into issues as an alternative to Docker. I’m hoping the kinks get worked out and I can move over.
We have been using podman here for all of our developers and have yet to find anything different to docker. Perhaps you are using a more obscure feature.
For the Mac, just get Canonical’s Multipass (http://multipass.run) and do an apt-get to install Docker into a VM and use VS Code to “remote” to it. It will automatically install the Docker extension inside the Linux VM and you’re set.
For Windows, use WSL2 and do the same.
Both can mount “local” folders, although the setup is obviously different.
You now have a better way to manage containers than ever before.
Well, it does set up everything automagically for you. I can also dig around for my Docker CLI config and the right way to expose the Docker TCP socket to the host, but if you need a quick way to get working, VS Code is it.
It's in "beta" right now but it works quite well (you can find the binary in the dedicated GitHub issue). Under the hood it just uses QEMU which in turn uses Apple's Hypervisor.framework for virtualization
No, you can apt-get docker.io (the repackaged version available for the last 2-3 LTS releases, built from source and with fan networking support). Works for 99.9% of your use cases.
I would strongly recommend docker.io from Ubuntu/Debian repos. This will be always Apache 2.0 licensed. (It's a fork of Moby packaged by Debian people).
Docker Engine looks problematic since the license isn't clear at all. For instance, Microsoft didn't include Docker into GitHub Actions, they also forked Moby and packaged it on their own, since they can't comply with the End User Agreement of Docker Engine.
Why run Docker inside a VM on a Mac, when you can just run the Linux dev environment directly inside the VM? That's just starting to sound like Docker for the sake of Docker.
Multipass, Qemu, and Parallels can all provide a solid VM on Mac host. All you need after that is your dev environment VM guest image to deploy to the team.
Some people here actually want and need Docker features. For me it's the ability to run from a given image and know that I've got _exactly_ the same image that other developers have. Reproducibility.
Digests cryptographically guarantee that you get the correct content, which prevents both malicious tampering (mitm, stolen credentials, etc) or accidental mutations. This is why "immutable tags" are a bad substitute and an oxymoron.
There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.
> There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.
While agree on the unquoted part, this is true also for human-readable (aka mutable-that-should-be-immutable) tags, when that pull policy is set (which is by default for everything that is not `latest`)
I might be wrong, but I think his point is that by the time you're running a linux VM for docker, why not go ahead and get the rest of the tooling for free?
Docker can still be run in the VM just fine, for cases where you want a reproducible build environment.
I do this at any company that lets me (and by lets, I mean doesn't explicitly forbid) - They all give me a Mac, and the first (and sometimes only) thing I install is usually vmware fusion, followed by the linux distro of my choice (Arch).
>for cases where you want a reproducible build environment.
Or just create your reproducible build environment as a QEMU VM image instead of a docker file. That way you only have to install a VM image, instead of install VM image/OS + install Docker + install your Docker file.
Containers solve a different problem than vms. The biggest issues (at least for me) are
1. The second a dev starts using that VM, it's no longer reproducible. The goal of docker is that a developer can create reproducible images as a part of normal development.
2. I won't be running that QEMU vm in production, but I might very well be running the exact same container image in both development and production.
Because you can map your working folder inside it on both Multipass and WSL2, and you can get an integrated editor experience with VS Code, which is what many people apparently want to do (I’m a tmux guy so I don’t care, but I thought I’d provide a user-friendly approach).
I used fuse/sshfs quite a lot in the past, and never had much issues (I think most of my issues were with how my editor displayed and refreshed the file list, not with the actual sshfs implementation, and were similar to those on Linux/Windows.)
It’s not completely awful, but quite a long way from mounting a natively supported share, made worse by the already convoluted setup process that has been made worse by the project going proprietary.
I've been doing development in docker, but unrelated to that I did an upgrade to big sur and borked the machine for a few days.
Pulling the same projects to my (admittedly quite fast) linux box in the cloud is night and day for speed in docker with volume mounts. Browserfy runs 5x faster, at least. Yarn install is 10x faster.
And it's reliable. Docker's filesharing on the mac has about a 25% failure rate that any given save will be properly picked up by watch, with a complete, uncorrupted, updated file.
Personally I think just running portainer as a container is a viable alternative to docket desktop.
But I never really used the UI much, so perhaps there are features I don’t know of.
You’re going to spend scarce engineering resources reimplementing a Docker for Mac alternative, then roll out your immature alternative to 50+ engineers, instead of paying a few hundred dollars a month for a good product and moving on?
It seems to me you would be the one cutting off your nose to spite your face in this scenario.
The reason this move isn't popular is because it seemed like local docker development (for any size corporation) was always going to be free. If I personally had known this was in the cards I would have invested (time, money and effort) into alternatives earlier on. Instead they killed all the competition and are now demanding money. So yeah, this is the first move by Docker that has made me kind of mad at the company.
How does this affect consultants that want to introduce docker to large corporations but small teams? A lot of scenarios become crappy now.
> Instead they killed all the competition and are now demanding money. So yeah, this is the first move by Docker that has made me kind of mad at the company.
Which alternatives did they kill? The Podman tool ecosystem is doing fine and is closing in on being a complete replacement, and Docker Swarm hasn't exactly killed k{number}s.
Assuming that you currently don‘t need any other than the functionality the free plan provides, and assuming all 50 engineers need a license, your „a few hundred dollars“ is actually $1‘250/month just for getting the same as before.
I understand (in some way) the decision Docker made but I am not sure it is the way-to-go. However, it is a very hard question and if I had to pay a monthly fee for each component I‘m using to develop a solution, one or the other project would not even start because it‘s not worth it anymore.
That 50 people team probably costs at least 250000/month. Are you going to take away a tool that everyone on the team needs to save 1250?
Or put another way, how much time would you need to replicate what Docker offers for a team of 50 people? If it takes more than 25% of the time of a single employee, then Docker is cheaper (assuming your employee costs $5000 a month, which I guess is a lower bound for an engineer).
No, I am not (that was also not my point basically). My point is that you are going to pay for a) something you got for free (as in beer) before and b) something you don‘t (maybe) need/want.
I think it is a very valid question how to monetize Docker (and all the other libraries we are using for free), but I am personally not sure that subscriptions to everything are the solution.
I am sure that this expense should not get into your way if you have 50+ engineers, however if you think that with all expenses…
Isn't paying their fee also contributing to the effort of what they've put in to it so far, and ideally what they'll do to keep it working and improve over time?
I made https://github.com/lime-green/remote-docker-aws a while ago and I've been happily using it for about a year. It throws docker in a ec2 VM and allows you to call docker as if it were running locally by tunneling and syncing files. The network file systems I tried (sshfs, nfs) were way too slow when used as docker volumes so it uses a tool called unison which does two-way file syncing (rsync only does one way, which is a problem for something like making django migrations)
So you have a tool that your team use daily, but won’t pay a small license for it? I’m not sure I understand that logic. If the tool you have worked for you when it was free, it still works for you when you pay a small cost per month. Unless the cost is really that huge, I don’t see why that would be a reason to change.
I think it is mostly the issue of dealing with byzantine corporate procurement processes. Also, it's really not all the clear what value-add Docker for Desktop is. Essentially it is just doing what you can do using the OSS components (running a Linux VM which runs the docker daemon and mounting a Unix socket on the host machine to talk to it). The only "value add" is a UI app on the host machine which I have never once used personally or witnessed anyone else using.
I certainly don't begrudge Docker for trying to create a sustainable business, but as an "open core" model it's really hard to understand what their proprietary extensions are that people will want to pay for. They took a stab at the container orchestration space with Docker Swarm (which you could definitely imagine having an "enterprise version") but that lost out pretty definitively to Kubernetes. So they're left with Docker Hub? That just doesn't seem like it will really be much of a revenue generator. You're either using whatever cloud container registry is available (ECR, GCR etc) or you're using a more general artifact repository like Artifactory, GitHub which can be a container registry as well as a Maven/NPM/etc artifact repository.
Although that thread was posted earlier, I think we'll merge it into this one, on the principle that corporate press releases tend to make worse HN submissions. This is something of an exception to HN's original source rule.
Docker Desktop with developer environments would be a great value add if it supported Windows, macOS and Linux. As it is, we have developers in the company using Linux workstations so our Docker subscription is just for a registry.
We'll be moving soon given no forthcoming Linux client.
I wonder how many people just use docker desktop as a nicely packaged installer/VM manager? I know I don't use any of the other included tools, so can't see why I'd use docker desktop on Linux myself over just install docker from my package manager (or podman in my case)
Hi, we have requests for Docker Desktop Linux, please upvote https://github.com/docker/roadmap/issues/39 and we are looking at the details of what we need to do to implement this.
Thanks for listening, Justin. Looking forward to updates. I know it must be tough facing a lot of adversity from the community. I hope you guys continue playing to your strengths, improve customer support (number 1 in my book) and continue beefing out your product portfolio so companies like the one I work for can build healthy relationships with Docker, Inc.
If you are on Linux and using only the open-source bits (that's what I do) and have subscription for the registry, why would you be moving anywhere? What does this change bring that I am missing? As I understand it the change only affects Docker Desktop, which is for MacOS and Windows.
It's not this change in particular, it's that you can get paid image registries with better customer support at a lower price point and higher availability. Docker needs to value add to their bare registry product otherwise they will be outcompeted by larger companies that can offer registries as part of a larger product suite.
Unfortunately, Docker's most valuable addition, developer environments, is only for two of the three OSes used most commonly by developers in a corporate environment. No company is going to adopt a feature that can only be used by two-thirds of its workforce.
If Docker wants to grow up, maybe they could start with replying to support tickets from paying customers. I have a 10 day old open ticket with no reply.
I can no longer edit this comment but I just wanted to update that Docker the company has really made huge strides in the last few days to rectify our experience. So if you're having a hard time, reach out. My feeling speaking directly with some Docker people is that they're proud of the company and believe in its future.
Fwiw, while there probably isn't a _good_ public relations response here ... N=1, when I see a company publicly managing escalation via public shaming, it inclines me to steer purchasing decisions away from them in the future.
Policy success is directly dependent on how we handle requests for exception. Granting exceptions undermines people’s sense of fairness, and sets a precedent precedent that undermines future policy. In environments where exceptions become normalized, leaders often find that issuing writs of exception—for policies they themselves have designed—starts to swallow up much of their time. Organizations spending significant time on exceptions are experiencing exception debt. The escape is to stop working the exceptions, and instead work the policy.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 122). Stripe Press. Kindle Edition.
Another point of genius is right after the above section on exception debt.
It was in that era of my career that I came to view management as, at its core, a moral profession. We have the opportunity to create an environment for those around us to be their best, in fair surroundings. For me, that’s both an opportunity and an obligation for managers, and saying no in that room with my manager and CTO was, in part, my decision to hold the line on what’s right.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 123). Stripe Press. Kindle Edition.
So, like many companies, successful support consists of yelping at the appropriate public forum, be it Twitter or in this case, HN. Anything the public doesn't see: "due to unexpected call volume, you'll wait at least ten days before hearing from anyone". All the while the company forgets that the complaining customer isn't the only one reading. The rest of us are reading a live account of what company's customer support looks like.
Not really comparable to the problem with Google you're pointing to. Google's services are free, here we have tickets from paying customers.
I've never opened a ticket to Google as paying customer so I don't know for sure but unless someone comes and confirms that same crap is happening even if you pay we can't really compare those two cases and Docker is worse for simple reason that it demands payment yet ignores paying customers.
Hah, tell me about it. We were unable to give them more money (buy more seats), and our urgent support request was open for a week. Turns out (from a moment's console snooping) it was a straightforward REST call that was missing a body parameter, so a simple 'curl' fixed the issue for us. But I wonder... how long they were actively hurting their business? And how did a serious bug like that get into production? What does that say about their systems?
I personally support Docker Desktop for Mac for an organization of 250-300 engineers.
I have been supporting it for 2 years now. Been through all the Docker Desktop upgrades, performance issues everytthing. I have researched docker performance on macs running k3d + k3s + istio and a bunch of microservices. I have had to jump into the internals of Docker daemon and docker cli and networking to solve how docker networks are provisioned for various proxying issues.
1. Docker dragged their feet with native performance for file syncing. We have to selectively enable it and just so that it doesn't bog the machine down.
2. When running it gets the CPU running at 75-80C, causing the fan to run non-stop at 3000 rpm at least. It is definitely impact by bad macbook pro design, which is terrible at airflow and heat sink activities
3. We were on unstable for a bit to test the new file syncing approach. Docker dropped that in stable and said "deal with it"
4. The paid forced upgrade notification means that I can't peg the Docker Desktop version for the whole org at a certain version.
5. Right after we switch from the unstable to stable, the next minor version is a breaking change.
6. Number 4 would be fine it docker would keep to their guarantee of stable being stable. They do a terrible job of being backwards compatible. The current stable we had was 3.3.1. With the constant minor upgrades, and pushing people, some people went to 3.6.0. (the latest as of yesterday, Aug 30) This broke everything inexplicable with just a VM error where k3d would keep crashing. I downgraded everyone back to 3.3.1 to get teams unblocked while waiting for me to find a fix.
7. Finding a fix usually involves waiting for Docker to prioritize something but at this point I don't trust that Docker know what it is doing.
I am currently pushing for Linux laptops, hosted dev environments and reducing the need to run distributed monoliths. We shall see.
I hope you do get the Linux Laptops through. I just joined s company that made an exception for me to use Linux and I haven't felt more valued ever. I never want to use another OS again.
I think it's unreasonable to expect so much from a company that doesn't make money.
The non-desktop docker product on it's own is crazy good, I think it's reasonable to expect docker desktop to improve once docker actually makes money from it and can afford to hire more engineers to work on it.
Ok, I gave it a try. It's given me two K8s errors before any meaningful container work can be done. Not going to waste further time given a first run experience this bad. I'm interested in investing in my tools, not alpha-testing.
You guys (by you guys I mean you and Docker, Inc) would do yourselves a huge favor not spiting the Linux devs who invented the technologies you build your tools on.
Where's the Linux version? Give it to me in Snap, AppImage, Flatpak, deb, or rpm, whatever you want. Just offer something. We'll take care of the rest.
It’s open source, you could probably port it yourself.
I somewhat agree with your viewpoint, but given Windows 10 is generally just Windows 10 , OSX is OSX… But Linux could be anything from Redhat to Alpine to a raspberry pi , I understand why devs wouldn’t support it
Thanks for the feedback. A Linux version is in the roadmap for this fall. I've had several discussions on it in the past week.
Part of this was due to priorities and part of it was technicalities. For example, do we put it in a VM so that way someone can easily blow things away and we don't touch the base system? We had to come to some direction on what we wanted to do there. Now that we have that idea we need to finish up one thing on Mac that will translate over to Linux.
The Linux side will be based on Lima[1] just as the Mac side is.
Earlier today I had a discussion on the packaging format.
The whole reason this (and Docker Desktop) are used is that Docker and K8s does not run natively on macOS and Windows.
If you’re using Linux already, most of this stuff is as useful as nipples on a breastplate. You could theoretically run an emptied out husk of the app on Linux, but there are much better tools for working with the tools directly.
So I’d be greatly surprised if any Linux kernel hackers are miffed about this.
I'm not sure the whole reason for Docker Desktop is that Docker and K8s don't run natively. I mean, someone could create a Linux VM and get them running right through there. The tools exist to do this.
There are even programs like minikube that can get you Kubernetes in a VM on Mac.
There is something else to it that people want and that translates to Linux, I've learned. They want an easy button with an easy UX. There are a lot of people who are like that.
Right and when you're a corporation it cannot be overstated how important it is to coalesce around universal solutions that get up and out of the way with as few steps as possible. Handing new developers a handbook of incantations to get going is very fragile. Handing those same developers one executable with a big Go! button is much easier to get right.
One example from my last job was having one shell.nix in the root of every project folder a developer could nix shell into that contained everything they needed, same version and all, to get going with that project.
When you are a <10 person small development agency where juniors come to work it is critical. The subject of https://rietta.com/blog/dockerized-cost-savings/. Paying over and over again for new devs to "get set up" was devastating the budget.
1. There's very little "getting started" info here, you seem to assume everyone already runs kube everywhere else and already has workloads ready to go.
2. Not sure if this is feasible, but I'm looking for something that solves the Docker Desktop problem! I want something that can port map to a local port for testing, I want something that I can map a local folder to in order to store job input/output.
3. I tried starting it, and I'm already running Docker Desktop. It didn't seem to start a healthy kube cluster, and actually did nothing for me but just said it was waiting for the cluster. It might have been attempting to connect to old Docker kube clusters that I'm no longer running. Did I just need to wait longer? It wasn't clear.
Does this work with Docker compose files? For local development at the moment I mostly use docker-compose and for production using AWS Fargate so the kubernetes functionality is a bit wasted on me really
Looking at the installation instructions for Docker on Mac/Windows, what is the expected way to install the Docker Engine without installing the Desktop bundle?
Docker for Mac/Windows sets up a Linux VM using macOS/Windows native virtualization via the open-source HyperKit/VPNKit abstractions maintained by Docker-the-Company and the community. That VM runs Docker Enginer (dockerd) and all interaction (docker CLI commands, shared volumes, networking, etc.) are proxied into that VM.
WSL2 can get weird when you start trying to install software with low level virtualization and file system features. YMMV. I’d use it to install apps, but I wouldn’t be confident it’d work with Docker. Even if it did initially work, eventually you’ll hit a problem for which there is no googleable answer & good luck with that.
Current Docker on Windows detects if you have WSL2 or not, and gives you the option of just installing docker in WSL2 + configuring the Windows docker tools to manipulate the docker daemon running in WSL2.
I’m not a Windows user but AIUI just running dockerd in WSL2 misses some of the volume sharing and networking niceties. Nothing that couldn’t be replicated though
I think HN needs to update their algorithm. If there is a large number of upvotes and flags, flags should count as votes from some point on. More people need to see this post and discussion needs to happen instead of pushing it off the front page in less than an hour.
Curious to see what that means for Windows containers. Microsoft is heavily recommending Docker there, but asking people to license another thing from a third party just to be able to use a feature on their expensive Windows licenses seems somewhat on the nose for them to push.
This seems like a bit of a footgun from Docker Inc. Those on Linux will just run Docker Engine (the open source part) directly, or move to alternatives like Podman. Docker Desktop only really has value on macOS and Windows, and there it's only because nobody wants to manage the glue to setup a Linux VM. Given the cost, I suspect many will chose to do that glue work themselves and I wouldn't be surprised to see an open source project spring up to do that.
Everything else is handled by other parts of the ecosystem already, image registries both private and public, orchestration, etc.
macOS is the hard one to solve. It does a lot of magic things in the background and Docker even created their own "distro" / VM build system, linuxkit, that went on to be useful in a lot of other places to make it work.
A lot of macOS developers imo seem to have more knowledge in their specific domain and less in how to wire up a VM to look seamless, they'll need the docker CLI to work with the local filesystem to keep a lot of existing Makefiles functional, I see a bunch of companies caughing up money in the short term just for that.
Docker Desktop on Windows itself proves quite well that WSL2 works fine for this use case.
The hype/buzzword driven development surrounding micro services/containerization has hit middle America and enterprises spend dumb amounts of money on related projects. I can see them spending more money on Docker Desktop with no difficulty, because the incentive is not to save money.
It's a short sited move that will kill D.Desktop. It's not that these large corps don't have the money for this, it's how money is allocated in companies. Instead, now all hobby projects in large corp get killed fast and early because the hobbyist knows their project is doomed if the company isn't going to go for a new bill.
I agree that it seems self-destructive. I use Docker Desktop at work for a one-off side project that I run manually every once in a while. Using a container for it helps keep things maintainable compared to a full VM that needs full maintenance. If I have to get formal approval and a purchase to continue using it then the most likely outcome is this side project stops completely. And with it my excuse to gain professional experience using Docker.
"Selling" and "market share" is pretty generous when talking about people who are not and will never give you any money. Sure maybe they'll pay you in exposure, but personally I wouldn't bet much on that
Honestly, I don't see a reason to keep Docker for Mac installed on my computer. I haven't run a container workload locally in I don't know how long and I haven't built a container locally in even longer. It's just taking up space on my laptop and bugging me to update what seems like constantly.
596 comments
[ 2.7 ms ] story [ 269 ms ] thread"Specifically, small businesses (fewer than 250 employees AND less than $10 million in revenue) may continue to use Docker Desktop with Docker Personal for free. The use of Docker Desktop in large businesses, however, requires a Pro, Team, or Business paid subscription, starting at $5 per user per month."
basically most companies with ~50 people probably has 10 million in revenue (annually). considering wages and buildings and stuff you need for 50 people...
Businesses that would unknowingly risk this because some engineer just went and installed Docker Desktop because they couldn't be bothered chasing this through management and procurement? Well..
"Docker attempting to monetize users of its product who can easily afford the cost." I mean, the terms seems reasonable, and wouldn't you rather support Docker vs IBM (Redhat->Podman)?
Nothing changes for users who aren't making money using Docker, but I suppose you could still spend your time switching to podman on principal.
Solving for the intersection of building and maintaining tools people desire and those building said tools eating and paying rent is hard.
(no affiliation with docker)
> wouldn't you rather support Docker vs IBM (Redhat->Podman)?
Podman is an open source product and Docker is not. I'd much rather support an open source project. And what's wrong with "supporting" IBM anyways? Did they hurt you in some way???
The Docker Engine is Apache License and open source.
They are a dysfunctional consultancy masquerading as a technology firm, running on inertia. They are not to be supported. (Also, my genuine condolences)
https://news.ycombinator.com/item?id=24228972
https://news.ycombinator.com/item?id=26532125
https://news.ycombinator.com/item?id=26869877
https://news.ycombinator.com/item?id=22224782
https://news.ycombinator.com/item?id=23268191
https://news.ycombinator.com/item?id=27706128
https://news.ycombinator.com/item?id=24471903
TLDR I want the best experience for my fellow technologists and engineers.
[1] https://news.ycombinator.com/item?id=28181703
TLDR; your comment is stupid.
Before Docker Desktop, would need to create VM with Docker and connect to that. Docker Desktop makes that smooth and wraps in nice UI.
Most people like the convenience of that, if not the performance or (now) the cost.
(but, it's possible that what I'm using is also considered Docker Desktop—I just associated that term with their GUI thingy [and I think it includes some kind of sys tray widget?], which I've never used)
[EDIT] oh no you're kinda right, I think I recall having to run one command, post-install, on older versions, to set up the VM, though I don't think you still have to and that was all still handled for you, you just had to tell it to do it. `docker-machine create default` or something like that, was enough for 99% of use cases. Don't have to even do that, now, though, IIRC.
You can install the docker client inside WSL/OSX and connect over SSH to a docker CE instance.
Be warned
The article itself uses "we"
It's plain wrong. You can't refer to yourself as Docker AND as "we"
> No changes to Docker Engine or any upstream open source Docker or Moby project.
If you develop on Linux, no changes are needed.
Would I be able to install and run Docker inside Ubuntu's WSL distro to avoid paying for Docker for Desktop?
So install the client inside WSL and the engine on a Linux VM.
EDIT: https://raesene.github.io/blog/2018/11/11/Docker-18-09-SSH/ was a blog I wrote when that feature landed, AFAIK it works the same way now :)
I may have had to expose the Docker socket for VS Code containers support to work, but that wasn't any pain, and secured with TLS.
Never needed Docker Desktop, which seemed like a bloated mess.
If you need to use `docker` command under Powershell, maybe exposing docker socket to Windows host would probably work. I didn't try it as I don't need it.
I install `docker.io` via apt and its good to go except that package has on some ubuntu versions been missing the /etc/init.d/ startup script.
I build my WSL2 environments via Dockerfile. You can see everything here:
https://github.com/SeanTAllen/wsl-environments/tree/main/ubu...
Using that dockerfile I can then export the file system as a tar (https://wiki.seantallen.com/notes/docker-export-filesystem/) and import into wsl using the wsl import command.
https://www.redhat.com/sysadmin/podman-windows-wsl2
Your company is probably not going to fare well in this thread, but thanks for this! No benchmarking clauses are gross. Glad to see someone with the means to remove one do so.
Or their removal of Docker
I'd guess a lot of people will just use Docker engine on a Linux VM with the CLI on Windows/Mac as that'll work just fine and is open source.
This was kind of inevitable though, ultimately Docker had to find a revenue stream somewhere. Docker Hub must be massively expensive to run and developing docker's product isn't free either...
This will accelerate those programs
Podman is closest in function to docker engine, which is still open source.
This is why podman, and others are looking to replace the docker engine which while still open source is tainted by the actions of the parent company
Was free for as long as I've known it existed. Telerik recently bought by 'Progress' (ironic), software re-written in Electron and now charges a subscription to use it.
Glad HTTP Toolkit is now available free for 'hobbyist' tasks - https://httptoolkit.tech/
I should mention here: not only is the core product all free, it's also completely open source, even including the paid bits (https://github.com/httptoolkit). And those Pro features are completely free for all contributors to the project.
I've tried to set it up so I couldn't run off with it and force everybody to start paying even if I wanted to, but any suggestions for further improvements there very welcome.
I was very, very impressed when I opened the Android mode and my Genymotion emulator just opened automatically with the VPN app and connected.
Then everyone panics when a critical build stops working because some apt repository of some decades old distros is unplugged or some shell script piped directly to bash goes dark (or someone with a bit of security common sense rightfully has a panic attack) and we have to salvage it using some ex-employees backup images.
This is also why I just don't say I do devops because it just gets to a point where the "devops guys" are just the people you give the dirty jobs nobody wanna do.
Also, announced on 31.08, effective 31.08 (albeit grace period…)
The page reads as follows:
> These new terms take effect August 31, 2021, and there is a grace period until January 31, 2022 for those who require a paid subscription…
So: announced 31.08, effective 31.08 (albeit grace period).
To add to this, I have received their email with this announcement after after 2pm CEST on 31.08. This must have been an unplanned decision.
As soon as there is a viable alternative (and I’d be happy to contribute to the effort), I’ll be moving away from Docker for Mac.
podman stop -a
or you can mount the current directory
podman run -v .:/mnt
or you can mount while you build
podman build -v /dir:/dir
or you can work entirely without root and have the same user on the host also in the container:
podman run --userns=keep-id
(useful when a directory is mounted into container but the application refuses to run as root)
For Windows, use WSL2 and do the same.
Both can mount “local” folders, although the setup is obviously different.
You now have a better way to manage containers than ever before.
You could use anything to manage the Docker VM... VSCode is just one option.
Docker Engine looks problematic since the license isn't clear at all. For instance, Microsoft didn't include Docker into GitHub Actions, they also forked Moby and packaged it on their own, since they can't comply with the End User Agreement of Docker Engine.
Multipass, Qemu, and Parallels can all provide a solid VM on Mac host. All you need after that is your dev environment VM guest image to deploy to the team.
https://wiki.qemu.org/Hosts/Mac
https://www.parallels.com/
There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.
While agree on the unquoted part, this is true also for human-readable (aka mutable-that-should-be-immutable) tags, when that pull policy is set (which is by default for everything that is not `latest`)
Docker can still be run in the VM just fine, for cases where you want a reproducible build environment.
I do this at any company that lets me (and by lets, I mean doesn't explicitly forbid) - They all give me a Mac, and the first (and sometimes only) thing I install is usually vmware fusion, followed by the linux distro of my choice (Arch).
Or just create your reproducible build environment as a QEMU VM image instead of a docker file. That way you only have to install a VM image, instead of install VM image/OS + install Docker + install your Docker file.
Containers solve a different problem than vms. The biggest issues (at least for me) are
1. The second a dev starts using that VM, it's no longer reproducible. The goal of docker is that a developer can create reproducible images as a part of normal development.
2. I won't be running that QEMU vm in production, but I might very well be running the exact same container image in both development and production.
I just SSH into my server. The biggest pain about macOS is that it can't easily mount SFTP.
[1]: https://mountainduck.io
Pulling the same projects to my (admittedly quite fast) linux box in the cloud is night and day for speed in docker with volume mounts. Browserfy runs 5x faster, at least. Yarn install is 10x faster.
And it's reliable. Docker's filesharing on the mac has about a 25% failure rate that any given save will be properly picked up by watch, with a complete, uncorrupted, updated file.
It seems to me you would be the one cutting off your nose to spite your face in this scenario.
How does this affect consultants that want to introduce docker to large corporations but small teams? A lot of scenarios become crappy now.
Which alternatives did they kill? The Podman tool ecosystem is doing fine and is closing in on being a complete replacement, and Docker Swarm hasn't exactly killed k{number}s.
I understand (in some way) the decision Docker made but I am not sure it is the way-to-go. However, it is a very hard question and if I had to pay a monthly fee for each component I‘m using to develop a solution, one or the other project would not even start because it‘s not worth it anymore.
Or put another way, how much time would you need to replicate what Docker offers for a team of 50 people? If it takes more than 25% of the time of a single employee, then Docker is cheaper (assuming your employee costs $5000 a month, which I guess is a lower bound for an engineer).
I think it is a very valid question how to monetize Docker (and all the other libraries we are using for free), but I am personally not sure that subscriptions to everything are the solution.
I am sure that this expense should not get into your way if you have 50+ engineers, however if you think that with all expenses…
Isn't paying their fee also contributing to the effort of what they've put in to it so far, and ideally what they'll do to keep it working and improve over time?
I certainly don't begrudge Docker for trying to create a sustainable business, but as an "open core" model it's really hard to understand what their proprietary extensions are that people will want to pay for. They took a stab at the container orchestration space with Docker Swarm (which you could definitely imagine having an "enterprise version") but that lost out pretty definitively to Kubernetes. So they're left with Docker Hub? That just doesn't seem like it will really be much of a revenue generator. You're either using whatever cloud container registry is available (ECR, GCR etc) or you're using a more general artifact repository like Artifactory, GitHub which can be a container registry as well as a Maven/NPM/etc artifact repository.
Although that thread was posted earlier, I think we'll merge it into this one, on the principle that corporate press releases tend to make worse HN submissions. This is something of an exception to HN's original source rule.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
We'll be moving soon given no forthcoming Linux client.
Unfortunately, Docker's most valuable addition, developer environments, is only for two of the three OSes used most commonly by developers in a corporate environment. No company is going to adopt a feature that can only be used by two-thirds of its workforce.
EDIT: Wow, they actually did this and got back to me - thank you!
If I have to tweet-storm to get someone to look at my support ticket, there is no real support.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 122). Stripe Press. Kindle Edition.
It was in that era of my career that I came to view management as, at its core, a moral profession. We have the opportunity to create an environment for those around us to be their best, in fair surroundings. For me, that’s both an opportunity and an obligation for managers, and saying no in that room with my manager and CTO was, in part, my decision to hold the line on what’s right.
Larson, Will. An Elegant Puzzle: Systems of Engineering Management (p. 123). Stripe Press. Kindle Edition.
And that's why they are scaling back on free plans.
I've never opened a ticket to Google as paying customer so I don't know for sure but unless someone comes and confirms that same crap is happening even if you pay we can't really compare those two cases and Docker is worse for simple reason that it demands payment yet ignores paying customers.
I have been supporting it for 2 years now. Been through all the Docker Desktop upgrades, performance issues everytthing. I have researched docker performance on macs running k3d + k3s + istio and a bunch of microservices. I have had to jump into the internals of Docker daemon and docker cli and networking to solve how docker networks are provisioned for various proxying issues.
1. Docker dragged their feet with native performance for file syncing. We have to selectively enable it and just so that it doesn't bog the machine down.
2. When running it gets the CPU running at 75-80C, causing the fan to run non-stop at 3000 rpm at least. It is definitely impact by bad macbook pro design, which is terrible at airflow and heat sink activities
3. We were on unstable for a bit to test the new file syncing approach. Docker dropped that in stable and said "deal with it"
4. The paid forced upgrade notification means that I can't peg the Docker Desktop version for the whole org at a certain version.
5. Right after we switch from the unstable to stable, the next minor version is a breaking change.
6. Number 4 would be fine it docker would keep to their guarantee of stable being stable. They do a terrible job of being backwards compatible. The current stable we had was 3.3.1. With the constant minor upgrades, and pushing people, some people went to 3.6.0. (the latest as of yesterday, Aug 30) This broke everything inexplicable with just a VM error where k3d would keep crashing. I downgraded everyone back to 3.3.1 to get teams unblocked while waiting for me to find a fix.
7. Finding a fix usually involves waiting for Docker to prioritize something but at this point I don't trust that Docker know what it is doing.
I am currently pushing for Linux laptops, hosted dev environments and reducing the need to run distributed monoliths. We shall see.
The non-desktop docker product on it's own is crazy good, I think it's reasonable to expect docker desktop to improve once docker actually makes money from it and can afford to hire more engineers to work on it.
https://rancherdesktop.io/
Disclosure: I work on Rancher Desktop. Feedback welcome.
Where's the Linux version? Give it to me in Snap, AppImage, Flatpak, deb, or rpm, whatever you want. Just offer something. We'll take care of the rest.
I somewhat agree with your viewpoint, but given Windows 10 is generally just Windows 10 , OSX is OSX… But Linux could be anything from Redhat to Alpine to a raspberry pi , I understand why devs wouldn’t support it
Part of this was due to priorities and part of it was technicalities. For example, do we put it in a VM so that way someone can easily blow things away and we don't touch the base system? We had to come to some direction on what we wanted to do there. Now that we have that idea we need to finish up one thing on Mac that will translate over to Linux.
The Linux side will be based on Lima[1] just as the Mac side is.
Earlier today I had a discussion on the packaging format.
[1] https://github.com/lima-vm/lima
If you’re using Linux already, most of this stuff is as useful as nipples on a breastplate. You could theoretically run an emptied out husk of the app on Linux, but there are much better tools for working with the tools directly.
So I’d be greatly surprised if any Linux kernel hackers are miffed about this.
There are even programs like minikube that can get you Kubernetes in a VM on Mac.
There is something else to it that people want and that translates to Linux, I've learned. They want an easy button with an easy UX. There are a lot of people who are like that.
One example from my last job was having one shell.nix in the root of every project folder a developer could nix shell into that contained everything they needed, same version and all, to get going with that project.
1. There's very little "getting started" info here, you seem to assume everyone already runs kube everywhere else and already has workloads ready to go.
2. Not sure if this is feasible, but I'm looking for something that solves the Docker Desktop problem! I want something that can port map to a local port for testing, I want something that I can map a local folder to in order to store job input/output.
3. I tried starting it, and I'm already running Docker Desktop. It didn't seem to start a healthy kube cluster, and actually did nothing for me but just said it was waiting for the cluster. It might have been attempting to connect to old Docker kube clusters that I'm no longer running. Did I just need to wait longer? It wasn't clear.
From https://docs.docker.com/engine/install/binaries/#install-cli...
> The macOS binary includes the Docker client only. It does not include the dockerd daemon.
Docker for Mac/Windows sets up a Linux VM using macOS/Windows native virtualization via the open-source HyperKit/VPNKit abstractions maintained by Docker-the-Company and the community. That VM runs Docker Enginer (dockerd) and all interaction (docker CLI commands, shared volumes, networking, etc.) are proxied into that VM.
There's probably a fairly simple way to run Docker directly in WSL, but a lot of documentation is going to need to be updated to point to that method.
Everything else is handled by other parts of the ecosystem already, image registries both private and public, orchestration, etc.
A lot of macOS developers imo seem to have more knowledge in their specific domain and less in how to wire up a VM to look seamless, they'll need the docker CLI to work with the local filesystem to keep a lot of existing Makefiles functional, I see a bunch of companies caughing up money in the short term just for that.
Docker Desktop on Windows itself proves quite well that WSL2 works fine for this use case.
Good move by Docker, financially speaking. They have little to lose.
A whole bunch of scenarios die now.
Why would I go out of my way to set up Docker differently on my dev machine compared to my servers? That seems like a recipe for failure.