13 ms·

App Container and Docker

226 points by thousandx 12y ago

efuquen 12y ago
> At the same time as adding Docker support to Rocket, we have also opened a pull-request that enables Docker to run appc images (ACIs). I really hope this lands and something constructive can come out of it. There is a lot more that can be gained by these communities working together and not promoting divisiveness.
- AndrewHampton 12y ago
  I agree, I think it would be much better for everyone if the two container specs merged. However, after reading "This is a simple functional PR..." in the blog post, I was surprised to see the PR adds over 38k lines of code. Seems like that will take a while to review.
  - shawnps 12y ago
    Most of those lines added are appc getting vendorized
  - shawnps 12y ago
    Most of those lines added are appc getting vendorized
- rohansingh 12y ago
  Same here. It is a pretty huge PR though, without having gone through the usual design proposal process (i.e., https://github.com/docker/docker/blob/master/CONTRIBUTING.md#design-and-cleanup-proposals https://github.com/docker/docker/blob/master/CONTRIBUTING.md...).
  - philips 12y ago
    We wrote a proposal along with the PR: https://github.com/docker/docker/issues/10777 https://github.com/docker/docker/issues/10777 Adding a PR with working code was simply to show that adding this feature is something that is possible. It is OK if nothing from this implementation gets merged.
    - rohansingh 12y ago
      Yup, saw that. I do hope you guys are able to figure it out and get things merged.
- userp 12y ago
  > 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 the possibility that users benefit. Still, I'm of the opinion that all of this fighting behind the scenes (which, if you've been paying attention, this is) is kind of bad for everyone and a waste of resources.
  - tbatchelli 12y ago
    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.
    - eropple 12y ago
      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.
      - tbatchelli 12y ago
        Might send Open Source back to how it was pre-Red Hat. Whether that's good or bad, I don't know.
ABS 12y ago
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 company. Again nothing wrong with that, it's business and in fact a good move but in my eyes CoreOS lost quite some trust when they tried to potray Rocket as a selfless act of kindness towards the community that needed to be saved.
- dkarapetyan 12y ago
  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.
  - philips 12y ago
    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 containers are our package manager and the daemon can get in the way of doing that correctly. It is ok that Docker and Rocket have different design goals and both can exist for different purposes. But, I think we can share and converge on an image format that can be used by multiple implementations that includes cryptographically verifiable images, simple hosting on object stores and the use of a federated DNS based namespace for container names.
    - dkarapetyan 12y ago
      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 race and am not rooting for either side. Just from purely a technical perspective and resource use the fragmentation is now starting to feel something that is mostly driven by public relations and marketing. As someone that tries to use the best tool for the job I now have no compelling reason to choose either format and run-time which means I'm just going to wait it out and both sides are going to lose contributions from independent open source developers because their effort is going to be wasted.
Gigablah 12y ago
I think this is the first "PR PR" I've ever seen :)
Goopplesoft 12y ago
Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-74346219 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 fork/binary instead of a public scene to try to force dockers hand. Lots of fragmentation to come, which sucks because the ecosystem is so important.
- akanet 12y ago
  Yeah, I think my biggest turn off from Rocket is just how PR-oriented all their moves seem to be. I'd be cooler with what they were doing if they appeared to be more open with their motives, but they couch so much of the self-interested stuff they do in terms of benefitting me and "openness". Trips my BS alarm, even if it's legit.
- deleted 12y ago
  [deleted]
- panarky 12y ago
  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 open, let the best idea win. If this is a bad idea, then let the community examine it and it will lose on the merits. Don't force me into a false dichotomy.
  - film42 12y ago
    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's great the coreos guys are trying to make a bridge between the two projects, but so far, I don't see a need for this.
nstott 12y ago
This is useful for us. We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed our own toolset to handle the container images, and to manage the containers. Even though although it kind of deprecates a lot of our work, I really see the value in having a standard that can be used with different container runtimes, and I'll be looking at migrating our internal format to the app container specs. Having tools like this to handle migrations makes a lot of sense to me. We can continue developing our tools, without marrying a specific backend.
- josh2600 12y ago
  You can take a look at the work we've done with containers if you want over at Terminal.com. You can run it on your own metal too if you'd like. We wrote a blog post about running docker containers on it too a while ago: https://blog.terminal.com/docker-without-containers-pulldocker/ https://blog.terminal.com/docker-without-containers-pulldock...
  - nstott 12y ago
    That looks like a useful tool We're running on (mostly) raw lxc, with networking via openvswitch, cgroups, yada yada. so I don't think it's applicable to us at this point A containerized world makes a lot of sense, but it still seems like a really young ecosystem. It's really the 'wild west'at this point. To be honest, I'd rather back an accepted standard, then a specific implementation. Don't get me wrong, Tools like this are super valuable, and generally make my day to day life easier
i_have_to_speak 12y ago
Wow, almost as easy as "apt-get install redis".. (ducks)
- lclarkmichalek 12y ago
  Oh, containers don't improve on apt-get install. They mostly improve apt-get purge.

