JavaCro'15 - Service Discovery in OSGi Beyond the JVM using Docker and Consul - Frank Lyaruu
0 likes1,633 views
This document discusses service discovery for microservices using Docker and OSGi. It describes how Docker containers can be monitored to dynamically register their services in an OSGi environment. Consul is introduced as a distributed key-value store that can be used for service discovery across multiple hosts. The document concludes with demos of integrating Docker services with OSGi using Consul for service discovery.
JavaCro'15 - Service Discovery in OSGi Beyond the JVM using Docker and Consul - Frank Lyaruu
- 1. Service Discovery in OSGi Beyond the JVM using Docker and Consul
- 2. About me CTO @ Dexels Architect at Sendrato Wearables OSGi tinkerer NoSQL advocate
- 3. Service Discovery • As old as distributed systems • Find system components • Prevent hard-coding network addresses • Important for micro service architectures
- 4. Service Discovery • Finding services by exploring systems • Use a well-known central registry where every service registers
- 5. Service Repository • Watch out for a single point of failure • Distributed key-value stores • Low volume • Resilience and availability are most important
- 6. 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’
- 7. Docker containers • Light-weight virtual machine • Process with a filesystem and a network • Universal, polyglot application deployment mechanism • DockerHub image store
- 8. Mini demo
- 9. Docker from a service perspective • An image • An id • Exposed ports • ENV variables (& labels since Docker 1.6)
- 10. Docker • Makes reasoning about services much easier
- 11. Docker • Restful HTTP daemon on each host • CLI tools use the HTTP interface to the daemon
- 12. Service discovery So how do we ‘discover’ these services? We ask the Docker daemon
- 13. What’s missing? HostIp: 192.168.59.103 HostPort: 49212 ContainerPort: 3306 Protocol: TCP … we need more metadata
- 14. Metadata • Which service is this (name, tags) • What protocol? How do I consume the service? We can add them as environment parameters
- 15. Monitor the Docker Daemon • Completely generic • No need for a registry • Only require a few ‘annotations’
- 16. This was the easy part
- 17. Dynamic Services • Any service can just appear • Multiple instances can appear • Instances can disappear without warning • Service cascades
- 18. OSGi • Java based dynamic service framework • Since 1999 • Initially for embedded systems • Now very popular in cloud deployments
- 19. 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
- 20. Docker & OSGi • Monitor the Docker daemon • Inject into OSGi
- 21. Docker & OSGi • Mismatch between Java objects and Docker connection data • The Docker ‘monitor’ won’t know what a service is really about
- 22. Configuration Admin • Create Configuration objects based on docker data • Leave the actual interpretation to ‘driver bundles’
- 24. Another demo!
- 25. Limitations • Single host* • Docker API Security • Scalability
- 26. Consul • Distributed Key/Value configuration store • Like Etcd or Zookeeper • Very robust for node failure • But specifically built for Service Discovery • Nice web UI
- 28. Final demo!
- 29. Future work • Conventions on metadata would be nice • Better security model for Docker • Use other sources of configuration like Kubernetes
- 30. Thank you! [email protected] Twitter @lyaruu Tasman: https://github.com/flyaruu/tasman Blog: http://www.codemonkey.nl/