WIP Docker PR

[tomjn]

I don't expect to merge this PR as we'll create new PRs that take subsets of it out, or implement it differently. This will be similar to when we had M1 support, eventually this PR will have little to nothing in it and we can declare success!

Checks

• [ ] I've updated the changelog.
• [ ] I've tested this PR
• [x] This PR is for the develop branch not the stable branch.
• [ ] This PR is complete and ready for review.

[tomjn]

@pentatonicfunk one of the things we're hoping for, particularly in v3.8, si that we can separate out site/tool/extension provisioning, and the main/base provisioner. This way we can run just the main/base provisioner and package up a box to save time.

I expected the same to be true of a docker container, and that's the provisioner we would use to build an image as it installs all the packages necessary. We'd then try to remove things by using other containers so things weren't monolithic, e.g. a database container.

[tomjn]

I'd also like it if we can integrate as many things as possible into the existing VVV even without docker so that this PR gets smaller and more specific. We don't have to treat this as a single piece of work to be merged all at once

[pentatonicfunk]

@tomjn totally agree with you, this fork and PR merely a PoC and reference for the future when we actually start to fully support docker -- that if we really want to, and won't be a pain point to maintain.

And if there are any stuff here that can improve VVV in general, we can can just cherry pick it and make mini separate PRs like you already did. I don't even expect this to be merged at all, my main intention was to experiment, see how VVV will behave ( especially the provision part ) if i do use it with docker in certain way ( monolithic way ), and push my self to make it somewhat usable, and hopefully some good things get picked up after that.

As for services based containers ( docker-compose kind of ? ), that seems like the standard / ideal way in docker world. Although for development, based on my own personal experience, i can't say that i am comfortable with multi containers, having to interact with different container for different task is tedious. e.g. when i need to interact with mysql i need to go to mysql container, but if i wanna quick modify nginx config i need to interact with nginx container and so on. Meanwhile in development phase, these kind of tasks are often needed to be done and done quickly. Again, its just me. I am not familiar and not get used to it. One of the nice thing i love about VVV / vagrant, is that vagrant ssh and hack everything i want inside that single shell instance, be it modify nginx config or just tailing specific logs.

PS: i really got great input and insights from here, thanks a lot for doing it!

[tomjn]

@pentatonicfunk I've started a PR to see what more I can merge into VVV core, and left some more comments to try and clarify or suggest some things, I'm a little strapped for time today but intend to give this a proper run test sometime this week

[pentatonicfunk]

thanks @tomjn, i'll try to update my repo as per your suggestions

[tomjn]

@pentatonicfunk I've started https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2632 as I couldn't modify this branch, and merged some changes and made others compatible with non-docker.

Would you like to continue there if I add you as a repo member? We're not far from getting this in and it's a big milestone

[pentatonicfunk]

yes for sure

[tomjn]

closing this as we have #2632