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

Docker - the Linux container runtime

docker.io

Post reply on HN
Print view View original

71–80 of 209 posts

Re: Docker - the Linux container runtime

#71

Post by niall_ohiggins »

rlpb wrote: post #56
derefr wrote: post #28

Earlier quoted context omitted.

It's not that it's any different, it's that it's standardized . The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead…

So why not use VM images? Why not a VMware vagrant box, for example?

One major benefit over VM images is Linux Containers have very fast spin-up time. This can be especially useful for PaaS providers and CI servers.

Re: Docker - the Linux container runtime

#72

Post by ARothfusz »

GuiA wrote: post #44
shykes wrote: post #30

Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!

There was a lightning talk about Docker at Pycon; I'd assume that's where OP got the info from :)

I've posted a video of the lightning talk here: https://plus.google.com/photos/115695491015706412558/albums/...

It should be public so you can view it even without a G+ account (I think)

Re: Docker - the Linux container runtime

#73

Post by shykes »

shykes wrote: post #30

Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!

Also: there's an irc channel: #docker on freenode. Come hang out!

Re: Docker - the Linux container runtime

#74

Post by pshc »

Will there be any possibility of running dev instances in OS X? Perhaps we'll be able to do brew install docker-compat at some point in the future and get a best-effort emulation layer even though the Linux APIs are missing. I hate messing around with virtualization.

Re: Docker - the Linux container runtime

#76

Post by shykes »

derefr wrote: post #10
iand675 wrote: post #7

I'm not entirely sure that I understand what this does. Is it some sort of hybrid between provisioning automation and deployment automation?

It's a white-labelling of dotCloud's implementation of Heroku's "slug" concept ( https://devcenter.heroku.com/articles/slug-compiler ): basically, a SquashFS image with a known SHA, storing a precompiled runtime+libraries+code artifact that will never change, able to be union-mounted atop a "base image" (a chroot filesystem, possibly also a known-SHA SquashFS image), then spun up as an ephemeral LXC container. I actu…

This is mostly accurate :)

I will add that our implementation predates Heroku's. Using a generic container layer early on (first OpenVZ-based prototypes in 2009) is what allowed us to launch multi-language support a year before any other paas. It's also how we operate both application servers and databases with the same underlying codebase, and the same ops team.

Re: Docker - the Linux container runtime

#77

Post by peterwwillis »

derefr wrote: post #55
peterwwillis wrote: post #41

Earlier quoted context omitted.

Doesn't a standard involve, you know, standards? AFAIK a product name is not a standard. What if the namespace changes? What if AuFS changes? What if LXC changes? Independently or all together? ABI changes? Version changes? Feature changes? Are all the licenses compatible? Will it ever support platforms other than just certain versions of Linux? Or languages other than Go? I don't see a standard. I see marketing for…

I'm just presuming, but: 1. every one of those attributes would be fixed against a given version of the (coming) Docker spec, and a given host would specify what version(s) of the spec they were compatible with. 2. Go is, I think, just the language the glue code is written in; not the language your own things-deployed-using-Docker must be written in. 3. It might support other Linux distros (Fedora, probably), but it…

The trick here is that their xmame (Docker) may not be the same build on all hosts, so it may not play the ROMs all in the same way or support all ROMs. A standard works to improve interoperability between different builds/hosts/etc as well as provide an expected set of operations and their results. If all they provide is just one version of one product and call that standardized, that's like releasing a new version of Internet Explorer and calling it a web standard.

Re: Docker - the Linux container runtime

#78

Post by madisp »

shykes wrote: post #30

Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!

been waiting for something like this,

github: madisp

Re: Docker - the Linux container runtime

#79

Post by niall_ohiggins »

pshc wrote: post #74

Will there be any possibility of running dev instances in OS X? Perhaps we'll be able to do brew install docker-compat at some point in the future and get a best-effort emulation layer even though the Linux APIs are missing. I hate messing around with virtualization.

I run a Docker host fine on OS X w/ Vagrant. The client runs on OS X but not Linux Containers.

Re: Docker - the Linux container runtime

#80

Post by zimbatm »

shykes wrote: post #37
zimbatm wrote: post #26

Earlier quoted context omitted.

My guess is that the container specification is orthogonal to the sandboxing feature. In fact they're using LXC.

Correct, Docker is currently based on lxc, but that is an implementation detail. In theory it could be ported to any process-level isolation tech with similar features: OpenVZ, Solaris Zones - you could also try using BSD jails although I don't know if they have all the required features. To answer the original question: Docker extends LXC with a higher-level API which operates at the process level. OpenVZ helps you…

Nice. Can't way to try it out. I've built a similar tool in Go for PandaStream to isolate or encoding processes.
Post reply on HN