Deployment Configuration Locations

Every AM deployment has associated configuration data. Configuration data consists of properties and settings used by the AM instance to function.

Configuration data is often referred to as "static", because after your instance is configured to your requirements, it does not need to be changed.

Configuration data includes properties and settings for the following:

  • Global services

  • Realms

  • Authentication trees

Configuration data can be stored is the following places, each tailored to particular deployment requirements:

Embedded DS Instance

For evaluation deployments, you can store all your configuration data in the single, embedded DS server that is included in AM.

Embedded DS Deployments

Important

Use of embedded DS servers for production deployments is not supported in AM 7.

For information on installing an AM instance for evaluation, see the Evaluation Guide.

External DS Instances

Storing configuration data in external DS data stores offers deployment flexibility and provides instance high availability.

Configuration data in the DS instances is shared between the AM instances in your deployment. The configuration data can be replicated between multiple DS instances in a cluster, and made available to AM instances in different regions, improving availability, and data integrity.

External DS Deployments

For information on installing AM instances with external data stores, see the Installation Guide.

Files

File-based configuration is used specifically for automated cloud deployments, and only available and supported when used within Docker images.

AM's static configuration data is written to files in the file system, and checked into a source control system, such as Git.

AM instances are created as Docker images, with the file-based configuration incorporated in the image.

File-Based Configuration Deployments

You can insert variables into these configuration files before checking them into source control. These variables are substituted with the appropriate values at runtime, when starting up an image, so that the same base configuration files can be reused for multiple instances, and different staging; for example, development, QA, or pre-production, and then promoted to production.

For information on installing AM instances with Kubernetes, see the ForgeRock DevOps (ForgeOps) documentation.

AM instances also create dynamic, run-time data. This data can change and grow often, even in a production instance, as business logic changes.

Dynamic data includes properties, settings, and values for the following:

  • Policies, policy sets, and resource types

  • OAuth 2.0 client profiles

  • Federation entities

  • Core Token Service (CTS) tokens

  • UMA resources, labels, audit messages, and pending requests

Dynamic data is stored in one or more DS instances. You can choose to store dynamic data alongside the configuration data, or separate it into different data stores.

How you separate dynamic data into data stores will depend on the amount dynamic data you expect to handle. For example, CTS data is often highly volatile and short lived, so it warrants its own set of tuned DS instances. The other dynamic data types may not be so volatile, and could potentially all share a set of differently tuned DS instances.

For information on setting up external stores for use with AM, see Preparing External Stores

Read a different version of :