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

App Container and Docker

coreos.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: App Container and Docker

#41

Post by bjt »

film42 wrote: post #35
panarky wrote: post #24

Earlier quoted context omitted.

Shykes > Can someone explain to me how the user benefits from this? As a user, it would be fantastic to run my App Container images on Docker hosts, and Docker images on Rocket hosts. If only I could move my virtual machine images this easily and avoid high switching costs between platforms. Shykes > just do it in your own project and let the best project win ... you have to choose one or the other Bullshit. If it's…

I see what Shykes is getting at though. I mean, if you want to use the rocket, then use the rocket. If you want to use docker, then how does adding another runtime help a docker user, when they could simply switch to rocket? I can understand how their might be a "convenience" factor, but if you're already actively deploying with docker images, then why bother with a separate image type? Don't get me wrong, I think it…

Rocket != App Container. This PR is about the latter. There are already non-Rocket implementations of the App Container spec.

If I were a Docker user, and found some awesome app that only came packaged in App Container format, it'd be very valuable to have this compatibility.

Re: App Container and Docker

#42

Post by m_mueller »

dmourati wrote: post #37
philips wrote: post #12

Earlier quoted context omitted.

All of us want containers to be successful, they solve a ton of problems. But, part of that success is getting the format and the security correct. And we want to have that technical discussion and settle on those best practices for all implementations. There are things in the App Container spec that we would like to see in Docker, this is why we put in the work to make a spec, write the code to make it work and star…

"they solve a ton of problems" Name two?

Deploying to a cleanly defined fresh state without paying any performance penalty. Documenting your dependencies by writing the deployment script (=Dockerfile) and not having to reinvent the wheel everytime (image inheritance). Sandboxing linux applications without paying any performance penalty. Creating a PaaS where your services internally always see the same standard port, externally they're linked together through docker, thus separating the routing concerns from your application logic.

Re: App Container and Docker

#45

Post by tiramisou »

panarky wrote: post #24
Goopplesoft wrote: post #21

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-743... Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker…

Shykes > Can someone explain to me how the user benefits from this? As a user, it would be fantastic to run my App Container images on Docker hosts, and Docker images on Rocket hosts. If only I could move my virtual machine images this easily and avoid high switching costs between platforms. Shykes > just do it in your own project and let the best project win ... you have to choose one or the other Bullshit. If it's…

Agreed, it is a bit like saying: We do not need a standard http protocol. If you want to use Firefox use Firefox, otherwise use Chrome. No need that they display the same web pages.

Re: App Container and Docker

#46

Post by iso8859-1 »

m_mueller wrote: post #42
dmourati wrote: post #37

Earlier quoted context omitted.

"they solve a ton of problems" Name two?

Deploying to a cleanly defined fresh state without paying any performance penalty. Documenting your dependencies by writing the deployment script (=Dockerfile) and not having to reinvent the wheel everytime (image inheritance). Sandboxing linux applications without paying any performance penalty. Creating a PaaS where your services internally always see the same standard port, externally they're linked together throu…

Why do you mention like Linux? Containers shouldn't be specific to Linux.

Re: App Container and Docker

#47

Post by m_mueller »

iso8859-1 wrote: post #46
m_mueller wrote: post #42

Earlier quoted context omitted.

Deploying to a cleanly defined fresh state without paying any performance penalty. Documenting your dependencies by writing the deployment script (=Dockerfile) and not having to reinvent the wheel everytime (image inheritance). Sandboxing linux applications without paying any performance penalty. Creating a PaaS where your services internally always see the same standard port, externally they're linked together throu…

Why do you mention like Linux? Containers shouldn't be specific to Linux.

Well.. in Docker's case they are? It's based on lxc, a Linux kernel technology. Of course BSD had it before that, although with a different name.

Re: App Container and Docker

#48

Post by vezzy-fnord »

m_mueller wrote: post #47
iso8859-1 wrote: post #46

Earlier quoted context omitted.

Why do you mention like Linux? Containers shouldn't be specific to Linux.

Well.. in Docker's case they are? It's based on lxc, a Linux kernel technology. Of course BSD had it before that, although with a different name.

Docker hasn't been based on LXC since 0.9 by now. It uses its own libcontainer.

Re: App Container and Docker

#49

Post by m_mueller »

vezzy-fnord wrote: post #48
m_mueller wrote: post #47

Earlier quoted context omitted.

Well.. in Docker's case they are? It's based on lxc, a Linux kernel technology. Of course BSD had it before that, although with a different name.

Docker hasn't been based on LXC since 0.9 by now. It uses its own libcontainer.

Which to my knowledge ist still linux-only, so while it's good to be technically correct, it doesn't change my point.

Re: App Container and Docker

#50

Post by vezzy-fnord »

m_mueller wrote: post #49
vezzy-fnord wrote: post #48

Earlier quoted context omitted.

Docker hasn't been based on LXC since 0.9 by now. It uses its own libcontainer.

Which to my knowledge ist still linux-only, so while it's good to be technically correct, it doesn't change my point.

That much is correct, it's still tied to namespaces, cgroups and the standard mechanisms for implementing jailing on Linux. The point is it stands at a layer of abstraction designed for easier portability than outright depending on LXC.
Post reply on HN