Docker-rsync does the same job. What we need here is to synchronize the configurations between the nodes.
Most of the cases, automation test covers if there is any configuration issue. Thank you! On Mon, Dec 12, 2016 at 5:55 PM, Hanen Ben Rhouma <[email protected]> wrote: > Thanks guys for the answers, > > Actually I found a project called docker-rsync I don't know if this is > what you meant Pubudu, it seams a good solution for such issue, we need to > test it first. What about WSO2 cloud based solutions don't you guys have a > continuous build pipeline to validate each change happening to the config > as well as the resources? How are you handling such scenarion? > > > > Regards, > Hanen > > > On Fri, Dec 9, 2016 at 9:06 PM, Pubudu Gunatilaka <[email protected]> > wrote: > >> Hi, >> >> I think we can use dep sync. This is what normally do for API Manager and >> ESB. If we use SVN based dep sync, server changes will be pushed to SVN. >> SVN server can be a dedicated server or docker container. >> >> If you use docker containers for SVN, you need to mount the container >> file system to the container host machine file system. If you are using >> container management systems such as Kubernetes, Mesos, etc. you need to >> restrict SVN docker container to spin in the same host machine. >> >> Thank you! >> >> On Fri, Dec 9, 2016 at 11:32 PM, Harsha Thirimanna <[email protected]> >> wrote: >> >>> Hi Hanen, >>> >>> Yes, there may be several possibilities to do this such a situation. >>> If we consider the real container base deployment, it may not be >>> possible to allow to generate files in within the container itself because >>> in that case we can't push that changes to the original docker image >>> directly to add the new changes to the next spawning instance using current >>> image. So if we want to go in that approach, definitely we have to first >>> build a concrete identity server instance with the all the configuration >>> changes except the runtime data that is stored in databases. >>> As an example, when we create secondary user store, we create it in file >>> system. So we can't allow to add such one in container model and we have to >>> create it first and prepare the cdocker image using that concrete instance. >>> That is not the specific problem to the WSO2 IS, but for this deployment >>> model. >>> In other way, it would be nice if we could point our configs in central >>> place and use same image always. But that is not the expected container >>> model. But in practical world it may be the one we can use. But WSO2 IS, we >>> don't have a way to point configs in out side place of the product. All are >>> relative to the product home folder. >>> Am i answered to you ? Please let me know for further clarification. >>> >>> thanks >>> >>> *Harsha Thirimanna* >>> *Associate Tech Lead | WSO2* >>> >>> Email: [email protected] >>> Mob: +94715186770 <+94%2071%20518%206770> >>> Blog: http://harshathirimanna.blogspot.com/ >>> Twitter: http://twitter.com/harshathirimann >>> Linked-In: linked-in: http://www.linkedin.com/pub/ha >>> rsha-thirimanna/10/ab8/122 >>> <http://wso2.com/signature> >>> >>> On Fri, Dec 9, 2016 at 7:42 PM, Hanen Ben Rhouma <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> I have a question related to WSO2 IS deployment on the cloud: what is >>>> the best approach to set up a continuous build pipeline for WSO2 IS knowing >>>> that the idea behind is to launch a dockerfile which is going to deploy the >>>> WSO2 IS image on AWS, the challenge is how can we keep our dynamic data >>>> generated after manipulating WSO2 on the cloud, we can persist xml files on >>>> BitBucket and retrieve them each time we rebuild the image but aside from >>>> those files there are some other types of transient data that are generated >>>> by the user actions once he starts configuring WSO2 from the administration >>>> console, how can we make sure that they're not lost once the docker image >>>> is regenerated ? >>>> >>>> >>>> Regards, >>>> Hanen >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Pubudu Gunatilaka* >> Committer and PMC Member - Apache Stratos >> Software Engineer >> WSO2, Inc.: http://wso2.com >> mobile : +94774078049 <%2B94772207163> >> >> > -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Software Engineer WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
