This forum has moved to a new location and is in read-only mode. Please visit talk.octobercms.com to access the new location.
@maxacarvalho If I was going for an individual site deploy, I'd likely just check in everything but vendor, storage, and .env into git and deploy/composer install the files. However my goal from the beginning when I migrated to OctoberCMS was to build reusable, versioned plugins that I can add to client sites. My clientele are all fairly niche and have a pretty large overlap in functionality. The challenge here is that I'm using private bitbucket packages - which is why I went the satis route. If all of your plugins are open source you could skip that step.
I build my plugins based on common default functionality and use semantic versioning to ensure compatibility requirements. With my setup I'm able to composer require my themes into a fresh octobercms install which will automatically install all of their plugin dependencies. If I deactivate core updates, I can run composer update at will without worrying about pushing any package or plugin beyond its limits.
Similarly selling new non-breaking functionality to a client means updating their site's composer.json with the new plugin version (e.g. v1.5 instead of v1.2), running a composer update, php artisan october:up, and having it auto implement to their server. Enjoy your new widget or import/export!
This might be overly complicated for a one-off site but my motivation was moving a web agency from an outdated, non-modern cms to something that can hopefully make things easier to build and update. If anyone has any questions about my experiences, feel free to ask. I'm still perfecting my process but I'm really pleased with how it is working.
Last updated
This is how we Deploy October To Production. We actually spent a lot of time and that's the best solution we came up with. It's pretty seamless once set up.
Most importantly, there's no manual pushing of files. Everything is pushed on every commit. 100% automated.
Last updated
Hello,
how have you been dealing with caching of twig and other files in the storage/cms directory - across multiple servers?
I'm using Forge, I have 1 load balancer, 2 app servers and 1 db/cache server - everything is working fine except files in some storage directories are only being created on one server. I know this is due to the load balancer - however is there a way to move all the caching to a dedicated server so all can share?
Thanks, Ross
Yes and it's supported out of the box by October. You need a central cache instead of file caching on each webserver. The best option is Redis and you can use a client like Redsmin to view the cache keys. Check the October docs on caching
This will require some changes to your code but the performance boost along with centralized cache is worth the dev time and gives you the ability to scale faster if you get a traffic spike.
The other option is setting up a replication ring between the web servers but that's prone to error as a user could upload a file to one server then another user requests it from the other node before the replication has occurred.
Aside from cache files, make sure all static assets are on a CDN.
If you want more detail I'll put together a blog post with guidance on how to do all of that.
Thanks for the info.
I do have Redis setup in the cache.php file - it's pointing to the db/cache server external IP. I don't see session files being created in the framework/sessions folder so I assume it's working partly - however cms cache files are still being created. Also, files are appearing in the temp folder.
All other assets like images/js will be hosted via CDN.
Any pointers would be great as I can't seem to work this out.
Thanks!
** Edit
I'm running redis-cli monitor on the 2 app servers and the db/cache server. Looks like it's not hitting the intended host server. Only the 2 app servers are showing connections. Hmmm... what did I do wrong.
Last updated
OK so I managed to solve the Redis connect issue. The db/cache server is now being hit instead of the 2 app servers - however I still have issues with where cache files are being stored.
Looking at the storage directory of each app server, files are still being generated under CMS and TEMP. How can I centralise this as well so both servers use a single set of cached files?
info14532 said:
If you want more detail I'll put together a blog post with guidance on how to do all of that.
just wanted to check if you have made a blog for this , also any idea on how to migrate the file system to aws