Understand Your Deployment Architecture Options

When initially provisioned, all instances of Oracle Content and Experience are deployed on Oracle Cloud Infrastructure. This architecture is a high-availability topology across multiple availability domains within a single geographic region. It uses Oracle Container Engine for Kubernetes (OKE) with its elastically scalable Kubernetes clusters across these availability domains.

  • Availability Domains—An availability domain is one or more data centers located within a region. Availability domains are isolated from each other, fault tolerant, and unlikely to fail simultaneously. Because availability domains don’t share physical infrastructure, such as power or cooling, or the internal availability domain network, a failure that impacts one availability domain is unlikely to impact others. Availability domains in a region are connected to each other by a low-latency, high-bandwidth network. This predictable, encrypted interconnection between availability domains provides the building blocks for both high availability and disaster recovery.
  • Fault Domains—A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain contains three fault domains. Fault domains let you distribute your instances so that they are not on the same physical hardware within a single availability domain. As a result, hardware failures or maintenance events that affect one fault domain do not affect instances in other fault domains. You can optionally specify the fault domain for a new instance at launch time, or you can let the system select one for you.

In a default deployment, OKE automatically creates multiple clusters (or nodes) across availability domains. All sites and assets are synchronized to each availability domain. If one availability domain goes down, OKE automatically directs all incoming traffic to the operational availability domains. That way end users won't notice a service outage while the failed availability domain is restored.
Example of high-availability architecture

We encourage you to use our Upgrade Schedule option to control when your instance receives a new release of Oracle Content and Experience. In most cases your instance that serves production traffic and any instance that may serve traffic in the event of a failure should use the delayed upgrade option. Instances that are meant for development and testing purposes should use the upgrade immediately option. This combination of settings will provide you a full release cycle to ensure your code is robust and provide you time to address any issues before they might impact your production traffic. The Upgrade Schedule option is set when you create your Oracle Content and Experience instance.

Beyond High Availability

While a high-availability service is designed to deliver a high degree of uptime and accessibility, many customers have additional needs that can be met with different architectures. These additional architectures, while still benefiting from the high availability provided out-of-the-box by Oracle Cloud Infrastructure and OKE, can be built to support development processes, even multi-region failover, or enhanced with private high-performance connections. To find the architecture that's right for your needs, you'll need to determine your organizations’ development process needs, your acceptable recovery time objectives (RTO), and your recovery point objectives (RPO).

  • Recovery Time Objective (RTO)—The RTO is the target time that is required to restore your application functionality after a disaster happens. The goal is to measure how quickly you must recover from a disaster. Typically, the more critical the applications, the lower the RTO.
  • Recovery Point Objective (RPO)—The RPO is the acceptable timeframe of lost data that your applications can tolerate. RPO is about how much data your applications can afford to lose in a disaster scenario.

Private Instance Using Oracle Cloud Infrastructure FastConnect

Some customers may also need additional performance or security that may not be available over the public internet. Oracle Cloud Infrastructure FastConnect can be used to provide a more performant, robust, and secure connection to your Oracle Content and Experience instance. This type of connection is often used by customers who want to ensure access is limited to internal networks or that end users have the best and most reliable connection possible.

If you want to create such an instance, you need to set up Oracle Cloud Infrastructure FastConnect and perform some additional prerequisite steps. FastConnect provides a dedicated private connection with higher bandwidth and a more reliable and consistent networking experience when compared to internet-based connections.

See Create a Private Instance Using Oracle Cloud Infrastructure FastConnect.

Development Process

This refers to the process your organization uses to build and deploy new functionality and content for Oracle Content and Experience. It can include multiple environments that new functionality and content must go through before being approved for high-level environments and production. A common setup would include environments for development, testing, staging, and, finally, production. You organization's needs may vary.

Customers who want to utilize multiple instances to support their development processes should provision their additional instances as described in this document but do not need to provision a web application firewall (WAF) in front of them as they will be accessed directly. After you develop content in one of your instances, you can use the command-line interface (CLI) of the OCE Toolkit to propagate that content from one Oracle Content and Experience instance to another.

Note:

When you create an additional instance that won't serve production traffic, you must mark it as non-primary so you don’t pay for duplicated assets. Primary instances are charged for the total number of assets in the instance. Non-primary instances are charged for a single block of assets per month (for example, 5,000 assets, and, if you have Video Plus, 250 Video Plus assets) regardless of the total number of assets being replicated. For more information, see Oracle PaaS and IaaS Universal Credits Service Descriptions.

To propagate changes, you can use OCE Toolkit commands to create sites and manage their life cycles on development, test, and production instances. You can make changes to sites in a development environment and propagate those changes to test and production environments. You can also incorporate this set of command-line utilities into your scripting environments to manage your deployments. With the CLI utilities, you can roll out new items, such as assets and components, as well as updates of existing content.

