They default to docker compatibility, so if you specify 'busybox' it will pull your default registry, which defaults to dockerhub. If you specify 'k8s.gcr.io/etcd-amd64', then it will try to pull from google cloud registry.
You can redirect such urls to a different registry if you prefer, by using the containerd mirrors configuration.
Really, there is none. After reading through so many of these types of threads, I'm convinced there is no sustainable business model for open source infrastructure.
The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.
This seems at odds with the multiple open source kubernetes distributions on the market. The problem isn't that Docker is open source infrastructure, the issue was that it remained too low-level as a container daemon, didn't manage to build a large community around swarm, and then were really late to embrace kubernetes.
There easily could have been an alternate history where Docker Inc was the first one out of the gate with an enterprise kubernetes distribution, been a positive part of the community, and been a success.
> I'm convinced there is no sustainable business model for open source infrastructure
From my personal point of view, the most sustainable way of funding development of free software is through businesses that utilize that software, but whose main business is not that software. The value proposition for the business to open source their software is mainly in getting improvements from outside, and to ensure better integration with other free software. But the main reason to build software should be selfish in the sense that you can directly use it yourself, and not the idea that you could somehow sell the software in some way or form.
Docker, Inc. has the opportunity to be the NPM, Inc. for container images. How much did NPM sell to GitHub for?
Less concretely, is there a business model for a low-level piece of infrastructure like Docker? Is there a business model for ncurses or readline or df or ls?
"Real world" infrastructure is typically high capex, low margin. How many VC-funded startups build bridges or tunnels? SpaceX is pivoting to Starlink to find good margins and escape the fate of being a trucking company to space.
I don’t think there is anything wrong with their margins - their costs are way below anyone else’s. I think the rationale behind Starlink is to soak up their excess capacity while the market demand for space access grows in response to their increasingly low prices.
But I agree that in general, “real world” infrastructure is low margin, I think that’s because it’s completely undifferentiated and has become a commodity
There is an interesting talk [0] by Philipp Krenn (Elastic) on
“Open Source as a Business. Strategy, struggle, success”. This talk takes the perspective of Elastic, the company behind the open source products Elasticsearch, Kibana, Beats, and Logstash, which makes its money with support, the commercial extensions, and cloud offerings. But we are also taking a look at how others are approaching this challenge, what worked, and what failed.
My own opinion: I think there is as a marketplace. Years ago when I started browserless.io, I wanted to find a way to sell access to the core image of ours. Docker kinda has/had a marketplace, where you can buy access to curated and secure images, but it didn’t get any support or news on it. Because of this we went the open-code route and just sold licenses. Too bad because I’d much rather have had a marketplace to do this instead.
OpenFaaS has been a struggle even since it was started, even with a large community and many commercial end-users, none pay for support, services or sponsor.
Most of the time saying that Open Source isn't sustainable results in some smarty dropping Elastic or some other massive VC-backed company in like GitLab. It's not helpful.
I suppose it's open core. Open Source is hard because you have to separate people from their money even though the code is "free." I'm not saying it's _the_ answer, but browserless.io isn't VC backed, and it certainly makes more money than most of the Patreon/sponsor models. I understand that it's not just a library, but a full-blown service, which makes it easier to market and sell.
Have you considered a hosted product? I have no idea what your audience is like, but that seems to be where we've had a lot of success. Happy to chat anytime as well: joel at browserless dot io.
It depends on what that infrastructure is. Docker owes its existence to the OS not providing an adequate interface to create lighter containers than 00's style virtual machines. They chose to be imported and used as part of the stack by kubernetes instead of offering a better solution, which was clearly where kubernetes was headed. This one is less of a model question, than a market position question.
Elastic, on the other hand, is a very specialized application and the main issue they've had is having to compete with cloud providers (MongoDB also shares this problem). It's a very different problem, and both companies (Elastic and Mongo) seem to be finding ways to compete and cooperate. Elastic on Amazon is a great gateway drug to Elasticco's offerings.
Can’t speak for the poster who wrote the parent post, but we’ve just evicted the AWS Elasticsearch stack from our platform. For something simple, it was a resource hog, configured badly out of the box, complex in all the wrong places, and limited in its offering and linkages to other AWS resources. Just my 2 cents of course.
Dev-tooling. I would have expected them to come up with something like https://www.testcontainers.org/ and sell enterprise/community licenses, just like they do with their cross platform clients. Enterprises need support, and by creating a rich suite of products that become essential to developers, they could have maybe really stuck (hard to predict what could happen).
Instead they tried really hard to make docker swarm a thing while kubernetes started taking off. To be sure, at the time, it wasn't clear which platform would succeed, and I remember that a certain OpenStack project tried to support both (like all OpenStack projects that try to be everything to everyone). Kubernetes has a lot of concepts that need to be learned, so the barrier to entry was much higher, and docker swarm seemed more straightforward.
All devs loved docker right away but in the early days I remember there being a lot of blogs about NOT running containers in production because of all the security issues. Kubernetes made that problem go away. It got adoption by different cloud providers which made it easy to deploy/use on their platform. That was maybe a tell: if devs loved docker so much and kubernetes was the tool that cloud providers supported, they could have focused on the former.
Private repo host...because whatever they charge, it is cheaper than using an FTE to maintain it internally unless you want a flaky internal SLA.
I use it as a private repo host. The cost is a no-brainer. We'd probably pay 2x or 3x more compared to the value we're getting. The independence from the Cloud services (ECR, ACR, GCR) makes it a better option. Also, for now, there isnt any funny-math on multi-factor egress costs -- which become tricky to compute in real life.
We use it for containers to be run on k8s. As long as there are not super-low latency requirements for startup, I'd prefer an independent single private repo over multiple in-zone repos.
I think what Heroku did right is really nail the Rails experience, and the Rails customer base. And then they expanded to multiple languages with the "Cedar" stack.
dotCloud tried to do every language from the get-go, and had a subpar experience for all of them, from what I understand.
The python/django experience on dotCloud was really rather nice, actually. Perhaps much of that sympathy was coming from people were comparing Rails/Heroku with Rails/dotCloud, where Heroku has a rather big head start, but Django/dotCloud was the first easy, pipelineable deployment experience I had ever found despite having already tried all the early competition.
It probably wouldn't have taken long for a Python-centric competitor to leapfrog them, but by the time they had, dotCloud was basically all in on the Docker experience, which was transformative.
Docker Inc's antagonistic attitude towards Red Hat and personal attacks on their engineers was the beginning of the end for them. The people who really headlined those attacks are now gone, but the damage was done. Docker made it clear from the beginning they had no desire to be part of a community and now the community is leaving them behind. Good riddance.
Every time there’s drama about Docker being mean, it’s almost always a Red Hat employee behind it... Like this article, and the OP blog post. Maybe just a coincidence.
That clearly there has been a conflict between Red Hat and Docker employees in the past, and that when Red Hat employees tell their version of the story which happens to make them look good and the opposite side look bad, one should take that narrative with a grain of salt. Especially when one side is 100x larger and more powerful than the other by any metric: number of people, revenue, marketing and PR budget.
Are we really supposed to believe uncritically that Red Hat, a publicly traded company with billions of revenue and an army of engineers at their command, are being bullied by a startup of what, a couple hundred people?
I’m sure the people at Docker did behave badly in some way to piss off people at Red Hat, but whenever I dig into the underlying facts, it’s always something silly and sometimes ridiculous. I’ve seen a talk by a Red Engineer dedicated entirely to the topic of how mean Docker maintainers were to him. The actual offense was 1) refusing to merge certain PRs Red Hat deemed important, 2) a tweet by an individual maintainer’s personal twitter account making fun of Red Hat for sending low-quality patches. That’s the kind of ridiculous petty food fights this whole “Docker vs the world” drama is built on. I mean, who cares?
TLDR: the real story is probably more complicated than “everything was great then Docker was mean and then they failed because they were mean, the end” and best told by a less biased source.
Yeah I followed Docker from the very beginning, and this was also what I remembered.
The biggest incident, if I remember well, was related to the layerfs stuff, which was supported by Ubuntu, but which RH refused to include. Instead they pretty arrogantly pushed to merge a PR which was breaking other stuff in Docker, and were pissed when the maintainers refused to. That whole thing obviously rubbed people working on Docker the wrong way, which was the beginning of the pretty sour relationship.
After that I don't think there was a lot of goodwill from Docker towards RH, probably causing a lot more issues..
Docker Inc put themselves in an impossible situation because they wanted Docker to be a standard and also be a massively profitable monopoly but they didn't have enough moat to pull it off. Red Hat and Google saw the monopolization coming and aggressively commoditized Docker for the good of the community but also for their own benefit.
I feel like I'm missing some key insight here. To me, the tl;dr of this post is: Kubernetes removed the need for Docker just to run container images in a k8s cluster, ergo, Docker is dead.
But Kubernetes is super complicated. The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkill.
Now, I'm no guru in this field at all. In fact, one thing I always liked about Docker is it made you feel able to atomically deploy software without having to become an expert at anything first. But what's the current "don't have to be an expert" way to ship software if Docker is, supposedly, dead? Do we all have to learn Kubernetes?
I've never used Swarm but I've been told that one thing it had going for this is that it allowed you to do smallish setups pretty easily. If that's true, then I'm sad it lost the popularity war.
Swarm was great. It takes literally 30 seconds to put together a cluster with a few nodes. (1 command per host.) The problem was that Docker Inc. tried to push people towards Docker EE (that had all kinds of extra functionality above pure Swarm), but that was super buggy.
Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert?
I mean, that was one of the key Docker promises, and they delivered to quite an extent.
You want helm or one of the many, many tools built on top of kubernetes to ease the deployment of applications. All of the same complexity of deploying services was there with docker, you were just insulated and hidden from it by some of its opinions. Whether you want to or not, if you want to manage costs and performance of your app you're going to need to learn (or pay people who have learned) about how to deploy and manage apps in production at scale.
From my experience kubernetes is quite complicated to manage (ie for the "infra team"), but not very complicated to use as a developer. You tell it which container you want it to run and how many copies and off it goes.
If you have an existing cluster somewhere (say a managed cluster from AWS or GCP) that you want to run your webapp on, just copy/paste a YAML from any of the hundreds of guides on the internet and off you go. The k8s docs themselves are also pretty thorough. Your app will run with automatic failover and rolling deploys and whatnot right out of the box.
Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert?
Yes absolutely, the YAML will just need to be updated for API keys or whatever.
Kubernetes is complicated to build a production grade cluster on bare metal but for getting started as a developer it’s no more complicated than Docker actually
This is super helpful, thanks. I always had the idea that I needed to grok all of Kube to get productive with it (and very much got that feeling last time I explored the docs). But knowing that I can ignore a lot of that if I use some kubernetes cloud service and just put my images up there, that's super nice. Thanks (also to some sibling comments of yours) for clearly drawing up the difference between those two things.
Yes, a simple workflow is running Minikube or K3s locally for testing and then pushing it out to a managed Kubernetes platform like DigitalOcean Kubernetes. This avoids having to know any of the underlying details of setting up the Kubernetes cluster. Everything you do in terms of interacting with the cluster on Minikube will be the same as on your production managed Kubernetes.
All you really need to learn is some basics around Kubernetes terminology, the kubectl command line utility, and then some of the YAML config syntax for setting up application deployments and probably an ingress into the cluster. You can also add helm into the mix if you'd like to take advantage of pre-built packages that you can install to your cluster. For example SSL certificate management or a webserver ingress like nginx-ingress.
I remember trying to set up k3s a few months ago and encountered a hard error that gave zero results when googling. I don't remember the error anymore. Was not impressed though and would not call it trivial to set up.
From my experience, it's getting easier to set up Kubernetes with things like OKD (open source OpenShift) or Rancher... but it'll still take you days or weeks (or months in my case). And the organisations that I've heard of in Norway that have actually had success have also had a team of devops people to both set it up and keep it running.
Yeah if you have experience with it you can set up OKD/OpenShift in a few days, but IME no K8s distros are truly "set it and forget it." Everyone needs a "platform" or "kubernetes" team. In a small company it doesn't have to an exclusively K8s team (the can have other responsibilities) but someone will need to watch over and maintain the cluster.
Anytime I hear people nuh-uhh someone saying "X is complicated", the difference is often someone having to deal with security and someone getting to deploy with more lax considerations.
I find quite cute that in 2020 people are still echoing this to the extent that now I have to answer questions like "explain what kubernetes is" during job interviews.
To me seems that a bigger group of people get jealous about a smaller group getting new tools. Then this "stuff x is complicated" propaganda is passed on through the industry like the plague.
k8s is complicated (have you seen the docs on node affinity and taints? come on). i've seen several cases where a group of k8s experts pitched the infra as easy to configure/maintain and 12 months later they're being crushed by the weight of all k8s abstractions.
i don't blame you. k8s is great job security ;) for now.
I think you've been using it long enough that you forgot how much of a hurdle learning an extremely high-surface-area piece of tech is. The individual abstractions may be simple once you understand them in hindsight, but making an application developer that normally does not work with cluster management learn 100 new abstractions is not "easy".
I'm a sysadmin and dev with 10+ years of experience, I've literally written my own cluster container management system, and I've spent probably a hundred hours learning and using kubernetes for months with dozens of services. After a few months I switched everything back to docker compose because it wasn't worth the complexity for our small sized company. k8s is not a magic bullet, it's an incredibly dense and nuanced piece of technology that is only the right solution for a certain class of problems.
Perhaps most things look hard until you understand them, but that doesn't make the learning curves the same. Having attempted to learn enough docker swarm and k8s to cover the same uses (standard "run a bunch of containers on a homogeneous group of servers to provide a webapp"), and sunk massively more time into k8s and still not figured out major sections of how it's supposed to work, I can assure you that k8s does in fact suck as a beginner, and dismissing valid criticism as propaganda is plain wrong.
For small-ish setups, Swarm is still great. The cost of abstraction, and cognitive load, that k8s brings is greatly played down during discussions, and I feel it's quite a dangerous game to be playing.
The overhead with Swarm though, is low, and I like it. Where possible though, I'd also recommend having a look at ECS Fargate. Make it someone else's problem.
I like the Fargate model. It's far lighter and easier to work with than EKS. I haven't tried GKE so I can't speak to that comparison.
All I've ever really wanted is: "take this container with this config and auto-scale it for me".
Of course it should also be run in a private network, have blue-green deploys, auto-restart containers on failure, have geographic redundancy, etc. etc. but I don't want to have to think about any of that.
Docker was always about making it easy for developers to build isolated applications. Kubernetes was about making it easy for cloud providers to support deploying these isolated applications in their systems. A lot of organizations tried to support docker swarm (or their own versions of an "ocean" of containers) but it was just too difficult, the products failed and/or were unreliable and docker didn't provide a toolkit to do this better. When they tried kubernetes, it worked (probably because kubernetes creators had experience from running an actual production system before viz. Borg).
So then cloud providers coalesced around the platform. People who learned the concepts found it easy to use and loved it and it fueled the adoption.
I still believe that despite all the hate that k8s gets on HN, its popular because it works and its users love it. There is very loud subset of users who makes their displeasure known very well but we have to look at concrete data on usage and the data points to k8s being a very popular platform for USERS.
> Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile.
Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive.
Docker is still the simplest way to install Elasticsearch, to make sure everyone on your team is using the same Java version, or run up a production equivalent environment on your laptop. Regardless of if you are on Linux, Mac or Windows.
I still love Docker and hope they end up finding a good business model so they can continue to live on.
Back in 2013 before I took a job at amazon but after working with a game dev for playstation I had 2 months off, playing with docker I realized how good it's be for crap like chroot jail dev or multi-project dev env isolation. There were big blockers for it being used this way then. I did some chatting with the docker team and we did push things a little in that direction. But the vision was still about running in prod.
To their credit the docker folks I talked with did listen and respond and move the needle (obviously) on it being a local dev tool, so I cheer them for that.
I use it all the time in my windows box for dev. Tho I do try and keep my software able to run on any os.
Not that poster, but I use Fedora in WSL2 and the Docker for Windows integration and things (and by things I mostly mean `docker-compose`) just...work.
They have some k8s stuff I've never looked at, too.
Take this post with a hint of bias as it's written by a Red Hat'er - if you ask an employee what the "next thing" is, I wouldn't be surprised to hear "podman" (which is an opinionated docker clone)
The number of Docker Desktop installations and the popularity of local Kubernetes tools (think KinD, k3d) show that "Docker got boring" which is an aspiration for infrastructure tooling.
Author here. I no longer work for Red Hat these last few years, and my words are strictly my own. I wanted to communicate what's happening now in the context of what I experienced from Docker's early days in the industry.
Podman would be next big thing if:
1. they make a package like docker ob mac where you dont have to fiddle with manually starting vms. An environment where using docker feels native
2. When they start the vm to run podman they will use qemu on arm to simulate an x86 machine and run x86 containers
The second one will be a huge step forward as docker will not be able to do this for a long time as they use the mac hypervisor which can‘t run x86 vms. Podman would enable again prod/dev comparability which may work for redhat to more people switching to podman even for their production systems.
The Podman team is working on it but it's not quite there yet. Podman now has an API so at a minimum the whole opaque VM thing should be usable here soon. podman-machine and boot2podman already work for some people, although they didn't work for me.
I have a dream of using a lightweight Fedora Core OS VM on Mac/Windows for running the containers with a podman-remote client seamlessly driving it from the Mac user space. Once podman-remote is working, that's my next plan ;-)
A self plug here, I'll be keeping an eye open for all of these things and will blog about once I get it reliably working. I'll be submitting it to the Red Hat developer blog but I cross publish everything I write to medium as well in case you want to look for it: https://freedomben.medium.com/ I'm also starting to tweet when I blog (I'm finally getting serious about it now haha) @Freedom_Ben on twitter.
A lot of people seem to think 'running under WSL2' is equivalent to 'works on Windows', but they're just not the same thing. That's like saying 'it runs in a VM on my Mac'.
Thanks for sharing because this is interesting to me. I would not have guessed that. When I use WSL2 it's mostly transparent to me so I don't think about the implementation.
Do you consider "Docker" to be "works on Windows?"
There’s no need for them to live on. There are open source alternatives that mimic Docker exactly. In fact on Fedora[1] the “docker” cli command is actually buildah and podman (you actually can’t install Docker on Fedora anymore - I genuinely haven’t noticed a difference). The commands are exactly the same right down to the command starting with the word “docker”.
I don’t wish them ill, but literally everything has been replicated. If they fail as a company it won’t matter to developers who don’t use their enterprise software.
I actually think the company isn’t long for this world. It wouldn’t surprise me if they got bought for a paltry sum in the next few years.
Their lasting legacy is that most software and people assume that a shortened container image points to docker.io.
buildah/podman/skopeo are nice tech. and all, but they don't exactly mimic the setup of Docker for Windows/Mac.
If for no other reason that, they don't do Windows containers :) I know of quite a few corps using Windows containers in prod. now, take up may have been slow, but it's happening.
Also Docker for Windows/Mac have an easier install/setup process than manually setting up VMs and installing tools on them.
I had had some pretty positive experience with docker-in-docker running in podman for ci/cd until podman v2 was released. Then I started getting a lot of weird crashes and segfaults and ditched podman.
Yes, you read it correctly, running privileged docker-in-docker containers with podman to spawn docker containers in dind containers. The good thing is that networking was handled flawlessly. And there were no conflicts between docker and podman
I'm aware of podman, which is more or less a drop-in replacement for Docker, but is there anything comparable to Docker Compose and Docker Swarm?
I use Docker Swarm (technically "Swarm Mode") in production, and I'm really happy with it - it's so easy to configure and operate, but I am worried that it will no longer be maintained at some point.
Maybe not, but considering how much they gave, I think we should want them to live on, and do what we can to help them. Do we really want to live in a world where a startup company makes as big an impact on the way we develop and deploy software as Docker did, only to have all possible business taken from it by bigger players?
I understand this sentiment, but a lot of the original team and the certainly the original founder aren’t even there anymore. Not to mention that a lot of Docker’s business missteps have been self inflicted wounds.
There have been lots of great technologies that haven’t directly made their creators rich, but their good legacy usually/eventually catches up with them.
So I agree with you about supporting good technology which you want to see survive.
I don't think the poster you're replying to was invoking a just world fallacy, however. I read it as saying that developers who build solid systems that people like tend to thrive, even if their business fails.
That appears to be true, and not because of karma, because top-tier developers are in very high demand. Demonstrating that you're one of those isn't the same thing as running a successful business.
Podman is not mature yet and it has many bugs. I am currently using it for a project, and lately I am starting to doubt it is prod ready. But it has some security options not available with docker. So Docker is still my first option.
Docker Desktop is the only non-hacky way to get a decent Docker (and k8s) setup for development purposes on macOS and Windows. Linux on the desktop never needed that, but those other two do.
Red Hat removed docker prematurely, Podman is not ready to replace docker for all production cases yet.
We have had to replace RHEL systems with Ubuntu to keep some of our applications running as they fail on Podman.
A major problem is also that podman-compose is far from feature parity with docker-compose.
> We have had to replace RHEL systems with Ubuntu to keep some of our applications running as they fail on Podman.
I replaced Centos8 with Amazon Linux 2 ("amazon linux extras" provides a working docker installation) for exactly the same reason. I like the idea of podman and buildah and I wish them well, but for the time being I can't afford to debug the missing pieces and subtle failures.
True but I would use pod yaml with podman. It’s not anywhere near being on par with Docker-compose but it’s the better tool because every pod can be used rootless.
A bigger issue is the fact that they were not able to become a unicorn despite having a tremendously popular product. It means there is no money in development tools innovation. This is not a good thing for the software community as it means all tooling innovation will only done and controlled by the FAANGs.
I don't think that's a good read on the situation. I think a better analysis is that there is no money being what amounts to a facade on top of an operating system/kernel capability. All the real novelty and challenge to containers is in the OS itself. Everything else is more or less ease of use, which is important but relatively easy to replicate. In the span of 5 years or so, Docker went from being critical glue code to cruft.
BSD jails weren't widely adopted because the BSDs themselves weren't widely adopted by the time the industry got to the point where something like Docker was increasingly seen as necessary. I remember being involved in one project that had to decide this exact question in the very early days of Docker - jails were much more stable back then, but customers wanted Linux containers, not "sufficiently Linux-like".
I work for Red Hat but I'm a long time fan and user of Docker.
I don't think that's what this means at all honestly. Docker (the company) made some poor decisions that led to their troubles. I'm not here to crap on docker, but they quit investing in and moving their tool forward because they were focused on the EE offering. This opened the door for "competitors" to do the things docker wasn't doing (daemonless, rootless, cgroups v2, just a few). They also did things that scared people, like the whole "moby" rename thing. It made people worried that (fairly or not) Docker the company didn't have the best intentions for the open source version. They had poor direction on product.
They would routinely refuse nice features that people wanted (many that included PRs) for things with terse, unkind "do not want" rejections, and then 6 months later they would end up adding it anyway. Some of these were suspected to be refused so as not to allow open source docker to compete with EE feature sets. docker-compose was the worst at this (To be fair I think it was mostly one very loud/very powerful person wrt docker-compose).
Docker started the race way ahead of everyone. To this day people still use the name "docker" to generically refer to containers.
Anyway, my point is not to crap on docker, just to say that in my opinion, in so many areas important to an open source leader, they made decisions that undermined their long term outlook.
- they stopped evolving the Dockerfile. Really this is the complexity killer that developers just "get".
(also they wouldn't have their entire API cloned if they were moving it forward)
- they subtly force everything through docker hub and conveniently forgot to do something like let people have a local repo. (redhat lets you define a local repo with --add-registry)
- telemetry. I went to install it on macos and it started collecting telemetry the moment I launched the installer.
Great points. I think they started requiring an email and sign up too for the Mac download, although if you had a deep link that would still work but if you didn't already have it you had to sign up.
Because the FOSS generation feels entitled to be paid while refusing to pay for tools, which leaves the typical enterprise customers as the only place one can make money with development tooling.
That's not true. As a FOSS lover, I pay for a lot of tools. Both development related and unrelated. Moreover, some of the tools that I pay extend on FOSS software (Tower, Viscosity, Permute) and some of are FOSS already (Cyberduck).
The thing is, as a person I don't want to feel ripped off. I don't subscribe to JetBrains since my work doesn't require these tools (also, I use Eclipse for 15+ years and it works well). The subscription culture allows developer to pump features indefinitely but, I can't subscribe to all tools that I like.
There are many services that I subscribe too (Dropbox, Spotify, Netflix, IFTTT premium, Evernote, etc.) but, they give me a service which touches my life everyday. I have no budget to subscribe to a tool to test for a year. It's not feasible. I need to eat.
So yes, I'd rather have a good FOSS tool which doesn't want $100+ from me every year and I'd rather patch it myself. But, if you provide me a good service which I can't replicate easily, or don't want to manage myself, I'd pay you good money. I'd be also very happy if the tool I'm paying is FOSS.
Also the biggest obstacle driving me away from paying is the tools are closed source and I'd be locked in if the tool/company lets out the magic smoke. All the services I pay are not locking me in. I can get my data out of them. So it's not always wanting to earn money for free.
I have no doubt about their quality and affordability. Also, the price goes down when you subscribe for a longer time.
I write C/C++ and Python mainly. Eclipse CDT and PyDev are very good. Since I'm using the platform for 15+ years, I've seen its bad days too. Except some edge cases, CDT is bulletproof and works very well. PyDev is also very smart and helps me the way I need.
Actually, Eclipse has the best and most sensible Git UI I've ever used. I also like Tower but, Eclipse both makes sense and helps a lot in the relevant places.
Eclipse CDT is very good? I think we have a very different definition of very good. Could write a long rant on everything that was broken in Eclipse for C and C++ development.
One question on eclipse. Did eclipse finally sort out git/svn support?
Here's an interesting tidbit of history for those who don't know. One of the main drivers for the decline of eclipse was the complete lack of support for source control, which is a pretty basic feature for an IDE.
You could try to get some plugins. There were 2 major plugins for SVN and neither worked half the time for no particular reasons. It was a complete shitshow. Don't even think of doing that in a company where HTTP access must go through a proxy.
Developers eventually gave up and moved to JetBrains IDE. Source control worked out of the box.
Eclipse CDT was really bad back in the day. Slow, crashing, not smart enough but, it's very good now from my point of view. It can satisfy my needs and, I'm happy with it.
Heck, I've developed my whole Ph.D. with it and it interfaced the tools that I need to use well, was stable and fast. When I pressed a shortcut, it did the thing I expected it to do. The whole experience was, well, uneventful.
I've used Subversive IIRC during my Master's and it was uneventful too. Didn't lose any data, the plugin didn't misbehave or had any problem with it. Was using Assembla's SVN + Redmine bundle as my remote repository.
The git support was similar. I just installed it and it worked. Still works. As I said before, they've nailed the best logical view for git IMHO. IIRC, now it comes bundled with the Eclipse.
They may have done some things wrong in the past but, it's a solid IDE and I like working with it. I don't think they deserve the strong words you choose, but to each his own.
Of course, your mileage, taste and views may vary.
I wonder if a timed open source license would work? One in which code/features were automatically scheduled by the license to revert to GPL/BSD/whatever at a point a year or three in the future?
I think that might sap some of the impetus to reinvent those features in a competing open source project (they can of course just copy them if they wait), and also might entice people to pay that wouldn't normally because they don't want to get on the paid product train. Users also get a known date a feature will be available, a real date, not a projected delivery date.
In a lot of ways it's what many companies that develop products do already to allow people to get familiar with their product (have an open source version with less features), but this allows them a better story, makes users feel more sure about what's going on, and if they release the code immediately but it's unusable for a period by other projects, that does make it harder for those projects to cleanly reimplement unless they're sure they haven't seen in (that might be a net negative for the public with a litigation happy company).
The hard part would be tracking the time, but git has ways to make that pretty simple.
A number of databases uses the Business Source License (and its variants, usually including a non-compete clause). It acts as an option which vests (switches to a non-copyleft libre license) after n months. There is also the Polyform project but adoption has been low and their licenses are extremely controversial and unpopular.
There's no money in backends unless you have a great enterprise sales team.
SAS, Matlab, Oracle, Arc, there's lots of really boring backend systems with plenty of FOSS alternatives but you need sales.
If the customer is the developer, then they might ask their manager for a text editor with a nice UI. If the customer is the whole enterprise, then someone needs to wine and dine the CEO to get that $10,000 per core contract signed.
This is a really interesting point. I work in backend enterprise software (as a consumer more than a provider).
Surely the critical success component at scale is more than just "wining and dining". I truly wonder how Oracle has managed to do it for all these years...
It is, but the syntax is uglier. Also imagine that you might want to do more than just RUN in a single layer. Maybe COPY some file into the container and then RUN something that uses it.
In the simple case, yes it is, but it scales poorly; consider ex. https://github.com/docker-library/postgres/blob/b9c080857b88... which is 112 lines run together like that to keep things in a single layer. This is pretty bad for readability. Also, as sibling comment notes, that only works for RUN commands, not other or mixed groups of commands.
I too have wanted a solution for the massive amount of layers that are generated just by doing normal things. When you reach a point where you're trying to be so clever just to avoid the creation of a useless layer, it's the tooling's fault, not yours.
You might investigate buildah. You can achieve precise control over layers. Also, buildah mount is awesome; direct access to a container file system from the host; COPY/ADD et al. are obviated.
Yeah we asked for transactions and they gave us this... thing.
It’s cute, and useful, but in the end it brings back the primary problem that Docker actually solves: absolutely getting all of the files your code needs to run into the package, and the right version.
Multistage builds require you to airlift files out of one image into another. Accurately. If cherry-picking is the best option on offer by docker, there are plenty of other tools that can do that.
Collapsing layers is about seeing that an image provides a set of services at point A, and another set at point B, and that nothing in between represents an interim state of any substantial value. For most images, this is one or two layers that relate to either the main payload, or one particularly volatile dependency.
The real purpose for multi-stage builds is for compiled languages.
If you have some service written in say C++/Java/C#/Go, then building it in one container (that has the build tools) and copying the build result to another that only has the stuff actually needed at runtime makes good sense. That is much easier and saner than trying to uninstall all the build time components after using them.
It is not like for desktop software we install the build tool, build, and then uninstall build tools. Instead we grab the relevant build outputs and package them into an archive or installer.
But as a solution for clearing out cruft like package manager caches, etc, yeah multi-stage build is not really optimal.
Being able to write the executed steps in a natural way, and then specify at the end to compare everything to come specified previous layer, and create a layer that just has the differences would be really useful.
They could even still cache the intermediate layers as part of the build caching process if they wanted, so long as they are not included in final image as pushed to a repository.
Docker does have a super cut down version of this with its experimental `--squash` option, but that only makes sure there is a single new layer for the output of the whole dockerfile run. You cannot use this if you for some reason want exactly 2 new layers. This limitation is probably acceptable in a lot of cases. However this option is not supported in the buildkit based backend yet.
I have used container based technology for about 20 years now, starting with Virtual Vault on HP-UX, and happen to know a couple of things about what containers are supposed to be.
> As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive.
Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Compose with Go to make it more consistent with their main CLI. Looks like full steam ahead to me rather than death.
It's really nice having the same Dockerfile + docker-compose.yml get used in dev + ci and prod. There's no surprises and no massive amount of complexity.
I second this, we've been running Docker Compose in production for years and love it. It's massively simplified our production environment, and for a company that only serves 100,000-1,000,000 monthly hits it's the perfect middle ground. We've tried k8s several times and have always ended up going back because we didn't need the complexity.
We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks because we don't need the complexity of swarm and v2.4 provides everything we need. Sometimes simple is best.
I personally use compose to manage services on my own laptop and homelab as well, it just has the massive advantage of being the greatest common denominator that everyone can pick up in a few days if they're familiar with basic container concepts.
Exactly this here as well. I have helped setup a few successful SMEs with Docker, Compose, and some CI/CD best practices. They are running 7-figure businesses on the backend.
>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks...
Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case.
Compose v2.4 was released long ago and abandoned by docker. Some features/workarounds that worked in that version were killed in the next versions. It seems to me that you're stuck on that old version unable to upgrade because of that?
IMO this is a perfect illustration of how Docker sucked in practice (both the product and the company), the industry naturally converged into trying to get rid of it because there was no other choice.
You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested).
Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it)
I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.
Problem being, "depends_on" was removed in version 3, with no replacement in sight.
I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall).
P.S. For readers who don't have context. Make a basic compose file with a webserver and a database. "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.
> "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.
Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control.
But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'ing into your main container to run tests or migrations).
For that I wrote a simple Bash script at https://github.com/nickjj/wait-until. IMO a problem like this can't really be solved at the Docker Compose level. But without such a script you can easily end up with failing CI tests because there's a multi-second but varied amount of delay on upping a database for the first time. That script has become a part of all of my CI / deployment pipelines.
Wait for a TCP port to come up or wait for a HTTP healthcheck to succeed. I think it's exactly the sort of things that should be supported by the tool out of the box. It's a very common need.
The job of the tool is to manage a bunch of containers that depend on one another and restart them on failure. The tool has to know about dependencies and liveness anyway.
Docker compose development was compromised by the agenda of pushing people to use swarm.
This is why v2 features like resource limits were moved under the deploy: key and you have to use the special "--compatibility" flag to get them to work locally.
This is no longer the case. Compose is an open spec and the v2 and v3 formats are being merged into a unified format (where you don't need version numbers). There are now multiple implementations (eg for ECS/Fargate and ACI), and implementations are being encouraged to support all the options.
This is an application-level design flaw, not a flaw inherent to docker-compose. Regardless of whether you use docker or even if you use containers at all, your webapp should be able to restart if the connection to the database fails or is interrupted for any reason.
You would have the same problem if you used supervisord for example. The general solution is to auto-retry the connection until it comes back up, or hard fail and auto-restart the entire app in the event of a hard failure (e.g. with restart: on-failure or autorestart=true).
Hm, yes, but to play devil's advocate - if you want compose for orchestration (I don't) then you want that dependence not so much for initial start up, but for triggering restarts on failure.
As it stands, AIUI, all it does is mean that dependency A comes up too (in some order) when you `up B`.
You can define any order or restart behavior you need with v2. As long any container with a service dependency fail hards if that dependency is missing/down, it will be restarted and the whole app will eventually reach an up state.
This is amazing news, I was not aware of this. Thank you so much for linking! Do you know if it also applies to the cpu/memory limits and health checks? Is it a true full merge of the two specs? (I will investigate myself and post back too)
I use Docker Swarm (basically multi-node Compose) in production, and am also really happy with it. It's an order of magnitude simpler than k8s, and perfect for small-medium scale deployments.
In terms of configuring your stack, you use regular Compose files, with a few enhancements available (such as better support for secrets). I love it!
I also want use docker swarm in production, but I keep hearing people say it has network bugs like after some time services cannot talk to each other. Have you experienced any such issue?
I haven't experienced any networking issues in production at all.
I have experienced 1 networking issue, but only specifically when keepalives are disabled on Windows (where I use Docker for dev/test only)[0]. When using an overlay network, network connections to dockerised Postgres go "stale" after 15 minutes. I workaround it by publish the Postgres port in "host" mode instead of the default of "ingress" mode using `endpoint_mode: dnsrr`.
I've never actually had to use shared disk, but I'd use NFS if I did (as another commenter suggested) - I've tried it out before, just when playing, and it worked fine.
I recommend taking a look at Hashicorp's Nomad. I was in a similar situation where I wanted container orchestration but our use case wasn't yet at the point where the complexity of kubernetes was justified. Nomad strikes a great balance. Its single binary and makes it easy to get a cluster up and running. You can run tasks other than docker containers as well.
It keeps living on Linux too. My customers are too small to need Kubernetes and we won't switch off our docker containers in development and production. And a customer created a container on his Mac on Thursday to run something I run natively on my Ubuntu laptop.
To be fair to the author of the post, he wrote about the continuing life of docker in the inner loop of development. It will keep going also in production on medium and small projects until we start using something else for multiplatform pull and run software distribution.
minikube. It works with every hypervisor (or even old docker desktop) and spins up a linux VM to run all the kubernetes services, your containers, etc. The CLI is dead simple to learn (minikube start and you're done) and the tool is endorsed, used and maintained by the official kubernetes team.
There's always minikube/k3s, but I think the article overblows the death of Docker a bit. Docker no longer being required in k8s is going to hurt its potential in "prod" for sure, but the `docker run` style commands for running a db locally will work for a long long time.
This article seems to be focusing on using Docker on production servers, rather than as a Developer tool, which is where Docker the company are focused now.
As a developer tool I'm not aware of another option which has a similar setup. You can , of course, manually spin up VMs and install kind/minikube/k3s on them, but that may be more work than you want.
Even though Kubernetes won't use Docker inside anymore.., Docker is still a very good piece of software for easily running Linux images on Windows and Mac. Dockerfile is still the easiest way to build images (even though now there are alternatives to docker build such as buildah). docker-compose is still a very simple way of running containers locally if you don't need kubernetes (e.g. on my raspberrypi for running homeassistant, transmission and plex)...
but yeah.., Docker Inc. overestimated their importance and got what they deserve = Open Source tools wanting to distance from them.
After they released local kubernetes support for the docker mac client, I've stopped using docker swarm completely. Although to be fair, I didn't use it all that frequently anyways.
If your language runtime supports testcontainers (https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.
I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.
Docker-compose v2.4 is arguably much better than v3.0, and in a lot of ways they are really separate specs, not a "newer version" of an old spec. Compose v3 exists to push you towards swarm, whereas compose v2 exists to make docker-compose a complete mini cluster management tool, and succeeds at it in my experience.
We continue to use v2.4 in all our projects today because it allows you do easily do things like define startup order with healthchecks, as well as limit cpu, memory, etc. without having to spin up a whole swarm cluster.
If anyone is curious, this is the native official way to define startup order using healthchecks present in v2.4 (but removed in v3 to push you towards swarm):
TIL this has been returned to compose in the latest version! They merged the specs in September so this is now officially supported again going forward. That fixes my last major gripe with compose trying to push people to swarm, which no longer seems to be the case after this merge.
It's worth noting that dockershim isn't actually getting removed at the moment, it's being deprecated (so a warning will pop up in kubelet logs) and there's no fixed date for actual removal.
At the same time Docker/Mirantis have committed to creating a CRI plugin for Docker, so it seems pretty likely that Docker is and will continue to be an option for Kubernetes clusters.
You can do scaling and fault tolerance without a mesh networking approach. We've been doing it for a long time, even including containers as app delivery.
Kubernetes adds some nice stuff but “scaling” and “fault tolerance” can be achieved very easily without it.
Kubernetes is great because it’s a very standard way to interact with computers. Doesn’t matter really if it’s google cloud, on prem, AWS or whatever, it is the same.
The idea being that it abstracts away a lot of the toil work of ops, with the very obvious caveat that you don’t know what the sausage factory is doing.
I’m pretty kubernetes neutral, some of the concepts are great and deserve replication. (Kube-dns + etcd!, sidecars, scheduling to a cluster)
Some are pitfalls that might cost a lot of people a lot of time in the future. (Networking and storage abstractions being prominent examples)
But as with everything, it’s pros and cons, the complexity being a pretty large con in my personal opinion. I say this as a person who is currently converting a lot of stuff to kubernetes because it solves some particular problems we have really well.
Care and feeding of a production Kubernetes cluster requires constant care, feeding, and maintenance of expertise that would cost any company hundreds of thousands of dollars a year.
Have we really arrived at a point where a good old autoscaling group with a few servers and a replicated database is just not good for anything?
I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows.
Kubernetes continues to use OCI, runc and containerd - so basically the parts of Docker the kubernetes community asked for.
Yet here we are commenting on their demise as a business, blaming it on their “not being nice” and “not listening to their community”. It’s bullshit. We should be discussing how the longstanding tension over the role of Docker in the Kubernetes was finally resolved, in large parts through the successful efforts of the oci, runc and containerd projects which Docker started and shepherded to mass adoption.
Let’s take a step back and look at who is pushing this narrative about Docker, and how they benefit. I can’t help but notice whenever this drama pops up, a Red Hat employee is involved. Maybe it’s time for Red Hat to give up on old grudges and give credit where credit is due? Just a thought.
Docker may have failed as a business but it’s ridiculous to blame it on their lack of openness when their number one problem was being too open and trying too hard to get everyone to love them. Basically the opposite of what this blog post claims.
Hey there. Author of the article here. I'm no longer a Red Hatter and my words are strictly my own.
I don't intend to push a narrative, rather my intent is to communicate what I experienced with Docker in an enterprise setting across time. A lot of this also comes from my time outside of Red Hat as well.
I'll also comment specifically on your remark: I never mentioned Docker's behavior in the community, good or bad. The story of the Summit shirts was to illustrate their entry as a competitor and how that changed the narrative. I give Docker immense credit for what they did, and I state as much toward the end of my post.
Fact: Docker is insanely popular with devs but Docker Inc. is struggling as a company. Devs have invested a lot on the platform and entire production systems and deployment pipelines use it.
k8s announces "we're no longer supporting docker shim!" and what most devs heard is "k8s is moving off from docker (which we know has been struggling for a while)! Fuuuuuccckkkk what do we need to do??" and panicked. This is the source of the drama, and we're going to see many "takes" on it. Its just the way the blogging ecosystem works.
You summarized the last part of my post. In part, I wrote this article because I wanted to give a little bit of history on why docker is being deprecated at all, where it's being deprecated, and that meant calling out the fact that Docker Inc, at one point, tried to make docker into an enterprise platform.
My other intent was to clarify that this has little impact on the runtime, because Docker was never the runtime, it was always containerd.
To me this article conflates the removal of a piece of legacy hard-coding (dockershim) with the overall death of Docker.
That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker.
But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest way to use containers, without having (mostly) to worry about low-level implementation details.
Whether that can be translated to a successful business model, is another question :)
Author here. Thanks for your comment! I struggled with this as well. I agree that I might be conflating things a bit, but I did try to contextualize the slow but gradual move away from all things docker with the fate of the company, starting with the platform wars and resulting in the runtime deprecation. I think a lot of what happened came about because Docker took on Kubernetes with Swarm and lost.
But take a look at this from a different angle. Yes, from the business perspective Docker, inc. seems to be failing badly. But from the engineering perspective they did a tremendous job splitting the monolith to separate components. Containerd was once part of Docker daemon and then abstracted away to an independent entity. And we all hugely benefit from this split.
Now, the next big thing is happening - buildkit. It is already possible to build containers using buildkit without docker. There is even a plugin for kubectl for convenience.
Docker is tearing itself apart but I see only good things happening around it.
> Docker for Windows/Mac is the easiest way to use containers
This is depressing.
Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?)
Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.
And it works pretty well, other than some network bugs every now and then, which seem to be a WSL2 thing. I moved from OSX to Windows around the release of build 2004 and the development experience has been great.
> Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.
WSL2 is also a VM. Docker is in truth Linux-only software, and "Docker" on any other platform is a polished interface for spinning up a Linux VM and running the real version of Docker there.
I don't think this is such a bad thing. What non-Linux Docker really provides is a nice UI.
On my Mac, I switched from doing a lot of development in VMWare Fusion to using docker-machine (set up to still use VMWare under the hood). With docker-machine especially, it's quite obvious that I'm still just using a VM, but it all feels a lot more seamless than when I was running a bunch of commands to start up VMWare, SSH in, and sync my local files.
----------
† I can't use Docker Desktop because I insist on running an old version of OS X.
Docker for Windows is capable of running Linux containers (on top of WSL2 or a Docker-specific Hyper-V VM), and it can also run Windows containers. You can only pick one of those, but if you want to containerize Windows software, Docker can do this. (If you’re on Windows 10 Home, only the WSL2 backend is available.)
You can actually run both Windows and Linux containers at the same time. You don't need to pick "one of these". I think the flag to switch between them on the fly is "--platform".
> Even more depressing is that macOS still doesn't seem to have native containers.
Docker containers are reliant on Linux cgroups, so even if macOS had its own native containers, it would need to add a Linux cgroups compatibility layer on top of it for Docker to work natively.
Doesn't docker support pluggable backends for actually running containers? It can't possibly be hard-tied to cgroups, since docker can run native Windows containers.
> Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?)
I always found that to be weird as well, since AFAIK Darwin does have jails, but it's only used on iOS for some reason (unless I've misunderstood what "jailbreaking" means).
You've misunderstood what the concept of jailbreaking means.
Jailbreaking in the sense it is used for breaking out of the Apple defined jail/walled garden.
Darwin does not have jails as FreeBSD does. And the software they have for limiting what an application can do is not in any way similar to what a jail is.
Containers aren't really a thing. That's the more troubling bit.
Docker containers are an amalgamation of features, tweaks, and functions which combine together into one experience. There is no kernel concept of a container. There are cgroups, namespaces, capabilities, chroots, CoW Overlay VFS, bind mounts, firewalls, virtual networking... And a whole lot of custom crap Docker provides. You have to have a lot of custom glue to make it all work. You need "a Docker".
Every attempt to make a replacement for Docker falls short because of how many things it has to touch to make things easy to use. To replace it all (since it's not an OS primitive) requires product development, which is expensive and complicated, and probably not vendor-compatible with Docker anyway. So you might as well just have people run Docker.
Containers fundamentally change the concepts used to maintain and operate applications in OSes. I think eventually they will become core features, but it's going to take a while. Someone's going to need to start sending in some pretty big patch sets one piece at a time, such as kernel drivers for all the various features. OCI also needs a lot more help before we can run a container everywhere, and it will undoubtedly involve some virtualization layers we don't yet use as part of containers, which will add more complexity.
GA means general availability. This usually means the first release containing new features, excluding beta releases. It is intended for mainstream consumption and more stable than beta. Maintenance releases come next. They fix bugs in features but generally don’t release new features.
Of course, such nomenclature and how strictly it’s adhered to varies from project to project.
The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind.
If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes.
...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker without Kubernetes -- because I dont want to go down the rabbithole of
1. Installing kubernetes on my laptop
2. Ingress Controller hell
2b. Ingress Controller route/path/url annotation hell to make something like Jupyter work in Kubernetes
Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well.
I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.
You are missing the point. In this hypothetical case I'm not interested in knowing how Kubernetes works or is deployed, I'm only interested in running my tools. It's not laziness, it's pragmatism so I can solve what I'm actually trying to solve.
The challenge especially once you get to requiring Ingress Controllers is they are not a core part of Kubernetes, but third party. So you have NGINX, Kong, Traefik -- over a half dozen in total.
Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.)
Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite.
It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...'
It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.
This is great, until I need to run two Jupyter+Pytorch instances (say I want to test two library versions side by side, a very common task).
...on docker, I can do this in 20sec:
"docker run .... -p 8888:8888"
"docker run .... -p 8888:8889"
Enter k8s. Jupyter does not appear to allow path prefix-based url schemes, so the above wont work. That means, you can use "/" and the default-host, and you're good for your first instance. But what about the next instance? Now you need two different domains somehow supported. Unclear how this works, because unclear whose "problem" it is. It isnt clearly an NGINX problem, or a Jupyter problem, or a k8s problem, but a problem nonetheless. NGINX docs on multiple distinct host based ingress is thinner than that for base usage cases.
I do appreciate your post, but I think my point is that solving 80% of the cases isn't sufficient to make the case for adhoc k8s-usage-by-default on desktop. I'm sure I can make the above work (e.g. for group or Prod usage), but to make that effort worth it, there has to be a reason to do it. When I have an alternative of running two "docker run" commands for adhoc usage, i'm not sure if it is.
Your "docker run" example is equivalent to just accessing the Kubernetes services directly on their host names or IPs. For example, with Docker for Desktop, all services of type "LoadBalancer" will automatically get exposed on the host, just like with "docker run".
Ingresses are for setting up HTTP proxying of multiple services on a single host name.
Firstly, I totally agree. Secondly, but it speaks to my initial objection. Not everything can easily be thrown into an adhoc desktop kubernetes setup and it does not make sense for everything -- especially when you have a simple, almost instantaneous alternative way to do it -- docker cli+daemon
Of course but you’re forgetting that Docker is a commercial organization as well. If not for large scale container orchestration in the cloud, how can they add value that’s worth paying considerable $ for?
I think whether Docker adds value (1) and how to capture the value (2) are separate questions. This response was the value it adds. I think it adds a tremendous amount of value, and widespread academic and corporate usage speaks to that.
To your point, they also need to capture that value, because it would be a pity to lose Docker. I cover that in the thread of how they profit with one idea: https://news.ycombinator.com/item?id=25326062
There are other potential ideas -- marketplaces, indemnification services, security services. I hope they figure something out.
The overlap is in compatibility and consistency of the "units of programming" they can both run natively. I think of docker as the REPL for cloud computing.
I just want to make absolute sure that this is NOT the case. Does this mean that docker images built with `docker build` and pushed up to dockerhub will no longer be useable in kubernetes or not?
The writing for Docker for Mac is on the wall. It depends on a Linux VM, for which there is no business case to spend atrociously large amounts of resources to adapt for x86 container images to run on M1 ARM Macs.
For the life of me, I don't understand why Microsoft doesn't acquire Docker. Tighten the integration between Docker for Windows and WSL2, use Docker Hub to slowly push container authors onto managed Azure container registries, and use Docker Hub as a marketing channel for Azure.
> With all the years of bloat baked into the platform, it’s really just a matter of time before other areas to the left of the platform shed the debt of the Docker daemon
From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an example of toxic behavior on either side, they each had their motivations, and a consensus needed to be reached for both projects to proceed. From what I can tell that debate seems to be old news these days and I haven't seen as much clashing between those teams. I am not a developer on either side though, this is just from the perspective of a user who follows the Github issues.
And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it.
I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor.
This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.
I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy.
Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.
Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable.
Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.
I disagree that it was clearly wrong, because supervisord is a vastly simpler service manger than systemd. They wanted to put organizational pressure on people to move away from managing multiple units within a single container with an extremely complex octopus of a unit manager like systemd, and they arguably succeeded at that goal. (Even if it caused short-term discomfort for people who wanted to rely on systemd features within containers.)
Wonderfully written article. I like how it draws the distinction between Docker still possibly surviving in dev and ci/cd pipelines and Docker definitely being dead in production.
I wonder though if something simpler than Docker would arrive for dev and ci/cd and make Docker obsolete there too.
The wording seems so negative. You could also say Docker is evolving to something bigger. And that's a good thing. The simple approach to containers and the workflows that come along with them are nothing short of revolutionary if you ask me, and it will only get better.
285 comments
[ 3.6 ms ] story [ 238 ms ] threadThat’s `ctr`: https://github.com/projectatomic/containerd/blob/master/docs...
You can redirect such urls to a different registry if you prefer, by using the containerd mirrors configuration.
The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.
There easily could have been an alternate history where Docker Inc was the first one out of the gate with an enterprise kubernetes distribution, been a positive part of the community, and been a success.
From my personal point of view, the most sustainable way of funding development of free software is through businesses that utilize that software, but whose main business is not that software. The value proposition for the business to open source their software is mainly in getting improvements from outside, and to ensure better integration with other free software. But the main reason to build software should be selfish in the sense that you can directly use it yourself, and not the idea that you could somehow sell the software in some way or form.
Less concretely, is there a business model for a low-level piece of infrastructure like Docker? Is there a business model for ncurses or readline or df or ls?
"Real world" infrastructure is typically high capex, low margin. How many VC-funded startups build bridges or tunnels? SpaceX is pivoting to Starlink to find good margins and escape the fate of being a trucking company to space.
But I agree that in general, “real world” infrastructure is low margin, I think that’s because it’s completely undifferentiated and has become a commodity
Was this number released?
[0] https://media.ccc.de/v/froscon2019-2463-open_source_as_a_bus...
OpenFaaS has been a struggle even since it was started, even with a large community and many commercial end-users, none pay for support, services or sponsor.
Most of the time saying that Open Source isn't sustainable results in some smarty dropping Elastic or some other massive VC-backed company in like GitLab. It's not helpful.
Have you considered a hosted product? I have no idea what your audience is like, but that seems to be where we've had a lot of success. Happy to chat anytime as well: joel at browserless dot io.
Elastic, on the other hand, is a very specialized application and the main issue they've had is having to compete with cloud providers (MongoDB also shares this problem). It's a very different problem, and both companies (Elastic and Mongo) seem to be finding ways to compete and cooperate. Elastic on Amazon is a great gateway drug to Elasticco's offerings.
Why is that? Is amazon not able to run it properly?
Instead they tried really hard to make docker swarm a thing while kubernetes started taking off. To be sure, at the time, it wasn't clear which platform would succeed, and I remember that a certain OpenStack project tried to support both (like all OpenStack projects that try to be everything to everyone). Kubernetes has a lot of concepts that need to be learned, so the barrier to entry was much higher, and docker swarm seemed more straightforward.
All devs loved docker right away but in the early days I remember there being a lot of blogs about NOT running containers in production because of all the security issues. Kubernetes made that problem go away. It got adoption by different cloud providers which made it easy to deploy/use on their platform. That was maybe a tell: if devs loved docker so much and kubernetes was the tool that cloud providers supported, they could have focused on the former.
I use it as a private repo host. The cost is a no-brainer. We'd probably pay 2x or 3x more compared to the value we're getting. The independence from the Cloud services (ECR, ACR, GCR) makes it a better option. Also, for now, there isnt any funny-math on multi-factor egress costs -- which become tricky to compute in real life.
We use it for containers to be run on k8s. As long as there are not super-low latency requirements for startup, I'd prefer an independent single private repo over multiple in-zone repos.
https://en.wikipedia.org/wiki/Docker,_Inc.
Heroku had a lot of revenue and was acquired by Salesforce. I just learned on Twitter that YC was in the red before the Heroku acquistion !
https://twitter.com/paulg/status/1334945195532685317
I think what Heroku did right is really nail the Rails experience, and the Rails customer base. And then they expanded to multiple languages with the "Cedar" stack.
dotCloud tried to do every language from the get-go, and had a subpar experience for all of them, from what I understand.
It probably wouldn't have taken long for a Python-centric competitor to leapfrog them, but by the time they had, dotCloud was basically all in on the Docker experience, which was transformative.
Are we really supposed to believe uncritically that Red Hat, a publicly traded company with billions of revenue and an army of engineers at their command, are being bullied by a startup of what, a couple hundred people?
I’m sure the people at Docker did behave badly in some way to piss off people at Red Hat, but whenever I dig into the underlying facts, it’s always something silly and sometimes ridiculous. I’ve seen a talk by a Red Engineer dedicated entirely to the topic of how mean Docker maintainers were to him. The actual offense was 1) refusing to merge certain PRs Red Hat deemed important, 2) a tweet by an individual maintainer’s personal twitter account making fun of Red Hat for sending low-quality patches. That’s the kind of ridiculous petty food fights this whole “Docker vs the world” drama is built on. I mean, who cares?
TLDR: the real story is probably more complicated than “everything was great then Docker was mean and then they failed because they were mean, the end” and best told by a less biased source.
The biggest incident, if I remember well, was related to the layerfs stuff, which was supported by Ubuntu, but which RH refused to include. Instead they pretty arrogantly pushed to merge a PR which was breaking other stuff in Docker, and were pissed when the maintainers refused to. That whole thing obviously rubbed people working on Docker the wrong way, which was the beginning of the pretty sour relationship.
After that I don't think there was a lot of goodwill from Docker towards RH, probably causing a lot more issues..
They threw me off the Docker Captains programme for saying that Rancher was a good product. Hilarious!
Now the last battle is over Docker Hub.
similar to npm though they'll keep getting second chances since it's the default namespace in the cli
But Kubernetes is super complicated. The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkill.
Now, I'm no guru in this field at all. In fact, one thing I always liked about Docker is it made you feel able to atomically deploy software without having to become an expert at anything first. But what's the current "don't have to be an expert" way to ship software if Docker is, supposedly, dead? Do we all have to learn Kubernetes?
I've never used Swarm but I've been told that one thing it had going for this is that it allowed you to do smallish setups pretty easily. If that's true, then I'm sad it lost the popularity war.
It can be, but running minikube or k3s on your laptop is trivial, and what you do with them transfers very easily to real Kubernetes.
I mean, that was one of the key Docker promises, and they delivered to quite an extent.
If you have an existing cluster somewhere (say a managed cluster from AWS or GCP) that you want to run your webapp on, just copy/paste a YAML from any of the hundreds of guides on the internet and off you go. The k8s docs themselves are also pretty thorough. Your app will run with automatic failover and rolling deploys and whatnot right out of the box.
Yes absolutely, the YAML will just need to be updated for API keys or whatever.
Kubernetes is complicated to build a production grade cluster on bare metal but for getting started as a developer it’s no more complicated than Docker actually
The discoverability is still a problem with it, if no one told you e.g. about k3s you would never guess the name. Good luck :-)
All you really need to learn is some basics around Kubernetes terminology, the kubectl command line utility, and then some of the YAML config syntax for setting up application deployments and probably an ingress into the cluster. You can also add helm into the mix if you'd like to take advantage of pre-built packages that you can install to your cluster. For example SSL certificate management or a webserver ingress like nginx-ingress.
Anytime I hear people nuh-uhh someone saying "X is complicated", the difference is often someone having to deal with security and someone getting to deploy with more lax considerations.
I find quite cute that in 2020 people are still echoing this to the extent that now I have to answer questions like "explain what kubernetes is" during job interviews.
To me seems that a bigger group of people get jealous about a smaller group getting new tools. Then this "stuff x is complicated" propaganda is passed on through the industry like the plague.
i don't blame you. k8s is great job security ;) for now.
Yes, pretty neat and easy way to tag your nodes and tell where your workload will run.
What is the deal?
Doesn't mean that the tool itself is complicated, and spreading propaganda is plain wrong.
Instead, I recommend to read the docs, watch videos and, most important, try it out.
The overhead with Swarm though, is low, and I like it. Where possible though, I'd also recommend having a look at ECS Fargate. Make it someone else's problem.
All I've ever really wanted is: "take this container with this config and auto-scale it for me".
Of course it should also be run in a private network, have blue-green deploys, auto-restart containers on failure, have geographic redundancy, etc. etc. but I don't want to have to think about any of that.
Fargate gets reasonably close to this ideal.
So then cloud providers coalesced around the platform. People who learned the concepts found it easy to use and loved it and it fueled the adoption.
I still believe that despite all the hate that k8s gets on HN, its popular because it works and its users love it. There is very loud subset of users who makes their displeasure known very well but we have to look at concrete data on usage and the data points to k8s being a very popular platform for USERS.
I think Red Hat deserve a lot of credit for being early to package and productionise Kubernetes.
> Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile.
Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive.
Docker is still the simplest way to install Elasticsearch, to make sure everyone on your team is using the same Java version, or run up a production equivalent environment on your laptop. Regardless of if you are on Linux, Mac or Windows.
I still love Docker and hope they end up finding a good business model so they can continue to live on.
To their credit the docker folks I talked with did listen and respond and move the needle (obviously) on it being a local dev tool, so I cheer them for that.
I use it all the time in my windows box for dev. Tho I do try and keep my software able to run on any os.
They have some k8s stuff I've never looked at, too.
The number of Docker Desktop installations and the popularity of local Kubernetes tools (think KinD, k3d) show that "Docker got boring" which is an aspiration for infrastructure tooling.
Hat'ers gonna Hat.
(disclaimer: author does not actually work for Red Hat.)
The second one will be a huge step forward as docker will not be able to do this for a long time as they use the mac hypervisor which can‘t run x86 vms. Podman would enable again prod/dev comparability which may work for redhat to more people switching to podman even for their production systems.
The Podman team is working on it but it's not quite there yet. Podman now has an API so at a minimum the whole opaque VM thing should be usable here soon. podman-machine and boot2podman already work for some people, although they didn't work for me.
I have a dream of using a lightweight Fedora Core OS VM on Mac/Windows for running the containers with a podman-remote client seamlessly driving it from the Mac user space. Once podman-remote is working, that's my next plan ;-)
A self plug here, I'll be keeping an eye open for all of these things and will blog about once I get it reliably working. I'll be submitting it to the Red Hat developer blog but I cross publish everything I write to medium as well in case you want to look for it: https://freedomben.medium.com/ I'm also starting to tweet when I blog (I'm finally getting serious about it now haha) @Freedom_Ben on twitter.
Do you consider "Docker" to be "works on Windows?"
I don’t wish them ill, but literally everything has been replicated. If they fail as a company it won’t matter to developers who don’t use their enterprise software.
I actually think the company isn’t long for this world. It wouldn’t surprise me if they got bought for a paltry sum in the next few years.
Their lasting legacy is that most software and people assume that a shortened container image points to docker.io.
1 https://fedoramagazine.org/docker-and-fedora-32/
Moby is docker effectively. Your link describes how to install docker on Fedora.
If for no other reason that, they don't do Windows containers :) I know of quite a few corps using Windows containers in prod. now, take up may have been slow, but it's happening.
Also Docker for Windows/Mac have an easier install/setup process than manually setting up VMs and installing tools on them.
Yes, you read it correctly, running privileged docker-in-docker containers with podman to spawn docker containers in dind containers. The good thing is that networking was handled flawlessly. And there were no conflicts between docker and podman
I use Docker Swarm (technically "Swarm Mode") in production, and I'm really happy with it - it's so easy to configure and operate, but I am worried that it will no longer be maintained at some point.
https://www.mirantis.com/blog/mirantis-acquires-docker-enter...
Maybe not, but considering how much they gave, I think we should want them to live on, and do what we can to help them. Do we really want to live in a world where a startup company makes as big an impact on the way we develop and deploy software as Docker did, only to have all possible business taken from it by bigger players?
There have been lots of great technologies that haven’t directly made their creators rich, but their good legacy usually/eventually catches up with them.
I think that's the just-world fallacy. [1] It's up to us to reward good work. So I guess I should go get a paid Docker Hub account.
[1]: https://en.wikipedia.org/wiki/Just-world_hypothesis
I don't think the poster you're replying to was invoking a just world fallacy, however. I read it as saying that developers who build solid systems that people like tend to thrive, even if their business fails.
That appears to be true, and not because of karma, because top-tier developers are in very high demand. Demonstrating that you're one of those isn't the same thing as running a successful business.
We have had to replace RHEL systems with Ubuntu to keep some of our applications running as they fail on Podman. A major problem is also that podman-compose is far from feature parity with docker-compose.
I replaced Centos8 with Amazon Linux 2 ("amazon linux extras" provides a working docker installation) for exactly the same reason. I like the idea of podman and buildah and I wish them well, but for the time being I can't afford to debug the missing pieces and subtle failures.
I don't think that's what this means at all honestly. Docker (the company) made some poor decisions that led to their troubles. I'm not here to crap on docker, but they quit investing in and moving their tool forward because they were focused on the EE offering. This opened the door for "competitors" to do the things docker wasn't doing (daemonless, rootless, cgroups v2, just a few). They also did things that scared people, like the whole "moby" rename thing. It made people worried that (fairly or not) Docker the company didn't have the best intentions for the open source version. They had poor direction on product. They would routinely refuse nice features that people wanted (many that included PRs) for things with terse, unkind "do not want" rejections, and then 6 months later they would end up adding it anyway. Some of these were suspected to be refused so as not to allow open source docker to compete with EE feature sets. docker-compose was the worst at this (To be fair I think it was mostly one very loud/very powerful person wrt docker-compose).
Docker started the race way ahead of everyone. To this day people still use the name "docker" to generically refer to containers.
Anyway, my point is not to crap on docker, just to say that in my opinion, in so many areas important to an open source leader, they made decisions that undermined their long term outlook.
- they stopped evolving the Dockerfile. Really this is the complexity killer that developers just "get".
(also they wouldn't have their entire API cloned if they were moving it forward)
- they subtly force everything through docker hub and conveniently forgot to do something like let people have a local repo. (redhat lets you define a local repo with --add-registry)
- telemetry. I went to install it on macos and it started collecting telemetry the moment I launched the installer.
The thing is, as a person I don't want to feel ripped off. I don't subscribe to JetBrains since my work doesn't require these tools (also, I use Eclipse for 15+ years and it works well). The subscription culture allows developer to pump features indefinitely but, I can't subscribe to all tools that I like.
There are many services that I subscribe too (Dropbox, Spotify, Netflix, IFTTT premium, Evernote, etc.) but, they give me a service which touches my life everyday. I have no budget to subscribe to a tool to test for a year. It's not feasible. I need to eat.
So yes, I'd rather have a good FOSS tool which doesn't want $100+ from me every year and I'd rather patch it myself. But, if you provide me a good service which I can't replicate easily, or don't want to manage myself, I'd pay you good money. I'd be also very happy if the tool I'm paying is FOSS.
Also the biggest obstacle driving me away from paying is the tools are closed source and I'd be locked in if the tool/company lets out the magic smoke. All the services I pay are not locking me in. I can get my data out of them. So it's not always wanting to earn money for free.
I agree that intellij and eclipse are similar, but as soon as you work with C, C# or Python, there's very few good open source alternatives.
I write C/C++ and Python mainly. Eclipse CDT and PyDev are very good. Since I'm using the platform for 15+ years, I've seen its bad days too. Except some edge cases, CDT is bulletproof and works very well. PyDev is also very smart and helps me the way I need.
Actually, Eclipse has the best and most sensible Git UI I've ever used. I also like Tower but, Eclipse both makes sense and helps a lot in the relevant places.
One question on eclipse. Did eclipse finally sort out git/svn support?
Here's an interesting tidbit of history for those who don't know. One of the main drivers for the decline of eclipse was the complete lack of support for source control, which is a pretty basic feature for an IDE.
You could try to get some plugins. There were 2 major plugins for SVN and neither worked half the time for no particular reasons. It was a complete shitshow. Don't even think of doing that in a company where HTTP access must go through a proxy.
Developers eventually gave up and moved to JetBrains IDE. Source control worked out of the box.
Heck, I've developed my whole Ph.D. with it and it interfaced the tools that I need to use well, was stable and fast. When I pressed a shortcut, it did the thing I expected it to do. The whole experience was, well, uneventful.
I've used Subversive IIRC during my Master's and it was uneventful too. Didn't lose any data, the plugin didn't misbehave or had any problem with it. Was using Assembla's SVN + Redmine bundle as my remote repository.
The git support was similar. I just installed it and it worked. Still works. As I said before, they've nailed the best logical view for git IMHO. IIRC, now it comes bundled with the Eclipse.
They may have done some things wrong in the past but, it's a solid IDE and I like working with it. I don't think they deserve the strong words you choose, but to each his own.
Of course, your mileage, taste and views may vary.
I think that might sap some of the impetus to reinvent those features in a competing open source project (they can of course just copy them if they wait), and also might entice people to pay that wouldn't normally because they don't want to get on the paid product train. Users also get a known date a feature will be available, a real date, not a projected delivery date.
In a lot of ways it's what many companies that develop products do already to allow people to get familiar with their product (have an open source version with less features), but this allows them a better story, makes users feel more sure about what's going on, and if they release the code immediately but it's unusable for a period by other projects, that does make it harder for those projects to cleanly reimplement unless they're sure they haven't seen in (that might be a net negative for the public with a litigation happy company).
The hard part would be tracking the time, but git has ways to make that pretty simple.
SAS, Matlab, Oracle, Arc, there's lots of really boring backend systems with plenty of FOSS alternatives but you need sales.
If the customer is the developer, then they might ask their manager for a text editor with a nice UI. If the customer is the whole enterprise, then someone needs to wine and dine the CEO to get that $10,000 per core contract signed.
Surely the critical success component at scale is more than just "wining and dining". I truly wonder how Oracle has managed to do it for all these years...
RUN apk update && apk upgrade && apk add foo
the way to create small docker image is:
It should be replaced with actual first-order dockerfile statementsYou can use multi-stage builds, but they are sort of hacky and do not match your thinking.
You can also use --squash but it is a hack too and usually is not available where needed because of experimental.
Also, ADD is stupid.
You can add a tar.gz file and it will expand it (but you can't use -k)
You can add the same file using http/https, except it WON'T expand it so back to the RUN dilemma you get:
If the Dockerfile is canonical, I should have as much as I can reasonably put into it.
https://docs.docker.com/develop/develop-images/multistage-bu...
It’s cute, and useful, but in the end it brings back the primary problem that Docker actually solves: absolutely getting all of the files your code needs to run into the package, and the right version.
Multistage builds require you to airlift files out of one image into another. Accurately. If cherry-picking is the best option on offer by docker, there are plenty of other tools that can do that.
Collapsing layers is about seeing that an image provides a set of services at point A, and another set at point B, and that nothing in between represents an interim state of any substantial value. For most images, this is one or two layers that relate to either the main payload, or one particularly volatile dependency.
If you have some service written in say C++/Java/C#/Go, then building it in one container (that has the build tools) and copying the build result to another that only has the stuff actually needed at runtime makes good sense. That is much easier and saner than trying to uninstall all the build time components after using them.
It is not like for desktop software we install the build tool, build, and then uninstall build tools. Instead we grab the relevant build outputs and package them into an archive or installer.
But as a solution for clearing out cruft like package manager caches, etc, yeah multi-stage build is not really optimal.
Being able to write the executed steps in a natural way, and then specify at the end to compare everything to come specified previous layer, and create a layer that just has the differences would be really useful.
They could even still cache the intermediate layers as part of the build caching process if they wanted, so long as they are not included in final image as pushed to a repository.
Docker does have a super cut down version of this with its experimental `--squash` option, but that only makes sure there is a single new layer for the output of the whole dockerfile run. You cannot use this if you for some reason want exactly 2 new layers. This limitation is probably acceptable in a lot of cases. However this option is not supported in the buildkit based backend yet.
This will adds the script without adding a layer for it.
Containers should be about security not cloning local development environment.
Why not? One way to use containers is as a light-weight virtual machine without a kernel, which can be pretty useful.
Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Compose with Go to make it more consistent with their main CLI. Looks like full steam ahead to me rather than death.
It's really nice having the same Dockerfile + docker-compose.yml get used in dev + ci and prod. There's no surprises and no massive amount of complexity.
[0]: https://github.com/docker/roadmap/issues/15
We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks because we don't need the complexity of swarm and v2.4 provides everything we need. Sometimes simple is best.
I personally use compose to manage services on my own laptop and homelab as well, it just has the massive advantage of being the greatest common denominator that everyone can pick up in a few days if they're familiar with basic container concepts.
Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case.
See various workarounds over the years: https://stackoverflow.com/questions/31746182/docker-compose-...
Compose v2.4 was released long ago and abandoned by docker. Some features/workarounds that worked in that version were killed in the next versions. It seems to me that you're stuck on that old version unable to upgrade because of that?
IMO this is a perfect illustration of how Docker sucked in practice (both the product and the company), the industry naturally converged into trying to get rid of it because there was no other choice.
Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it)
I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.
I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall).
P.S. For readers who don't have context. Make a basic compose file with a webserver and a database. "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.
Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control.
But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'ing into your main container to run tests or migrations).
For that I wrote a simple Bash script at https://github.com/nickjj/wait-until. IMO a problem like this can't really be solved at the Docker Compose level. But without such a script you can easily end up with failing CI tests because there's a multi-second but varied amount of delay on upping a database for the first time. That script has become a part of all of my CI / deployment pipelines.
The job of the tool is to manage a bunch of containers that depend on one another and restart them on failure. The tool has to know about dependencies and liveness anyway.
This is why v2 features like resource limits were moved under the deploy: key and you have to use the special "--compatibility" flag to get them to work locally.
You would have the same problem if you used supervisord for example. The general solution is to auto-retry the connection until it comes back up, or hard fail and auto-restart the entire app in the event of a hard failure (e.g. with restart: on-failure or autorestart=true).
As it stands, AIUI, all it does is mean that dependency A comes up too (in some order) when you `up B`.
https://docs.docker.com/compose/compose-file/compose-file-v2...
> Problem being, "depends_on" was removed in version 3, with no replacement in sight.
How is v2 relevant?
In terms of configuring your stack, you use regular Compose files, with a few enhancements available (such as better support for secrets). I love it!
I have experienced 1 networking issue, but only specifically when keepalives are disabled on Windows (where I use Docker for dev/test only)[0]. When using an overlay network, network connections to dockerised Postgres go "stale" after 15 minutes. I workaround it by publish the Postgres port in "host" mode instead of the default of "ingress" mode using `endpoint_mode: dnsrr`.
[0] https://success.mirantis.com/article/ipvs-connection-timeout...
To be fair to the author of the post, he wrote about the continuing life of docker in the inner loop of development. It will keep going also in production on medium and small projects until we start using something else for multiplatform pull and run software distribution.
As a developer tool I'm not aware of another option which has a similar setup. You can , of course, manually spin up VMs and install kind/minikube/k3s on them, but that may be more work than you want.
but yeah.., Docker Inc. overestimated their importance and got what they deserve = Open Source tools wanting to distance from them.
If your language runtime supports testcontainers (https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.
I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.
We continue to use v2.4 in all our projects today because it allows you do easily do things like define startup order with healthchecks, as well as limit cpu, memory, etc. without having to spin up a whole swarm cluster.
For local development use-cases, docker-compose v3 is just v2 minus all the features Docker Swarm doesn't support.
https://github.com/docker/compose/releases/tag/1.27.0
At the same time Docker/Mirantis have committed to creating a CRI plugin for Docker, so it seems pretty likely that Docker is and will continue to be an option for Kubernetes clusters.
Kubernetes is great because it’s a very standard way to interact with computers. Doesn’t matter really if it’s google cloud, on prem, AWS or whatever, it is the same.
The idea being that it abstracts away a lot of the toil work of ops, with the very obvious caveat that you don’t know what the sausage factory is doing.
I’m pretty kubernetes neutral, some of the concepts are great and deserve replication. (Kube-dns + etcd!, sidecars, scheduling to a cluster)
Some are pitfalls that might cost a lot of people a lot of time in the future. (Networking and storage abstractions being prominent examples)
But as with everything, it’s pros and cons, the complexity being a pretty large con in my personal opinion. I say this as a person who is currently converting a lot of stuff to kubernetes because it solves some particular problems we have really well.
Have we really arrived at a point where a good old autoscaling group with a few servers and a replicated database is just not good for anything?
Kubernetes continues to use OCI, runc and containerd - so basically the parts of Docker the kubernetes community asked for.
Yet here we are commenting on their demise as a business, blaming it on their “not being nice” and “not listening to their community”. It’s bullshit. We should be discussing how the longstanding tension over the role of Docker in the Kubernetes was finally resolved, in large parts through the successful efforts of the oci, runc and containerd projects which Docker started and shepherded to mass adoption.
Let’s take a step back and look at who is pushing this narrative about Docker, and how they benefit. I can’t help but notice whenever this drama pops up, a Red Hat employee is involved. Maybe it’s time for Red Hat to give up on old grudges and give credit where credit is due? Just a thought.
Docker may have failed as a business but it’s ridiculous to blame it on their lack of openness when their number one problem was being too open and trying too hard to get everyone to love them. Basically the opposite of what this blog post claims.
I don't intend to push a narrative, rather my intent is to communicate what I experienced with Docker in an enterprise setting across time. A lot of this also comes from my time outside of Red Hat as well.
Fact: Docker is insanely popular with devs but Docker Inc. is struggling as a company. Devs have invested a lot on the platform and entire production systems and deployment pipelines use it.
k8s announces "we're no longer supporting docker shim!" and what most devs heard is "k8s is moving off from docker (which we know has been struggling for a while)! Fuuuuuccckkkk what do we need to do??" and panicked. This is the source of the drama, and we're going to see many "takes" on it. Its just the way the blogging ecosystem works.
My other intent was to clarify that this has little impact on the runtime, because Docker was never the runtime, it was always containerd.
That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker.
But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest way to use containers, without having (mostly) to worry about low-level implementation details.
Whether that can be translated to a successful business model, is another question :)
Now, the next big thing is happening - buildkit. It is already possible to build containers using buildkit without docker. There is even a plugin for kubectl for convenience.
Docker is tearing itself apart but I see only good things happening around it.
P.S. It has been possible to use containerd directly as CRI for Kubernetes since v1.10 https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...
This is depressing.
Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?)
Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.
WSL2 is also a VM. Docker is in truth Linux-only software, and "Docker" on any other platform is a polished interface for spinning up a Linux VM and running the real version of Docker there.
I don't think this is such a bad thing. What non-Linux Docker really provides is a nice UI.
On my Mac, I switched from doing a lot of development in VMWare Fusion to using docker-machine (set up to still use VMWare under the hood). With docker-machine especially, it's quite obvious that I'm still just using a VM, but it all feels a lot more seamless than when I was running a bunch of commands to start up VMWare, SSH in, and sync my local files.
----------
† I can't use Docker Desktop because I insist on running an old version of OS X.
Docker containers are reliant on Linux cgroups, so even if macOS had its own native containers, it would need to add a Linux cgroups compatibility layer on top of it for Docker to work natively.
I always found that to be weird as well, since AFAIK Darwin does have jails, but it's only used on iOS for some reason (unless I've misunderstood what "jailbreaking" means).
Jailbreaking in the sense it is used for breaking out of the Apple defined jail/walled garden.
Darwin does not have jails as FreeBSD does. And the software they have for limiting what an application can do is not in any way similar to what a jail is.
Docker containers are an amalgamation of features, tweaks, and functions which combine together into one experience. There is no kernel concept of a container. There are cgroups, namespaces, capabilities, chroots, CoW Overlay VFS, bind mounts, firewalls, virtual networking... And a whole lot of custom crap Docker provides. You have to have a lot of custom glue to make it all work. You need "a Docker".
Every attempt to make a replacement for Docker falls short because of how many things it has to touch to make things easy to use. To replace it all (since it's not an OS primitive) requires product development, which is expensive and complicated, and probably not vendor-compatible with Docker anyway. So you might as well just have people run Docker.
Containers fundamentally change the concepts used to maintain and operate applications in OSes. I think eventually they will become core features, but it's going to take a while. Someone's going to need to start sending in some pretty big patch sets one piece at a time, such as kernel drivers for all the various features. OCI also needs a lot more help before we can run a container everywhere, and it will undoubtedly involve some virtualization layers we don't yet use as part of containers, which will add more complexity.
Of course, such nomenclature and how strictly it’s adhered to varies from project to project.
https://news.ycombinator.com/newsguidelines.html
If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes.
...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker without Kubernetes -- because I dont want to go down the rabbithole of
1. Installing kubernetes on my laptop
2. Ingress Controller hell
2b. Ingress Controller route/path/url annotation hell to make something like Jupyter work in Kubernetes
...when I can do that in 5 minutes with docker.
> 2b. Ingress Controller route/path/url annotation hell...
Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.
I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.
I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works.
I no longer see lazyness as a good trait in programing.
Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.)
Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite.
It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...'
It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.
...and this is your idea of easy? For something that should be as simple as "this path goes to this group" + "this group is these containers"?
...on docker, I can do this in 20sec:
"docker run .... -p 8888:8888"
"docker run .... -p 8888:8889"
Enter k8s. Jupyter does not appear to allow path prefix-based url schemes, so the above wont work. That means, you can use "/" and the default-host, and you're good for your first instance. But what about the next instance? Now you need two different domains somehow supported. Unclear how this works, because unclear whose "problem" it is. It isnt clearly an NGINX problem, or a Jupyter problem, or a k8s problem, but a problem nonetheless. NGINX docs on multiple distinct host based ingress is thinner than that for base usage cases.
I do appreciate your post, but I think my point is that solving 80% of the cases isn't sufficient to make the case for adhoc k8s-usage-by-default on desktop. I'm sure I can make the above work (e.g. for group or Prod usage), but to make that effort worth it, there has to be a reason to do it. When I have an alternative of running two "docker run" commands for adhoc usage, i'm not sure if it is.
Your "docker run" example is equivalent to just accessing the Kubernetes services directly on their host names or IPs. For example, with Docker for Desktop, all services of type "LoadBalancer" will automatically get exposed on the host, just like with "docker run".
Ingresses are for setting up HTTP proxying of multiple services on a single host name.
To your point, they also need to capture that value, because it would be a pity to lose Docker. I cover that in the thread of how they profit with one idea: https://news.ycombinator.com/item?id=25326062
There are other potential ideas -- marketplaces, indemnification services, security services. I hope they figure something out.
For the life of me, I don't understand why Microsoft doesn't acquire Docker. Tighten the integration between Docker for Windows and WSL2, use Docker Hub to slowly push container authors onto managed Azure container registries, and use Docker Hub as a marketing channel for Azure.
Yes!
I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor.
This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.
Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.
Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.
I wonder though if something simpler than Docker would arrive for dev and ci/cd and make Docker obsolete there too.