Hacker News new | ask | show | jobs
by sirius87 1185 days ago
In its weird death spiral, if Docker Inc. were to be bought out by Microsoft, I shudder to think how much of the dev ecosystem would yet again depend on Microsoft's good graces to shoulder the burden of storage and data transfer costs for building products. They already do npm and Github (+ Github Container Registry) so they have some standing in being stewards in this space.

On the plus side, it would perhaps give enterprises more confidence about their build pipelines remaining dependent on Docker Hub, maybe even being more comfortable paying for it.

On the flip side, far too much of the dev ecosystem would depend on Microsoft, the famed supervillain of open communities. EDIT: With that sense in mind, I am indeed rooting for Docker Inc. to succeed.

4 comments

> if Docker Inc. were to be bought out by Microsoft...

You can always use Podman. We already have fully OSS solutions in the container space.

On my personal computer and projects I always use Podman. There is even a fancy web app if people desperately want a cool icon on their menu bar, though it pales in comparison to Docker Desktop in features. (For instance, it's not able to search for images, whereas Docker Desktop can).

I do not miss Docker at all considering that I can copy paste almost every docker invocation I see online and have it run flawlessly with Podman. Unfortunately my workplace will probably never even consider trying out Podman as a replacement to Docker. I wonder if someone here has a nice anecdote of using Podman successfully at their workplace.

We are now on the Podman train. We used Docker for a while on some parts of our services. We did a thorough comparison of Podman and Docker when it was time to move over all the rest of our legacy-deployed services. Podman won out on many technical, subjective, and future-looking topics. Feels good, everybody is on board here.
Big ask but I'm sure that would make a fantastic blog post...
Since you seem to miss the GUI, have you tried Podman desktop?
Call me when podman fully supports the Compose spec(so Docker compose V2)
Podman speaks the Docker API these days so you can use docker-compose with it.
With no support for starting containers on startup using `restart: always` or buildkit
podman runs or builds containers? as far as i understand it docker desktop does 2 or 3 different things and i haven't managed to untangle that yet because it hasn't fully broken my workflow yet. getting more and more tempting to remove it but i need something for my weird windows+wsl setup
> podman runs or builds containers?

It does… in the same sense that docker (the program/tool) does, that is: both are not container runtimes (such as containerd which docker uses, or runc and crun which are the options typically used with podman) but a container management tool that control a container runtime. So you would indeed use podman to create a container just like you would with docker.

As for building images, buildah is the tool most used in the podman community for that. and yes, both podman and docker can handle containerfiles (what is/was called "dockerfiles" in the docker world)

> need something for my weird windows+wsl setup

oh, well, uhm, my condolences for that. Luckily I never had to use that for containers, but a quick look on the podman homepage tells me that they also offer a virtualized WSLv2-based distribution for Windows users: https://podman.io/getting-started/installation.html#windows …And of course, there is Podman Desktop if you want something more click-UI-based than the command line podman (never really tried it though, so I can't really say if it's good or not): https://podman-desktop.io/

Docker Desktop runs dockerd in WSL and adds a few things to enable working with it from Windows (e.g. installs the docker CLI on the Windows side and exposes the dockerd control socket to it). You can easily get rid of it and replace it with running dockerd in WSL on your own, or with podman-based tools.
Docker did do something smart with Docker Desktop by including wsl-vpnkit...to work around brain-dead corporate VPNs that break docker networking. Your alternative solutions don't work when AnyConnect or GlobalProtect, etc, are running.
With AnyConnect you can definitely work around enough to make WSL2 + dockerd functional: https://gist.github.com/pyther/b7c03579a5ea55fe431561b502ec1...
This is only partially true, if _all_ traffic is tunneled over the vpn, then yes you’ll have this issue, but if the traffic is split such that only interesting traffic is sent over the vpn, then you won’t have this issue.
AWS Client VPN breaks it just by having ever run, even if not currently active, as it sets `sysctl net.ipv4.ip_forward=0` 'for you'.

My suspicion is that since you pay for client connections, they don't want you running a single bastion client and having your real clients connect via that. But it's annoying, and if you really wanted to do that, you only have to edit the script, or set it back on a schedule/after starting up the client.

Yes, though the end user has no control over that knob...the corp end can turn off split tunneling and it's off by default.
Where do you host the base images? Someone's footing that bill or are you paying for it?
Why not decentralized? Debian (for example) can provide one or two servers with a gigabit line. That's going to be quite slow to download during every CI build. Therefore, your CI provider would have a caching proxy registry. You get fast service, upstream doesn't need a ton of bandwidth.
Docker images are often tied to CI runs. So a Github action is configured to "bake" a docker image that saves the image to Github Container Registry and a CI platform is triggered to pull the image and run tests immediately thereafter. Imagine this happening on every Git commit in a certain branch.

Often, there isn't time for an image to be pulled from a mirroring serving.

I meant the base images. If you're pushing your own images, then you can use any service you want (and pay for it). Since the traffic doesn't need to go through the internet at all, the bandwidth cost to Dockerhub would be irrelevant.
Base images are already available on different container image hosting platforms. For instance, ubuntu is here [1] on Amazon ECR. So it's matter of updating Dockerfiles to use them.

There again there's the question of finding image sources you can trust to be updated and secure. Docker Hub has a "Docker Official Image" tag for critical base images that are managed by each community.

[1] https://gallery.ecr.aws/ubuntu/ubuntu

> I shudder to think how much of the dev ecosystem would yet again depend on Microsoft's good graces to shoulder the burden of storage and data transfer costs for building products

Does that hint that the model of sending around megabytes-to-multigigabytes of VMs is inherently too expensive to maintain as a backbone for an awesome tool?

For the same reason, I wonder why provides Maven Central and NPM repositories, whether they will do it for free, but at least those are billions of small jars, not hundreds of thousands of gigabyte-sized VMs.

> model of sending around megabytes-to-multigigabytes of VMs is inherently too expensive

Yes. I think automated build pipelines running 24x7 that could request even for the oldest version of a sizable image without caching at their end is part of the issue. There was no limit that I'm aware of on the no. of tags/versions per image or per OSS account on DockerHub, so just like package repositories, effectively every image had to be available forever and each image was of significant size. I don't believe storage and network tx costs have reduced at the same rate as increase in adoption of build pipelines and automation.

Same issue exists for apt, NPM, Maven, PyPi, or any other repository, but yes, the storage requirement should be significantly smaller.

Aside: Because Java has been around for so long in enterprises, many have learned over time to set up registries internally - a combination of wanting to host private packages securely on prem and protecting from downtime, supply-chain attacks. JFrog Artifactory is pretty commonly seen. However, IIRC npm registry was not easy to self-host on prem in the early days, and many enterprises had their private packages hosted on npm.

The ISO mirrors of every Linux / BSD* have been successful for decades. Decentralized repositories could solve many problems. Add Bittorrent as acceptable usage pattern like the free AI community is using to solve it even further, the Internet was not designed to be centralized IMHO.
The difference is that the average distro user cannot just push a new ISO image to the mirror network, say after changing some installer defaults (or more realistically, push a new QCOW2 image). There's also a substantial delay between mirror pushes and the update being ready for installation everywhere, something that developers probably would not accept in their pipelines.
>Microsoft, the famed supervillain of open communities.

FOSS: "Never thought I'd die fighting side by side with Microsoft."

Microsoft: "What about side by side with a friend?"

FOSS:

Since Azure became the most relevant platform for Microsoft business, DevDiv now under Azure organigram, has turned into a polyglot unit, not only about .NET and C++, rather anything that can bring developers into Azure.

Who would imagine that 20 years later, Microsoft would become yet again a Java vendor, with their own OpenJDK based distribution and upstream contributions to ARM JIT, and escape analysis improvements?

they're hosting npm now? i didn't know