7 ms·
I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should
by justinsb 12y ago
I prefer the Unix model - many programs that work together. That might not be practical for networking (a natural plug-in, probably), but feels like it should be the way for orchestration.
The Docker image registry and image management should really be a separate program as well - that is a huge pain point that Rocket seems more likely to get right.
- ecnahc515 12y agoInterestingly enough, with flannel, docker's advanced networking capabilities become pretty trivial, and communication across hosts is also pretty trivial. I think all in all, CoreOS has built out a ton of tools to make using Docker easier, and they're all very well defined, and compossible. I'd even say that a lot of docker's features could be completely removed by using some of these tools. Links? Nah just use ips/dns + etcd for service discovery. Networking? Need very basic bridged networking, and flannel will handle communication on a single host, or multihost. Deployment? Use fleet. Not that all these are 100% perfect like I've made them out to be, but any individual component could be swapped out if you want.
- bananaoomarang 12y agoI think this is probably more indicative of the issue that Future Docker would like to be a CoreOS-competing platform, and has been edging towards that state. This is CoreOS' natural bounceback from that.
- spb 12y agoThe thing I like about the link model is that they hide your containers from other containers and only expose the connections you want (I think using iptables?) I'd like a tool that makes this linking easier outside of Docker, but for now this is one of the features I like about it (although holy moly do Docker links have a lot of baggage you have to bring along for the ride, like giving everything names).
- vishvananda 12y agoShameless self plug, but not sure if you saw my project that does something along these lines: https://github.com/vishvananda/wormhole https://github.com/vishvananda/wormhole
- spb 12y agoFrom the docs, it looks like that has a dependency on Docker, which kind of defeats the purpose. If I'm stuck with Docker, I'm better off just sticking with links: I'm looking for something that could work with systemd-nspawn, etc.
- digitalzombie 12y agoThat sounds awesome. I'm learning docker and I might wait on this issues to resolve first. I don't like the sound of locking into one vendor for everything.
- curun1r 12y agoThe problem with the CoreOS tools is that they're pretty tightly coupled. We looked into using fleet to manage our deployments. Unfortunately, it relies on a minor feature of etcd and cannot work with Consul, our corporate standard. Flannel? Yep, again, tightly coupled with etcd. I like some of the ideas behind the CoreOS tools, but until they start playing well with others, they're a non-starter for me. I'm not interested in tools that try to lock me into other, inferior, tools.
- techdragon 12y agoThe Unix model works great at the network later. Otherwise I couldn't be building a complete, multi tenant, docker container as a service / infrastructure as a service, cloud. Built on top of an end to end SDN.
- justinsb 12y agoInteresting. Which SDN are you using?
- mrkurt 12y agoWe're doing something like that on top of Open vSwitch, OpenFlow, and vxlan.
- justinsb 12y agoWould you consider open-sourcing / documenting / blogging how you do that (or even providing some pointers to help get me started)? I'm playing with kubernetes and AWS, and it isn't clear what the best networking solution is (rudder, weave, IPv6, SDN); it would be helpful to have some pointers on the OpenVswitch front. (I only ask because it doesn't look like it is your core business)