Using the existing repo for mautic’s docker image as a starting point, I was able to create a docker image to host version 5 of mautic.
However, there’s a problem with how I expect to update it. As a background, typically in other PHP apps I dockerize that use composer, I store the source code in my own git repo. I can update the packages, and also write my own plugins, and then commit that to source and have it deployed to the cloud (AWS in my case) when I choose.
This lets me test changes locally before they go out to production, eliminating the chance that an update screws up live users. It’s basically completely replaced on each deployed new version, and I control when.
In those situations, I’m able to mount a docker volume to persist ONLY the files that are not in source control. These are usually assets like images users uploaded.
However in mautic, the current strategy is to persist the entire docroot directory. I am new to mautic so I apologize if this has already been covered somewhere else in the documentation I missed, but are there more discrete folders for lets say just the images and uploads I can persist in a docker volume, so other files that may be changed as part of my code can be deployed without conflicting with what’s already in docroot?
Or is docroot sort of guaranteed to be a set of files that will never need to be touched once deployed for the first time? Sorry if this is confusing, thanks for reading.
1 Like
Look at the .gitignore in Mautic repo.: mautic/.gitignore at 3be38f31b6b5d8d8c7e1feff30dd4d388619ff70 · mautic/mautic · GitHub
I think the things that are listed there would need to be mounted as volume.
The problem comes at the moment of update. Besides updating the php files, there is an update necessary for the database files. So the normal process is to mount the docroot. When doing a version upgrade you run mautic:update:apply, run again mautic:update:apply --finish and clear the cache.
If you want to have a different approach, you need to test if you can do only the mautic:update:apply --finish without having run the update of the code before, but upgraded it with a new docker image.
What you need to mount for sure, is the media folder, the var folder for cache and temp and the settings. And like a said, a lot of testing, because you are trying a non standard thing here.
Make sense. Another open source PHP product I’ve successfully deployed to AWS is roots bedrock. It’s a composer based installation of wordpress that’s really popular.
In their deployment approach, rather than using a “off the shelf” docker image, I create a copy of the roots bedrock code (similar to mautic) and store it in my own github repo. Then I can build a Docker image containing the code from that repo, and any dependencies, prior to deployment.
There is just one folder, “uploads” that contains any content created by users that needs to be persisted across docker rebuilds. I just make sure that folder is mounted as a volume that points to cloud storage and it works beautifully.
I do also have my CI/CD pipeline run some commands to apply database migrations on each deployment, but that happens prior to pushing the updated docker image.
I was able to get mautic to do the same by putting it’s code in /var/www/mautic but pointing apache to /var/www/mautic/docroot. That way the bin commands (that expect files above docroot to be there) still run.
There were some features like zapier integration that were missing though, so I put migrating to mautic on hold for a bit. I hope to use it eventually, it would save me a ton of money over Active Campaign! If I find some time later this year, I hope to contribute to the code if I can get my head around it. I’m familiar with laravel, but new to Symfony.