Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker Volumes Usage #511

Closed
llaville opened this issue Feb 25, 2019 · 3 comments
Closed

Docker Volumes Usage #511

llaville opened this issue Feb 25, 2019 · 3 comments
Assignees
Labels

Comments

@llaville
Copy link
Contributor

Hello @cytopia

It's not really a bug report, and most probably be labeled enhancement, and as it's also a little question: should be in forum. Sorry, if it's not in good place.

With your recent works, especially on ELK stack, I've noticed usage of Docker Volumes.
Could you make a summary about usage, and if possible a link to current doc.

I've also noticed that some docker-compose.override.yaml still use volume folder bind.

https://github.com/cytopia/devilbox/blob/master/compose/docker-compose.override.yml-rabbitmq#L18
https://github.com/cytopia/devilbox/blob/master/compose/docker-compose.override.yml-varnish#L19

Thanks in advance to clarify the situation !

@llaville llaville added the bug label Feb 25, 2019
@cytopia cytopia removed the bug label Feb 26, 2019
@cytopia cytopia self-assigned this Feb 26, 2019
@cytopia
Copy link
Owner

cytopia commented Feb 26, 2019

I am slowly migrating the Devilbox to use Docker Volumes instead of simple directory mounts (where possible). This brings several advantages, performance improvements and fixes a couple of issues on Windows and MacOS.

To ensure I will not break all setups out there at once, I do it gradually, by implementing parts of it into the override container. The full migration will be handled in the upcoming release: #416

This includes the full switch to Docker volumes.

I do however encourage everybody to already use the mentioned release branch, as many other bugfixes already went into it.


Latest features, improvements and smaller bugfixes are available in the master branch first (e.g.: Varnish, ELK stack, etc). I will rebase this around every week into the release branch. So feature-wise its a bit behind, but should be the new standard.


Why am I not merging the release branch right away?

The release branch will make all your persistent data unavailable. So one must first backup all databases, switch to the release branch and import them again. Merging this without enough visibility will most likely make people unhappy and think they might have lost their data.

So I am still in the process to raise visibility for that branch and that's why I also encourage people to use this one (migrate to it) first.

@llaville
Copy link
Contributor Author

Thanks for this reply and clarify the situtation !

@cytopia
Copy link
Owner

cytopia commented Feb 26, 2019

You're welcome. I will close this issue then. As a side note: You've already mentioned it above, that this kind of stuff is better kept in the Forum and I also fully agree. This is important information and should not be hidden in closed issues. ;-)

So please add similar questions to the Forum in future, as it will persist there for everybody to pick up.

@cytopia cytopia closed this as completed Feb 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants