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

31–40 of 64 posts

Re: App Container and Docker

#31

Post by bmelton »

xnxn wrote: post #30
conradk wrote: post #25

Earlier quoted context omitted.

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…

To clarify, I don't want to run my own registry and I don't want to rely on any third party for image hosting. I just want to pull tarballs from a dumb file server. No need to run a registry for that, and no one company has a privileged position in the namespace. It's maddening, because I love Docker-the-concept but not Docker-the-implementation nor Docker-the-ecosystem. I honestly do understand how many would find t…

> I just want to pull tarballs from a dumb file server.

Is there something I'm missing that you couldn't just use wget? If you have the URIs, I can't imagine how pulling down an image by name would be more than a quarter-page Python script, even if you include the untarring and such.

Re: App Container and Docker

#32

Post by josh2600 »

nstott wrote: post #29

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 migr…

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-pulldock...

Re: App Container and Docker

#33

Post by xnxn »

bmelton wrote: post #31
xnxn wrote: post #30

Earlier quoted context omitted.

To clarify, I don't want to run my own registry and I don't want to rely on any third party for image hosting. I just want to pull tarballs from a dumb file server. No need to run a registry for that, and no one company has a privileged position in the namespace. It's maddening, because I love Docker-the-concept but not Docker-the-implementation nor Docker-the-ecosystem. I honestly do understand how many would find t…

> I just want to pull tarballs from a dumb file server. Is there something I'm missing that you couldn't just use wget? If you have the URIs, I can't imagine how pulling down an image by name would be more than a quarter-page Python script, even if you include the untarring and such.

Yeah, that's about what I've been doing, but AFAICT I lose the benefits of layering when I refuse to speak the registry protocol. Docker's export command dumps the entire image tree, so I'm stuck transferring GB-sized payloads to deploy the tiniest change to my app. appc manages to do layers without a coordinating registry. (Kind of funny that CoreOS bought Quay, on that note.)

Re: App Container and Docker

#34

Post by nstott »

josh2600 wrote: post #32
nstott wrote: post #29

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 migr…

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-pulldock...

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

Re: App Container and Docker

#35

Post by film42 »

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…

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.

Re: App Container and Docker

#36

Post by Goopplesoft »

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…

> just do it in your own project and let the best project win > Bullshit. If it's open, let the best idea win.

So are you suggesting docker should merge and maintain support for a container spec they weren't involved with which, was created because docker is "fundamentally flawed"?

I'm sure the pull-request author knew that this would do nothing more than cause fuss in the community. Shykes comment seems to me like it was a response to what seems like a hardly legitimate PR and much like a PR stunt.

Docker has 722 contributors on github, I'm sure the community will discuss and decide what to do with this while I watch this battle play out and work with both products.

Re: App Container and Docker

#37

Post by dmourati »

philips wrote: post #12
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…

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?

Re: App Container and Docker

#38

Post by burke »

Goopplesoft wrote: post #36
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…

> just do it in your own project and let the best project win > Bullshit. If it's open, let the best idea win. So are you suggesting docker should merge and maintain support for a container spec they weren't involved with which, was created because docker is "fundamentally flawed"? I'm sure the pull-request author knew that this would do nothing more than cause fuss in the community. Shykes comment seems to me like i…

I can't speak for panarky, but there are two separate issues here:

1. Rocket implementing the docker image format

2. Rocket PR'ing the rocket image format to docker.

It is 100% reasonable and likely a good business move to reject the PR, but the only reason to be mad about (1) is if it benefits the end user in a way that weakens Docker's market share, which it does.

Re: App Container and Docker

#39

Post by rdtsc »

philips wrote: post #12
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…

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…

> All of us want containers to be successful, they solve a ton of problems.

Not sure I want containers to be successful (unless of course the main business is building and marketing containers). I want my problem solved but whether they are solved with containers, mocks, jails, VMs, and so on doesn't matter as much.

Re: App Container and Docker

#40

Post by rdtsc »

panarky wrote: post #26
shykes wrote: post #16

Earlier quoted context omitted.

Brandon, let me respectfully ask you 3 questions: 1) As you very well know, Docker is already working on cryptographic signature, federated DNS based namespace and simple hosting on object stores. If you "would like to see convergence", why didn't you join the effort to implement this along with the rest of the Docker community? The design discussion has been going on for a long time, the oldest trace I can find is a…

> 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

Post reply on HN