Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Service Discovery in OSGi: Beyond the JVM using Docker and Consul


Published on

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, so we’d like to discover those too. 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.

Published in: Technology
  • Be the first to comment

Service Discovery in OSGi: Beyond the JVM using Docker and Consul

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