This is Part 2 in a 3-part series focusing on working with Nuxeo Cloud Customer Console in sandbox environments. In this part, we take a look at high-level strategies for migrating from OpenShift sandbox environments. Before diving into this article, check out Part 1 – Navigating Change: Your Guide to Nuxeo Cloud Customer Console Migration.
By default, Nuxeo Cloud does not migrate any data or content from the legacy OpenShift sandbox environments. This means Nuxeo Cloud customers should export and save any content, users, configurations, and secrets that should be imported into the new Nuxeo Cloud Customer Console sandbox environment. Let’s dive into what this migration entails.
Recommending a general migration strategy is challenging due to many factors: document volume, binary volume, and handling security, lifecycle, and other system properties if needed. See this guide for an in-depth discussion about choosing import strategies with the Nuxeo Platform.
The most efficient way to migrate users and groups is via migration script. It's a good practice to keep a CSV or JSON record of all groups that should exist in your application. Then, using your preferred scripting language (I use node.js), write a script that parses the contents of the group record and makes an API call to the target Nuxeo environment to create each group, ignoring “group already exists” failures.
This script can be used to set up new Nuxeo environments and to sync missing groups on existing environments. A similar approach can be implemented for user migration, once groups have been created.
This can also be achieved by providing an installation template that contributes user and group directories populated with custom data files. The pitfall of this approach is the table creation policy must be set to always. This means the user and group tables are recreated whenever the system is rebooted with the installation template applied.
Is your Nuxeo Package environment aware? If not, this is a great opportunity to streamline how your package is configured across environments. The objective is for a Nuxeo deployment to use a single configuration property, nuxeo.environment, to determine how it should configure itself. When nuxeo.environment has a value, Nuxeo will initialize its configuration properties by loading nuxeo.defaults and an additional configuration file that is specific to the environment.
For example, if the Nuxeo environment is set to 'dev,' Nuxeo will initialize the configurations of an installation template by loading nuxeo.defaults followed by nuxeo.dev. This allows environment-specific configurations to override default configurations. Additionally, component XML contributions can be templatized using Freemarker syntax.
Components will then be dynamically contributed, omitted, and configured based on the environment-specific configuration properties that were initialized by Nuxeo. This will provide one installation template to be used for your package across all Nuxeo environments. An example of writing a templatized XML component contribution with Freemarker can be found here.
Nuxeo Cloud recommends that customers use the configuration override feature to provide secrets for their deployment. Customers should communicate with the Nuxeo Cloud Operations team to have their secrets added to the Cloud Stack Secrets Manager.
TNCCC sandbox environments have a different URL than OpenShift sandbox environments. Any users or external applications that depend on reaching Nuxeo via a sandbox URL will need to be updated as part of the Nuxeo Cloud Customer Console sandbox migration.
The Nuxeo Cloud Customer Console provides a lightweight but powerful interface that gives Nuxeo Cloud customers more control over their higher-level environments while simplifying the management of sandbox environments. But with change often comes growing pains. Hopefully, the deployment tutorial and migration strategies discussed in this guide will help to make the transition as seamless as possible for Nuxeo developers.
The Genus team is always here to help assist or answer any questions on the Nuxeo Cloud Customer Console, or other product information. Contact us anytime.
In Part 3 of this special series, we conclude on this transition's impact on Nuxeo Cloud customers' CI/CD and release processes.
About the Author
Diego Brito is a Software Engineer and Consultant at Genus Technologies. Diego is passionate about developing enterprise software in the Content Services space. Throughout his career, Diego has developed a deep understanding of the Nuxeo Platform and works on the Genus team identifying market needs, content services, and solutions for Nuxeo customers, as well as contributing add-ons to the Nuxeo Marketplace. Connect with Diego on LinkedIn!
Get more useful content, expert tech tips, and timely articles delivered to your inbox ~ Subscribe to Genus Blogs!