Using Trellis to Provision and Deploy a Laravel app

trellis
1

I’ve recently taken a couple of on-line courses on Laravel, and I have a very simple app in development.

I’ve seen that a lot of Laravel developers use Forge to provision VMs and then deploy apps.

Is there any good reason I can’t use Trellis for Laravel in the same way that I use it for WordPress? Most of the requirements are the same, and it’s easy for me to add in a few Ansible roles where necessary. Given Sage 9 is moving to support Laravel Mix, can I use (modified) Trellis deploy scripts to deploy my Laravel app?

I understand that the directory structure is different but that hopefully won’t be a show-stopper.

I’m going to give it a go anyway, just wondered if anyone has any insights or experiences.

2

I recently deployed a Laravel app with Trellis (and am looking to do this more). Taking cues from a few people here on Roots Discourse, I just copied and modified the wordpress-setup and wordpress-intsall roles. I made a fork of Trellis if you want to see an example:


These modifications were my first foray into Ansible, so there might be some further modifications that would be needed. Any tips/feedback would be great. I do know I made some more changes to this in my actual project code (I should update this fork to reflect those changes). You might want to make some tasks for Artisan to generate the app key and to migrate (you may need the --force flag). Most of the changes you’ll need to make will probably be for the .env template (roles/laravel-install/templates/env.j2 and trellis/roles/deploy/templates/env.j2).

EDIT: Updated link to laravel branch instead master (since I changed the name and reset the master branch).

4 Likes
3

This is great @knowler, thanks!

I should have dug a bit deeper on discourse before posting.

Have you got Trellis deploys working for your app?

The more I learn about Laravel, the more I like it.

Turns out that Roots have already introduced me to a lot of the stuff it uses like composer and dotenv, so I feel right at home.

I’ll take a closer look at your fork and try using it for my app.

I will let you know how it goes…

4

Yes, I have deploys working great. In my project files, I’ve added a lot of the secrets from .env to the vault and then modified the templates to reflect this. Also, after reviewing that code, the --force flag is required for migrating in production (otherwise it’ll fail because it prompts you—proceed with caution though). I’ve appended the following migration task to roles/deploy/hooks/build-after.yml:

- name: Migrate
command: php {{ deploy_helper.new_release_path }}/artisan migrate --force

I haven’t figured out an ideal solution for key generation. In the fork, I have a task for it in the same build-after hook, but this means that every time you deploy, it generates a new key, which I think was problematic for me, because in my project files, I eventually commented out the key generation task. Alternatively, you could generate it yourself and just add it to the vault. However, I’m sure there’s a way to have Ansible check if it’s already there—my knowledge of Ansible just isn’t there yet.

1 Like
5

I think you can just use the ‘creates’ option to have a command run only if the file doesn’t already exist. Example here:

http://docs.ansible.com/ansible/latest/command_module.html

6

Sorry @knowler, now I see that the app key lives in the .env file so the above post is not helpful. The question is, does the key need to be the same for every environment?

Maybe the answer could be to add it manually at the beginning of the project in a similar way to how we add salts in a fresh vanilla trellis project. I think it does need to go in the vault as you say.