Docker-sync: [idea/discussion] Support 1-way sync from container to host

Created on 17 Jul 2018  路  7Comments  路  Source: EugenMayer/docker-sync

In our project we have some large folders that originate from the container. Changes in these folders are only made in the container and are very useful to have on the host machine. F.e. dependency folders like vendor and node_modules, or a cache folder.
Installing and updating dependencies we perform on the container and not on the host machine (less dependencies required on the host machine, less confusion on where to perform commands).
Including these folders in the default synchronization process is a bad idea, but are very useful to have on the host for f.e. code completion and inspection.

Docker by default offers mounting volumes readonly by the container, but that's exactly the other way around.
The rsync strategy also syncs from host to container and that makes sense when writing code.

What about adding a reverse rsync strategy that actually syncs back changes from the container to the host, ignoring changes made on the host? It would lessen the long initial sync when using native_osx/unison strategy significantly. Any thoughts on this?

Edit: I just saw that @talya brought up the same idea https://github.com/EugenMayer/docker-sync/issues/585#issuecomment-404467257

feature help wanted incomplete

Most helpful comment

I understand what you are looking for and it could be useful to some.

for my POV I want be able to put any work into that, but if you do, I am happy to review any pull requests.

We tend to have a rule of thumb here, if an idea does not get any traction after one month, we close it until someone picks it up... it gets reopened. I would like to apply this here too.

looking forward to reviewing your stuf

All 7 comments

I understand what you are looking for and it could be useful to some.

for my POV I want be able to put any work into that, but if you do, I am happy to review any pull requests.

We tend to have a rule of thumb here, if an idea does not get any traction after one month, we close it until someone picks it up... it gets reopened. I would like to apply this here too.

looking forward to reviewing your stuf

@netiul - awesome to hear you have a similar use case :)

Have you tried this approach manually yet?
I have currently switched my efforts to poc a similar setup but with VirtualBox, but I hope to be able in the future to tryout this rsync from inside the container and see if it's viable.

Do update if you have any success or other useful findings.

@EugenMayer @talya Glad to see some thumbs up. I can work on this, but not before the coming 4 weeks (will have some vacation in between).

I just want to say, that this will be great. I'm doing this kid of sync via Makefile now (and I have filewatch in phpstorm to execute it on save to have services registered by annotations discovered)

refresh-cache:
    @curl -k --output /dev/null --silent --head --fail https://project.local/

sync-cache:|refresh-cache
    @mkdir -p ./cms/app/cache/dev
    @$(eval CONTAINER:=`docker-compose ps -q service-name`)
    @docker cp $(CONTAINER):/app/cms/app/cache/dev/profiler/. ./cms/app/cache/dev/profiler/
    @docker cp $(CONTAINER):/app/cms/app/cache/dev/translations/. ./cms/app/cache/dev/translations/
    @docker cp $(CONTAINER):/app/cms/app/cache/dev/appDevDebugProjectContainerUrlGenerator.php ./cms/app/cache/dev/appDevDebugProjectContainerUrlGenerator.php
    @docker cp $(CONTAINER):/app/cms/app/cache/dev/appDevDebugProjectContainer.xml ./cms/app/cache/dev/appDevDebugProjectContainer.xml

This strategy will make my sync-cache target obsolete (which is great!) :)

I would love to onboard this feature into 0.6.0 - what is the actual status of that feature, does anybody use this in production?

@EugenMayer I'd pretty much only use it in development for a few of my containers, but it seems really useful

I close this issue since the PR was declined, since the author explained he did this approach due to various issues with it. It sad to see how much work already went into it, but it is good that at least a decision has been made, that this poc might be not working as expected in the end / long run.

Closing this issue, just forgot about it after closing the PR

Thank you for the work and for sharing the ideas!

Was this page helpful?
0 / 5 - 0 ratings