Hi All, If the deployment has support for network volumes, it would be much easier to use a volume mount for distributing runtime artifacts than using SVN or rsync based dep-sync.
Thanks On Thu, Dec 15, 2016 at 11:12 PM, Pubudu Gunatilaka <[email protected]> wrote: > 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 > > -- *Imesh Gunaratne* Software Architect WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: https://medium.com/@imesh TW: @imesh lean. enterprise. middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
