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

51–60 of 64 posts

Re: App Container and Docker

#51

Post by vidarh »

dkarapetyan wrote: post #11
ABS wrote: post #10

little bit of snark: wasn't Docker "fundamentally flawed"? If that was really the premise to launch Rocket why bother with this humongous PR? Don't get me wrong, I totally see how this is good for Rocket, just be honest and admit the "fundamentally flawed" argument was mainly smoke and mirrors to justify a defensive-offensive move by a VC-backed, for-profit company launched against another VC-backed, for-profit compa…

Ya, the messaging is starting to get really confusing. If the container formats really are that similar then there is no point in two parallel implementations, either augment docker containers or app containers. Doing both at the same time is just silly since from the looks of it they are going to converge on the same format anyway.

Basically App Containers is about laying down the gauntlet for Docker because the changes they are asking for are/were unlikely to be accepted without backing them up with the pressure of facing a competing project if they're not.

The federated nature of image identity that CoreOS is pushing for is a direct challenge to the special status that Docker has given index.docker.io, and that they have been strongly resisting attempts to change.

I don't care much if Rocket or Docker "wins", but I really hope the App Container federated approach does.

Re: App Container and Docker

#52

Post by vidarh »

conradk wrote: post #25
xnxn wrote: post #20

Earlier quoted context omitted.

I've got a use case. ACI support would let me use containers without being coupled to Docker's registry. I really don't want to run that software, and I really, really don't want to rely on Docker Hub. ACI's use of existing standards for their "registry" implementation is a major draw for me.

Actually, I think you don't have to rely on Docker's registry: - you can simply use Dockerfiles and build your own images, - apparently, it seems like you can host your own registry [1] - you can even use a service run by CoreOS, ie Quay, to host your Docker images [2] I'm not sure I understand what you mean by "I really don't want to run that software". Does it mean you don't want to use Docker ? [1] https://blog.do…

Yes, you can run your own registry, but doing so without every pulling anything from DockerHub means rebuilding all images yourself and tagging all of them for your own registry and pushing to that, or DNS / firewall hacks to redirect requests for index.docker.io (or forking Docker).

They've made it much harder than necessary.

Re: App Container and Docker

#53

Post by vidarh »

dkarapetyan wrote: post #15
philips wrote: post #14

Earlier quoted context omitted.

This initial discussion is just about the container image format and we would really like to see convergence on that front. As container runtimes Rocket and Docker have different design goals though. As one example, Rocket is designed to be a standalone tool that can run without a daemon and works with existing init systems like upstart, systemd and sysv. We needed this standalone property because on CoreOS container…

In that case I don't see how the image format ties into any of what you just said. Seems to me the image format is completely irrelevant. Docker's format could be augmented to include all the security features you want and rkt could just use docker containers. That's where the confusion is. It is clear that the image format is orthogonal to all the other issues you mentioned. By the way I don't have a dog in this rac…

It's not just the image format, it's about getting the DNS based federation and content-addressible images, which effectively takes away "index.docker.io"'s special status.

And that's where the problem is. I can very much understand why Docker sees holding onto that as a great advantage to them, but it's not an advantage to me as a user.

Re: App Container and Docker

#54

Post by dmourati »

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…

These are all great but I get the most of the same benefits from VMs and many more:

fresh state/ no performance penalty (AMI+autoscaling) Document dependencies, not reinvent (Packer file) Sandboxing (same) Always use same standard port (easier with VMs as 1:1 map)

I know most people think that containers/docker/whatever new stack does these things better and they may be right. The benefits however don't outweigh the costs in weaker toolset and less mature stack.

For my use cases, the biggest problem is that containers don't solve the "where does this run" question. Whenever I ask this, people loudly exclaim "anywhere!" which is the same as "I don't know" to me.

AWS AMIs run in 11 regions x N AZs around the world. This solves a much bigger technical problem for me than "it's lighter weight and easier to do incremental releases on top of" which seem to be the only things in favor of containers.

Many people, including Amazon, say "run containers on VMs!" This seems unnecessarily complex for little additional gain.

I'm really curious if the containerization folks are using Packer and if not why not.

Re: App Container and Docker

#55

Post by vidarh »

rdtsc wrote: post #40
panarky wrote: post #26

Earlier quoted context omitted.

> How will it benefit Docker users to have to memorize a new command-line option User here. I couldn't care less about a new command-line option, but it would be worth a lot if I could run any image on any platform. If you claim this is "all about the user" then talk more about what the user gains or loses. Is the biggest downside really just another command-line option? Docker already has a metric fuckton[1] of comm…

