Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changes to Docker Hub Autobuilds

docker.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Changes to Docker Hub Autobuilds

#41

Post by ridv »

pm90 wrote: post #28
WnZ39p0Dgydaz1 wrote: post #14

Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.

Agreed. Docker (actually, containers in general but docker tooling) made it so damn easy to get local, reproducible builds. It’s fantastic and made life so much easier for me professionally as a Software Engineer. I remember the early days when Docker had just released, all devs were super excited but nobody had run containers “in production”. AFAIK I believe it was mesos that was used widely for orchestrating contai…

The history of the relationship between Mesos and Docker is definitely an interesting one. If memory serves right, Mesos was not keen of supporting Docker as a containerizer. The devs wanted to stick to improving the Mesos containerizer.

In the end, the community was so vocal about Docker being supported in Mesos that it happened, but the end result was not stellar by all accounts (and a bit of a nightmare to deal with on the framework side to boot).

I'm not privy to what was going at the time since I was just part of the larger Mesos community, but looking back, can't help but wonder what would have happened if they collaborated instead.

Re: Changes to Docker Hub Autobuilds

#42

Post by mikepurvis »

nrmitchi wrote: post #24
Jleagle wrote: post #20

Earlier quoted context omitted.

By cryptocurrencies do you just mean BitCoin? Most new crypto's use proof of stake which doesn't use up GPUs. Not heard it blamed for using up hard drives before.

Bitcoin mining also doesn't use GPUs any more, as far as I know that space is almost entirely custom ASICs. > Most new crypto's use proof of stake What (of any substantial volume) uses proof of stake at the moment? That's Ethereum's path, but it's not there yet. Regarding hard drives, I think it's "Chia" that just purposely uses an insane amount of disk space; "proof of space": https://www.theguardian.com/technology/…

> almost entirely custom ASICs

Those are still a cause for chip shortages as crypto customers bid themselves to the front of the line at TSMC:

"Chip manufacturing is already under huge pressure to meet demand, and TSMC is facing a serious water shortage in Taiwan on top of that. Bitmain's order only adds to the pressure, but TSMC clearly wouldn't agree to production if it didn't think it had the spare capacity. Anyone attempting to place new chip orders in the future may end up with a different outcome, though."

https://www.pcmag.com/news/cryptocurrency-miners-are-getting...

Re: Changes to Docker Hub Autobuilds

#43

Post by imiric »

WnZ39p0Dgydaz1 wrote: post #14

Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.

I'm still rooting for them, specifically for Swarm which is a breath of fresh air for small and personal deployments. Though tooling around Kubernetes has improved in the last couple of years and it's much easier to get started now, the system still has a steep learning curve compared to Swarm.

Re: Changes to Docker Hub Autobuilds

#44

Post by Hamuko »

bentsku wrote: post #23
Jleagle wrote: post #20

Earlier quoted context omitted.

By cryptocurrencies do you just mean BitCoin? Most new crypto's use proof of stake which doesn't use up GPUs. Not heard it blamed for using up hard drives before.

Chia coin is using Proof of Space. It is growing really fast and not a really good thing. Even cloud providers are reacting to it. See https://blog.scaleway.com/scaleway-and-chia/

>Chia plotting is extremely I/O intensive and destroys most SSDs in under a few weeks

More like Proof of SSD-shredding.

Re: Changes to Docker Hub Autobuilds

#45

Post by KurtMueller »

imiric wrote: post #43
WnZ39p0Dgydaz1 wrote: post #14

Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.

I'm still rooting for them, specifically for Swarm which is a breath of fresh air for small and personal deployments. Though tooling around Kubernetes has improved in the last couple of years and it's much easier to get started now, the system still has a steep learning curve compared to Swarm.

I'm currently learning both Docker Swarm and Kubernetes (at the same time) and I'm a bit overwhelmed by Kubernetes (VS Code's extension and Kube's documentation helps with that). I just want use the Azure Kube Service to deploy my Rails app...

I'm also trying to learn Docker Swarm mode and both the community and documentation are not as nearly comprehensive as Kubernetes'. And Docker's official documentation and tutorial has me provisioning 3 nodes on a cloud provider instead of just booting up a swarm on my local machine.

And then I see any # of combinations of Docker Swarm with tools like Terraform or Pulumi. It's just all so overwhelming.

I think I'm going to keep banging my head with Kube and its super verbose manifests until I finally get it.

Re: Changes to Docker Hub Autobuilds

#46

Post by nickjj »

