Level 122
you could put the site into maintenance mode for a few seconds
or, what I do is replicate into a new folder, run composer install and then flip a symlink to point the webserver to the new folder
Mar 29, 2022
7
Level 1
Potential downtime on deployment with server side Composer installation
I deploy my code to production via rsync:
-a --delete --delay-updates
For this process I also ignore the vendor folder (plus the .env file and stuff like that). I sync composer.json as well as composer.lock. --delay-updates are added for better atomicity.
Then I run the following command on my server to make sure that the Composer packages are on par with my dev setup:
composer install --no-dev --optimize-autoloader --apcu-autoloader
Somewhere in this process a problem occurs. If any request hits the server or a command is executed during the deployment, Laravel fails to load due to missing service providers.
Before that, I never had any errors during deployment but I also deployed everything - including the vendor folder and dev-packages which means that I also didn't run Composer server side. I've tried mitigating this problem by adding both --optimize-autoloader and the --apcu-autoloader (APCu is indeed installed on the server) options to the Composer command.
I'm tempted to go back to the earlier setup but that means I will deploy the dev-packages as well.
Any input is greatly appreciated.
Level 1
@Snapey I assume your second solution will require Apache to follow symlinks, yes?
Level 1
@fogley This is also known as "blue-green deployment". Basically you will have the same app deployed twice and can easily swap back and forth using a symbolic link. I'm not entirely sure on how Apache works, but presumably you'll have to enable FollowSymlinks at the root level. Just make sure to disable it everywhere else.
1 like
Level 122
@fogley no, the symlink is done to the folder above what apache is looking at
ie I have a 'Live' folder which is symlinked to the Laravel project
The webserver serves Live/public
for instance;
drwxrwxr-x 14 mark mark 4096 Mar 27 14:31 1648391499/
drwxrwxr-x 14 mark mark 4096 Mar 28 12:54 1648472062/
lrwxrwxrwx 1 mark mark 10 Mar 28 12:54 Live -> 1648472062/
drwxr-xr-x 3 www-data www-data 4096 Dec 11 13:03 master/
The folder name is created with a timestamp. Live is a symlink to the latest folder.
master contains things I need in each deployment such as the .env file and it is copied into the deployment folder at each deploy.
1 like
Level 1
@Snapey Very helpful, thanks. I'll reimplement my deployment to fit this general idea. Much appreciated.
Level 1
Hmm, so. I tinkered with the above solution but it presented a lot of new problems. One example is the storage folder on the server which needs to be maintained across deployments.
Another problem is the fact that I don't deploy files that are currently not committed (AKA. files that are work-in-progress). - Obviously the older version of the files still needs to be present on the server.
However, I found a rather simple workaround. I just "deploy" my project locally by running this on my development machine prior to executing my rsync command:
composer install --no-dev --optimize-autoloader
When the sync is done, I revert back to the dev environment by running this:
composer install
Level 122
Storage folder: Can also be managed with a symlink to a storage folder in the master folder.
File integrity: You should be working from a version control system. A simple git clone command can pull down the main branch or any specific branch to the server before running composer install.
Please or to participate in this conversation.