What is a typical update scenario with zero downtime look like for a nuxeo cluster

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Caley_Goff

Greetings-

While evaluating the Nuxeo platform in AWS I've come across a few questions. I'm mostly curious of the following:

Is it possible to deploy Nuxeo updates with zero downtime in a clustered environment, think blue/green deployments.

How does a single Nuxeo cluster behave with a shared database and other Nuxeo servers with different versions of the Nuxeo app running at the same time (think rolling deployments), in other words can Nuxeo Platform handle two versions of Nuxeo running against a particular version of the database(s) at the same time?

What happens if there is a schema update during a Nuxeo update, which is ran against one node in a Nuxeo Cluster, and that schema is changed while another older Nuxeo app running on a given server is accessing that schema? Are these changes backward compatible?

Is it or will it be possible to have Nuxeo initiate an update on /all/ nodes by responding to an event on the message bus when a node in a given cluster is updated to a given patch? This stems from the current perception that each individual node must be updated on its own.

Florent_Guillau

Zero-downtime upgrades are mostly down to proper orchestrating the shutdown, upgrade and restart of nodes and the coordination with the load balancer.

If a shared database is used by several nodes with different software versions, then this will work only if the configurations don't conflict with each other. This is true of any system, not only Nuxeo. In the case of schemas changes, adding or remove fields from a schema is not an issue as a node that doesn't know a field will ignore it on read even if it exists in the database, and a node that expects a field but does not see it in the database will read a null instead.

About your last question, we're working on having better automation for what you describe. It's doable "by hand" today but isn't completely automated and integrated into an easy-to-use tool. But an external orchestrator is usually the best solution for this, as it's usually the component that knows about software versions and that expects to update them.