Service routing turns containers into microservices
Flux is a new project from Weaveworks that gives you service routing for Docker containers. What is service routing? It’s a layer on top of the network that means your application code can connect to services rather than individual...
Flux is a new project from Weaveworks that gives you service routing for Docker containers. What is service routing? It’s a layer on top of the network that means your application code can connect to services rather than individual containers. This can be a powerful tool, since it means you can build long-lived, evolving services out of short-lived containers.
What’s more, the web UI for Flux gives you a live view of how well your services are running. It can show charts for individual containers, or group containers by image, version and so on.
Flux helps you build microservices
Organizing your application into services is the central idea of microservice architecture. Flux diminishes the trade-offs you have to make to get there.
For a start, it simplifies the infrastructure you need. With Flux, a service is available everywhere at a well-known address, which you can put in DNS to make things even simpler. Client connections are load-balanced among instances of a service. Flux keeps track of which instances are available, and retries failed connections automatically.
Flux also helps with the operational complexity of a microservice architecture, by making the state of the running system more visible. You can query which containers are instances of a service, and which instances are live. And, as shown above, it gives you performance charts so you can compare different versions of a service.
Often to obtain these kinds of benefits you have to adopt an application framework or an entire infrastructural platform. With Flux we have tried to keep things open. It doesn’t need any special code to be integrated into your application. You can start and stop containers, and configure Flux to run, any way that you please.
How does Flux do service routing?
Like most technology, Flux is a combination of borrowed and adapted ideas (in large part from Kubernetes and pioneering work by Glider Labs).
The Flux daemon (fluxd) runs on each host and proxies client connections from that host. It distributes requests to a service among its instances. Since it is local to the clients of the service, it avoids the extra network hop a centralized proxy would incur. It’s also here, closest to the client, that metrics are collected.
Each fluxd watches Docker to see containers start and stop, and decides which should be registered against services. These instance records are distributed to fluxd on other hosts so they can route clients to the instances.
Since each host will experience its own network conditions, each fluxd keeps track of which instances it has successfully connected to recently. It periodically retries instances that have failed to see if they are available again.
You most likely also want to load-balance traffic at the public face of your application. Again, Flux can help you: it will dynamically configure Nginx to use the instances of a given service.
You can try Flux now
We have written guides showing how to get something working on a single host, or with Docker Swarm.
We just released version 0.2 of Flux. As the version number suggests, it is still early days. Many aspects of Flux are still in, well, flux. For instance, we chose to use etcd as a shared database to get things off the ground; but, we appreciate that people using Weave Net like the convenience of not needing to run a separate database. So we’re looking for ways to remove that dependency.
As always we’re interested in hearing your ideas and other feedback — the best venues for that are the weave-users mailing list, and the GitHub issue tracker for Flux.
