Docker's Second Death • Hacker News Board

Re: Docker's Second Death

#141

Post by fredthomsen » Sun, Dec 06, 2020, 8:50 PM UTC

nikisweeting wrote: post #132

nickjj wrote: post #115

Earlier quoted context omitted.

> 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 Comp…

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 li…

Couldn't agree more. compose is a wonderful tool that lets you avoid the k8s complexity if you don't need it.

Re: Docker's Second Death

#142

Post by fredthomsen » Sun, Dec 06, 2020, 8:51 PM UTC

heavyset_go wrote: post #128

hacknat wrote: post #51

Earlier quoted context omitted.

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 b…

podman claims to be a drop-in replacement for Docker, yet when I tried to treat it as one, I ran into bugs and a lack of feature parity.

Had the same experience and the compose equivalent was barely functional.

Re: Docker's Second Death

#143

Post by GordonS » Sun, Dec 06, 2020, 8:52 PM UTC

hacknat wrote: post #51

hmottestad wrote: post #12

I enjoyed the following: > 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…

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 b…

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.

Re: Docker's Second Death

#144

Post by wisty » Sun, Dec 06, 2020, 8:53 PM UTC

ampdepolymerase wrote: post #62

hmottestad wrote: post #12

I enjoyed the following: > 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…

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.

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.

Re: Docker's Second Death

#145

Post by yjftsjthsd-h » Sun, Dec 06, 2020, 8:55 PM UTC

enos_feedler wrote: post #114

brainzap wrote: post #83

Earlier quoted context omitted.

I wish we could replace Dockerfiles already with a format that allows for fine grained layer control.

What kind of control are you looking for?

I'd like explicit layers (transactions, I guess?) - so instead of every command making a layer, I could write

    FROM alpine
    STARTLAYER
    RUN apk update
    RUN apk upgrade
    RUN apk add foo
    ENDLAYER

and end up with a 2-layer image (alpine + my stuff) rather than the 4-layer image that docker would produce today.

Re: Docker's Second Death

#146

Post by bayindirh » Sun, Dec 06, 2020, 8:56 PM UTC

pjmlp wrote: post #109

ampdepolymerase wrote: post #62

Earlier quoted context omitted.

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.

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.

Re: Docker's Second Death

#147

Post by yjftsjthsd-h » Sun, Dec 06, 2020, 8:57 PM UTC

heavyset_go wrote: post #135

musicale wrote: post #93

Earlier quoted context omitted.

> 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 fo…

> 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.

Re: Docker's Second Death

#148

Post by yjftsjthsd-h » Sun, Dec 06, 2020, 8:59 PM UTC

musicale wrote: post #93

raesene9 wrote: post #48

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…

> 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 fo…

> 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).

Re: Docker's Second Death

#149

Post by mwcampbell » Sun, Dec 06, 2020, 8:59 PM UTC

hacknat wrote: post #51

hmottestad wrote: post #12

I enjoyed the following: > 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…

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 b…

> There’s no need for them to live on.

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?

Re: Docker's Second Death

#150

Post by freedomben » Sun, Dec 06, 2020, 9:00 PM UTC

tpetry wrote: post #91

alexellisuk wrote: post #38

Earlier quoted context omitted.

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.

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 hyper…

Agreed, podman needs better support for mac. It works fine under Windows WSL2 currently, see: https://www.redhat.com/sysadmin/podman-windows-wsl2

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.