An Overview of Docker Desktop Alternatives(matt-rickard.com)
matt-rickard.com
An Overview of Docker Desktop Alternatives
https://matt-rickard.com/docker-desktop-alternatives/
195 comments
> it quite sad to see reactions on HN regarding the introduction of Docker Desktop subscription model.
Docker Desktop for Mac simply sucks. It starts slowly, has slow UX, burns CPU all the time even when not active and no container instance is running. They recently added that "you have to upgrade now" popup and it feels updates are more frequent. I might be biased here due to poor UX with the popups, updates were smoother before. If I'm to pay for it, I really would like to have better experience using it. I can run VSCode, IntelliJ and Firefox with dozen of tabs open and my mac isn't as hot as when running docker desktop.
Docker Desktop for Mac simply sucks. It starts slowly, has slow UX, burns CPU all the time even when not active and no container instance is running. They recently added that "you have to upgrade now" popup and it feels updates are more frequent. I might be biased here due to poor UX with the popups, updates were smoother before. If I'm to pay for it, I really would like to have better experience using it. I can run VSCode, IntelliJ and Firefox with dozen of tabs open and my mac isn't as hot as when running docker desktop.
> popup and it feels updates are more frequent
When was the last time it asked you for the system password to update, though?
I think they botched it because mine just doesn’t update anymore. It keeps asking and I press “Install & restart” but it doesn’t do anything!
When was the last time it asked you for the system password to update, though?
I think they botched it because mine just doesn’t update anymore. It keeps asking and I press “Install & restart” but it doesn’t do anything!
You need to manually quit it, then start again - the update will be installed at that point. I agree though, horrible UX.
Whether you like the tool or not, they are free to charge for it. Clearly there’s a market > yourself.
This is absolutely not my experience with Docker for Mac. I've been using it daily for years and can't remember a single issue I had with it. Performance is also adequate, even when running many containers, though usually not more than 10 or so. I use a base model MacBook Pro 16".
Same. Docker definitely had some performance issues on Mac a few years ago but it's fine now.
you must be running tiny containers - I spin up a dozen containers and run a few tests every day. The entire test suite takes 45 minutes on my mac and 25 on linux. Docker for mac performance is atrocious
Do you have any speed data for Docker via Docker Desktop (the tool in question) versus a manually setup Docker Mac setup?
You can’t compare Docker between OSes, and blame Docker after you chose to use an OS that doesn’t support the necessary primitives.
You can’t compare Docker between OSes, and blame Docker after you chose to use an OS that doesn’t support the necessary primitives.
If it sucks so much then why are you using it? There must be a reason, right? And if there's such a compelling reason that you're using it despite how much it sucks, that means it's worth something?
Docker on an M1 Mac is inconsistent too. Generally it works fine but not always. It uses qemu and doesn't always surface qemu errors when you're building images (you can see the errors when you're running containers, so less of a problem there). They complete build "successfully" and look like valid images when they aren't. I've had multiple k8s deployments fail locally on minikube and on GKE/EKS because of bad images built by Docker on my M1 Mac. The solution is generally rebuild until it works or use my 10 year old Intel-based Mac, but those are bad solves.
Docker shouldn't be charging anyone for that inconsistent experience.
Docker shouldn't be charging anyone for that inconsistent experience.
Author here. I agree. Even as a past maintainer of minikube, I still am a frequent user of Docker Desktop and would gladly pay for it
Btw, thanks for the article, it’s an interesting read, I like your writing style
In big Companies, the usage of VPN solution is pretty common. Especially since COVID with the rise of remote workers.
One big feature Docker Desktop nailed is the VPN friendlyest of the solution! They developped VPNKit to solve VPN issues, and honestly it works very well.
None on the alternatives provide such feature!
What does it do?
It links docker's network through a linux/windows pipe to a process on your windows/mac host. So containers network packets don't get out from a virtual network adapter (that can be filtered out) but from a vpnkit.exe process on windows.
Using this, you are more compliant with strict corporate security rules and are less likely to be blocked by your VPN client, proxy firewall etc...
> If your team is using their tools daily since years, and you decide to change to a different one just to avoid a small license fee, that feels hypocritical
From engineer's perspective the difference between a free tool and a "small fee" (in most companies) is not money. It's the fact that you now have to jump through provisioning hoops and ask for permission to use the tool. The difference in flexibility is enormous.
From engineer's perspective the difference between a free tool and a "small fee" (in most companies) is not money. It's the fact that you now have to jump through provisioning hoops and ask for permission to use the tool. The difference in flexibility is enormous.
That’s exactly what Docker wants though - You’re using a tool for gainful development for your company. They should be able to afford a fee to compensate Docker for that.
And the risk to Docker is that the red tape required to buy the product isn’t worth the hassle, especially if there are alternatives to using the paid product.
This is all based on open source, so I’d expect there to be many new alternatives within weeks. And workflows for existing tools/interfaces will probably be detailed in blog posts by the weekend.
This is all based on open source, so I’d expect there to be many new alternatives within weeks. And workflows for existing tools/interfaces will probably be detailed in blog posts by the weekend.
There’s a lot of companies (FAANG incl.) that prefer licensed software with support, over random GitHub repositories.
Most people on this thread are not commenting on lack of business model, rather that they “don’t want to pay”.
Most people on this thread are not commenting on lack of business model, rather that they “don’t want to pay”.
> There’s a lot of companies (FAANG incl.) that prefer licensed software with support, over random GitHub repositories.
FAANG (especially Google) have a tendency to take inspiration and rewrite the things that they find interesting.
Notably: Piper (very similar to Perforce) in google.
FAANG (especially Google) have a tendency to take inspiration and rewrite the things that they find interesting.
Notably: Piper (very similar to Perforce) in google.
They also have a tendency to be facing problems and scale issues that are irrelevant to like 99% of other developers, so it's a moot point.
Not sure why you’re comparing version control to a GUI - my experience at FAANG has been quite positive on the usage of licensed tools like Docker Desktop.
People keep telling me that docker for desktop is more than a gui. So either it is or it isn’t and that’s not really for me to say.
But perforce is a (mainly) gui thing and was not “safe” from reimplementation.
A deciding factor may have been that perforce is licensed software; but it could have just of easily been because google wanted better integrations. Both are true for Docker for Desktop
But perforce is a (mainly) gui thing and was not “safe” from reimplementation.
A deciding factor may have been that perforce is licensed software; but it could have just of easily been because google wanted better integrations. Both are true for Docker for Desktop
I don’t doubt it. But not everyone works for those kind of companies. I’m also not sure which class of company outnumbers the other, but I think we’d both be surprised.
Totally. Paying a reasonable amount is actually cheaper than the manpower and attention required for an ‘open source check.’ And isn’t it nicer to pay engineers, rather than lawyers? :-)
> And isn’t it nicer to pay engineers, rather than lawyers? :-)
100%. That’s why these threads shitting on Docker bug me.
100%. That’s why these threads shitting on Docker bug me.
That’s not a risk. Show me a real company that doesn’t pay for any products and I’ll show you a thousand that do.
Not pay for Docker? What are they going to do? Get everyone on AWS tomorrow? The cost and downtime for most places would be massive.
Not pay for Docker? What are they going to do? Get everyone on AWS tomorrow? The cost and downtime for most places would be massive.
> From engineer's perspective the difference between a free tool and a "small fee" (in most companies) is not money. It's the fact that you now have to jump through provisioning hoops and ask for permission to use the tool. The difference in flexibility is enormous.
So is the difference in cost to the business: if the fee is small per seat, then the big cost is the license administration overhead, not the license fee, so the induced cost can be much greater than the revenue the seller realizes.
So is the difference in cost to the business: if the fee is small per seat, then the big cost is the license administration overhead, not the license fee, so the induced cost can be much greater than the revenue the seller realizes.
As usual situations vary: I work in a small company, I'm the sole dev, there's absolutely 0 budget for dev tools, if it's not free I can't have it.
In this case Docker's approach serves you well, as you are not expected to pay the subscription fee if your company has less than 250 people.
We're very close to 250 people (but probably under, I need to check) but we're over the 10M / year line.
And yes, the company could pay, it's just they don't want to.
Just an example, I need to vent: I wrote a program that pilot all the lights in the company. To my great shame, it was failing spectacularly despite hours spent debugging the thing.
I received a lot of criticism about my coding skills.
Until I convinced him to buy pro dedicated hardware instead of cheap Arduino knockoffs to be the interface between my program and the light switches.
It's working like a charm since 2010.
And yes, the company could pay, it's just they don't want to.
Just an example, I need to vent: I wrote a program that pilot all the lights in the company. To my great shame, it was failing spectacularly despite hours spent debugging the thing.
I received a lot of criticism about my coding skills.
Until I convinced him to buy pro dedicated hardware instead of cheap Arduino knockoffs to be the interface between my program and the light switches.
It's working like a charm since 2010.
[deleted]
I agree with (some) of this. Companies are always going to be free to find alternatives if they're motivated to do so, but the cost of this subscription model is a drop in the bucket for a lot of larger firms, and there's nothing wrong with supporting a company that maintains and develops a critical piece of your infrastructure (in fact it's quite savvy).
I sometimes worry that we've gotten too used to free things, whether those things are youtube videos, articles by journalistic institutions or pieces of software. I'm hardly an exception here -- I too wince when I see a paywall in front of an article, but people need to be able to sustain themselves when they create things that benefit others. It's hard the reconcile the paradox of wanting high quality things without paying for it.
I sometimes worry that we've gotten too used to free things, whether those things are youtube videos, articles by journalistic institutions or pieces of software. I'm hardly an exception here -- I too wince when I see a paywall in front of an article, but people need to be able to sustain themselves when they create things that benefit others. It's hard the reconcile the paradox of wanting high quality things without paying for it.
My problem is less that it is happening but how we got here.
If docker desktop was originally subscription based or they said that they wanted to make it subscription based later than the reaction would be very different.
But Docker as a company has failed multiple times now to attempt to make money and this feels like a hostage situation by taking away a tool that many now rely on.
They tried to go the support route like RedHat and others, but who needed just Docker support? Especially when there orchestration layer was basically DOA with k8s available.
Last year (?) they started limiting pulls from docker hub unless you paid up. Which spawned companies like AWS to announce their own free alternative/mirror.
At some point with in the last few months they made it so without paying I was forced to update docker desktop or constantly have to click snooze. I was perfectly happy with what it was currently doing and had no desire to update. But they added that artificial limitation after release.
Now they are charging for something that was once free without really explaining any benefits?
I think the reaction is perfectly valid given the companies track record.
There are likely other examples they have tried but likely just didn't notice. Since Docker is in a situation where docker itself is just not what most of us really think about. It is the orchestration and docker is just a path to that.
Edit: Also not super enthused about the idea that I now need to ask during a job interview what software I will be able to have locally for part of my workflow.
If docker desktop was originally subscription based or they said that they wanted to make it subscription based later than the reaction would be very different.
But Docker as a company has failed multiple times now to attempt to make money and this feels like a hostage situation by taking away a tool that many now rely on.
They tried to go the support route like RedHat and others, but who needed just Docker support? Especially when there orchestration layer was basically DOA with k8s available.
Last year (?) they started limiting pulls from docker hub unless you paid up. Which spawned companies like AWS to announce their own free alternative/mirror.
At some point with in the last few months they made it so without paying I was forced to update docker desktop or constantly have to click snooze. I was perfectly happy with what it was currently doing and had no desire to update. But they added that artificial limitation after release.
Now they are charging for something that was once free without really explaining any benefits?
I think the reaction is perfectly valid given the companies track record.
There are likely other examples they have tried but likely just didn't notice. Since Docker is in a situation where docker itself is just not what most of us really think about. It is the orchestration and docker is just a path to that.
Edit: Also not super enthused about the idea that I now need to ask during a job interview what software I will be able to have locally for part of my workflow.
> Now they are charging for something that was once free without really explaining any benefits?
It was free when they could afford it. Now it’s not, because they do indeed, need money. Why is that so wrong?
It was free when they could afford it. Now it’s not, because they do indeed, need money. Why is that so wrong?
Generally, this pattern has a name: bait and switch. I'm not saying that the company shouldn't make money, but I'm saying that it's widely recognized that providing something free and changing your mind later will inevitably degrade your users' trust in you. So don't be surprised when there's backlash and migration away from your services and tools if you decide to try to turn formerly free services and tools into paid versions with no additional incentive.
I know that HN loves calling everything a bait and switch, but this is not that. It’s a useful product - despite so many here that apparently use it but insist that it’s useless. Docker wants to grow their revenue and is going to start charging companies (who also presumably have some revenue) a fee for the product.
Absolutely normal business strategy.
Absolutely normal business strategy.
I haven't said it's useless, and I don't think I've seen anyone's comments calling it useless. But the reality is, what docker does is not complicated. It was not replaced because there wasn't a real reason to. If you built a docker competitor that was also free but did exactly the same things, you'd have been asked "why?"
Now, the answer to that question exists. It's no longer free, which was the primary reason anyone just kept using it when (especially today) it doesn't offer much over alternatives.
Now, the answer to that question exists. It's no longer free, which was the primary reason anyone just kept using it when (especially today) it doesn't offer much over alternatives.
Why is the goalpost “Docker” suddenly? That’s still fully free. This whole thread is about the convenient GUI, which is what everyone is complaining about lacking features or purpose.
Docker Desktop, I mean. I personally haven't ever used the GUI except to deal with their new autoupdate prompts. I, and many others, just need something to set up the VM and orchestrate things so that `docker` in my terminal does as expected when I'm using my work-issued Mac. On Linux this is a non-issue, yes.
It’s not “wrong”, but it’s annoying. They’re asking me to invest into their platform, but they’re also constantly increasing the price and/or making it more restrictive. This makes it hard for me to understand the long term cost of a commitment.
They’re now charging for the GUI they have developed, while the core of Docker is still free. Someone has to fund continued development, asking companies for a fee feels quite logical.
Seems to me that a value-add tool makes sense to commercialize. It doesn’t provide a large array of features yet, but this funding will help with that.
If you don’t find it useful enough for the fee, clearly you’re better off with CLI or alternative GUIs.
Seems to me that a value-add tool makes sense to commercialize. It doesn’t provide a large array of features yet, but this funding will help with that.
If you don’t find it useful enough for the fee, clearly you’re better off with CLI or alternative GUIs.
What features? Are people really asking for more features for Docker Desktop?
I know for me I install it, let it do its setup, and then I do everything from the Docker CLI as if I was on a linux machine.
It has k8s built in if you want to add that also.
We are not talking about a tool here that needs a ton of functionality. But they have become (seemingly at least) the standard tool to have a more consistent Docker setup on Mac or Windows compared to where it will eventually be deployed (Linux). Once you have it setup you should be using the CLI.
I feel like they are severely overestimating the software, I am anticipating several open source alternatives to quickly become available since it wouldn't (or shouldn't) change your workflow at all to put in another alternative.
Edit: TBH I often forget docker desktop is sitting there until it starts asking me to update... so this is a perfect opportunity to replace it.
I know for me I install it, let it do its setup, and then I do everything from the Docker CLI as if I was on a linux machine.
It has k8s built in if you want to add that also.
We are not talking about a tool here that needs a ton of functionality. But they have become (seemingly at least) the standard tool to have a more consistent Docker setup on Mac or Windows compared to where it will eventually be deployed (Linux). Once you have it setup you should be using the CLI.
I feel like they are severely overestimating the software, I am anticipating several open source alternatives to quickly become available since it wouldn't (or shouldn't) change your workflow at all to put in another alternative.
Edit: TBH I often forget docker desktop is sitting there until it starts asking me to update... so this is a perfect opportunity to replace it.
You’re the perfect out of market example. Use other tools, and be content.
Of course, they’re not charging individuals, so I’m not sure why you’re complaining.
Of course, they’re not charging individuals, so I’m not sure why you’re complaining.
Docker is a valuable product only because of the CLI, not for the GUI. To be honest, no one wants their GUI. It's unfortunate Docker as a company only promotes the Docker Desktop (with GUI) for Mac and Windows.
Because I work at a company that I would have to justify the subscription too?
But you’re not using it? You stated that you don’t even know it was running - clearly you don’t even need a GUI, just CLI.
No, I said I forget it is running.
That is not because I am not using it, but I am indirectly using it by working with the Docker CLI.
What it does is very valuable, but it is a perfect candidate to be replaced by an open source alternative as long as I can continue to use the Docker CLI.
That is not because I am not using it, but I am indirectly using it by working with the Docker CLI.
What it does is very valuable, but it is a perfect candidate to be replaced by an open source alternative as long as I can continue to use the Docker CLI.
Who’s going to fund your open source alternative? Definitely not you, since Docker asking companies to pay a fee is somehow preposterous.
[deleted]
One important question to ask yourself is, what happens next time they want more money? Just how much of a hostage are you willing to be?
This can be said of literally any paid service. It’s not much of an argument, except on these kinds of HN threads.
A reasonable point.
It is, however, much easier to say it of a service that has a history of flailing around about how and what they want money for than one that has a consistent history of not being surprising.
It is, however, much easier to say it of a service that has a history of flailing around about how and what they want money for than one that has a consistent history of not being surprising.
The more nuanced argument is that the reaction to Docker’s change to charging for the Desktop version is less about the money and more about the stability of the company itself. Surprising your customer base by charging for a previously free product shows that the financials of the company aren’t very stable. This, in turn, is a red flag to rely too heavily on this particular product. Which can then start to cause a downward spiral, if not managed correctly.
But honestly, we already knew this about Docker. They’ve always had issues trying to figure out their business plan.
But honestly, we already knew this about Docker. They’ve always had issues trying to figure out their business plan.
Unfortunately, despite HN’s insistence that FOSS is sustainable - they have realized the truth, as seen by replies with views similar to yours, that Devs are too stingy to pay and support Dev tools.
Developer tools have always been a tough business to be in. On one hand, you have tools that people love to use that pay the bills. I’m thinking about tools like IntelliJ. But for each of these, there is an Eclipse project that is right there trying to keep pace. And many companies choose Eclipse because it’s free, but others choose IntelliJ because of the quality. I use Eclipse for Kava projects because it’s “good enough” and when I started programming Java, paying for IntelliJ wasn’t something I could afford.
On the other hand, we’re developers… so many of us like building our own tools. Why are there so many options for text editors? Depending on the type of tool, it might just be easier/fun to build your own tool.
It is possible to make money in FOSS, but you really have to get the business plan right from the beginning. It’s a hard business to be in.
If you haven’t read it, “Dreaming in Code” by Scott Rosenberg is a great story about just how hard it is to make a successful FOSS project, even for experienced teams. It details all of the ups and downs of the Chandler project from the early 2000’s.
On the other hand, we’re developers… so many of us like building our own tools. Why are there so many options for text editors? Depending on the type of tool, it might just be easier/fun to build your own tool.
It is possible to make money in FOSS, but you really have to get the business plan right from the beginning. It’s a hard business to be in.
If you haven’t read it, “Dreaming in Code” by Scott Rosenberg is a great story about just how hard it is to make a successful FOSS project, even for experienced teams. It details all of the ups and downs of the Chandler project from the early 2000’s.
So your point is that you (personally) don’t like their business model, and don’t like funding the company that created the free Docker software and ecosystem that you use all the time?
"Depends".
IntelliJ and Visual Studio are doing perfectly well.
Maybe not every tiny little tool should be a subscription.
(yes, docker is a tiny tool compared to, say, linux, or kubernetes)
IntelliJ and Visual Studio are doing perfectly well.
Maybe not every tiny little tool should be a subscription.
(yes, docker is a tiny tool compared to, say, linux, or kubernetes)
It’s good for the world that random HNers don’t get to decide what other people/companies should do to please them.
It's not wrong, and it's also not wrong of any previous user to decide to move to a free alternative. Let the free market decide whether they are charging a fair price for the value they provide or if there is more value in other options. For as smart as many people are on HN, I've rarely come across a more clueless bunch of folks as far as basic economics
When comments condescendingly say “free market”, it’s a red flag that you’re going to read a “wise” rant.
Meh. GUIs and other frilly OSX crap are a real pain to maintain. Paying for them makes sense.
> and you decide to change to a different one just to avoid a small license fee,
That’s an oversimplification of the issue.
I really don’t care about the small monetary cost. I do, however, care about adding yet another recurring license fee to my already long list of recurring charges and licenses to manage across the team.
It’s not necessarily Docker’s fault, but I think many of us are experiencing a lot of SaaS fatigue with the ever-growing list of services and plans and recurring charges that need to be managed.
Evaluating alternatives isn’t just about dodging a nominal fee. It’s about avoiding yet another recurring overhead and associated hassle, however small, that comes with every additional subscription.
That’s an oversimplification of the issue.
I really don’t care about the small monetary cost. I do, however, care about adding yet another recurring license fee to my already long list of recurring charges and licenses to manage across the team.
It’s not necessarily Docker’s fault, but I think many of us are experiencing a lot of SaaS fatigue with the ever-growing list of services and plans and recurring charges that need to be managed.
Evaluating alternatives isn’t just about dodging a nominal fee. It’s about avoiding yet another recurring overhead and associated hassle, however small, that comes with every additional subscription.
Oh, all those subscriptions. Office space, cleaning, drinks, coffee, electricity, heating, water, ...
Dealing with expenses is part of running a business. Sure there's a lot, but that's part of it.
Dealing with expenses is part of running a business. Sure there's a lot, but that's part of it.
I pay my electricity by the watt, and I pay for water because without it, we die.
I don't really care about your $25/month Wiki/Container/Notes SaaS as much. If you raise the price anywhere along the subscription chain, this little frog is going to jump out long before you start boiling the water.
I don't really care about your $25/month Wiki/Container/Notes SaaS as much. If you raise the price anywhere along the subscription chain, this little frog is going to jump out long before you start boiling the water.
Before you had a free lunch. Now they set a price on it. You check if the value you get from their product is worth the price they ask for (IMHO they priced it way too low). If that doesn’t match then you move away. Economics 101. The way people describe the situation in this thread makes it like they have been betrayed by their spouses… Nobody is exploiting anyone else, only one side decided to ask something in exchange for their beloved product. And only from large companies!
You're correct.
My experience procuring SaaS (or even just self-hosted software licenses) is that there's a very different process for those than there is for sandwiches or janitorial staff. The engineers are always involved, but the negotiation process is arduous _every time_, and requires looping in the procurement team, who is essentially paid by how much of a discount they get off of sticker. So there I am, trying to run a suite of services for the company I work for, and every renewal is an existential crisis where the procurement team plays chicken with the vendor to see who will crack first in the negotiation, all the while the license expiration for my service is creeping ever closer. I've suffered large production outages because of this dynamic, and I'm tired of it: it's a totally avoidable risk, and I view part of my value to my employer as helping them avoid totally avoidable risks.
So, I tend to go for open source or "bundled" solutions (like AWS) where I can avoid this process. I suspect this is what GP was getting at.
My experience procuring SaaS (or even just self-hosted software licenses) is that there's a very different process for those than there is for sandwiches or janitorial staff. The engineers are always involved, but the negotiation process is arduous _every time_, and requires looping in the procurement team, who is essentially paid by how much of a discount they get off of sticker. So there I am, trying to run a suite of services for the company I work for, and every renewal is an existential crisis where the procurement team plays chicken with the vendor to see who will crack first in the negotiation, all the while the license expiration for my service is creeping ever closer. I've suffered large production outages because of this dynamic, and I'm tired of it: it's a totally avoidable risk, and I view part of my value to my employer as helping them avoid totally avoidable risks.
So, I tend to go for open source or "bundled" solutions (like AWS) where I can avoid this process. I suspect this is what GP was getting at.
As someone with only minimal experience with containers, is Docker the company still relevant? When I set up a new server with RHEL it has some open source replacements (podman) instead, and says they work with the same containers.
The Docker Desktop client obviously is useful for quickly setting up and interacting on macOS and Windows graphically, but is Docker still relevant for the server? It seems like Docker Swarm never took off and everyone just uses Kubernetes anyway.
The Docker Desktop client obviously is useful for quickly setting up and interacting on macOS and Windows graphically, but is Docker still relevant for the server? It seems like Docker Swarm never took off and everyone just uses Kubernetes anyway.
Reframing the discussion in terms of just server seems to be deliberately missing the point, since the issue under consideration is the new pricing model for Docker Desktop. Which is 100% about developer experience on OS X and Windows.
Step 1) Release open source free software
Step 2) Get millions of people aboard
Step 3) Clamp down, raise prices, make people pay for their mistake of relying on 'free' services/products.
If you change Step 1) to Subsidize services, then you get Uber/Lyft. This also applies to drug trading (first time is free!).
It gives unfair advantage to companies that have deep VC-lined pockets and a huge pool of money to spend. It raises the critical barrier for the small-guy to compete in this landscape. It also makes it easy for these companies to wipe out competition by undercutting them. This is just cheating.
Step 2) Get millions of people aboard
Step 3) Clamp down, raise prices, make people pay for their mistake of relying on 'free' services/products.
If you change Step 1) to Subsidize services, then you get Uber/Lyft. This also applies to drug trading (first time is free!).
It gives unfair advantage to companies that have deep VC-lined pockets and a huge pool of money to spend. It raises the critical barrier for the small-guy to compete in this landscape. It also makes it easy for these companies to wipe out competition by undercutting them. This is just cheating.
It’s good business, i don’t see wha is wrong with it. You offer code source, documentation, tools for free for a very, very long time. Eventually you ask for a small license fee from big companies. Everybody benefited immensely from this.
Docker Enterprise was already sold.
What they said then about the community and future was this:
> Moving forward, we will expand Docker Desktop and Docker Hub’s roles in the developer workflow for modern apps.
Problem is, that i don't see anything really improving. It seems that they are cashing in, no?
What they said then about the community and future was this:
> Moving forward, we will expand Docker Desktop and Docker Hub’s roles in the developer workflow for modern apps.
Problem is, that i don't see anything really improving. It seems that they are cashing in, no?
They are continuously investing into Docker for Desktop, which is what is being discussed here. See the other people in the thread complaining they have to update too often as a side effect.
By 'cashing in', do you perhaps mean 'trying to earn a living'?
I would think that is the idea of having an enterprise version for. Which they sold.
And so they're never allowed to change their business model? Companies sell divisions and change their product lines all the time. What makes Docker's change so different? Let me guess, it's because it inconveniences a few loud HN commenters.
I personally am just looking for a stable tool to build and test images. I can appreciate that Docker is looking for a way to become sustainable, but the way they are going about doing it has become disruptive to how I use the tool, thus alternatives like podman are becoming much more attractive.
The license fee is really not an issue for me - but continuously having to adjust my workflows when Docker Inc decides to change how things work on the back-end is an issue, and it's much more expensive for me than the license.
The license fee is really not an issue for me - but continuously having to adjust my workflows when Docker Inc decides to change how things work on the back-end is an issue, and it's much more expensive for me than the license.
You’re using Docker, and confusing the convenient UI app for the CLI. You can easily setup Docker without it, and never have to worry about any GUI asking for a fee.
Yet, here we are. Lots of complaints, but no real understanding.
Yet, here we are. Lots of complaints, but no real understanding.
If an alternative like podman works for you, then Docker for Desktop is not really targeting you at all, right? It's only for Mac and Windows computers, not for Linux.
If you just want to build and test images, a Linux VM with the open source Docker engine installed will work fine :)
It's the bait-and-switch aspect I suspect most are reacting negatively to. Given how many of these 'pivots' we've seen, let's be honest is observing that generally the plan for a sustainable model all along most likely was "don't start charging for it until we're sure we've become a user habit and killed the competition." They knew long ago, if not on day one, that "give it away for free and make it up in volume" wasn't a serious long term plan. On the one hand, I don't blame companies for pulling this because the market continues to go along with it. On the other, I have no sympathy for the backlash they get for doing it.
Choice and competition are good. Companies taking a scorched earth approach with extended "free... for now (because we've got the runway to do it)" business models are bad for the ecosystem.
Choice and competition are good. Companies taking a scorched earth approach with extended "free... for now (because we've got the runway to do it)" business models are bad for the ecosystem.
TBF if you know the history of Docker, it seems unlikely that this was their plan in the beginning.
Docker started back before the container orchestrator wars and the rise of Kubernetes. They couldn't have predicted that or the popularity of their services and tools.
They then had the enterprise Docker edition and swarm along with UCP which at one point looked like a reasonable path to monetization.
It was only after selling the enterprise software arm to Mirantis, which isn't that long ago really, that it would have been likely that their end game was charging for the Docker desktop product.
Docker started back before the container orchestrator wars and the rise of Kubernetes. They couldn't have predicted that or the popularity of their services and tools.
They then had the enterprise Docker edition and swarm along with UCP which at one point looked like a reasonable path to monetization.
It was only after selling the enterprise software arm to Mirantis, which isn't that long ago really, that it would have been likely that their end game was charging for the Docker desktop product.
How do people who use containerd and minikube benefit from a well supported Docker company?
Docker begat ContainerD, so without Docker the organization, it would not exist as a project in it's current form.
As to current support, well if you're just using minikube, you don't need Docker Desktop, so this isn't a problem :)
As to current support, well if you're just using minikube, you don't need Docker Desktop, so this isn't a problem :)
But would they care if Docker Inc went bankrupt now? The claim was we all benefit. Universal and present tense.
If Docker hub went away, I have a fairly strong feeling the sound of CI/CD pipelines collapsing around the world would be heard for quite a while :)
Also without paid developers maintaining Docker Engine, there would be a nasty situation next time there was a security issue in it and the millions of installs were unmaintained.
Also without paid developers maintaining Docker Engine, there would be a nasty situation next time there was a security issue in it and the millions of installs were unmaintained.
That’s not really relevant, the discussion is about Docker for Desktop. But your still benefit from their brand and marketing and development efforts, as the rest of the ecosystem.
Do you mean you just meant Docker Desktop users when you said we all?
The ecosystem doesn't depend on Docker Inc now. And how do I benefit from the brand?
The ecosystem doesn't depend on Docker Inc now. And how do I benefit from the brand?
You benefit from the brand because you can point to the success of Docker instead of having to argue with other engineers that containerization is a good approach to development/deployment.
I never had to do that. I had to convince people Docker isn't the right tool for every job though.
If Docker Desktop seemed like it was a great product I would be happy to pay money for it. But I've been using it for years and it still doesn't feel like Docker gets what I want from it, and I'm not sure I see the thing evolving to be what I want.
I want something a lot more like minikube or preferably buildah/podman. So this is a natural moment to ask if I can get the thing that I really want and incidentally avoid spending $1000/year in licensing which is not nothing.
I want something a lot more like minikube or preferably buildah/podman. So this is a natural moment to ask if I can get the thing that I really want and incidentally avoid spending $1000/year in licensing which is not nothing.
The license fee doesn't come out of your pocket though? It's purchased by your company. And that too only for businesses large enough to qualify for that tier.
> I personally find it quite sad to see reactions on HN regarding the introduction of Docker Desktop subscription model
Let me tell you what the problem is. This is the Darth Vader business model: "I have altered the deal, pray that I don't alter it further".
The reactions didn't start today.
First, features that could decrease their lockin tend to linger in limbo forever. For example, the ability to have mirrors. This works, but _only for dockerhub_. Isn't that odd? There are even pull requests proposed ( * )
https://github.com/moby/moby/issues/18818
Then there were the Dockerhub changes. Those are understandable, it must be a heavy money sink to maintain that service. Want to keep using that registry? Pay them. This is a fine arrangement (but note that dockerhub has special status, as you can use it without specifying the registry, and it can be used a a mirror). Still ok though.
More recently they changed Docker Desktop to not allow skipping updates if you are not paying them. That was the strangest "feature" ever. Don't want to support? Say that's the last supported "free" version and stop providing updates after a certain date. But this "you can only choose NOT to update if you are pro" was weird.
And then there's this.
They have been trying and failing to extract a working business model out of their technology. So instead of trying to offer something that would entice people to pay, they have started to cripple their product for the ones who don't pay, just to get back to the same feature level they had before.
Can they do that? Of course. What else will they decide to do in the future though?
( * ) Maybe this would be a Docker Pro/Team/Enterprise/whatever feature? Ok cool. This would make my life easier to try to pitch buying it. Mirrors would improve stability. Maybe some fancy local caching for K8s clusters so they would avoid pulls if another machine has pulled an image already? Give us something that will save time or money or improve stability and I can pitch to management. Right now? I see no reason to pitch pro/team/business as most of their stuff we don't care about. And maybe don't conflate Docker, the software, with DockerHub?
Let me tell you what the problem is. This is the Darth Vader business model: "I have altered the deal, pray that I don't alter it further".
The reactions didn't start today.
First, features that could decrease their lockin tend to linger in limbo forever. For example, the ability to have mirrors. This works, but _only for dockerhub_. Isn't that odd? There are even pull requests proposed ( * )
https://github.com/moby/moby/issues/18818
Then there were the Dockerhub changes. Those are understandable, it must be a heavy money sink to maintain that service. Want to keep using that registry? Pay them. This is a fine arrangement (but note that dockerhub has special status, as you can use it without specifying the registry, and it can be used a a mirror). Still ok though.
More recently they changed Docker Desktop to not allow skipping updates if you are not paying them. That was the strangest "feature" ever. Don't want to support? Say that's the last supported "free" version and stop providing updates after a certain date. But this "you can only choose NOT to update if you are pro" was weird.
And then there's this.
They have been trying and failing to extract a working business model out of their technology. So instead of trying to offer something that would entice people to pay, they have started to cripple their product for the ones who don't pay, just to get back to the same feature level they had before.
Can they do that? Of course. What else will they decide to do in the future though?
( * ) Maybe this would be a Docker Pro/Team/Enterprise/whatever feature? Ok cool. This would make my life easier to try to pitch buying it. Mirrors would improve stability. Maybe some fancy local caching for K8s clusters so they would avoid pulls if another machine has pulled an image already? Give us something that will save time or money or improve stability and I can pitch to management. Right now? I see no reason to pitch pro/team/business as most of their stuff we don't care about. And maybe don't conflate Docker, the software, with DockerHub?
> More recently they changed Docker Desktop to not allow skipping updates if you are not paying them.
More recently than that, they changed it back to allow skipping the updates for free after all.
> So instead of trying to offer something that would entice people to pay,
Like a convenient desktop-based virtualization layer that allows running Docker containers on Mac and Windows?
> they have started to cripple their product for the ones who don't pay
You mean like how Linux software doesn't run on Windows and Mac natively? Weird.
More recently than that, they changed it back to allow skipping the updates for free after all.
> So instead of trying to offer something that would entice people to pay,
Like a convenient desktop-based virtualization layer that allows running Docker containers on Mac and Windows?
> they have started to cripple their product for the ones who don't pay
You mean like how Linux software doesn't run on Windows and Mac natively? Weird.
I haven’t read all the replies so someone else may have talked about this, however for enterprises it’s not the cost, so I certainly agree with you. Enterprises pay large amounts for services (ie Slack, etc) so the number of employees using docker in a corporation isn’t overall large enough that these changes would cause a blip on a finance statement.
That being said, while I’m not a first person knowledge on the reasons, the company I work for would not accept the licensing terms. What exactly the issue is, I don’t know, but I know a lot of effort has gone into prepping to mitigate this change and move the company away from Docker as a solution.
In the end, I’m guessing the biggest misstep here is the terms included in the new agreements, not the price.
That being said, while I’m not a first person knowledge on the reasons, the company I work for would not accept the licensing terms. What exactly the issue is, I don’t know, but I know a lot of effort has gone into prepping to mitigate this change and move the company away from Docker as a solution.
In the end, I’m guessing the biggest misstep here is the terms included in the new agreements, not the price.
Nothing mentioned here is actually an alternative for Docker Desktop. The article is very k8s focused, which is really just a feature that was added to Docker Desktop.
Agreed. I want a .app file for macOS that does everything Docker Desktop does, without the bloat.
Apps on Mac OS X are bundles, they're actually folders. This is something from the NeXTSTEP era that still persists in Mac OS X.
update:
"To everyone in the NeXTSTEP community (and it is a community) but also to @mattl I apologize for saying Mac OS X apps are files not folders."
"To everyone in the NeXTSTEP community (and it is a community) but also to @mattl I apologize for saying Mac OS X apps are files not folders."
> Agreed. I want a .app file for macOS that does everything Docker Desktop does, without the bloat.
Everything Docker Desktop does, without the bloat of the Desktop app ;)
Everything Docker Desktop does, without the bloat of the Desktop app ;)
I think that, in this case, "without the bloat" is not a very meaningful ask.
Most of the size of the app bundle is the image for the virtual machine it uses to host Docker. By comparison, the GUI bits are quite small.
Most of the size of the app bundle is the image for the virtual machine it uses to host Docker. By comparison, the GUI bits are quite small.
Minikube was initially based on docker-machine. It’s the closest alternative to having just Docker on macOS or Windows
You can't just have Docker on macOS or Windows though. There has to be an underlying VM, which Docker Desktop hides the details of.
Could you explain what Minikube brings, if you don't need Kubernetes, beyond setting up up docker-machine and virtualbox with something like this? https://apple.stackexchange.com/questions/373888/how-do-i-st...
I'd love a maintained, packaged solution, but it looks to me that I still have some configuration to do with minikube to set up a virutalization driver etc..?
I'd love a maintained, packaged solution, but it looks to me that I still have some configuration to do with minikube to set up a virutalization driver etc..?
I don’t want any kubernetes, though. I just want a VM (or similar) with a Docker in it, that’s simple enough for me to easily set up for my whole company with minimal scripting, and requires zero hand holding for continued support from me.
> I just want a VM (or similar)
Especially something like WSL2, which Docker Desktop for Windows uses in the latest releases. I know that is a VM (or similar) but the way it uses memory on demand, rather than reserving a huge chunk of your memory up front, makes a huge difference from a typical VM experience.
Especially something like WSL2, which Docker Desktop for Windows uses in the latest releases. I know that is a VM (or similar) but the way it uses memory on demand, rather than reserving a huge chunk of your memory up front, makes a huge difference from a typical VM experience.
VM tools have allowed this sort of RAM management for years.
That's unhelpfully dismissive. It's not how VirtualBox (with guest additions) or HyperV seem to work in the default configuration, so it's not trivial to do. Could you explain how to get this to work on Windows? What virtualisation software would you suggest? (And can it nest in Hyper-V?)
LXD/LXC. It can run Docker containers inside LXC containers, and it also supports clustering.
Just note that if you run ZFS, it's difficult because overlay2 doesn't work, AUFS is deprecated, and ZFS nesting is not supported.
It will fallback to VFS which is very slow.
It will fallback to VFS which is very slow.
[deleted]
Sounds like you're getting a lot of value from Docker Desktop, which does exactly that.
For those interested, there is Rancher Desktop[1]. It's an open source desktop app for K8s and containers. Works on Mac (Intel) and Windows. Apple Silicon and Linux Desktop support are both planned.
[1] https://rancherdesktop.io
Disclosure, I work on Rancher Desktop.
[1] https://rancherdesktop.io
Disclosure, I work on Rancher Desktop.
will it allow me to continue to run docker commands in the macos command line as usual? I don't want to go back and update all my preexisting scripts.
I tried running Kubernetes on my MacBook Pro, and it was just too resource-hungry — Kubernetes relies on a lot of polling, and it was constantly consuming about half a core. (I tried out both Minikube and Kind.) Does Rancher strip down Kubernetes to make it less resource-hungry and more friendly to individual developer machines?
Rancher Desktop uses k3s[1] which is a distro of Kubernetes designed for light weight environments. I run is on a fairly new MBP and a 7 year old MBP without an issue. I also run it on a 9 year old server with low resource usage.
While Kubernetes is present we want those components to use the fewest resources they need to.
On Mac, all of this runs in a VM and you can control the resources given to the VM.
[1] https://k3s.io/
While Kubernetes is present we want those components to use the fewest resources they need to.
On Mac, all of this runs in a VM and you can control the resources given to the VM.
[1] https://k3s.io/
The article is wrong....
> microk8s – a Snap distribution of Kubernetes. Only for Linux. Not sure why you would use it. Minikube has been far more battle-tested and is multi-platform, and doesn't require lock-in to a pseudo-package manager.
microk8s is available on macos, and works well from my limited testing of it
https://microk8s.io/
> microk8s – a Snap distribution of Kubernetes. Only for Linux. Not sure why you would use it. Minikube has been far more battle-tested and is multi-platform, and doesn't require lock-in to a pseudo-package manager.
microk8s is available on macos, and works well from my limited testing of it
https://microk8s.io/
I'd say the main argument for using microk8s over minikube is that Canonical supports it, assuming that's a relevant concern.
The issue for both microk8s and minikube is how to actually build the containers in the first place. With Docker Desktop or the Docker Engine on Linux, you can use "docker build" to build them. Without that, you need to install a separate tool to do the build (buildah/podman/generating tarballs by hand?) and then push it into a suitable registry or import it into Kubernetes.
The issue for both microk8s and minikube is how to actually build the containers in the first place. With Docker Desktop or the Docker Engine on Linux, you can use "docker build" to build them. Without that, you need to install a separate tool to do the build (buildah/podman/generating tarballs by hand?) and then push it into a suitable registry or import it into Kubernetes.
The author doesn't point this out well, but Minikube allows you to pretty easily expose a remote Docker host to be used for `docker build` and other Docker API commands. The command is `minikube docker-env`, which defines env vars that point the `docker` CLI client at Minikube's Docker API.
minikube now includes a command called "minikube image build", which builds the images for your Kubernetes cluster - for any container runtime, including docker - but also containerd
It requires users to install multi pass. You can run any of these tools in a virtual machine
How would I use Minikube to replace Docker Desktop if I don't want to use (or learn anything in depth) about Kubernetes? Like in the case where we just want to build images locally, optionally send to a docker registry, and use docker commands to run the docker containers?
Assuming you've installed Minikube and separately downloaded the Docker CLI client, you start up Minikube, set up the Docker environment using `minikube docker-env`, and run `docker` commands as usual.
This configures the Docker client to run against a "remote host", it does have some notable limitations. The `--publish` and `--volume` arguments don't work the same way, for instance.
This configures the Docker client to run against a "remote host", it does have some notable limitations. The `--publish` and `--volume` arguments don't work the same way, for instance.
Would love to know this as well! I never use the GUI of Docker Desktop, I just need the docker and docker-compose commands on the command line (on macOS).
I found (but not yet tried) these instructions on how to set up minikube as a drop-in replacement for docker desktop on mac: https://gist.github.com/protosam/11800faea25a3f89af9ece4f11c...
I’ve see no mention of dinghy (https://github.com/codekitchen/dinghy), which is what I used to roll before Docker for Mac really got up and running. I pulled it up yesterday and everything still works.
For anyone who is interested in a Docker Desktop alternative but without the k8 overhead, there’s a head start here just waiting to be picked up and revitalized.
For anyone who is interested in a Docker Desktop alternative but without the k8 overhead, there’s a head start here just waiting to be picked up and revitalized.
I've uninstalled Docker Desktop and installed podman in WSL2. So far I haven't had a problem.
Granted not everyone can do this if they have a dependency on the Docker ecosystem, but as someone who just used Docker desktop to run and build containers on the cli or via Ansible, podman is nearly a drop in replacement. As a bonus, theres no docker bridge IP conflict I need to worry about.
Edit: Alternatively, this also looks comprehensive: https://dev.to/bowmanjd/install-docker-on-windows-wsl-withou...
Granted not everyone can do this if they have a dependency on the Docker ecosystem, but as someone who just used Docker desktop to run and build containers on the cli or via Ansible, podman is nearly a drop in replacement. As a bonus, theres no docker bridge IP conflict I need to worry about.
Edit: Alternatively, this also looks comprehensive: https://dev.to/bowmanjd/install-docker-on-windows-wsl-withou...
Can you mount folders from the Windows host, or do you keep all your files in the WSL2 VM?
WSL2 can automount the Windows host in to the folder of your choosing. In my case its /mnt/c for the C:\. I often cross the filesystem boundary.
Going the other way, WSL exposes a SMB share so you can browse the Linux filesystem. This would be via //wsl$
Going the other way, WSL exposes a SMB share so you can browse the Linux filesystem. This would be via //wsl$
"Minikube is the officially supported way to run Kubernetes locally on macOS, Windows, or Linux. Furthermore, it is the only tool that is a drop-in replacement for Docker Desktop."
Huh, I hadn't realised that Minikube was available on Windows!
I use Docker Desktop on Windows, to make it easy to run Docker, Docker Compose, and Docker Swarm.
Does Minikube support these things, or only Kubernetes? If it's the latter, then of course it's not a drop/in replacement for Docker Desktop.
Huh, I hadn't realised that Minikube was available on Windows!
I use Docker Desktop on Windows, to make it easy to run Docker, Docker Compose, and Docker Swarm.
Does Minikube support these things, or only Kubernetes? If it's the latter, then of course it's not a drop/in replacement for Docker Desktop.
It exposes the Docker socket so you can use the docker client with it. That’s the recommended configuration anyways.
Is there any special configuration required for this? I.e. if I install minikube on MacOS, and download the docker CLI binary separately, will the docker binary just find /var/run/docker.sock and work automatically?
There is special setup required. The docker daemon won't be running on /var/run/docker.sock, needs to point to a network port where the remote host is exposed (ex: tcp:///172.21.108.0:2376).
Aside from starting the Kubernetes cluster, you need to run `eval $(minikube docker-env)` which sets up the environment variables like DOCKER_HOST to point the client at the remote host.
Aside from starting the Kubernetes cluster, you need to run `eval $(minikube docker-env)` which sets up the environment variables like DOCKER_HOST to point the client at the remote host.
I feel like we need an update of that Jamie Zawinski adage:
> Some people, when confronted with a problem, think "I know, I'll use kubernetes." Now they have two problems.
> Some people, when confronted with a problem, think "I know, I'll use kubernetes." Now they have two problems.
Careful not to conflate docker and K8s.
Someone should tell this to the author of the posted article!
Now they have N problems, and with just the right yaml...
Too much yaml? No problem, let’s generate manifests via Helm or jsonnet! Glad I solved your N problems! Of course keep in mind you now have to deal with NM issues :)
Love it. Always thought "Docker" was precisely the sort of thing that was destined to be a great and useful tool and a terrible kabillion dollar business.
The best revenue stream available to Docker was the numerous, generous buyout offers they had in the early days.
Did they? Like Oracle or Microsoft or something? I could see that.
It's the kind of thing that was a really killer way of bringing a half dozen open technologies into one easy-to-use tool, and despite the general simplicity of it, there wasn't much reason for quite a while to try to build anything better. Not that it wouldn't have been pretty easy to do, but if you did, most people would have said "but why?"
And now Docker, Inc. has gone on to answer the "why" for us.
And now Docker, Inc. has gone on to answer the "why" for us.
The article doesn't mention k3d (https://k3d.io/) which is a variant of k3s that runs in docker (rather than a VM) - very nice for k8s dev/test on developer workstations.
It integrates very nicely with https://tilt.dev/ also (another very useful tool for k8s related dev/test).
It integrates very nicely with https://tilt.dev/ also (another very useful tool for k8s related dev/test).
I believe the point of this article was to point out alternatives to Docker Desktop -- that is, Docker solutions that run on Windows and Mac hosts. The point wasn't to highlight alternative k8s distributions.
Author here. Tilt is great.
After minikube I wrote skaffold, which is a closer alternative to docker compose for Kubernetes with file watching and automated rebuilds and syncs.
https://skaffold.dev
After minikube I wrote skaffold, which is a closer alternative to docker compose for Kubernetes with file watching and automated rebuilds and syncs.
https://skaffold.dev
There's also Kind (Kubernetes in Docker) which accomplishes the same thing using upstream Kubernetes.
https://kind.sigs.k8s.io/
https://kind.sigs.k8s.io/
I wrote an installer that sets up a VirtualBox VM, installs docker in it and sets everything up with a single command. It has a few drawbacks but might be good enough for a lot of use cases: https://github.com/dziemba/mobymac
We used to do similar things with Vagrant
This is essentially what minikube does with the virtual box driver
I did an (admittedly quick) evaluation yesterday, and came away with the impression that migrating away from Docker over this would be penny wise and pound foolish.
There are other options that have a lower sticker price. But Docker Desktop's price isn't exactly high, and we've already got a lot of investment in Docker, knowledge about Docker, and related infrastructure such as testcontainers. So, after factoring in that we are still a company and do have to pay developers for their time, I concluded that, big picture, just giving them some money is the vastly less expensive option.
There are other options that have a lower sticker price. But Docker Desktop's price isn't exactly high, and we've already got a lot of investment in Docker, knowledge about Docker, and related infrastructure such as testcontainers. So, after factoring in that we are still a company and do have to pay developers for their time, I concluded that, big picture, just giving them some money is the vastly less expensive option.
This article should do a better job of explaining how Minikube is a "drop-in replacement for Docker Desktop". After installing Minikube, you won't just be able to run `docker` commands (`docker build`, `docker run`, etc.) on the terminal like you would after installing Docker Desktop.
You need to download the Docker client somewhere, need to configure this client to point to Minikube's remote host (`minikube docker-env` helps here), and some Docker commands won't work the same (--publish, --volume).
You need to download the Docker client somewhere, need to configure this client to point to Minikube's remote host (`minikube docker-env` helps here), and some Docker commands won't work the same (--publish, --volume).
Minikube is more similar to Docker Toolbox, which is not too surprising - considering they are built on the same Docker Machine.
Which Docker Inc. doesn't want to support anymore, saying that it was replaced with Docker Desktop and is now deprecated (since 2019).
Which Docker Inc. doesn't want to support anymore, saying that it was replaced with Docker Desktop and is now deprecated (since 2019).
Lima is also a solid alternative for macOS users. https://github.com/lima-vm/lima It runs containerd+nerdctl but I've heard it can also be set up to run Moby engine (docker). https://twitter.com/_AkihiroSuda_/status/1432906244860223493
The article completely misses the point. And this at the end:
> In closing, I think that the outrage over Docker's decision is far overblown. If you're an enterprise using Docker Desktop at scale, then you should be paying for support.
Sure. But Docker doesn’t want the enterprises to pay for “support”. They are turning something what not many people know how to viably and reliably replace into a paid product. The enterprises will essentially just have to “suck it up”.
This rapid decision about the Docker Desktop makes me think what is Docker the company going to do about Linux? Start charging for compose? swarm? The realistic goal must surely be monetisation on Linux, not macOS or Windows…
> In closing, I think that the outrage over Docker's decision is far overblown. If you're an enterprise using Docker Desktop at scale, then you should be paying for support.
Sure. But Docker doesn’t want the enterprises to pay for “support”. They are turning something what not many people know how to viably and reliably replace into a paid product. The enterprises will essentially just have to “suck it up”.
This rapid decision about the Docker Desktop makes me think what is Docker the company going to do about Linux? Start charging for compose? swarm? The realistic goal must surely be monetisation on Linux, not macOS or Windows…
Perhaps I have misunderstood something, but the Docker engine remains free and open source. What annoys me is that they treat Windows & macOS users differently than Linux users. Linux Desktop users this doesn't impact at all. I have never used the Docker Desktop application. But for me as macOS user Docker Desktop was the only way to run the Docker engine native (more or less, I think they use HyperKit under the hood) on my host system. Is there any alternative to run just the Docker engine on macOS just like Docker Desktop does? I don't want any Kubernetes on my Laptop. All I need is the Docker engine and the Docker CLI.
Docker is essentially a wrapper for containerization tech that is native to Linux only (cgroups etc.). So no, there's no way to just run the engine directly on other OSs. Docker Desktop takes care of the dirty details of virtualizing a Linux layer on Mac and Windows so the engine can run there. And they want to charge larger companies for it. Which seems very reasonable to me.
Is there a Docker Desktop for Linux? I don't see one here https://www.docker.com/products/docker-desktop (the Linux link takes you to Docker Engine).
The article presents "Docker Desktop Alternatives", then says "Minikube requires a VM. False" but it looks like on the platforms being compared here (macOS and Windows, since Docker Desktop is only available there) it does use a VM.
Did I get this wrong?
The article presents "Docker Desktop Alternatives", then says "Minikube requires a VM. False" but it looks like on the platforms being compared here (macOS and Windows, since Docker Desktop is only available there) it does use a VM.
Did I get this wrong?
I think the author was speaking generally about Minikube, not specifically as a Docker Desktop replacement here. Minikube can also be installed on Linux and doesn't require a VM in that environment. On Mac and Windows, it does of course require a VM, just as Docker does.
No, not wrong. Any non-Linux system that runs a Linux container will need to run a Linux kernel for that container. This is most often done with a VM even if that VM is obfuscated behind an application like Docker Desktop. This is why WSL 1 is often not supported by such systems even through you can run an "Ubuntu" application within WSL 1.
https://docs.microsoft.com/en-us/windows/wsl/compare-version...
https://docs.microsoft.com/en-us/windows/wsl/compare-version...
> Any non-Linux system that runs a Linux container will need to run a Linux kernel for that container.
Well, actually...
WSL 1, Illumos/SmartOS/OmniOS's LX-branded zones [1], and FreeBSD's Linux Jails [2] all work without a Linux kernel by translating syscalls.
This is somewhat analogous to how Wine can run Windows programs without a Windows kernel.
Last time I was paying attention to it, Joyent's Triton product provided a Docker API-compatible interface to run Docker containers on their SmartOS-based servers. Looks like that may still be around.[3]
Well, actually...
WSL 1, Illumos/SmartOS/OmniOS's LX-branded zones [1], and FreeBSD's Linux Jails [2] all work without a Linux kernel by translating syscalls.
This is somewhat analogous to how Wine can run Windows programs without a Windows kernel.
Last time I was paying attention to it, Joyent's Triton product provided a Docker API-compatible interface to run Docker containers on their SmartOS-based servers. Looks like that may still be around.[3]
1. https://wiki.smartos.org/lx-branded-zones/
2. https://wiki.freebsd.org/Linuxulator
3. https://www.joyent.com/triton/computeThank you for the "well actually." I generally feel discomfort at blanket statements and often hedge things a bit. This often makes sentences longer and harder to read. This "well actually" did a great job of outlining the corner cases where syscall translation "works," and there aren't many. I'm glad I wasn't totally deluded.
"kind, microk8s, or k3s are replacements for Docker Desktop. False. Minikube is the only drop-in replacement. The other tools require a Linux distribution, which makes them a non-starter on macOS or Windows."
False, kind can run on top of Docker Desktop on Mac, it does not require Linux exclusively.
False, kind can run on top of Docker Desktop on Mac, it does not require Linux exclusively.
As an overview of Docker Desktop alternatives, running on Docker Desktop makes it not an alternative. Your comment seems to have missed the point of the article.
Such an effort to let these 10mln+ enterprise save money, i wish there was no free (as in beer) software
Fwiw, I switched to a docker-machine based deployment with vmware.
https://gist.github.com/visualphoenix/1bfa6f05289902bf2858bc...
https://gist.github.com/visualphoenix/1bfa6f05289902bf2858bc...
I don’t see any mention of rancher desktop which is a drop in replacement, fully open alternative. It’s not feature complete but works quite well.
I’d hate to contradict you but Minikube does indeed require a Linux distribution on Windows- it installs as a VM in Hyper-V.
if the author is reading this, can you re-evaluate from a wsl2 standpoint ?
Basically installing docker desktop gets you seamless docker working on the wsl2 commandline - which is basically a linux experience at minimal performance hit. far far better than any VM.
Basically installing docker desktop gets you seamless docker working on the wsl2 commandline - which is basically a linux experience at minimal performance hit. far far better than any VM.
On WSL2 you can run the Docker from Ubuntu/RedHat/Upstream locally and not worry about Docker Desktop. As a bonus, you get a better version of Docker.
The docker daemon running in WSL2 is completely unmodified from the upstream source, and is in fact byte for byte identical with the official docker for Linux package binaries. So if you are getting a "better" version, it is by way of distro specific patches, or being able to run a marginally newer release than has been included in docker desktop yet.
However docker desktop has done a lot of tricks to enable you to run docker containsers from two or more different WSL2 distros seamlessly, as well as managing them from the windows command prompt. You can have a container started from windows with a windows bind mount, alongside a container from ubuntu with an ubuntu bind mount, and a container from fedora with a fedora bind mount all connected to the same docker network, since they are all running on the same daemon.
Out of curiosity, I partially reverse engineered what all they had done here, and it is a heck of a lot more involved then you expect. There is an awful lot of subtle things going on to help make things just work they way one would expect them to even in advanced scenarios like those. And I'm sure there is a lot more going on, as there was plenty I saw hints about but did not try to reverse engineer.
Admittedly I'm not a fan of this new docker desktop licensing change, But I think people underestimate the amount of work Docker Inc has done to make docker desktop work well.
However docker desktop has done a lot of tricks to enable you to run docker containsers from two or more different WSL2 distros seamlessly, as well as managing them from the windows command prompt. You can have a container started from windows with a windows bind mount, alongside a container from ubuntu with an ubuntu bind mount, and a container from fedora with a fedora bind mount all connected to the same docker network, since they are all running on the same daemon.
Out of curiosity, I partially reverse engineered what all they had done here, and it is a heck of a lot more involved then you expect. There is an awful lot of subtle things going on to help make things just work they way one would expect them to even in advanced scenarios like those. And I'm sure there is a lot more going on, as there was plenty I saw hints about but did not try to reverse engineer.
Admittedly I'm not a fan of this new docker desktop licensing change, But I think people underestimate the amount of work Docker Inc has done to make docker desktop work well.
So ultimately - what do u recommend ? cos i couldnt make cmdline docker work on wsl2 Ubuntu.
Is Docker Desktop the only way out ?
Is Docker Desktop the only way out ?
Struggle to imagine why you'd want any of that Docker Desktop stuff.
Docker Desktop provides an easy way to run `docker` commands from a non-Linux host, taking care of the VM management under the covers. It simplifies a lot of concerns so Docker "just works" on a non-Linux host.
Do you work with everything (source code, command line etc) in WSL2, or do you keep it on the Windows host and mount folders into containers when needed?
i WANTED to keep it on the windows host..but the performance hit is too great. So I keep everything in wsl2.
I tried it as a test - im a die hard Fedora user for 20 years now. I have found it very pleasant ..especially on Windows 11 (which surprisingly seems to be inspired by Gnome)
I tried it as a test - im a die hard Fedora user for 20 years now. I have found it very pleasant ..especially on Windows 11 (which surprisingly seems to be inspired by Gnome)
[deleted]
Poor users of Bill Gates OS.
[deleted]
It's okay. We can just install WSL2 and the free bit of Docker works as if it were running on Linux.
Yea, I have docker desktop installed, but I can't remember the last time I've used it. I've only used docker inside of wsl2.
Yeah, unless you get the 0x80370102 error when running WSL2 containers. I wasn't able to make any progress at all on my employer's Windows workstation with Docker Desktop until the Windows 10 20H2 update fixed it. And now all of that's in limbo while management decides if jumping through procurement hoops for Docker Desktop Business subscription will be worth it for them.
exactly as well, in fact:)
Companies paying for developer tooling is good for the ecosystem.