See Set Up a Test to Production (T2P) Deployment.

Implement a Backup Region

If your organization wants to use a backup region, you do so by configuring a web application firewall (WAF) and replicating your content to the backup.

Your backup can be in the same geographic region as your primary instance or in a different region. Creating your backup in a different region provides more protection against loss of data or availability.

Here's an example of what the architecture looks like:

Example of WAF setup

Creating a backup can take quite a bit of time, especially if you have a lot of sites and assets, so we suggest you back up during off hours. Depending on the amount of content changes made in your instance, you should determine if backups should be made daily or as infrequently as once a week.

When implementing a backup region you use the Oracle Cloud Infrastructure Web Application Firewall service to direct traffic to your primary (active) instance, and in the event of a failure, you switch it to point to your backup (standby) instance.

Note:

When you create your backup instance, you must mark it as non-primary so you don’t pay for duplicated assets. Primary and non-primary instances are billed at different rates.

After creating your primary instance, perform the following steps to implement your backup region:

  1. Create a new Oracle Content and Experience instance.

    When provisioning this instance, which will serve production traffic only in the event of a failure of the primary region, make sure to mark it as non-primary to avoid being double-billed for all of your assets in this instance. Also, because this could become a production instance, it should generally be set for delayed upgrade, however it must be on the same upgrade schedule as the primary region to avoid issues when switching traffic between the primary and backup regions.

    If you want your backup to be in a different region from your primary instance, create it in a secondary region.

  2. Configure a web application firewall (WAF) using the Oracle Cloud Infrastructure Web Application Firewall service.
  3. Use the OCE Toolkit to transfer all your sites and assets from your primary instance to your backup instance:
    1. Duplicate the repositories, channels, and localization policies that exist on your primary instance on your backup instance.
    2. If you haven't already done so, create a VM Compute instance.
    3. Install the OCE Toolkit on your VM Compute instance and have it use IDCS authentication.
    4. Register your Oracle Content and Experience primary and backup instances.
    5. Transfer your sites and their assets from your primary instance to your backup instance.
  4. Test that your data will be replicated correctly. Make a few changes (less than five) in the primary instance, including changes to each object type, then use the OCE Toolkit to backup your data again, and confirm the changes are accurately reflected in the backup instance.
  5. Sync any users who may need access to the backup instance in the event the primary instance is unavailable. For example, at a minimum, you'll need your administrators synced.
  6. Test that your system behaves as expected when the primary region fails:
    1. Disable the primary instance.
    2. Switch the WAF origin, by updating the WAF policy so that traffic is pointed at the backup instance.
    3. When the WAF policy change has propagated, confirm that all user experiences behave as expected on the backup instance.
  7. Re-enable the primary instance, updating the WAF policy so that it is again pointing to the primary instance, and confirm that the primary instance behaves as expected when it takes over its original responsibilities for content management and end-user delivery.

Configure a Web Application Firewall

There are several steps involved with configuring and enabling a web application firewall (WAF) to implement a backup region:

  1. Create a WAF Policy
  2. Upload Your SSL Certificate and Key
  3. Create a Secondary Origin
  4. Publish Your Changes
  5. Update DNS Configuration
  6. Configure WAF on Your Instances

If you need to switch from your primary to your secondary instance, you can do so by updating your WAF policy.

Create a WAF Policy

To configure a WAF policy, perform the following steps:

  1. Sign in to Oracle Cloud as the cloud account administrator. You can find your account name and login information in your welcome email.
  2. In the Infrastructure Console, click Navigation menu icon,on the top left to open the navigation menu, then, click Security, and then click WAF Policies. You might need to use the scroll bar on the left to scroll down to see the menu option.
  3. Select the compartment in which you want to create the WAF policy.
  4. Click Create WAF Policy.
  5. Enter following details to create the WAF policy:
    • Name: Provide a unique name for the policy (for example, cross_site_WAF). Avoid entering confidential information.
    • Primary Domain: Enter the fully qualified domain name of your application (for example, oce.example.com). This is the URL your users will use to access your application, which will then point to either the primary or secondary Oracle Content and Experience instance.
    • Additional Domains: Optionally, enter any subdomains where the policy should be applied.
    • Origin Name: Provide a unique name for the primary origin (for example, primary_salesdocuments1).
    • URI: Enter the public facing endpoint (the URI) of your primary instance (for example, salesdocuments1-myaccount.cec.ocp.oraclecloud.com).
  6. Click Create WAF Policy.

Upload Your SSL Certificate and Key

