ApacheCon Core: Service Discovery in OSGi: Beyond the JVM using Docker and Consul
•
1 like•725 views
OSGi offers an excellent service discovery mechanism, but it is limited to services inside the JVM. With Docker nowadays it is trivially easy to deploy all kind of (micro) services, using pretty much any technology stack, so we’d like to discover those as easily as the ones inside the JVM. We will have a look at how we can use the Docker API to discover services in other containers, and how we can use Consul to expand service discovery to other hosts.
More Related Content
What's hot
What's hot (19)
Similar to ApacheCon Core: Service Discovery in OSGi: Beyond the JVM using Docker and Consul
Similar to ApacheCon Core: Service Discovery in OSGi: Beyond the JVM using Docker and Consul (20)
More from Frank Lyaruu
Recently uploaded
Recently uploaded (20)
ApacheCon Core: Service Discovery in OSGi: Beyond the JVM using Docker and Consul
- 1. Service Discovery in OSGi Beyond the JVM using Docker, Consul and Registrator
- 2. About me CTO @ Dexels Architect at Sendrato Wearables Mildly incoherent at times
- 3. • Service Discovery ‘Theory’ • Pile up technologies • Demo • Conclusion • Wild discussions Service Discovery in OSGi Beyond the JVM using Docker, Consul and Registrator
- 4. Service Discovery (SOA) • Can change providers at will • Access to many 3rd party services • Services go shopping for other services • Services can respond to ‘markets’
- 5. Service Discovery for normal people Find system components
- 7. Traditional solutions • Hard code it • DNS • Configuration management
- 8. Why does that need to change? • Horizontally scaled architectures • Cloud infrastructure • Micro services
- 9. How? • Finding services by exploring systems • Use a well-known central registry where every service registers
- 10. Service Repository • Distributed key-value stores • Low volume • Resilience and availability are most important
- 11. Bear with me!
- 12. Consul • Distributed Key/Value configuration store • Like Etcd or Zookeeper, but opinionated • Availability over consistency • Nice web UI • Service check agent • DNS and HTTP API
- 13. Consul DNS Api • Use consul as DNS server • Serves: service.consul domain • Resolve service with [tags].<name>.service.consul • Legacy friendly
- 14. DNS limitations • Port is missing (except in SRV records) • Not designed for dynamic data
- 15. Consul HTTP Api • All Consul functions available • No out of the box support • Event notification with long polling
- 16. So suppose this thing works… • We have a reliable, distributed service store How do we feed it?
- 17. Docker containers • Light-weight virtual machine • Process with a filesystem and a network • Universal, polyglot application deployment mechanism
- 18. A Docker container from a service perspective • An image • An id • Exposed ports • Labels
- 19. Docker • Makes reasoning about services much easier
- 20. Docker • Restful HTTP ‘manager’ daemon on each host • CLI tools use the HTTP interface to the daemon
- 21. Demo: Basics
- 22. Registrator • Go based • Watches Docker daemon using long polling • Updates a back-end: Etcd, Consul or SkyDns • https://github.com/gliderlabs/registrator
- 23. What data do we have? HostIp: 192.168.99.102 HostPort: 49212 ContainerPort: 3306 Protocol: TCP
- 24. Metadata • Which service is this (name, tags) • What protocol? How do I consume the service? We can add them as docker labels!
- 25. Docker labels • Completely generic docker run --name some-mysql -P -l SERVICE_NAME=my_mysql_instance -l SERVICE_TYPE=mysql -l SERVICE_TAGS=production -l SERVICE_VERSION=5.5.1 --rm mysql
- 26. So suppose this thing works… • We have a reliable, distributed service store • We synchronize it with the Docker daemon(s) • We can access it using an HTTP API • It notifies us when it changes
- 27. This was the easy part
- 28. Dynamic Services • Any service can just appear • Multiple instances can appear • Instances can disappear without warning • Service cascades
- 29. OSGi • Java based dynamic service framework • Since 1999 • Initially for embedded systems • Now very popular in cloud deployments
- 30. OSGi • Central ‘Service Bus’ • Any Java object can be registered as a service • Code can redeploy on the fly • Services can come and go dynamically • Services can depend on other services
- 31. Consul & OSGi • Monitor Consul • Inject services into OSGi
- 33. Docker & OSGi • The Consul ‘monitor’ won’t know what a service is really about • We need to separate configuration from the ‘driver’
- 34. Configuration Admin • Create Configuration objects based on docker data • Configuration object = PID + KV • Leave the actual interpretation to ‘driver bundles’ • ‘Source agnostic’
- 35. Example • Create a HTTP / JSON driver • Insert documents into Elasticsearch
- 36. Final demo!
- 37. Service Checks • Consul can add checks to a service registration • HTTP API • Script API • Deadman switch • If the check fails it will no longer report that service
- 38. Dynamic • Truly embraces a dynamic system • Matches the OSGi ‘way’
- 39. Really simple • Registrator is a few hundred lines of Go code • consul-osgi is a few hundred lines of Java
- 40. Scheduler agnostic • It does not matter who / what started the containers
- 41. Unix philosophy • Do one thing and one thing well • Easily integrate with other tools
- 42. consul-OSGi is a hobby project! • But turning it into something more would be cool And I think it can benefit the OSGi community
- 43. Future work • Conventions on metadata would be nice • Better security model for Docker • Use other sources of configuration like Kubernetes • Downloadable drivers using mvn coordinates • Consul backed load balancer (Vulcand) • Integrate with secure storage
- 44. Thank you! frank@dexels.com Twitter @lyaruu https://github.com/flyaruu/consul-osgi blog: http://www.codemonkey.nl/