Five weeks since its initial inception, and a month since its last release, the new v0.8.x version of the hesco/weave puppet module has now been released to the puppet forge.
This latest minor release brings three new features to the project. The second feature listed below, responds directly to the use case which frames the question above.
(1) weave::simple:: types
It introduced new weave::simple::(run|interface) defined types. These new types provide wrappers around the weave::(run|interface) base types made available in earlier versions of the module. As the namespace implies, they provide a more simple interface to the underlying weave SDN management tools. The same number of arguments are still required, but with the weave::simple::<types>, most of those arguments can now be hidden in your hiera data, keyed off a host name passed across the interface of the ::simple:: types.
(2) weave::firewall:: classes and types
New types and classes have now been added to a new weave::firewall:: namespace, meant to reproduce the firewall management offered by the docker and weave tools, but in a way which is compatible with the use of puppetlabs/firewall for the management of your firewall rules not specific to docker and weave, but nonetheless required to be run on your docker hosts. weave::firewall::docker reproduced the iptables rules created by daemonizing docker. weave::firewall::weave reproduces the firewall rules otherwise generated by
weave launch. In addition, weave::firewall::listentopeer opens up port 6783 for tcp and udp traffic on the docker host between the weave peers, with a sanity check to prevent the unnecessary rules for a peer listening to itself. weave::firewall::dnatpublishedport currently requires user intervention to invoke it for each port published by EXPOSE in a Dockerfile, or with the -p switch to
docker run adding rules to the FORWARD chain and the DOCKER chain to provide network address translation through the firewall to the container. A future version should more tightly integrate this functionality with weave::simple::run to automate this functionality from hiera data.
(3) new facts for docker and weave
Two new facts are exposed by this version as well.
$::weave_router_ip_on_docker_bridge retruns an IP as a string.
$::docker_hosted_containers returns a complex data structure derived from running
docker inspect on every container running on a docker host and exposing all of the metadata available to puppet as facts, accessible at the same keys used by docker.
Some of this functionality probably belongs more appropriately in the agarethr/docker module. And I have begun a conversation on migrating that functionality over to be maintained there in the future. But for now, that code is available here.
Fifty-plus commits in the making, this new functionality has now been managing the configuration in our production environment for the past two weeks. Combined with weave it has provided a stable software defined network bridging communication between docker containers on multiple docker hosts. And it has done so in ... (more)