Sorry, there are different parts that I don't follow. Why daemon set? And fundamentally why not rebuild ok SVN changes? You can automate that. Take into account that if you don't have different images with the code, you can't use Kubernetes to rollback either. Or you should check in some other way which pod had which svn revision at any moment in time, and also handle if an SVN up fails or fails in some pods only. OIW, it can add more problems than it solves to do that, consider it carefully.
That being said, you can use a sidecar container to update the SVN code in a shared volume. That sounds like a good approach (in most Kubernetes examples shown with a webserver and git, but it's the same). And you should be able to handle restarts and that stuff fine. On Monday, April 23, 2018, <mderos...@gmail.com> wrote: > Thanks for these suggestions! > But do these solutions use persistent disk? > In my case the persistent disk is a necessary requirement because in > certain rare situations the pods restart. Therefore it is necessary to use > a persistent disk so that the code does not change in case of reboot.. > > Just to clarify the scenario under analysis: > - the image that I'm using is a debian with svn installed and configured > - so inside the image there is all my project code (besides apache, php, > etc) > - after a deploy I could execute a 'svn update' on every pod (using a > multi-terminals app like Terminator) but the problem is that if a pod > restarts, the code will return to the original revision when the image was > created > > So I'm searching a solution where I could use a daemonset configuration > with a hostPath section where to indicate, in some way, a persistent disk > (previously created) and the path where to mount it > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