To upload your SSL certificate and key, perform the following steps:

  1. Open the WAF policy you created, then, on the left, click Settings.
  2. On the General Settings tab, click Edit.
  3. In the Edit Settings dialog:
    1. Select Enable HTTPS support so that communications between the browser and web app are encrypted.
    2. Select Upload or paste certificate and private key.
    3. Under Upload certificates source, drag and drop or select a file, or select Text and paste in a valid SSL certificate in PEM format. You must also include intermediate certificates (the primary domain certificate must be first).
    4. Under Upload private key source, drag and drop or select a file, or select Text and paste in a valid private key in PEM format in this field. The private key cannot be protected by a password.
    5. If you're using a self-signed certificate, select Self Signed Certificate to show an SSL warning in the browser.
    6. If you want to automatically redirect all HTTP traffic to HTTPS, select HTTP to HTTPS Redirect.
    7. Click Save Changes. This update appears under Unpublished Changes.

Create a Secondary Origin

To create a secondary origin, perform the following steps:

  1. Click the Origin Groups tab.
  2. On the Origin Groups tab, click Edit.
  3. Click Additional Origin.
  4. Enter following details:
    • Name: Provide a unique name for the secondary origin (for example, secondary_salesdocuments1).
    • URI: Enter the public facing endpoint (the URI) of your secondary instance (for example, salesdocuments2-myaccount.cec.ocp.oraclecloud.com).
    • HTTP Port: Enter the HTTP port the secondary instance listens on. The default port is 80.
    • HTTPS Port: Enter the port used for secure HTTP connections to your secondary instance. The default port is 443.
  5. Click Save Changes to create the secondary origin. This update appears under Unpublished Changes.

Publish Your Changes

To publish the changes you've made, perform the following steps:

  1. On the left, click Unpublished Changes.
  2. Click Publish All.
  3. In the Publish Changes dialog, click Publish All.

    It may take some time for the update to complete.

Update DNS Configuration

Update your DNS configuration with the CNAME for your zone to route requests from internet clients to WAF. You can find the CNAME by opening the WAF policy you created. The CNAME value is a hyphenated version of your primary domain within the OCI domain (for example, oce-example-com.o.waas.oci.oraclecloud.net).

If you use the subdomain cec.ocp.oraclecloud.com, you'll need to log a support request asking Oracle Support to perform the DNS update.

Configure WAF on Your Instances

To configure WAF on your instances, perform the following steps:

  1. In the Infrastructure Console, click Navigation menu icon,on the top left to open the navigation menu, then, click Application Integration, and then click Content and Experience. You might need to use the scroll bar on the left to scroll down to see the menu option.
  2. Click the primary instance to view the instance details.
  3. Click Configure WAF.
  4. In the Configure Web Application Firewall dialog, select the WAF policy you created earlier.

    The instance's compartment name is displayed. If the WAF policy is in a different compartment, click Change Compartment, and select the correct compartment.

  5. Click Save Changes.

    You'll see the progress in the Activities list as the update is made to the instance. After the update is complete, when you look at the instance details, you'll see the WAF Primary Domain listed.

  6. Repeat steps 2 through 5 for your secondary instance.

Switch Your WAF Origin

If you need to change your WAF origin from your primary instance to your secondary instance (or vice versa) for testing or backup purposes, you do so by updating the WAF policy.

To switch your WAF origin, perform the following steps:

  1. Sign in to Oracle Cloud as the cloud account administrator. You can find your account name and login information in your welcome email.
  2. In the Infrastructure Console, click Navigation menu icon,on the top left to open the navigation menu, then, click Security, and then click WAF Policies. You might need to use the scroll bar on the left to scroll down to see the menu option.
  3. Open the WAF policy you created for your instances, then, on the left, click Settings.
  4. Click the Origin Groups tab, and then click Edit.
  5. Set the origin you want to switch to as the Default origin, and then click Save Changes. This update appears under Unpublished Changes.
  6. On the left, click Unpublished Changes.
  7. Click Publish All.
  8. In the Publish Changes dialog, click Publish All.

    It may take some time for the update to complete. When it's done, traffic to your application will be directed to the selected origin.

Set Up a Test to Production (T2P) Deployment

This model is essential for providing the checks and balances necessary for running a high-availability environment efficiently and to seamlessly manage applications as they move from test to stage to production.

