Laravel 5 deployen bij hosting (Antagonist)

[TheRicolaa10]

Hallo,

Ik ben bezig met een project in Laravel 5 wat ik lokaal via Homestead ontwikkeld heb. Nu wil ik het graag deployen in combinatie met Bitbucket. Tot zover pullen e.d. is geen probleem. Maar zodra ik naar de url ga waar mijn project sta krijg ik een wit scherm (error 500). Heb ook geprobeerd om via de htaccess te automatisch te redirecten naar de public map, geen succes. Tevens heb ik geprobeerd in combinatie met Installatron om het werkend te krijgen, maar helaas.

Wat is de makkelijkste/handigste manier om een Laravel 5 project te deployen?

Alvast bedankt.

[ Voor 3% gewijzigd door TheRicolaa10 op 17-05-2016 21:07 ]

[Wiebeltje]

Ik zou eens in de errors logs kijken. Een 500 is meestal toch een PHP / .htaccess foutmelding.

[Room42]

Wat Wiebeltje zegt. Zonder de error log ben je in dit geval nergens.

[TheRicolaa10]

Wiebeltje schreef op dinsdag 17 mei 2016 @ 21:21:
Ik zou eens in de errors logs kijken. Een 500 is meestal toch een PHP / .htaccess foutmelding.

Hier had ik nog niet aan gedacht!
Heb even gekeken, kreeg deze melding:

code:

Backend fatal error: PHP Fatal error:  require(): Failed opening required '/home/deb101136/domains/domein.nl/public_html/live/bootstrap/../vendor/autoload.php'

Dus ik denk dat er iets niet helemaal goed ingesteld staat. Ik ga er nog is naar kijken.

[kutagh]

Dat lijkt mij een gevalletje ontbrekende dependencies. Ik gok dat je met de standaard .gitignore werkt, die dus bijvoorbeeld de vendor map weglaat in git, en dat je op de webserver geen composer install hebt (en/of kan) gedraaid?

[TheRicolaa10]

kutagh schreef op dinsdag 17 mei 2016 @ 22:35:
Dat lijkt mij een gevalletje ontbrekende dependencies. Ik gok dat je met de standaard .gitignore werkt, die dus bijvoorbeeld de vendor map weglaat in git, en dat je op de webserver geen composer install hebt (en/of kan) gedraaid?

Na het googlen van de melding hierboven was ik inderdaad vergeten om een "Composer install" te doen. Nu nog zorgen dat er geen public in de URL staat.

[Barryvdh]

Je Laravel installatie in in een losse map zetten:
domains/yourdomain.com/application

Dan in plaats van public_html gebruiken, die map verwijderen en een symlink maken naar application/public

domains/yourdomain.com/public_html --> domains/yourdomain.com/application/public

Hoef je niks te rewriten etc en kan je gewoon de Laravel mapnamen blijven gebruiken.

[ Voor 12% gewijzigd door Barryvdh op 18-05-2016 13:22 ]

[AW_Bos]

Barryvdh schreef op woensdag 18 mei 2016 @ 13:22:
Je Laravel installatie in in een losse map zetten:
domains/yourdomain.com/application

Dan in plaats van public_html gebruiken, die map verwijderen en een symlink maken naar application/public

domains/yourdomain.com/public_html --> domains/yourdomain.com/application/public

Symlink op een shared webhosting? Vaak is dat niet eens mogelijk .

[esch]

Vergeet ook niet te controleren of de webserver in de 'storage'-map mag schrijven. Daar liep ik laatst tegenaan...

[Ventieldopje]

AW_Bos schreef op donderdag 19 mei 2016 @ 23:27:
[...]

Symlink op een shared webhosting? Vaak is dat niet eens mogelijk .

Vaak is de ~/www map ook een symlink naar ~/public_html. Maar dat terzijde, je hoeft niks te symlinken of aan te passen. Je kunt simpelweg in je Laravel applicatie het pad van de public map aanpassen in public/index.php: https://laracasts.com/dis...ublic-directory-laravel-5. Zo kun je gewoon public_html gebruiken als public map.

In de index.php vind je overigens ook require call naar de Composer autoloader Maar die hoef je dan niet aan te passen.

In git kun je gebruik maken van een bare repository op je server (waar dan ook, als je er maar via ssh bij kan) waarna je met de post-receive hook een checkout kan doen (wel even de git work directory zetten naar het pad van je applicatie, die map moet leeg gemaakt kunnen worden en kan dus niet je ~/ zijn oid.). Na de checkout kun je dan natuurlijk scripts draaien als gulp of composer.

Beter is om gebruik te maken van een CI tool en je builds ook daadwerkelijk te testen voordat je ze deployed. De deployment is dan ook simpeler omdat je kan aangeven dat je de hele directory (waar ook al je scripts zoals composer al zijn gedraaid) wil deployen. Zo zit je niet snel meer dat de boel ineens niet meer werkt want dit zou betekenen dat je build ook zou falen.

[ Voor 46% gewijzigd door Ventieldopje op 20-05-2016 02:27 ]

[Barryvdh]

AW_Bos schreef op donderdag 19 mei 2016 @ 23:27:
[...]

Symlink op een shared webhosting? Vaak is dat niet eens mogelijk .

Ik dacht dat dat bij Antagonist wel kon. En anders is het niet zo handig, want dan kan je ook geen php artisan/composer commando's/git draaien. (Kan in principe wel, maar wordt je niet blij van, met vendor met en alles via FTP).

Je kan inderdaad ook de public map renamen naar public_html, al vind ik het meestal prettiger om een losse application map te hebben, en niet tussen de andere mappen van DirectAdmin te zitten. Ook kan je dan, als je iets verder wil gaan met je deployment, bijv. application/release/20160520.. maken, en application/current naar de nieuwste release wijzen. Dan kan je symlink naar application/current/public zijn, en als je een nieuwe release maakt, clone je alles naar een nieuwe map + install scripts + storage delen en dan de symlink aanpassen. Geen downtime Kan automatisch met bijv. http://deployer.org/