https://github.com/dkfbasel/kolumbus

Service discovery for microservice architecture with grpc, docker and envoy proxy
https://github.com/dkfbasel/kolumbus

docker envoy envoyproxy grpc miroservice

Last synced: 3 months ago
JSON representation

Service discovery for microservice architecture with grpc, docker and envoy proxy

• Host: GitHub
• URL: https://github.com/dkfbasel/kolumbus
• Owner: dkfbasel
• Created: 2018-01-19T07:22:43.000Z (about 7 years ago)
• Default Branch: master
• Last Pushed: 2020-05-18T15:10:31.000Z (over 4 years ago)
• Last Synced: 2024-04-15T00:43:16.809Z (10 months ago)
• Topics: docker, envoy, envoyproxy, grpc, miroservice
• Language: Go
• Homepage:
• Size: 40.2 MB
• Stars: 13
• Watchers: 5
• Forks: 0
• Open Issues: 1
• Metadata Files:
  • Readme: readme.md

Awesome Lists containing this project

README

        
# Kolumbus: Creating a service mesh with docker and envoyproxy

![Overview](kolumbus.png)

Docker makes it easy to package your applications and run it reliably in

different environments.

However, orchestrating multiple containers with load balancing, rate limiting,

dynamic replacement of services, monitoring and all the nice operational stuff

can quickly become quite cumbersome.

Given our current move to a microservice architecture that makes heavy use of

the grpc framework, we were looking for a simple solution.

Up until now, we were managing our services manually with caddyserver as proxy

and were quite happy with this. We did look into traefik as a possible alternative

but found that it is not really what we were looking for.

With envoyproxy and its sidecar philosophy we found a solution that seems to

work very well with our setup. One of the great things about it, is that

envoyproxy instances can fetch almost all of the configuration dynamically.

This allowed us to write a simple orchestration service ("kolumbus"), that

will watch all docker containers in the same network and use simple docker labels

(very similar to traefik) to dynamically generate the configuration required

to run an envoyproxy service mesh.

In addition the kolumbus container starts its own internal envoyproxy process,

which makes it trivial to connect local services for development purposes.

Finally, it is possible to automatically fallback to services on a remote

cluster (i.e. your integration testing server) with very little configuration.

Respective server and client certificates will automatically be generated if

the remote proxy mode is set to inbound.

An example on how kolumbus can be used in development and production is given

in the examples directory.

Please note that `Kolumbus` is currently pretty new and we are still working on

several aspects to improve the user experience.

Kolumbus is provided as docker container from dkfbasel/kolumbus.