[jboss-jira] [JBoss JIRA] (WFCORE-433) git backend for loading/storing the configuration XML for wildfly

[James Strachan (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167398#comment-13167398 ] 

James Strachan commented on WFCORE-433:
---------------------------------------

Thanks [~bstansberry]. So a way to do a similar thing with Kubernetes using a git repo is :

* use a gitRepo volume in the Replication Controller YAML file:  http://kubernetes.io/v1.1/docs/user-guide/volumes.html#gitrepo so that each pod has a specific git revision (SHA) cloned at a specific folder. The WildFly container then just loads config from disk as usual.
* when someone makes a change via the WildFly Admin Console a new git commit is done
* update the git revision in the Replication Controller and do a 'Rolling Update' in Kubernetes like this example https://github.com/fabric8io/kubernetes-client/blob/2e79032968bb2dfc299dc467af96115eecb0da87/kubernetes-examples/src/main/java/io/fabric8/kubernetes/examples/FullExample.java#L147 only you'd be updating the spec.template.container's git volume rather than the image
* this basically then creates a new Replication Controller for the new git revision and starts spinning up new containers with the new configuration; as each one starts, is running and is 'ready' (using Readiness Probes to know if the WildFly container is up and running - e.g. is it listening on all the ports, is it ready to receive HTTP requests and whatnot) http://kubernetes.io/v1.1/docs/user-guide/production-pods.html#liveness-and-readiness-probes-aka-health-checks - when the container is ready then it takes part in the Kubernetes services for load balancing. Then when its ready, the old RC is scaled down; so that 1 container rolls over from the old to the new configuration. 
* the process running the rolling upgrade can monitor the newly created pods and check they startup OK; if they don't it can rollback the change and if need be rollback the git revision (or you can use branches if you want, kinda "Pull Request" stylee that changes only get merged to master after the rolling upgrade succeeds?)

You could run the above in the wildfly container that gets the git commit change from the Admin Console; though it might be better to elect a leader using Kubernetes' leadership election and letting that container watch for changes in git and perform the above steps. 

You already have code to do dynamic updates of configuration on the fly to WildFly containers; you could keep doing that if you like - though its kinda easier to just adopt the immutable container model as there's less chance of incremental change bugs; plus you can the reuse the 'rolling upgrade' mechanism to do more than just deal with config changes - e.g. for testing out rolling upgrades of new docker images of wildfly too.

BTW you might want to look at using Kubernetes lifecycle hooks to ensure that containers are sufficiently drained before they are stopped. e.g. http://kubernetes.io/v1.1/docs/user-guide/production-pods.html#lifecycle-hooks-and-termination-notice - then you can make kubernetes wait for the containers to have completed processing requests before it shuts down etc.

> git backend for loading/storing the configuration XML for wildfly
> -----------------------------------------------------------------
>
>                 Key: WFCORE-433
>                 URL: https://issues.jboss.org/browse/WFCORE-433
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: James Strachan
>            Assignee: Jason Greene
>
> when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like:
> * git pull
> * write the, say, standalone.xml file
> * git commit -a -m "some comment"
> * git push
> (with a handler to deal with conflicts; such as last write wins).
> Then an optional periodic 'git pull' and reload configuration if there is a change.
> This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git)
> Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)