[deleted]
Weave – The Docker Network
31–40 of 65 posts
Re: Weave – The Docker Network
#32as someone who is more developer than ops, I feel like the docker stuff is still changing fast and that the way you would use docker today will be very different a year from now; but that containers seem to be the way of the future - if I have no pressing need to change my server architecture does it make sense to wait for things settle or would it be more beneficial to get in and learn now and experience the changes…
Docker hopefully will be a little different in a year as it will offer solid security isolation (which is not the case now).
Right now if you run a Docker container and run something within it as root, if that application gets compromised someone can break out of that container and alter the master (due to the way Docker links container-root and system-root, a root user in a container is effectively a root user on the whole system).
Docker are working on allowing containers to run entirely in user-mode (thanks to improvements in LXC). This would mean that you can run a process as root within a container, and if that gets compromised there is near zero chance of leveraging that into damaging the master OS (since it will just have normal user privileges).
Here's an article about their progress (to usermode):
http://s3hh.wordpress.com/2013/07/19/creating-and-using-cont...
To quote Docker's own documentation[1]:
> However, it has been pointed out that if a kernel vulnerability allows arbitrary code execution, it will probably allow to break out of a container — but not out of a virtual machine.
In other words, right now, a root process is likely able to escape a Docker container. You can use SELinux, AppArmor, and similar to somewhat mitigate that when it happens but neither are near as powerful as having that usermode isolation on the master.
If Docker is able to get usermode containers working, it will be very difficult for a Docker container to either alter other Docker containers or the master system (other than over the network, maybe).
[1]http://blog.docker.com/2013/08/containers-docker-how-secure-...
Re: Weave – The Docker Network
#33Earlier quoted context omitted.
I'd like to see a post/writeup (or even an essay!) on how to do the magic "backing services" ( http://12factor.net/backing-services ) with Docker. And that's where I find Deis and other Docker orchestration systems lacking very much. Sure, you can run MySQL in Docker, but it's a far cry from running it on native xfs with aligned partitions and whatever fancy you feel configuring. And since docker containers are very…
Unfortunately I haven't read enough 12fa, but I know I can address most of your questions with one factoid: Volumes. You are absolutely right that Docker containers are meant to be disposable, and should not contain backing data. That is what Volumes are for. I haven't done enough with volumes to give you a real primer on the use of them, but volumes can run on whatever backing store you want and they are not so inte…
I'm familiar with volumes, and here's how I see the problem:
On a docker host you have the docker daemon, and whatever auxiliary stuff you need to orchestrate either the containers or the host (update docker itself, and so on), you have space for /var/lib/docker, and that's it. Volumes are always somewhere on /host/data. That means you have to make up a scheme and convention, and cook up scripts and add it to your already quite dynamic mental model.
If you go and want to manage volumes, you need something for that. And currently everyone and their cats have their own solutions (because there is one they claim to use and one they use, and one they hack on to use later). I'm not claiming it's a hard problem, just that it's not taken care of yet.
Maybe Flocker will deliver, I haven't checked it since it was posted 5 minutes ago :)
Re: Weave – The Docker Network
#34can you compare this with openvpn, or any other vpn if we're at it?
Re: Weave – The Docker Network
#35Earlier quoted context omitted.
I'd like to see a post/writeup (or even an essay!) on how to do the magic "backing services" ( http://12factor.net/backing-services ) with Docker. And that's where I find Deis and other Docker orchestration systems lacking very much. Sure, you can run MySQL in Docker, but it's a far cry from running it on native xfs with aligned partitions and whatever fancy you feel configuring. And since docker containers are very…
Nothing is stopping you from running MySQL in Docker on native xfs with aligned partitions: bind-mount whatever partition you want into the container by defining a volume in Docker. This will be persistent, and will survive when you destroy the container. I use this to e.g. share a /home directory between a dozen experimental dev container I use to run my various projects - each container ensures I keep track of exac…
Last time I tried was around 0.8, and aufs was not happy with xfs. I haven't tried having /var/lib/docker on ext4 and "/volumes" on xfs, I'll try if the need arises.
I run a few MongoDBs with volumes, but I'm not confident that I won't accidentally start two with the same volume, or that someone won't accidentally delete the volume, or .. or .. or.
As I've written to a sibling comment, I don't consider it a hard problem, but it hasn't been taken care of .. yet!
Re: Weave – The Docker Network
#36Earlier quoted context omitted.
Startup time for a docker container is way way faster than a VM. Also, you could run the exact binary state of production, which is helpful if you run into "works on my machine" types of problems.
At the company I work for, we went through all the trouble of getting our distributed backend application running Vagrant using Chef so that we could have identical local, dev and production environments. In the end, it's just so slow that nobody uses it locally. Even on a beefy Macbook Pro, spinning up the six VMs it needs takes nearly 20 minutes. We're looking at moving towards docker, both for local use and produc…
I don't see how Docker solves the speed problem without a workflow change that could already be accomplished with Vagrant.
* Install your stack from scratch in 6 VMs: slow * Install your stack from scratch via 6 Dockerfilea: slow * Download prebuild vagrant boxes with your stack installed: faster * Download prebuilt docker images with your stack installed: fastest
The main drawback of Vagrant is that afaik it has to download the entire box each time instead of fetching just the delta. That may not matter much on a fast network.
Re: Weave – The Docker Network
#37This is really interesting. I've been looking for a way to build in support for networking between Docker hosts in my clocker.io software, to simplify deploying applications into a cloud hosted Docker environment. I'd been young with adding Open vSwitch, but am going to try weave as the network layer in the next release. Will there be any problems running in a cloud where I have limited control over the configuration…
TCP and UDP is all you need. (And the UDP can actually be quite broken, just not completely)
We've created weave networks spanning hosts on EC2, GCE and local data centres.
Re: Weave – The Docker Network
#38This looks like a great idea. For me this was a missing piece two months ago when playing with Docker. However I have strong doubts about the network performance, not only the overhead of the UDP encapsulation (that should be quite small), but mostly the capturing of packets with pcap and then handling them in user-mode. Looks like a lot of context-switches, copying and parsing with non-optimal code paths. Are there…
re benchmarks...publishing some is on the TODO list. See https://github.com/zettio/weave/issues/37. Informally, weave is pretty fast but it's not saturating Gbit Ethernet. As you say, capturing with pcap and handling packets in user space carries an appreciable overhead.
We've got some issues filed to look at pcap alternatives and also generally aim to improve performance.
re suitability for NoSQL clustering... depends on where the bottlenecks are; if you want to cluster for HA rather than scale, i.e. there aren't any real bottlenecks, then weave will work well. Same if you want to cluster because of CPU or memory bottlenecks. If, otoh, networking is the bottleneck then adding weave into the mix isn't going to improve matters.
Re: Weave – The Docker Network
#39Earlier quoted context omitted.
I'd like to see a post/writeup (or even an essay!) on how to do the magic "backing services" ( http://12factor.net/backing-services ) with Docker. And that's where I find Deis and other Docker orchestration systems lacking very much. Sure, you can run MySQL in Docker, but it's a far cry from running it on native xfs with aligned partitions and whatever fancy you feel configuring. And since docker containers are very…
At the expensive of sounding like I'm just plugging my own company, this is what we're working on in the open-source project Flocker ( https://github.com/ClusterHQ/flocker ). We think that data-services like databases, queues and key-value stores, and anything else with state should be able to run inside docker containers too. Yes, you can already run a database in a docker container, but from an ops perspective, thi…
You say that running a database in a Docker container is "a nightmare and very far from what you want to be able to do in a production system," but you do not explain why. Perhaps you might substantiate such a claim?
Re: Weave – The Docker Network
#40as someone who is more developer than ops, I feel like the docker stuff is still changing fast and that the way you would use docker today will be very different a year from now; but that containers seem to be the way of the future - if I have no pressing need to change my server architecture does it make sense to wait for things settle or would it be more beneficial to get in and learn now and experience the changes…
Docker hopefully will be a little different in a year as it will offer solid security isolation (which is not the case now). Right now if you run a Docker container and run something within it as root, if that application gets compromised someone can break out of that container and alter the master (due to the way Docker links container-root and system-root, a root user in a container is effectively a root user on th…
It has nothing to do with LXC, but the Linux kernels. LXC simply bundles all of the linux kernel namespace features together into one shiney thing to make containers. Conceptually, docker, via libcontainer, does the exact same thing.