Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What would it take to add support for Docker Swarm please? #67

Open
julianharty opened this issue Nov 17, 2017 · 1 comment
Open

What would it take to add support for Docker Swarm please? #67

julianharty opened this issue Nov 17, 2017 · 1 comment

Comments

@julianharty
Copy link

As https://github.com/worstcase/blockade/blob/master/docs/install.rst states, Docker Swarm isn't currently supported. I think I'd need Docker Swarm support in order to test machine clusters e.g. a Kafka cluster that's running on Virtual Machines e.g. from VMWare or a cluster of physical machines e.g. Raspberry Pi's :)

If you could provide some pointers on what'd it'd take to add support for Docker Swarm that'd be a great help. Of course, if there are other ways to solve my testing challenge (of meddling with nodes running Kafka, Zookeeper, etc. and their connections) that'd be appreciated too.

PS: thanks for an excellent project and capability, I came here by following a well-trodden path of Jepsen, then jepsen-python which uses blockade 👍

@labisso
Copy link
Member

labisso commented Nov 18, 2017

Thanks for your message. I think Swarm support is possible and would definitely be nice to have. There are two main obstacles I am aware of:

Blockade uses a HostExec mechanism to run commands in a host container alongside your application containers. These commands manipulate the network stack of the host itself, and necessarily need to run on the host that also runs the target application container. This is easy now because there is only one host that runs all the containers, so we can simply run the commands there. But with Swarm, the application is potentially spread across multiple hosts. And to further complicate things, for performance, the host container is actually kept running for the duration of your blockade and is fed commands as needed via docker exec.

To support Swarm, this mechanism would need to be extended to run and track host containers across every Swarm host used by your application. I believe this could be accomplished using Docker placement constraints. HostExec.run currently accepts only a command argument, but it could perhaps be extended to also accept a container_id. Then it could figure out the host the container runs on, and use placement constraints to coschedule a host container to that host as well (if one isn't already running).

The other obstacle requires some thought and experimentation. Blockade uses iptables to implement network partitions, and uses the above HostExec mechanism. We create a chain for each partition, direct all traffic from hosts in that partition to the chain, then add drop rules for any container NOT in the partition. Here is the implementation. I am not sure how well this will extend to Swarm. The same mechanism might work if we simply run the same iptables commands on all relevant Swarm hosts, using the improved HostExec mechanism. But I am not sure about this.

These are the issues I know about. There could certainly be more complexities that arise during implementation. Because Blockade manipulates the underlying network stack, I've come across a lot of surprises during implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants