lazypower / flannel-docker-charm Goto Github PK

Subordinate charm for creating a mesh-overlay network for Docker Container hosts, which enables cross-host communication for distributed services, container farms, and HA configurations.

Home Page: http://chuckbutler.github.io/flannel-docker-charm/

License: BSD 4-Clause "Original" or "Old" License

Python 93.41% Shell 2.34% Makefile 4.25%

flannel-docker-charm's Introduction

Flannel (Docker Flavored)

About Flannel

Flannel (originally rudder) is an overlay network that gives a subnet to each machine for use with containers.

One of the common issues when using containers in clouds is the inability to do cross host communication between the containers as they default to using a local bridge.

flannel uses the Universal TUN/TAP device and creates an overlay network using UDP to encapsulate IP packets. The subnet allocation is done with the help of etcd which maintains the overlay subnet to host mappings.

This charm uses flannel to setup an overlay network and configures docker containers on that host to use the overlay.

NOTE! For up to date, and complete documentation - please see the Charm Documentation Site.

Charm Usage

Flannel-docker is a subordinate charm, and is designed to be be deployed into the scope of a docker host, configuring its networking bridge (docker0) to use the TUN/TAP overlay network so docker containers can communicate cross-host. This facilitates in HA and colocated networking deployment.

Deployment

Start by deploying ETCD to your bootstrap node (this is for cost reduction, its not uncommon for multiple etcd hosts to reside as a cluster for HA scenarios. This particular deployment is non-HA)

Deploy the docker charm, and flannel-docker. Then relate docker to flannel-docker, and flannel-docker to etcd. The networking magic will reconfigure the network as a mesh overlay.

juju deploy cs:~kubernetes/trusty/etcd --to 0
juju deploy trusty/docker
juju deploy trusty/flannel-docker
juju add-relation flannel-docker:docker-host docker:juju-info
juju add-relation flannel-docker:db etcd:client
juju add-relation flannel-docker:network docker:network

Known Limitations

This charm does not currently work with the Juju local provider. The combination of apparmor and LXC prevent the flannel function from working. Deploy this charm to a cloud environment.

The included binary files are amd64 only. The flannel code is compiled and will not run on architectures other than amd64 (x86_64). Use the constraints flag with the juju command to specify the proper architecture from your cloud environment.

Contact information

The Flannel-Docker subordinate is heavily based on the Flannel charm produced by Kapil Thangavelu

Maintainer: Charles Butler <[email protected]>

Flannel information

flannel-docker-charm's People

Contributors

Stargazers

Watchers

Forkers

whitmo mbruzek hamsterksu

flannel-docker-charm's Issues

Network relationship call fails with 2 hosts of different names

Steps to reproduce:

juju deploy docker
juju deploy docker docker2
juju deploy docker-flannel
juju add-relation flannel-docker:docker-host docker
juju add-relation flannel-docker:docker-host docker2
juju add-relation flannel-docker:network docker:network
juju add-relation flannel-docker:network docker2:network

When the charm scans the relationship id's it picks both network:# relationship id's to send across the wire whereas the relationship id's were scoped to the host in prior formations. This poses an interesting problem when you have 2 differently named docker clusters, and deploy flannel on top of both clusters.

Needs support for ARM

request for a topology

would it be possible for a ubuntu juju lxc/docker based diagram such as https://raw.githubusercontent.com/coreos/flannel/master/packet-01.png to help graps the concepts?

Add Troubleshooting steps when networking doesnt appear to be working

relations are order dependent

Investigate a fix for making flannel call the network relation-changed event if the db relationship is added after networking relationship has been established

Compile flannel from source

As it stand today, the flannel binary is already behind the current stable release of flannel. This leads me to believe we should be compiling on the host. Go is super simple to install, compiles fast, and we can share the binaries amongst peers.

Move away from the vendored binary and insert compilation from source option(s) to keep flannel current.

Missing key during network-relation-changed with similar interface on kubernetes

The kubernetes charm is fetching and filtering data keys directly from the relationship data-source. When attempting to use the flannel-docker charm as a drop in replacement for flannel - there is a return error that it is missing the key "overlay_type"

Missing data for overlay_type {'proxy_bind_addr': '54.145.255.30', 'overlay_type': None, 'etcd_servers': 'http://10.12.131.18:4001', 'identifier': 'kubernetes-0', 'kubeapi_server': 'http://10.4.115.212:808', 'kubelet_bind_addr': '10.29.5.88'}

Needs support for PPC64EL

Needs integration tests

the charm requires integration tests to drive future development to ensure the charm interface(s) are not broken - as this is a cornerstone of the smorgasboard bundle

sending networking data is dependent on relationship-order

The current process of configuring the charm is highly dependent on ordering of the relations.

This is not idempotent, and creates a scenario where the charm is left in a broken state. The subnet network data is cached on the agent side and the routine of setting/sending this data should happen when it is available.

The stop hook appears to be broken

While testing the flannel-docker charm I was trying to reset the environment (juju deployer -T) several times. The stop hook resulted in an error. This error cause me to have to use --force to destroy the machine.

We should make sure that even the stop hook completes successfully.

Flannel Docker enters error state during teardown trying to send data to etcd node

During CI testing, occasionally ETCD will be torn down before flannel-docker is aware its been torn down. When flannel-docker attempts to send data, it gets a connection-refused and enters an error state - keeping the charm around, when its during a teardown sequence, and should not be blocking.