Propose alternative stack based on a VM

[tristanbes]

Hello,

I'm proposing an alternative stack using a virtual machine provisionned with Ansible using open-sourced manala roles;

It has very minimal impact to the actual project;

2 directories has been added:

• var/ -> must be present to the log and cache dir can be symlinked inside the VM
• ansible/ -> contains the configuration for ansible to provision the VM

1 file has been added:

• Vagrantfile which contains the skeleton for the VM;

I don't want to start any fights againt Docker; The stack i'm proposing is working on Unbutu/Debian/MacOS without any performance problematic we often see on MacOS environment with Docker;

I've updated the README to include the requirements;

Summary:

You need to install 4 things:

• make
• VirtualBox 5.2.4+
• Vagrant 2.2.5+
• Vagrant Landrush 1.2.0+

Then run

    $ make setup # boot + provision the VM
    $ vagrant ssh # to access the VM
    # uncomment the alternative DATABASE_URL inside the .env file (L39) and comment the default one;
    $ make install-app # provisions the app

The codes lies under /srv/app/ inside the VM.

Results:

Accessible on : http://resop.vcap.vm/
3 min to boot & provision both the VM and the app

[mRoca]

Hi Tristan, thank you very much for your PR!

I'm not sure it's a good idea to add another stack in this project:

• we'll have to maintain 2 different stacks and help people on both
• we'll need to sync config and php extensions (e.g.: you don't have APCu on yours for now, and your vm is running Debian whereas the Dockerfile is based on Alpine)
• adding all those files and Make commands in the repo (even if in only one folder) will increase the complexity of the project for a newcomer

But as your already did this great job, it would be nice to keep it. Do you see any other way to allow people to use it, but without adding the files ? A single .md file ? Another repo ?

wdytat ?

[tristanbes]

I totally get your point about having 2 stacks; TBH it's a very selfish move, because Docker has so many performance problems on OSX that in order to just boot the project I didn't want to get any closer to docker than that;

As for the maintenance, it requires very little maintenance, but it's a very understandable point. especially since I'm on medication leave because of COVID19 & I don't know how much time I can put in this project. I just needed a quick way (not docker) to do some code review on the project;

I won't get mad at all if you don't merge this PR, it's the game ;), but I definitely agree, it may be useful to other developers;

We can split the documentation in another markdown file; Having another Makefile in order not to pollute the file is easily doable, but it would mean that we have to maintain 2 Makefiles instead of 1 for any changes related to the project itself;
But one thing; not committing the ansible/ dir + Vagrantfile file (i'm not talking about the var/ dir which should have been present) will make any use os the VM stack very difficult for newcomers;

Another solution would be documenting that a VM stack solution is possible and point to this PR.

---

I saw that one of the difference is ACPu.
Can I ask why you would prefer to use APCu over (preferred) OPcache ?

[mRoca]

APCu and OPcache are usefull, it can be nice to have both ;-) OPcache for ... well, opcaching, and apcu for app cache.

I'll have a look to what we can do tonight.

Regarding the performance issues on Mac, I think the stack can be fast enough with the good docker-compose.override.yml file (the :cached property makes the difference !)

[tristanbes]

Unless i'm wrong, you don't use APCu in this project; I only saw apcu were using to optimize the autoloader but the optimize-autoloader + authorative class map is preferred; (https://getcomposer.org/doc/articles/autoloader-optimization.md)

Also, if you require application cache, a key-value store like redis would be better for usability/purpose w/ the Symfony cache component;

[fmeynard]

I'm not convinced by adding this to the project.
Providing one stack sounds already fine to me especially because Docker is working on Linux, MacOS and Windows.

Contributors are free to use it or build their own stack, it can native, vagrant etc..

So maybe a wiki page and a reference to it in the readme ?

[mRoca]

We close this PR, as we won't include a second stack into the project, but:

• we have added a How to boot the stack without docker part in the README
• we have added a link to this PR in the README