226 points by thousandx 12y ago

> At the same time as adding Docker support to Rocket, we have also opened a pull-request that enables Docker to run appc images (ACIs). I really hope this lands and something constructive can come out of it. There is a lot more that can be gained by these communities working together and not promoting divisiveness.

AndrewHampton 12y ago
I agree, I think it would be much better for everyone if the two container specs merged. However, after reading "This is a simple functional PR..." in the blog post, I was surprised to see the PR adds over 38k lines of code. Seems like that will take a while to review.
- shawnps 12y ago
  Most of those lines added are appc getting vendorized
- shawnps 12y ago
  Most of those lines added are appc getting vendorized
rohansingh 12y ago
Same here. It is a pretty huge PR though, without having gone through the usual design proposal process (i.e., https://github.com/docker/docker/blob/master/CONTRIBUTING.md#design-and-cleanup-proposals https://github.com/docker/docker/blob/master/CONTRIBUTING.md...).
- philips 12y ago
  We wrote a proposal along with the PR: https://github.com/docker/docker/issues/10777 https://github.com/docker/docker/issues/10777 Adding a PR with working code was simply to show that adding this feature is something that is possible. It is OK if nothing from this implementation gets merged.
  - rohansingh 12y ago
    Yup, saw that. I do hope you guys are able to figure it out and get things merged.
userp 12y ago
> 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 the possibility that users benefit. Still, I'm of the opinion that all of this fighting behind the scenes (which, if you've been paying attention, this is) is kind of bad for everyone and a waste of resources.
- tbatchelli 12y ago
  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.
  - eropple 12y ago
    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.
    - tbatchelli 12y ago
      Might send Open Source back to how it was pre-Red Hat. Whether that's good or bad, I don't know.

ABS 12y ago

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 company. Again nothing wrong with that, it's business and in fact a good move but in my eyes CoreOS lost quite some trust when they tried to potray Rocket as a selfless act of kindness towards the community that needed to be saved.

dkarapetyan 12y ago
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.
- philips 12y ago
  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 containers are our package manager and the daemon can get in the way of doing that correctly. It is ok that Docker and Rocket have different design goals and both can exist for different purposes. But, I think we can share and converge on an image format that can be used by multiple implementations that includes cryptographically verifiable images, simple hosting on object stores and the use of a federated DNS based namespace for container names.
  - dkarapetyan 12y ago
    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 race and am not rooting for either side. Just from purely a technical perspective and resource use the fragmentation is now starting to feel something that is mostly driven by public relations and marketing. As someone that tries to use the best tool for the job I now have no compelling reason to choose either format and run-time which means I'm just going to wait it out and both sides are going to lose contributions from independent open source developers because their effort is going to be wasted.

Gigablah 12y ago

I think this is the first "PR PR" I've ever seen :)

Goopplesoft 12y ago

Shykes latest comment on that github thread has a point: https://github.com/docker/docker/pull/10776#issuecomment-74346219 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 fork/binary instead of a public scene to try to force dockers hand. Lots of fragmentation to come, which sucks because the ecosystem is so important.

akanet 12y ago
Yeah, I think my biggest turn off from Rocket is just how PR-oriented all their moves seem to be. I'd be cooler with what they were doing if they appeared to be more open with their motives, but they couch so much of the self-interested stuff they do in terms of benefitting me and "openness". Trips my BS alarm, even if it's legit.
deleted 12y ago
[deleted]
panarky 12y ago
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 open, let the best idea win. If this is a bad idea, then let the community examine it and it will lose on the merits. Don't force me into a false dichotomy.
- film42 12y ago
  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's great the coreos guys are trying to make a bridge between the two projects, but so far, I don't see a need for this.

nstott 12y ago

This is useful for us. We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed our own toolset to handle the container images, and to manage the containers. Even though although it kind of deprecates a lot of our work, I really see the value in having a standard that can be used with different container runtimes, and I'll be looking at migrating our internal format to the app container specs. Having tools like this to handle migrations makes a lot of sense to me. We can continue developing our tools, without marrying a specific backend.

josh2600 12y ago
You can take a look at the work we've done with containers if you want over at Terminal.com. You can run it on your own metal too if you'd like. We wrote a blog post about running docker containers on it too a while ago: https://blog.terminal.com/docker-without-containers-pulldocker/ https://blog.terminal.com/docker-without-containers-pulldock...
- nstott 12y ago
  That looks like a useful tool We're running on (mostly) raw lxc, with networking via openvswitch, cgroups, yada yada. so I don't think it's applicable to us at this point A containerized world makes a lot of sense, but it still seems like a really young ecosystem. It's really the 'wild west'at this point. To be honest, I'd rather back an accepted standard, then a specific implementation. Don't get me wrong, Tools like this are super valuable, and generally make my day to day life easier

i_have_to_speak 12y ago

Wow, almost as easy as "apt-get install redis".. (ducks)

lclarkmichalek 12y ago
Oh, containers don't improve on apt-get install. They mostly improve apt-get purge.