I am seriously considering building my new version on Laravel framework. At the moment I use my own custom application that emerged as I was making website and improving it over the years.
In this moment I simply pull from svn source run setupApp.php that basically makes some local folders and sets permissions and point Apache document root to public/ and I am ready to let load balancer hit that server... whole application with local caches works independently and session management is done trough session.save_handler=memcache and basically all 10+ servers work accessing the same session data and everything data-wise is done trough databases.
With Laravel I see there something like:
artisan down
ok that would serve 'maintenance' but only on one of the servers... what about the rest of the cluster?
Whole Laravel is done with idea 'one server one application' I am sure it is still useful but in order to use 'full potential' of this framework on the cluster what are the best practices and what to avoid using?
So basically my question is how to make laravel project deployment on the cloud with multiple 'worker' instances.
So there are multiple ways to do this. I currently run 3 app servers with a dedicated DB/Cache/Search backend. For non-db migration changes I have a fabric script that runs and just does artisan down on each one updates git and then artisan up. Easy peasy.
For migrating changes the same thing happens, except instead of doing artisan up right away they all stay down and i run artisan migrate on one of the app servers, wait until everything migrates then do artisan up on all of them.
Alternatively you could do this at the load balancer level which is probably what I'm going to do at some point. Right now there are some gotchas with artisan down and composer updates. If composer is updating the framework code the page that artisan down presents will 500 because it needs those components to run. Ideally the framework would pre-generate a down.html page or something of the sort instead of trying to run render a down page each time the endpoint is hit.
His suggestion was to set up apache/nginx to point to /var/www/app which is just a symlink to /var/www/releases/release_12-45_01-01-2015
When he triggers a new deployment, the script makes a new release directory using the time and date, downloads the site from github, runs composer, and creates a whole new application installation, and runs unit tests. If everything passes, then the script changes the app symlink to the new release directory.
That way there is no downtime during the build process. If something goes wrong, it's easy to change the symlink to the last release directory. This could start taking a lot of disk space so some kind of cron job to delete the all but the latest 3 releases is probably a good idea.
Only problem with symlink versions are files in public (uploads etc) and database stuff. It's good for a simple website but nothing more without extra steps to deal with those things.
