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

Docker

computer.rip

Post reply on HN
Print view View original

31–40 of 145 posts

Re: Docker

#31

Post by femto113 »

jcrawfordor wrote: post #15
mitchellh wrote: post #10

I’m someone who had a front row seat to the emergence of Docker, and some might say competed with them (I’d disagree on that point). I don’t plan on commenting on their company, business model, or recent decisions. The only thing I want to comment on is the claim Docker was evolutionary, not revolutionary. I disagree, I believe Docker /was/ revolutionary. And I feel like I see heavy technologists make this sort of di…

(author) I'm not sure that we really disagree, but I wrote this sort of late and I also think I wasn't entirely clear. The point I was trying to make is that the "container runtime" part of Docker is a lot less important than the tooling they put around it, and they made Docker Hub a very core part of that broader ecosystem.

I think that in many ways creating a shared, stable namespace for images was actually a bigger contribution than any of the technology. The ability to type somtething like 'FROM python:3' at the top of your Dockerfile and have that automagically mean what you expect was definitely revolutionary in terms of productivity. Behind the scenes I don't know it really matters that much whether that references an image hosted in a repository by Docker the company, or a file in AWS S3, or a tarball from the Python Software Foundation. And that namespace is exactly what they're stabbing in the heart.

Re: Docker

#32

Post by ghshephard »

berkle4455 wrote: post #14

okay so swarm is dead, but is kubernetes actually that good or is it just ubiquitous and you’re forced to use it today? what about nomad? or mrsk?

Nomad is awesome and works at scale. The engineers continue to battle harden it and it’s a joy to work with. You do have to manage things like service discovery (usually with consul) and traffic routing separately - but the integration with vault is sublime.

About the only real negative of Nomad is that it doesn’t have the mindshare that k8s does, so you don’t see the amount of developer engagement in extending it the way you do in the k8s SIGs. Also, being an expert in Nomad doesn’t give you the same number of career opportunities, and on the other side - there aren’t umpteen thousand nomad SREs the way there are with k8s - so getting someone up to speed can take a couple months (but this system is very well defined, well documented, and small enough that any half talented engineer can master it very quickly)

Nomad does have the very important advantage that Hashicorp stands behind the product - so if anything goes awry, you’ve got a support team and escalation that will jump on and root cause/resolve any issue, usually within a matter of hours and even in the really squirrelly cases (that you are only likely to see when when you are managing many, many thousands of nodes in a cluster) within days.

Re: Docker

#33

Post by _boffin_ »

Question: Possible for Docker to die as a company; VC's lose their money; the technology survives and is still the mainstay? if the answer is no, what's the future and what do you expect the timeline will be? have a probability of that actually occurring?

Re: Docker

#34

Post by wmf »

_boffin_ wrote: post #33

Question: Possible for Docker to die as a company; VC's lose their money; the technology survives and is still the mainstay? if the answer is no, what's the future and what do you expect the timeline will be? have a probability of that actually occurring?

Possible for Docker to die as a company; VC's lose their money; the technology survives and is still the mainstay?

Yes, this is the default assumption.

Re: Docker

#35

Post by wmf »

bobleeswagger wrote: post #17

I think we're past the point where key players like AWS have _ran with_ the technology Docker provided and did not pay their fair share in the process. Docker as a company may be a joke, but I don't think the software will be nearly as nice to use without them. I think it's ridiculous that so many asshats are jumping on the hate Docker (the company) bandwagon without understanding how much they have been taken advant…

No one will pay unless you force them. We can wish all we want that the world is different but I've seen this over and over. You need to hold something back from day one or you'll never make money.

Re: Docker

#36

Post by rtpg »

_boffin_ wrote: post #33

Question: Possible for Docker to die as a company; VC's lose their money; the technology survives and is still the mainstay? if the answer is no, what's the future and what do you expect the timeline will be? have a probability of that actually occurring?

I don’t know how Docker Hub falling by the wayside plays out. I suppose most cloud providers really should offer their own container image repo mirrors or something instead. But it’ll be painful

Wild to me that Docker inc. Doesn’t just charge to pull prebuilt images. Just send docker files!

Re: Docker

#38

Post by rcoveson »

cortesoft wrote: post #24

> In particular, the union file system (UFS) image format is a choice that seems more academically aspirational than practical. Sure, it has tidy properties in theory, but my experience has been that developers spend a lot more time working around it than working with it. What is the alternative that is better? The ability to have layers that build on top of each other and can be cached is a big feature... what alter…

IMO image definitions should be a list of mounts that may be overlays on root but may also be more “normal” mounts to directories within root. I should be able to make an image that is ubuntu:bionic plus a conda installation at /opt/conda plus a personal package at /usr/local/mything. Currently you have to decide on how to stack those layers, which is unnatural and prevent sharing/deduplication of partial-file system images where there’s no reason to prevent it.

Taken to the extreme, look at something like Nix (or conda, come to think of it). Why can’t I just have one copy of a package of a given version shared by all containers, if they all want that package? Unix file systems should be great at that kind of composibility; that’s the advantage of a unified tree instead of a tree-per-source. But in the docker model, you’re stuck with a stack.

My ideal image definition is a hybrid between docker’s immutable hash-addressed image layers and an fstab file to describe how and where to mount them all.

Re: Docker

#39

Post by EamonnMR »

ghshephard wrote: post #26

As a newcomer to the devops world I was kind of surprised at the general thesis of this article, that companies use docker hub and using something different is awkward. Neither of the two companies I’ve worked for use it (artifacory in both cases) and there is a general taboo around having docker desktop binaries on any company systems (though docker engine seems to be prevalent). I guess I had just assumed that the…

What I've deen is in-house base images in AWS's registry but still pulling stuff like Fedora base images from dockerhub.

Re: Docker

#40

Post by thristian »

cortesoft wrote: post #24

> In particular, the union file system (UFS) image format is a choice that seems more academically aspirational than practical. Sure, it has tidy properties in theory, but my experience has been that developers spend a lot more time working around it than working with it. What is the alternative that is better? The ability to have layers that build on top of each other and can be cached is a big feature... what alter…

The POSIX standard requires certain behaviours from the filesystem, that POSIX-compliant software can rely on.

Unfortunately, those behaviours are mutually exclusive with transparent layering.

It's certainly possible to build a file-system whose behaviours are compatible with that kind of transparent layering - Plan9 was built on exactly that model, for example - but then it wouldn't be a POSIX-compliant filesystem anymore.

The promise of Docker was that you'd be able to deploy your existing applications in a more reliable, repeatable way, but that breaks down when you have to tinker with your application's file-handling code, or jump through extra hoops to flatten the layers of your container's filesystem image.

Post reply on HN