> but it would be worth a lot if I could run any image on any platform. That technology exists, it is called a VM. Any platfrom that supports x86 for example will run any x86 compatible image. You can use wrappers and scripts like Vagrant on top of it. Or if you want all hosting managed as a pool of resources (storage, CPU) try something like oVirt. http://www.ovirt.org/About_oVirt

And VMs far more heavy-weight and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads

Re: App Container and Docker

#56

Post by wmf »

bjt wrote: post #41
film42 wrote: post #35

Earlier quoted context omitted.

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.

Are there any such apps in reality? Will there ever be?

Re: App Container and Docker

#57

Post by eropple »

wmf wrote: post #56
bjt wrote: post #41

Earlier quoted context omitted.

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.

Are there any such apps in reality? Will there ever be?

I'd like to use Rocket personally (I currently use Docker--while I think CoreOS's "containers everywhere" concept is a little misguided, I don't believe there's a good reason to have a permanent daemon, and if I need one I have Mesos) but make things I do easily available to Docker users.

(Docker's beefs here feel more like a company defending their turf than an open-source project, and that troubles me.)

Re: App Container and Docker

#58

Post by eropple »

tbatchelli wrote: post #9
userp wrote: post #8

Earlier quoted context omitted.

> There is a lot more that can be gained by these communities working together and not promoting divisiveness. Gained by who though? These are for-profit enterprises and there are real-money gains involved in controlling the spec. For better or worse, CoreOS controls the App Container spec and make no mistake that the primary reason they want it in Docker is because it benefits them. This of course does not exclude t…

Competition is benefitting users and producing some relative waste of resources on each company. We are benefitting because at the end of the day the container world will be more open. But I think that this VC-backed model might not be beneficial for OS as a business in the mid-long term. The race to $0 is greatly accelerated.

Do you think that the VC-backed model is good for open-source as an ecosystem, even if not a business? Because, watching the growth of Docker and CoreOS, I'm starting to wonder if it isn't just a tire fire for us at every level.

Re: App Container and Docker

#59

Post by eropple »

dmourati wrote: post #54
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…

These are all great but I get the most of the same benefits from VMs and many more: fresh state/ no performance penalty (AMI+autoscaling) Document dependencies, not reinvent (Packer file) Sandboxing (same) Always use same standard port (easier with VMs as 1:1 map) I know most people think that containers/docker/whatever new stack does these things better and they may be right. The benefits however don't outweigh the…

I run containers in Amazon. Not using their service, because their service is silly, but on Mesos.

I am not locked into a 1:1 tenancy between applications and instances (though I could have it if I wanted). Multitenancy is trivial. I have the ability to spin up new instances of my applications to combat spike loads or instance failures in single-digit seconds rather than in minutes. My developers can run every container within a single boot2docker VM instead of incurring the overhead of running six virtual machines. It's easier to integration-test because my test harness doesn't have to fight with Amazon, but can rather use a portable, cross-service system in Mesos. In addition, I don't have to autoscale with the crude primitive of an instance in production. Multitenancy means that I can scale individual applications within the cluster to its headroom, and only when the entire cluster nears capacity must I autoscale. I can better leverage economies of scale, while allowing me to leverage more vCPU power to applications that need it (running two dozen applications on a c3.8xlarge is very unlikely to bring to bear at any given time less computational performance to a given application than running each application on its own m3.medium).

I could do this without containers and with only Mesos. It would be worse, but I could do it. I could not do this at all with baked AMIs and instances without spending more money, doing more work, and being frustrated by my environment. I know this I've built the same system you describe (I preferred vagrant-aws because when something broke it was easier to debug, but we moved to Packer before I left) and I would never go back to it. It was more fragile and harder to componentize than a containerized architecture with a smart resource allocation layer. The running context of a container should be "anywhere", and it should be "I don't know", and you caring about that is a defect in your mental model.

Re: App Container and Docker

#60

Post by rdtsc »

vidarh wrote: post #55
rdtsc wrote: post #40

Earlier quoted context omitted.

> but it would be worth a lot if I could run any image on any platform. That technology exists, it is called a VM. Any platfrom that supports x86 for example will run any x86 compatible image. You can use wrappers and scripts like Vagrant on top of it. Or if you want all hosting managed as a pool of resources (storage, CPU) try something like oVirt. http://www.ovirt.org/About_oVirt

And VMs far more heavy-weight and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads

> and doesn't address any of the reasons why people prefer containers to VMs for some types of workloads

I was responding to one reason -- which is "running any image on any platform".

> why people prefer containers to VMs for some types of workloads

Sure but there are no magic unicorns underneath, knowing what you get from a technology requires some understanding on how it works. Saying things like "I want very lightweight but also want it to run any image on it" is asking for a trade-off. Or a complicated multi-host cabaility based platform.

Post reply on HN