In this deployment you create dedicated instances to keep your development, testing, and production separate.

  1. Create three Oracle Content and Experience instances with the following settings:
    • Development—Instance type: non-primary; Upgrade schedule: immediate upgrade
    • Testing—Instance type: non-primary; Upgrade schedule: immediate upgrade
    • Production—Instance type: primary; Upgrade schedule: delay upgrade

    Setting your development and testing instances to non-primary ensures you won't be double-billed for all of your assets in those instances.

    Setting your development and testing instances to upgrade immediately (as soon as a new release of Oracle Content and Experience is available) allows you to test the upgrade on those instances, making sure the upgrade doesn't interfere with any sites you've deployed. If you find any issues, you can report them to Oracle Support so they can be fixed before the delayed upgrade is applied to your production instance one release later.

  2. Create repositories, channels, localization policies, sites, and assets on your development instance.
  3. Duplicate the repositories, channels, and localization policies on your testing and production instances.
  4. If you haven't already done so, create a VM Compute instance.
  5. Install the OCE Toolkit on your VM Compute instance and have it use IDCS authentication.
  6. Register your Oracle Content and Experience source and target instances.
  7. Transfer your sites and their assets from your source instance to your target instance.
  8. Test that your data is being replicated correctly. Make a few changes (less than five) in the source instance, including changes to each object type, then confirm these changes are accurately reflected in the target instance.
  9. Sync any users who may need access to the secondary instances. For example, at a minimum, you'll need your administrators and developers synced.

For more information on the OCE Toolkit, see Propagate Changes from Test to Production with OCE Toolkit in Building Sites with Oracle Content and Experience.

Install the OCE Toolkit on Your VM Compute Instance

To create a Test to Production (T2P) deployment, you need to install the OCE Toolkit on your VM Compute instance and have it use IDCS authentication.

Perform the following the steps on your VM Compute instance:

  1. Sign in as an OPC user.
  2. Set up NodeJS:
    1. Install NodeJS as root:
      sudo -s
      cd /usr/local
      wget https://nodejs.org/dist/v12.16.2/node-v12.16.2-linux-x64.tar.xz
      tar xf node-v12.16.2-linux-x64.tar.xz
      exit
    2. Add NodeJS to PATH as opc user and reload profile:
      vi ~/.bash_profile
      --- add :/usr/local/node-v12.16.2-linux-x64/bin to the PATH -- e.g:
      PATH=$PATH:$HOME/.local/bin:$HOME/bin:/usr/local/node-v12.16.2-linux-x64/bin
      source ~/.bash_profile
    3. Test NPM and NodeJS:
      [opc@ocivm2pm ~]$ npm --version
      6.14.4
      [opc@ocivm2pm ~]$ node --version
      v12.16.2
  3. Set up the OCE Toolkit:
    1. OCE Toolkit supports connection via IDCS app, which removes the need to pop up Chromium to authenticate. Set the flag to skip this download:
      export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
    2. Install the toolkit as opc user:
      wget https://github.com/oracle/content-and-experience-toolkit/archive/master.zip
      unzip master.zip
      rm master.zip
      cd content-and-experience-toolkit-master/sites/
      npm install
    3. Test the install:
      [opc@ocivm2pm sites]$ ./node_modules/.bin/cec --version
      20.4.1
    4. Add soft link to cec binaries as root:
      sudo -s
      ln -s /home/opc/content-and-experience-toolkit-master/sites/node_modules/.bin/cec /usr/local/bin/cec
      exit
    5. Test that you can run cec from anywhere as opc user:
      cd
      [opc@ocivm2pm ~]$ cec --version
      20.4.1
    6. Setup cec source folder, and install cec in the folder. This will create a source tree, with a package.json, and do an npm install to fetch dependencies into the source tree.
      cd
      mkdir cec
      cd cec
      cec install
  4. Configure IDCS and register your instances following the directions on the IDCS app page.

Register Your Source and Target Servers

Register the connection details for your source and target instances using the following command. For example, if you're synchronizing content for a test to production deployment, you might have development (DEV), staging (TEST), and production (PROD) instances.

cec register-server DEV -e http://server:port -u username -p password
cec register-server TEST -e http://server:port -u username -p password
cec register-server PROD -e http://server:port -u username -p password
  • The first value (for example, DEV, TEST, PROD) is the server name used to identify the instance endpoint. This value can be any name you choose.
  • The -e value is the server and port that make up the URL you use to access the instance.
  • The -u value is the username. This user must be the user who can access the sites and assets on the source instance or who will own the sites and assets on the target instance.
  • The -p value is the password for the user.

Note:

You can pass in --keyfile to encrypt the password saved in the file.

Transfer Your Enterprise Sites

Transfer your enterprise sites using the following command:

cec transfer-site SiteName -s DEV -d TEST -r RepositoryName -l LocalizationPolicyName
  • The first value (SiteName) is the name of the site you want to transfer.
  • The -s value is the source instance name that you registered in the previous step.
  • The -d value is the target instance name that you registered in the previous step.
  • The -r value is the repository in the target instance that you want to transfer the site to. This is only required for transferring new enterprise sites to the target instance.
  • The -l value is the localization policy in the target instance that you want to apply to the transferred site. This is only required for transferring new enterprise sites to the target instance.

If you are updating a site on the target instance, you don't need to include the repository and localization policy.

For more information, see Propagate Changes from Test to Production with OCE Toolkit in Building Sites with Oracle Content and Experience.