Run your application at full speed while syncing your code for development, finally empowering you to utilize docker for development under OSX/Windows/*Linux
License: GNU General Public License v3.0
Thank you for all the feedback and support i already received!
Docker-sync has been improved by all of you in huge ways!
Important links:
Docker-sync needs contributions and help
Main Contributors:
I'd like to be able to create and sync containers, run some cleanup around file permissions stuff and then start watching. Currently creating and starting containers only happens with docker-sync sync, which stops containers when stopped.
I posted an issue on leighmcculloch/docker-unison#14 because their image is very big.
But in fact you can perhaps simply switch to https://github.com/onnimonni/docker-unison
When I'm using rsync I can fix the permission to www-data but not with unison. Is their a workaround?
I want to use unison to have a two way sync. So for example I can see and edit the drupal config files generated by php.
I'm using unison don't know if it apply with rsync.
If you launch the docker-sync and then after change the configuration and relaunch it, the sync folders are still going to be at the same place.
Hi! I'm having great results with this but we use a makefile to script docker environment creation locally, and the blocking UI for docker-sync is not so compatible with that. What about adding a command-line option to docker-sync start to run in the background and then a separate docker-sync stop command to stop the process?
Check if there are newer versions of docker-sync and warn the user
I've managed to get docker-sync running and it seems to share the volume data when I initially run docker-sync start, however, after editing anything in the directory that it's watching it doesn't appear to sync any data.
Restarting docker-sync shows a new set of data, but that defeats the purpose of running it once and letting data sync when saved/updated.
Is there possibly a step I'm missing here? I don't have any watch excludes setup and I'm using rsync 3.1.2 on OS X. I don't see any errors in the logs, either.
Please explain your use case, why you need 2 way sync so i can understand, what use case we are working towards. In my understanding right now, i cannot image a single usecase, but i already have several use-cases against using 2 way sync. I can share those later on
With a unison sync setup, adding/modifying files within the container does not cause those files to be synced back to the host. The only thing that seems to trigger a sync from the container back to the host is touching a watched file outside of the container.
Is this expected behavior? I had expected 2way sync to automatically detect changes made in either location.
rsync does not use --delete for now, but i worked with that already. I am yet not sure if we should add it to the defaults and make it possible to disable it ( there are some cases were you do not want this, i have such ) or keep the default as such.
Any suggestions?
It does not make any sense keeping it, AFAICs. Its worse in every metrik compared to unox.
@mickaelperrin any veto?
this should fix / make requires of docker-sync more convenient
the docker-sync container (the last one) seem to use a lot of memory after some time:
Right after starting memory consumption it's pretty standard but seem to grow very quickly every time their is a sync (just add/delete a empty folder):
at the same time, rename the current unison to unison-onesided
docker-sync start
works ok.
docker-sync-stack start
fails.
> docker-sync-stack start
/Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:105:in `private': nil is not a symbol (TypeError)
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:105:in `<class:Mapper>'
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:5:in `<module:Compose>'
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:2:in `<top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose.rb:10:in `require_relative'
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose.rb:10:in `<top (required)>'
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.13/tasks/stack/stack.thor:5:in `<top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.13/bin/docker-sync-stack:22:in `load'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.13/bin/docker-sync-stack:22:in `block in <top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.13/bin/docker-sync-stack:20:in `each'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.13/bin/docker-sync-stack:20:in `<top (required)>'
from /usr/local/bin/docker-sync-stack:23:in `load'
from /usr/local/bin/docker-sync-stack:23:in `<main>'
Add this advanced option so people can use their own images, if they actually know, what they are doing.
If the docker-sync's volume are still attached to a containers (even stooped), it will not remove those volume:
➜ git:(dev) ✗ docker-sync clean
Error response from daemon: No such container: code-sync
Error response from daemon: No such container: code-sync
Error response from daemon: Unable to remove volume, volume still in use: remove code-sync:
volume is in use - [0bf8bf2d470b484fd736cd245134bf75e294bd5eb664625688f649a57d54533c,
a266be7316732935631a3abc834cdf58e438385ff8fd6f201237a23a19a18109]
success Finished cleanup. Removed stopped, removed sync container and removed there volumes
I guess this is a safeguard, but what are the use cases as you should still have your files on your local file system.
Perhaps we can add a --force flag. Or a confirmation dialogue can be the default behavior:
➜ git:(dev) ✗ docker-sync clean --force
Volume still in use - [0bf8bf2d470b484fd736cd245134bf75e294bd5eb664625688f649a57d54533c,
a266be7316732935631a3abc834cdf58e438385ff8fd6f201237a23a19a18109]
Are you sure you want to delete those volume (y/n):
Since some people need 2 way sync, implement unison next to rsync.
Stub created here: https://github.com/EugenMayer/docker_sync/blob/master/lib/docker_sync/sync_strategy/unison.rb
Edge-cases are:
a) if a lot of fs-changes happen in a short time ( like comopser install ) at some point fsevents might be lost and not all changes are synced
b).. ?
@mickaelperrin can you add things you know here?
Instead of showing a annotated configuration, rather split into global options and syncs option and explain each value as:
anybody willing to help here? Be bold https://github.com/EugenMayer/docker-sync/wiki/2.-Configuration
everybody has write access
Avoid conflicts and inconvenience if sync-endpoints are named like there app-containers, which makes sense for the convenience see https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/126?u=eugenmayer
Its not like i do not write tests, but this here is pretty special. Containers, remote file sync and so on.
Any rubyist available to explain, how this would be done in a considerable amount of time?
Anyone who feels happy to structure the test-idea for this project, please go on!
/Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_strategy/unison.rb:49:in `sync': undefined local variable or method `out' for #<Docker_Sync::SyncStrategy::Unison:0x007fc942119b18> (NameError)
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_strategy/unison.rb:94:in `start_container'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_strategy/unison.rb:32:in `run'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_process.rb:64:in `run'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_manager.rb:103:in `block in run'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_manager.rb:102:in `each'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/lib/docker_sync/sync_manager.rb:102:in `run'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/tasks/sync.thor:32:in `start'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
from /Users/mickaelperrin/tmp/docker-sync-perso/docker_sync/bin/docker-sync:11:in `<main>'
Since if there is any ressource consumption, it would be the watcher ( fswatch ) under osx, make it possible to disable any file-watching. Even though this means the user has to either run
docker-sync sync
Himself whenever he wants to sync back or, and thats much more interesting, use IDE tools like file-watchers of e.g. Intellij to fire up the sync whenever you save a file ( of a specific glob ).
Its not a hard deal, just create watch_strategy as a configuration and allo
And create documentation why this is offered and how to utilize the IDE for that. Anyone feels happy, please help writing docs in the wiki :)
Sometimes it seem content are changed on both sides. I'm not sure it's actually the case because my IDE settings was definitely not changed on the server side.
Anyway in those case it would be great to be able to resolve the conflict by forcing on side or the other.
That's the errors I get with docker-sync sync
Looking for changes
Waiting for changes from server
Reconciling changes
Synchronization complete at 10:22:50 (0 item transferred, 6 skipped, 0 failed)
skipped: .idea/workspace.xml (contents changed on both sides)
skipped: README.md (contents changed on both sides)
skipped: web/sites/default/settings.php (contents changed on both sides)
skipped: web/sites/development.services.yml (contents changed on both sides)
skipped: web/themes/ehnv/templates/system/page.html.twig (contents changed on both sides)
If there is a docker-compose-dev.yml file in companion to the docker-compose.yml, load it as the second argument:
docker-compose -f docker-compose.yml -f docker-compose-dev.yml
This way, we can simplify https://github.com/EugenMayer/docker-sync/wiki/Keep-you-docker-compose.yml-portable
There is already an example in the boilerplate https://github.com/EugenMayer/docker-sync-boilerplate/tree/master/splitted-compose
Make it even easier to run a dev-stack and not to start several shells and so on
docker-sync start-stack
This should start the sync-services, wait until they are up, then start docker-compose. This means the docker-compose.yml file must be located next to the docker-sync.yml file
Explain all the different strategies we have right now, so people actually can chose out of the aspects
Hello!
I'm using docker-sync for symfony app. I have problems with user that sync in the container.
in eugenmayer/rsync container user is www-data, in php-fpm container user is xfs with another g_id, so I'm in troubles with permissions.
docker-sync.yml
syncs:
appcode-sync:
src: './../'
dest: '/var/www'
sync_host_ip: 'localhost'
sync_host_port: 10872
sync_user: 'www-data'
sync_userid: '1000'
sync_group: 'www-data'
sync_groupid: '82'
docker-compose.yml
version: '2'
services:
db:
image: mysql:latest
ports:
- "3306:3306"
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: lookaround
MYSQL_USER: root
MYSQL_PASSWORD: root
php:
build: ./../.docker/php-fpm
expose:
- "9000"
volumes_from:
- container:appcode-sync # will be mounted on /var/www
#command: ['watch', '-n3', 'cat /var/www/web/app_dev.php']
links:
- db
- redis
nginx:
build: ./../.docker/nginx
ports:
- "80:80"
links:
- php
volumes_from:
- php
volumes:
- ./../var/logs/nginx/:/var/log/nginx
elk:
image: willdurand/elk
ports:
- "81:80"
volumes:
- ../.docker/elk/logstash:/etc/logstash
- ../.docker/elk/logstash/patterns:/opt/logstash/patterns
volumes_from:
- php
- nginx
redis:
image: redis:latest
phan:
image: cloudflare/phan:latest
volumes:
- ./../:/mnt/src
volumes:
appcode-sync:
external: true
When verbose is activated, unisonshould be more verbose.
PR is incoming.
Hey @EugenMayer ... first off thanks for making this project, performance has become a real pain for us after moving to docker last week.
I'm not sure if I'm just doing something wrong or what but atm the files are coming through as nobody nogroup and my app loses permissions to write cache etc.
docker-sync.yml
syncs:
app_vol:
src: './'
dest: '/var/www/magento'
sync_host_ip: 'localhost'
sync_host_port: 10871
db_vol:
src: './.docker/mysql'
dest: '/var/lib/mysql'
sync_host_ip: 'localhost'
sync_host_port: 1087docker-compose.yml simplyfied
version: '2'
volumes:
app_vol:
external: true
db_vol:
external: true
services:
nginx:
container_name: nginx
image: nginx:latest
volumes_from:
- container:app_vol:rw
volumes:
# - "./:/var/www/magento"
- "./.docker/sites:/etc/nginx/conf.d"
ports:
- "80:80"
links:
- php
env_file:
- ./project.env
db:
container_name: db
image: mysql:5.6
volumes_from:
- container:db_vol:rw
volumes:
# - "./.docker/mysql:/var/lib/mysql"
- "./.docker/db/:/docker-entrypoint-initdb.d/"
ports:
- "3306:3306"
restart: always
env_file:
- ./project.env
php:
container_name: php
image: mikeymike/docker-php
volumes_from:
- container:app_vol:rw
volumes:
# - "./:/var/www/magento"
- "${HOME}/.composer:/root/.composer"
- "${HOME}/.ssh:/root/.ssh"
working_dir: /var/www/magento
ports:
- 9000
links:
- db
env_file:
- ./project.envAny thoughts on this would be awesome :D
Mentioned here https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/130?u=eugenmayer
Using OSXFS to sync from host to sync container "tmp folder" and then sync from this tmp folder to sync-container app-folder "locally".
This has some pros:
Cons:
a) still needs 2 fswatch processes : One the the sync container to watch the changes on the tmp folder, one on the app-mount folder in the sync container to get app-container changes on the share
b) docker for mac only and probably OSX only
Comments on the cons:
a) well, thats just the same number as we would have without OSXFS, so its rather on par, but, fswatch is more effective on linux due to inotify evens, so it might gain performance, sind we reduce the fswatch on OSX, shifting it into linux
b) Well we do support OSX with docker-sync yet only ( i guess, not tested on windows ). Secondly, since it would end up being a strategy only, we could say that some strategies are not available for some docker-types like docker-machine and stuff. So thats sovleable
the data flow would look like this
Host --- OSXFS ---> sync-container /tmp[fswatch-trigger]--- local unison sync ---> sync-container /app/code[fswatch-trigger] ----- named volume mount -> app container
I am trying to start the boilerplate project from here https://github.com/EugenMayer/docker-sync-boilerplate
docker-sync-stack start /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:105:inprivate': nil is not a symbol (TypeError)
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:105:in <class:Mapper>' from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:5:inmodule:Compose'
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose/mapper.rb:2:in <top (required)>' from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose.rb:10:inrequire_relative'
from /Library/Ruby/Gems/2.0.0/gems/docker-compose-0.8.3/lib/docker/compose.rb:10:in <top (required)>' from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:inrequire'
from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in require' from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.15/tasks/stack/stack.thor:5:in<top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.15/bin/docker-sync-stack:23:in load' from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.15/bin/docker-sync-stack:23:inblock in <top (required)>'
from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.15/bin/docker-sync-stack:21:in each' from /Library/Ruby/Gems/2.0.0/gems/docker-sync-0.0.15/bin/docker-sync-stack:21:in<top (required)>'
from /usr/local/bin/docker-sync-stack:23:in load' from /usr/local/bin/docker-sync-stack:23:in
Docker for Mac: version: win-beta-v1.12.0-rc5-beta21-68-g5b59d37
OS X: version 10.11.3 (build: 15D21)
logs: /tmp/0D3FC0FD-7C1E-4CF5-9BE7-AA033B364868/20160731-124903.tar.gz
[OK] docker-cli
[OK] app
[OK] moby-syslog
[OK] disk
[OK] virtualization
[OK] system
[OK] menubar
[OK] osxfs
[OK] db
[OK] slirp
[OK] moby-console
[OK] logs
[OK] vmnetd
[OK] env
[OK] moby
[OK] driver.amd64-linux
Thanks for help!
@mickaelperrin how do i get the unox dockerfile for now, so i can push it?
You should then reference it as default in the new unison strategy
Hi there!
First off -- love the amazing work you're doing here. From my research and experience, this is by far the best solution to osxfs performance problems, until Docker for Mac is able to fix for good.
I've noticed that when sync'ing with unison-dualside (not unison), my code effectively gets copied from 1 src folder to a 2nd src folder (quite destructive, in fact).
Sync config:
syncs:
web-sync:
src: '../web'
dest: '/app'
sync_host_port: 10872
sync_strategy: 'unison-dualside'
sync_userid: 'from_host'
unison-dualside_host_ip: 'auto'
unison-dualside_host_server_port: 6000
boxoffice-sync:
src: '../boxoffice'
dest: '/app'
sync_host_port: 10873
sync_strategy: 'unison-dualside'
sync_userid: 'from_host'
unison-dualside_host_ip: 'auto'
unison-dualside_host_server_port: 6000
Compose Config:
version: '2'
services:
web:
build: ../web
volumes_from:
- container:web-sync:rw
expose:
- 3000
ports:
- "3000:3000"
depends_on:
- mongodb
- redis
- boxoffice
- kraken
- geoduck
- multiverse
- discover
- embed
boxoffice:
build: ../boxoffice
volumes_from:
- container:boxoffice-sync:rw
expose:
- 4567
ports:
- "4567:4567"
depends_on:
- postgresql
volumes:
web-sync:
external: true
boxoffice-sync:
external: true
Any thoughts on why it's cross-sync'ing here? Thanks a ton!
Are there any strong feelings against rewriting docker-sync into golang? It has some pros:
Cons:
For now we use a jessie-based image https://hub.docker.com/r/eugenmayer/rsync based on https://gist.github.com/EugenMayer/f2698a902f8c6f9b214076e973dabd65#file-dockerfile ( did not create a repo yet )
We probably want to slim down the image on alpine. Anybody volunteers? :)
watch_excludes: ['./.git','./node_modules','./bower_components','./sass-cache','./.sass-cache','./.sass-cache', '.coffee','.scss','.sass','.gitignore','.ts','.less']
I made a link from the docker-sync exe to /usr/local/bin
When I run docker-sync sync -n src --config='/path/to/config/docker-sync.yml', I got the following error:
/Users/mickaelperrin/.rvm/rubies/ruby-2.2.1/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- docker-sync/update_check (LoadError)
from /Users/mickaelperrin/.rvm/rubies/ruby-2.2.1/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
from /usr/local/bin/docker-sync:5:in `<main>'
This also prevents the sync to be done on fsevents.
Using an absolute path works.
It will be replaced by unison-unox, see #74
Hi,
Thanks for working on this project.
I tried to configure my own docker project ith docker_sync and also tried the boiler plate but each ends with the error:
ok Starting unison
/Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_strategy/unison.rb:38:in `sync': undefined method `join' for nil:NilClass (NoMethodError)
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_strategy/unison.rb:93:in `start_container'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_strategy/unison.rb:32:in `run'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_process.rb:64:in `run'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_manager.rb:103:in `block in run'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_manager.rb:102:in `each'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_manager.rb:102:in `run'
from /Users/mickaelperrin/tmp/docker_sync/tasks/sync.thor:32:in `start'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
from ../../docker_sync/bin/docker-sync:11:in `<main>'
It looks like the args are not properly parsed.
Am I missing something ?
Regards,
Split the now days long readme into WIKI topics.
I beg people to help with that task :)
Hi,
I would love to have the opportunity to start / stop watchers from external calls. This would allow deactivating syncing temporarily when performing some tasks and reenable when needed.
The first use case of this is currently while installing Drupal from composer, we could wait the end of the bootstrapping script and the run manually a sync task.
What do you think of that ? what about implementing them as daemons ?
options->compose-path
Let the user manually set the location of his docker-compose.yml file optionally, so it does not need to be located where the docker-sync.yml file is
the fswatch stay alive and are not cleaned up anymore, beside one could do a
pkill fswatch to kill all of the running watchers.
It seems to happen if compose times out with the regular "to long HTTP request" - maybe others.
An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
EXCEPTION: #<Docker::Compose::Error: 'up' failed with status 'pid 4925 exit 1':
Not sure how to tackle this issue, we probably should rethink our whole architecture using either local sockets or pids
check the rsync image from time to time, same as gem
I am experiencing sync issues with unison, I try to understand what's going on.
I activated the verbose option and got this issue. It looks like there is a color definition missing.
/Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/shell/color.rb:90:in `const_get': uninitialized constant OK (NameError)
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/shell/color.rb:90:in `set_color'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/shell/basic.rb:98:in `say_status'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/shell.rb:59:in `say_status'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_strategy/unison.rb:83:in `start_container'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_strategy/unison.rb:32:in `run'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_process.rb:64:in `run'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_manager.rb:103:in `block in run'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_manager.rb:102:in `each'
from /Users/mickaelperrin/tmp/docker_sync/lib/docker_sync/sync_manager.rb:102:in `run'
from /Users/mickaelperrin/tmp/docker_sync/tasks/sync.thor:32:in `start'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
from /Users/mickaelperrin/.rvm/gems/ruby-2.2.1/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
from ../../../docker_sync/bin/docker-sync:11:in `<main>'
Which extra configuration does unox need in comparison to unison-onsided? We need this in the docs as a migration guide and as a fat-notice in the changelogs.
@mickaelperrin could you sum it up?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.