vergessenmir wrote: post #26
WnZ39p0Dgydaz1 wrote: post #14

Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.

They are hard for sure. Docker did make some fundamental mistakes early on, especially on community engagement and open stable APIs. It is a shame since I rooted hard for them in the early days.

I've been using Docker since 2014 and IMO they did a great job in terms of API stability from an end user's perspective.

Lots of CLI commands from 5+ years ago still work today and the upgrade story with Docker Compose has been gradual, painless and most importantly pressure-less for having to upgrade.

Re: Changes to Docker Hub Autobuilds

#47

Post by mmbleh »

zwass wrote: post #36

Do folks here have ideas of what will become the best place to host public Docker container images? Between this and the earlier changes to rate limit pulls, Docker Hub no longer seems like the ideal venue for reputable public images. Should we look into implementing our own registry with AWS ECR or similar?

Interesting reaction. This could also be interpreted as making it _more_ reputable, by removing abuse and cruft, allowing engineering time to be focused on things that provide value to end users.

Re: Changes to Docker Hub Autobuilds

#48

Post by imiric »

KurtMueller wrote: post #45
imiric wrote: post #43

Earlier quoted context omitted.

I'm still rooting for them, specifically for Swarm which is a breath of fresh air for small and personal deployments. Though tooling around Kubernetes has improved in the last couple of years and it's much easier to get started now, the system still has a steep learning curve compared to Swarm.

I'm currently learning both Docker Swarm and Kubernetes (at the same time) and I'm a bit overwhelmed by Kubernetes (VS Code's extension and Kube's documentation helps with that). I just want use the Azure Kube Service to deploy my Rails app... I'm also trying to learn Docker Swarm mode and both the community and documentation are not as nearly comprehensive as Kubernetes'. And Docker's official documentation and tuto…

It's been a while since I've read the Swarm documentation, but it was fairly comprehensive from what I remember. If you're referring to this tutorial[1], note that you don't need to use a cloud provider, and you can also do it with local VMs.

Actually you don't even need a cluster of machines. While Swarm can easily scale out, you can get started with a single machine and figure out the clustering later. Even on a single machine there are benefits of using Swarm over plain Docker (Compose): stacks, secrets, advanced networking. So you can test it out there and add more machines as you need it.

One thing I'd suggest is to first get familiar with Docker itself, since Swarm simply builds on these concepts and adds orchestration. Use `docker run`, understand volumes, images, permissions, user namespaces, cgroups, etc. Then move on to Docker Compose and get familiar with the configuration, services, etc. And then finally pick up Swarm, which even uses the same Docker Compose configuration file (with slight variations), so it should be fairly straightforward at that point.

Though honestly, learning Swarm in 2021 might not be a good investment, since Kubernetes is clearly the market leader, and I wouldn't be surprised to read a sunset notice about it, even though Docker Inc. is still supporting it. So you're probably making a good decision to stick with k8s.

Good luck!

[1]: https://docs.docker.com/engine/swarm/swarm-tutorial/

Re: Changes to Docker Hub Autobuilds

#49

Post by captn3m0 »

zwass wrote: post #36

Do folks here have ideas of what will become the best place to host public Docker container images? Between this and the earlier changes to rate limit pulls, Docker Hub no longer seems like the ideal venue for reputable public images. Should we look into implementing our own registry with AWS ECR or similar?

ECR Pblic, but Quay[0]'s free plan is still without limits. Rooting for them against the crypto-miners.

>Yes! We offer unlimited storage and serving of public repositories.

[0]: https://quay.io/

Re: Changes to Docker Hub Autobuilds

#50

Post by vergessenmir »

nickjj wrote: post #46
vergessenmir wrote: post #26

Earlier quoted context omitted.

They are hard for sure. Docker did make some fundamental mistakes early on, especially on community engagement and open stable APIs. It is a shame since I rooted hard for them in the early days.

I've been using Docker since 2014 and IMO they did a great job in terms of API stability from an end user's perspective. Lots of CLI commands from 5+ years ago still work today and the upgrade story with Docker Compose has been gradual, painless and most importantly pressure-less for having to upgrade.

They got the developer facing API just right making containers accessible but their promised plugin architecture never did come.

There was an arms race between them and the community to lead the story on new functionality. For example flannel came out first before docker acquihired SocketPlane for networking, while Calico was also in the works.

There was pressure from the community for a stable plugin API to allow for external contribution, but I imagine that it was ultimately against their best interest

Post reply on HN