Docker-sync: Initial Configuration Wizard

[EugenMayer]

When you start with docker-sync or you on-board a project, you need to create a docker-sync.yml file and a docker-compose-dev.yml file. Why not simplify this task by having

docker-sync configure

it reads your docker-compose.yml - gets all the host mounts ( all volumes starting with ./ or / ) and creates a sync for that in a docker-sync.yml. It adds some defaults like excluding node_modules and thats basically it.

This way people could have their on-boarding process simplified a lot, we could always provide best practises in those wizards and docker-sync would go like

gem install docker-sync
cd myproject
docker-sync configure
docker-sync-stack start

What do you guys think. Anybody feels luck picking this task?

[ignatiusreza]

Processing all host mount might be a bit too much, for example in our project, we have volume for .pry-history, since we want to keep the history across container lifetime, but we don't necessarily need docker-sync to make it super fast.. or .pryrc to keep personal customization.. but, it could be a reasonable default, and user could always edit the generated files..

About the default ignore, it could get ugly really fast, different project have different stuff that need to be ignored, how are we going to keep up? Instead, can't we take hint from .gitignore, .dockerignore or both?

[rwilliams]

Instead, can't we take hint from .gitignore, .dockerignore or both?

I like this. Look for and parse these guys and allow a selection from them maybe?

Also just some brain storming but i imagine this wizard parsing the docker-compose.yml allowing a selection of which services require syncing and then which volumes from those services they would like to sync.

[ignatiusreza]

Thinking about it more.. maybe a saner default is to automatically extract only host mounts which have relative path ./, (which should be relative to the root of the project).. it should be the one that you're making changes to anyway..

I can't think of a scenario that one would mount an absolute path, without breaking the possibility of sharing the same docker-compose file with team across multiple machine.. and even in case when you're working individually on a project, why would you want to mount something from absolute path on the host into a docker container, on which the path, and the environment it is going to run in is going to be different..

and path which refer to your home directory ~/ should be related to configuration stuff which shouldn't change so often..

thoughts?

[rwilliams]

There could be edge cases where teams are using a personal .env file and absolute paths specific to their machine for host mounts.

Update: Disregard this comment.

[EugenMayer]

As you all elaborated, it is hard to guess which host mount is the one you need to be synced and kept up to date and which is just a mount.

Since we simply cannot tell, be it relative or absolute, we should list every host mount and ask the user one by one, which he wants to sync - interactively non automated.

If we cannot guess by facts, just do not guess at all - let the user choose.

Waht do you think?

[rwilliams]

I say let the user choose. It shouldn't be difficult to implement and it should handle pretty much any edge case.

[EugenMayer]

seems like nobody is opting in to work on this. I guess we have been doing good without it too, so I close it for now. reopen it if you want to start working on it