0

We have experienced issues with Craft updates since the project config feature was released. Typically we run a multi-node application cluster that auto-scales up/down as needed. The current theory on what's going wrong is that if we have changes to make during the course of an update (ie, configuration, enabling modules, etc) we'd make those changes and they would likely be applied to only one node in the cluster and never sync to the other nodes.

How are other people solving this? I don't see recommendations in the official Craft documentation but I can envision two possibilities:

  1. Commit all changes to project config and only rely on deploys to put it in place.
  2. Create a shared mount point for project config so that all nodes read from the same configuration.

Any other ideas? Any officially blessed approaches here? I'm betting #1 is preferred.

7
  • "we'd make those changes and they would likely be applied to only one node in the cluster and never sync to the other nodes." - I can't tell from the context, but are you making those changes locally and deploying them? Or are you making those changes directly on production?
    – Brad Bell
    Jul 27 at 22:09
  • We have made changes after deploying the code - not using project config to push settings out. Jul 28 at 15:04
  • We made the changes directly on production, that is, not using project config. Jul 28 at 15:30
  • How exactly are you running your cluster? Kubernetes? AWS ELB? TBH this is not a problem for Craft necessarily, CMS like WordPress also have issues scaling and keeping resources in sync across multiple instances. Jul 28 at 17:22
  • @RitterKnight AWS ELB. I think you're essentially restating my question - I'm asking how others are keeping settings and resources in sync because surely we are not the only ones running Craft in a multi-node cluster. :) We use S3 for assets but what lives on disk is always isolated with ephemeral web nodes. Jul 28 at 19:07
0

As the Craft documentation suggests, it's best to avoid configuration changes in production by setting the $alloAdminChanges General setting to false.

In my company, we're used to doing all configuration changes in the development environment (ie. on developers' working copy), commit them & let CI deploy to staging & production environments. We run craft project-config/apply at the end of our deployment process.

This means we lose a little bit of agility, as every configuration related change involves work from a developer and a deployment. On the other end, this is a clear win in maintainability, because we know for sure that all environments share the same configuration.


Edit: I just noticed you said you didn't use project config.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.