Fabric8 (v2.X) and Spring-Cloud
207 views
Skip to first unread message
S C NG
Aug 17, 2015, 3:55:15 AM8/17/15
to fabric8
When considering the runtime environment for deploying Camel Applications in Production, I could find some references about deploying Camel app as Spring Boot, and we could enjoy features like auto-confg and create a managed cluster of Camel runtimes using Spring Boot and Fabric8 v1.x (ref. http://henryk-konsek.blogspot.hk/2014/10/using-apache-camel-with-spring-boot.html). My understanding is that the same can be achieved through Fabric8 v2.X, but on the other hand I recognized the Spring-Cloud project, which was built from Spring-Boot, and provided features like "Distributed/versioned configuration" or clustering features like "Leadership election and cluster state" (ref: http://projects.spring.io/spring-cloud/docs/1.0.3/spring-cloud.html).
I was wondering if there would be any comparison between Fabric8 v2.X and Spring-Cloud... or do I have any misunderstanding on what those solutions provides, so that the two solutions should be working together and complement with each other? Please kindly advice and comment.
I was wondering if there would be any comparison between Fabric8 v2.X and Spring-Cloud... or do I have any misunderstanding on what those solutions provides, so that the two solutions should be working together and complement with each other? Please kindly advice and comment.
James Strachan
Aug 17, 2015, 4:56:57 AM8/17/15
to S C NG, fabric8
Great question! We should create a FAQ entry on this one.
So one way to use spring boot in kubernetes is to include a static config file inside the docker image and to override environment variables in different environments.
Finally master election; if it's simple master election (1 master per namespace) then I'm hoping there will be native support in k8s support someday; maybe invoking some REST endpoint with whether a container is master or not so that it can be easily used with any language & framework.
--
In many ways kubernetes and spring cloud take different approaches; kubernetes tries to do things generically for all languages without needing special client libraries - then prefers to keep things simpler and composeable in a language neutral way via containers.
eg service discovery lets folks just use simple environment variables or command line arguments on docker containers instead of special discovery client libraries:
For configuration; the default docker / k8s approach is to use service discovery in each environment where possible and environment variables for actual environment specific configuration values - everything else ideally would be identical across environments. This then makes environments as similar as possible (the same container image runs everywhere with minimal amounts of environment variables).
Another approach to get the environment specific config is to use a database / source control system to keep different versions of a config file. The kubernetes way to do this is using a volume (k8s has native support for git volumes) to store the config files and then mount the volume into the docker container so that spring boot can read it.
The great thing about the volume approach is it works for all languages and runtime; not just Java apps using spring-cloud. Eg it works for tomcat / jetty / wildfly / karaf config files plus nodejs / golang apps. Also there are many ways to implement a volume - there are quite a few native volumes in k8s plus you can add a sidecar container to populate a volume using any database / library / tool (or update them in real time) which would then be reusable to any language / docker container .
However in many ways the k8s approach is to try minimize differences between environments. Eg k8s secrets & service accounts mean your container images can be identical between environments yet have individual user accounts / passwords / keys for each environment - similarly with service discovery for internal & external services.
So it begs the question how many times do you really need significant configuration differences between environments and can't a few environment variables be enough? The less differences between environments the better really as you're then testing more things before production.
I'd personally try keep things simple and use configuration files inside container images and stick to native k8s service discovery & secrets/service accounts then use environment variables for when things must change between emvironments.
Until then - or if requirements are more complex (such as sharding and federation) then you can always use ZK directly or use spring-cloud as an API to things like ZK.
In general you can use spring-cloud in k8s if you like - you can do pretty much anything you like in k8s; but I think increasingly the approach in k8s is to solve those problems more natively via k8s itself in a more container centric polyglot way (using services, volumes, secrets/service accounts, environment variables and sidecar containers).
The main missing bit so far today is master election really; apart from that I'd say k8s has an alternative to much of spring-cloud - but feel free to use it if you like!
When considering the runtime environment for deploying Camel Applications in Production, I could find some references about deploying Camel app as Spring Boot, and we could enjoy features like auto-confg and create a managed cluster of Camel runtimes using Spring Boot and Fabric8 v1.x (ref. http://henryk-konsek.blogspot.hk/2014/10/using-apache-camel-with-spring-boot.html). My understanding is that the same can be achieved through Fabric8 v2.X, but on the other hand I recognized the Spring-Cloud project, which was built from Spring-Boot, and provided features like "Distributed/versioned configuration" or clustering features like "Leadership election and cluster state" (ref: http://projects.spring.io/spring-cloud/docs/1.0.3/spring-cloud.html).
I was wondering if there would be any comparison between Fabric8 v2.X and Spring-Cloud... or do I have any misunderstanding on what those solutions provides, so that the two solutions should be working together and complement with each other? Please kindly advice and comment.
--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Medium: https://medium.com/@jstrachan/
Blog: http://macstrac.blogspot.com/
fabric8: http://fabric8.io/
Blog: http://macstrac.blogspot.com/
fabric8: http://fabric8.io/
James Strachan
Aug 17, 2015, 6:20:48 AM8/17/15
to S C NG, fabric8
Incidentally OpenShift templates (which hopefully will get merged upstream in kubernetes) provides a way to have a reusable blob of JSON / YAML metadata for resources (services & RCs mostly) which can be reused for all environments.
Then template parameters provide a way to customize configurations between environments - which are usually passed into the containers as environment variables or CLI arguments.
So another approach to storing different versions of config files for different environments is to store the parameters in git (using tags for versions and branches for environments) used to apply the templates to an environment.
Then your CI / CD system can automate the injection of environment specific parameter values into each environment for any docker container - spring boot or anything else - which can easily work with the k8s rolling upgrade back/forwards of code and configuration.
More details on CI / CD:
S C NG
Aug 18, 2015, 10:16:17 PM8/18/15
to fabric8, xlogg...@gmail.com
Hi James,
Really Thanks for your detail explanations.
For the statement "Finally master election; if it's simple master election (1 master per namespace) then I'm hoping there will be native support in k8s support someday"
May I know if that means Kubernetes (and so Fabric8 2.x) do not support active-standby setup for application processes?
As we are going to migrate some legacy app processes to Camel + Fabric8, those processes are running in active-standby mode and we want to retain the same in future (e.g. only one active Camel process is running at a time, and the standby Camel process will takeover in case the active one got any failure). I tried to check the Kubernetes documentations but I could only find 1 proposal active-standby, which seems like it has not been implemented yet... so I want to double confirm...
http://kubernetes.io/v1.0/docs/proposals/high-availability.html
Really Thanks for your detail explanations.
For the statement "Finally master election; if it's simple master election (1 master per namespace) then I'm hoping there will be native support in k8s support someday"
May I know if that means Kubernetes (and so Fabric8 2.x) do not support active-standby setup for application processes?
As we are going to migrate some legacy app processes to Camel + Fabric8, those processes are running in active-standby mode and we want to retain the same in future (e.g. only one active Camel process is running at a time, and the standby Camel process will takeover in case the active one got any failure). I tried to check the Kubernetes documentations but I could only find 1 proposal active-standby, which seems like it has not been implemented yet... so I want to double confirm...
http://kubernetes.io/v1.0/docs/proposals/high-availability.html
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Medium: https://medium.com/@jstrachan/
Blog: http://macstrac.blogspot.com/
fabric8: http://fabric8.io/
James Strachan
Aug 19, 2015, 12:43:08 AM8/19/15
to S C NG, fabric8
That's not currently supported natively in k8s. Using the master camel component with ZK is one option. Using an ActiveMQ queue with an exclusive consumer is another.
Though having a replication controller of scale of '1' is a good general alternative. A new pod is started within a second of the active pod failing; though it may take more seconds for the JVM to startup & the routes to start - which in your case may be too long?
Usually in k8s you run N instances of pods and use a service to load balance across them (with sticky load balancing) to get active-active type solutions so that there are always active pods but YMMV - it depends on requirements
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Medium: https://medium.com/@jstrachan/
Blog: http://macstrac.blogspot.com/
fabric8: http://fabric8.io/
--Medium: https://medium.com/@jstrachan/
Blog: http://macstrac.blogspot.com/
fabric8: http://fabric8.io/
--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Henryk Konsek
Aug 19, 2015, 2:14:39 AM8/19/15
to James Strachan, S C NG, fabric8
Hi,
Here [1] is the great summary of the master/slaves options available on the "raw Camel" level.
Henryk Konsek
Reply all
Reply to author
Forward
0 new messages