Use DDEV instead of Wodby

[rsanzante]

This just a proposal.

DDEV is surely the most used tool for Drupa local development. Apart from containers, it provides very useful tools like ddev pull tu pull data from a remote site, snapshots of the local database and many more.

We should evaluate if it is possible to use DDEV in this boilerplate keeping all the current functionalities and gain some benefits from DDEV.

Thins to keep and eye on:

1. Behat preconfigured and easy to run
2. MkDcos aditional container with its own URL for documentation
3. UID issues when runing the contaniers
4. BackstopJS preconfigured and easy to run
5. Drush preconfigured
6. Easy installation of a boilerplate similar to current way (using composer create-project
7. Drupal multisite support
8. Adding new components (Varnish, Redis/Memcached, Apache/Nginx, etc)
9. Use it to run tests in CI
10. Use two different sites that communicate between them (for example, one site queries a REST service of the other). This means two different codebases, so two different ddev sites (or one ddev an the other can be any other technology)

[omarlopesino]

I think this is a good idea and would rid boilerplate of some responsibilities that could be saved now: container orchestration, commands management (Makefile), container versioning (at least for the base containers), etc.

My main concern is the point about Use it to run tests in CI as ddev exposes a port for containers, which should not be needed, but it is possible that either I am wrong or this problem may be solved somehow.

[jorgetutor]

I wonder if the Docker in Docker approach will make sense here, that way we can provide an image with DDEV and ports will not be an issue. We need to test it but I have understood DDEV has no dependency on the user 1000 as wodby

[rsanzante]

Apparently, DDEV does some magic to run the containers always with the user uid that run the ddev up command, or that's what I understood.