shykes

84 ms·

841.
by shykes 13y ago
Sam (the guy who implemented docker support in Nova) is now adding docker support to Heat, the Openstack alternative to Cloudformation. It looks really awesome :) http://www.mail-archive.com/openstack-dev@lists.openstack.or.
842.
by shykes 13y ago
To me (docker user and contributor) CoreOS is simply the smallest distro which can run docker. That is already extremely nice when building minimal server images: faster boots, less disk usage and so on. To me etcd is a completely separate
843.
by shykes 13y ago
For a perspective on how to use Docker and Chef together, this article is a good starting point: http://tech.paulcz.net/2013/09/creating-immutable-servers-wi...
844.
by shykes 13y ago
Sasha has been incredibly involved and helpful in the docker community. He's one of my favorite sources of feedback on what should be fixed or improved next on docker. You can't beat large-scale production experience :) Thanks Sas
845.
by shykes 13y ago
I used to do it all the time. Then HR told me it introduced legal risks (and backed it up with real-life examples), so I reluctantly stopped.
846.
by shykes 13y ago
> I, for one, would like to hear more of Docker's benefits clearly explained (i.e. less shipping container metaphors, and more talk of IP configuration). I'd also like to hear more about the limitations of Docker (e.g. what ke
847.
by shykes 13y ago
peterwwillis makes 3 claims: 1) docker does not allow standardized, portable deployment of applications 2) docker is a "fancy wrapper" over lxc and adds no substantial value, 3) anyone who disagrees with this is spreading "li
848.
by shykes 13y ago
Hi, Evidently you don't feel the need for Docker and don't believe it's useful of needed, which is of course totally fine. I won't try to convince you since I've tried before and failed :) (if other are interested I
849.
by shykes 13y ago
That was true in earlier versions of Docker, but has been fixed. alexlarsson is correct :)
850.
by shykes 13y ago
The ancestor of Docker at dotCloud ran on openvz. We moved to lxc in 2010 when it became usable. I think of them as mostly interchangeable except for the shared hosting use case where openvz has a head start (more time for more eyeballs to
851.
by shykes 13y ago
The good news is that namespaces (the most interesting part of containers) are simpler than cgroups, and the api is stable. cgroups are indeed a mess. The api is highly unstable and there is an effort underway to sanitize it, with the help
852.
by shykes 13y ago
Damn. This means it's much less useful to me (and 99% of applications outside of google). I guess I could combine lmctfy with a namespacing library of my own. But that's more extra work than I was anticipating.
853.
by shykes 13y ago
Thank you! I was scanning .h files for a type declaration.. Silly old-school me :)
854.
by shykes 13y ago
Hey Tom, here's a high-level overview of containers in general (and docker in particular): http://www.docker.io/learn_more
855.
by shykes 13y ago
I'm sure they do - but again google is probably holding a proprietary alternative to virtually every piece of software in the world :) Most of it is too tied to "the google way" to be useful to anybody else.
856.
by shykes 13y ago
Quick summary of my early explorations: * Building is relatively straightforward on an Ubuntu system. You'll need to install re2 from source, but that's about it. * No configuration necessary to start playing. lmctfy just straight
857.
by shykes 13y ago
In response to the other comments mentioning docker - this definitely does not compete with docker. A better comparison would be with the lxc tools or maybe something like libvirt-lxc or systemd's nspawn.
858.
by shykes 13y ago
I just spend the last hour or so digging through the code and playing with CLI. It's pretty neat. The "specification" for creating new containers (how to describe limits, namespacing etc) is not very well documented so it tak
859.
by shykes 13y ago
This actually looks like a nice potential execution backend for docker. Currently docker shells out to lxc-start with a generated configuration - I would rather bind to a small low-level library which just handles the namespacing and cgroup
860.
by shykes 13y ago
Yeah, in general if you have a production system in place there's not much incentive to rip it out and replace it with something else - especially if your system is relatively new and shiny. It becomes more interesting when a) your sys
861.
by shykes 13y ago
Thanks - it's good to see it's still possible to disagree constructively on HN :) Yes, I think it's fair to say that a skilled sysadmin can assemble a system quite similar to the core of docker. In fact many, many sysadmins h
862.
by shykes 13y ago
Hi there, > Docker [...] doesn't [...] clean up after itself properly when you CTRL+C it. Sorry about that. It looks like nobody reported this issue yet. Would you mind filing a bug report on the github repo? Feel free to join the
863.
by shykes 13y ago
That seems like the most probable path, although I can't speak for the people making that contribution. What I mean, regardless of how we actually implement, is having an elegant way to deploy containers in environments where the sysad
864.
by shykes 13y ago
> No one marketed Xen, OpenVZ, or KVM Those are not very good examples. Xen was very heavily and skillfully marketed by its corporate sponsor, XenSource, and after that by various companies with a financial stake in the project. OpenVZ
865.
by shykes 13y ago
> From a purely technical perspective it's not very interesting or irreplaceable, the way that OpenVZ or lxc are. Obviously I am biased since I work on Docker. But I completely disagree. I believe Docker has the potential to be qu
866.
by shykes 13y ago
No, the goal is for the current user experience to remain the same. By default docker will create a sparse file, loop-mount it, and use that for all containers. There is some magic in thin provisioning which allows for dynamically resizing
867.
by shykes 13y ago
I think jQuery is a good analogy. One day jquery might be unnecessary, when all browsers everywhere implement all the high-level API goodness. In the meantime... :)
868.
by shykes 13y ago
Docker maintainer here. This is a common misconception, and I find it disappointing. On the one hand we glorify simple designs and the unix philosophy of doing one thing well... Only to trivialize and look down upon projects which apply thi
869.
by shykes 13y ago
I had nothing to do with the effort with getting it merged. But Junjiro Okajima (the author of aufs) seems to have tried a few times, and obviously it hasn't worked. At the same my observation as a "real world implementor" is
870.
by shykes 13y ago
Docker maintainer here. I love aufs, it's been awesome for us at dotCloud. It is definitely stable in production (at least it has been for us). I really really wish we didn't have to remove it as the default. And I don't real

More ›