Docker's Second Death
tariqislam.com
tariqislam.com
> 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.
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.
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...
FROM alpine
STARTLAYER
RUN apk update
RUN apk upgrade
RUN apk add foo
ENDLAYER
RUN apk update && apk upgrade && apk add foo
the way to create small docker image is:
RUN apt-get install foo && \
do bar && \
do more && \
remove all of the crap you don't want
You 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:
RUN apt-get install wget && \
wget foo.tar.gz && \
tar xvkf foo.tar.gz -C dir && \
rm foo.tar.gzIf 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.
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`.
restart: on-failure
depends_on:
other_service:
condition: service_healthy
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.
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.
Docker's second death is very much IBM/ RHEL's anti-competitive intent. An infrastructure provider should be neutral on how they present this kind of thing, especially a company selling enterprise reliability for running software on top. The 1984-esque double speak experience has been quite souring wrt ethics of doing business with them around cloud/container-era technology and trusting them for enterprise reliability.
I do find the podman ecosystem technically interesting... but due to the unethical corporate stewardship we're seeing, I'm uncomfortable seeing anyone use it.
1. Docker being deprecated has nothing to do with anyone's competitive intent. I believe that the Kubernetes community is optimizing away from bloat.
2. I do not espouse podman. This post was about the container runtime, which podman is most definitely not.
It's been a few years since I left the company, but it's unfortunate that you've had the experience you describe.
There's a difference between infra orgs promoting new tech as an alternative vs. blocking their competitors. Infra co's are paid to be reliable neutral providers & advisors - instead, it seems corporate greed here has folks actively breaking enterprise userland and misleading decisions makers in sensitive areas like gov, utilities, world-scale services, etc.
Like I said, I found the technical goal interesting and have been following. However, working through the year+ papertrail of RH doublespeak here makes me dread having to interact with them as an active OSS dev and in my dayjob working with big businesses / govs. RHEL often has policy lock-in in these orgs, so I know it'll keep happening unless the community stops it. As is, the stewards are needlessly risking putting podman and friends into a politically contentious category similar to urbit, oracle, etc., and are costing a lot of time & $$$ from people who are already stretched thin.
podman just doesn't work like docker and podman-compose isn't even at a usable state when RH deprecated Docker which seems completely rushed.
And when you see that it's actually not so easy to install docker anymore, you get the feeling RH has another intention such as trying to control container business by themselves by trying to move people off docker.
If it was purely from technical superiority, then it should've had a smoother migration path.
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"?
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myingress
spec:
rules:
- http:
paths:
- host: example.com
path: /
pathType: Prefix
backend:
service:
name: test
port:
number: 80
upstream backend {
server some-backend:80;
}
server {
listen :80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}...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.
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
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.
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.
some_service:
depends_on:
other_service:
condition: service_healthyAt 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.
If so, what should they replace it with, esp, if all you want to deploy to prod is contained in a single docker-compose? Is switching local development to kubernetes a good idea in terms of performance, fast feedback loop, development experience (smooth flow), etc. ?
There are some tools to convert your docker-compose into the k8s resource model. I'd advise against switching local development to Kubernetes. Docker found a sweet spot there, as heavyweight as it is today. I think where we'll land is Dockerfile + one of the other alternatives like kaniko, buildah, etc.
I am required by law to spruik Cloud Native Buildpacks. For most uses, I feel Dockerfiles are not necessary or desirable at this point.
Disclosure: I've been around CNBs for a while for Pivotal and now VMware.
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.
I personally always take the view that docker, by all accounts, blew off a potential once in decade chance of becoming the next VMware, because of its own arrogance and incompetence.
But, I am very much disgusted by the community's misplaced hate towards docker, and the equally misguided euphemism towards the big corps, particularly Google. After all, the whole container community own it's creation to docker. One can always claim that container exits long before docker, but that's like claim there were always operating system before Unix, etc.
I don't think anyone hates docker. But there is an issue of hubris here.
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.
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?
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.
Of course, such nomenclature and how strictly it’s adhered to varies from project to project.
That’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.
Tell me, how will the great majority of developers be creating images to run on kubernetes clusters? Not buildah or whatever. They will use docker build, I wager.
Docker will die eventually, yes. But not for a long time (>5 years) yet.
I wonder though if something simpler than Docker would arrive for dev and ci/cd and make Docker obsolete there too.
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.
Yes!
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.