ForgeOps

Highlights

June 30, 2022

New forgeops command

A new forgeops command is now available in the bin directory of the forgeops repository. Use this new command to:

  • Install the CDK. The forgeops command replaces the cdk command in version 7.1. The cdk command is deprecated in version 7.4.

    To install ForgeRock Identity Platform components in the CDK, run the forgeops install command with the --cdk option. Refer to CDK deployment and Staged CDK and CDM installation for examples.

  • Install the CDM. Refer to New CDM deployment technology.

To obtain ForgeRock Identity Platform passwords after installing the CDK or CDM, run the forgeops info command.

DS operator released from technology preview status

With this release, the DS operator moves from technology preview status to evolving status.

The DS operator is now supported for use with the CDK and the CDM, and for production deployments of the ForgeRock Identity Platform.

You can migrate an existing deployment of the ForgeRock Identity Platform on Kubernetes to use the DS operator. Details here.

New CDM deployment technology

A new way to deploy the CDM is now available:

  • Deploying the CDM is generally simpler and faster.

  • The forgeops install command, already used for CDK deployments, has been enhanced to support CDM as well. Refer to CDM deployment for an example.

  • As with CDK deployment, you can deploy the entire CDM with a single forgeops install command. You can also deploy individual CDM components one at a time, review the results, and then deploy the next component. Deploying the platform one component at a time can make troubleshooting simpler if you run into a problem.

    For a list of CDM components you can install one at a time, run the forgeops install -h command.

  • The CDM’s deployment namespace is no longer required to be prod, and the deployment FQDN is no longer required to be my-namespace.iam.example.com. Use the forgeops install command’s --namespace and --fqdn arguments to specify your desired deployment namespace and FQDN. Refer to CDM deployment for an example.

  • The forgeops install command is idempotent. The command checks the installation status of a component before it attempts to install it. For example, if you run the forgeops install command, and the ForgeRock UI pods are already installed and available, the installer won’t attempt to install the UI a second time unless you’ve specified different Docker images for running it, or modified the Kustomize files that orchestrate it.

  • The image defaulter gives developers fine-grained control over which Docker images are deployed with the CDM. The deployed Docker image no longer needs to be the last image that you built.

  • CDM deployment no longer uses Skaffold. Because of this, users no longer need to configure a default Skaffold repository before deploying the CDM.

  • The CDM incorporates ForgeRock’s DS operator, simplifying directory deployment.

  • The forgeops install command incorporates Secret Agent, DS operator, and cert-manager installation. Separate commands are no longer required to install these CDM components.

  • The CDM’s example Prometheus deployment requires cert-manager to be deployed before Prometheus can be deployed. In the new CDM, cert-manager is deployed when you run the forgeops install command. Because of this, you must now deploy the Prometheus, Grafana, and Alertmanager pods after you deploy the CDM.

    The bin/certmanager-deploy.sh script is no longer used to deploy cert-manager.

  • Kustomize manifests are now generated in the kustomize/deploy directory when you:

    • Install the CDM using the forgeops install command

    • Run the new forgeops generate command, which only generates the manifests, but does not install the CDM

    The Kustomize manifests let you:

    • Delete and redeploy CDM components using the kubectl delete and kubectl apply commands

    • More easily manage CDM deployment configuration changes using CI/CD systems

  • The forgeops delete command is now used to delete the CDM from a Kubernetes cluster. Refer to CDM removal.

You’ll find the documentation for the new technology CDM here.

Multicluster deployment sample

Sample artifacts for a multicluster deployment of the ForgeRock Identity Platform on Google Cloud are available in the forgeops repository.

The sample includes:

  • Fully meshed multicluster DS topology using Cloud DNS for GKE

  • Global HTTP(S) load balancing across multiple clusters with a multicluster ingress

  • Health checks to manage application-level failover between clusters

  • Proximity-based routing

  • Active/active deployment

  • Failover deployment

  • Blue/green deployment

For details about the sample, refer to the multicluster README. Note that the sample artifacts are available for Google Cloud only.

Configuration profiles moved to docker directory

Configuration profiles, formerly in the config directory of the forgeops repository, now reside in the docker directory. Utility scripts have been modified to accommodate the new location. Intermediate 7.0 directories are no longer used.

For more information about the location of configuration profiles, refer to Configuration Profiles.

This change impacts CDK deployment as follows:

  • The docker directory must now be Git-managed, because your configuration profiles are now stored there.

  • You can now use Git utilities, such as the git diff command, to review your changes to configuration profiles before you commit them.

  • When building a Docker image with the cdk build command, you must now use the new --config-profile option to specify the configuration profile that is to be included in your Docker image.

  • There is no longer a staging area in the docker directory. Previous versions required you to copy configuration (usually from the config directory) to the staging area in the docker directory before you built Docker images for the platform.

  • The config.sh command is deprecated.

  • You no longer need to use the config.sh init command to initialize the staging area.

  • Instead of using the config.sh export and config.sh save commands to export configuration from a running CDK instance to your configuration profile, use the new config export command. Refer to am image and idm image.

If you are developing custom Docker images for the ForgeRock Identity Platform, you must move existing configuration profiles in the forgeops repository from the config directory to the new locations in the docker directory before you can work with this version of the forgeops repository. For example, if you have a configuration profile named my-profile:

  • Move the contents of the config/7.0/my-profile/am directory to the path docker/am/config-profiles/my-profile.

  • Move the contents of the config/7.0/my-profile/amster directory to the path docker/amster/config-profiles/my-profile.

  • Move the contents of the config/7.0/my-profile/idm directory to the path docker/idm/config-profiles/my-profile.

  • If present, move the contents of the config/7.0/my-profile/ig directory to the path docker/ig/config-profiles/my-profile.

Do not move the canonical cdk configuration profile. The docker directory has already been provisioned with this configuration profile.
New CDM backup techniques

The CDM now includes two new techniques you can use when implementing data backup:

Refer to the backup and restore overview for more information.

The schedule-backups.sh script is deprecated, and ForgeRock recommends that you change your backup method to use a different backup and restore solution as soon as possible.

July 12, 2021

New CDK technology released from technology preview status

The new way of deploying the CDK, described here, has moved from technology preview status to evolving status.

The documentation for the new way of deploying the CDK, previously in the Technology Previews menu, can now be found here.

DS operator supported for use with the CDK

The DS operator is now supported for use with demonstration and developer deployments that use the CDK.

May 12, 2021

New CDK technology preview

A first look at a new way to deploy the CDK, and to use the CDK to develop custom Docker images for the ForgeRock Identity Platform with it:

  • The new way of deploying the CDK is generally simpler and faster.

  • The new CDK deployment uses a single DS pod—ds-idrepo-0. Functionality provided by the DS CTS pod in previous CDK versions is now merged into the ID repo pod. Deployment with a single DS pod is simpler, faster, and requires less resources than earlier versions. For example, the memory requirement for Minikube deployments decreases from 12GB to 10GB.

  • The new cdk install command lets developers deploy the CDK one component at a time. It’s still possible to deploy the entire CDK with a single cdk install command, but you can also deploy individual CDK components one at a time, review the results, and then deploy the next component. Deploying the platform one component at a time can make troubleshooting simpler if you run into a problem.

    For a list of CDK components you can install one at a time, run the cdk install -h command.

  • The new cdk install command is idempotent. The command checks the installation status of a component before it attempts to install it. For example, if you run the cdk install command, and the ForgeRock UI pods are already installed and available, the installer won’t attempt to install the UI a second time unless you’ve specified different Docker images for running it, or modified the Kustomize files that orchestrate it.

  • The new cdk build command lets you build custom Docker images for the ForgeRock Identity Platform.

  • The new image defaulter gives developers fine-grained control over which Docker images are deployed with the CDK. The deployed Docker image no longer needs to be the last image that you built.

  • The CDK incorporates the DS operator, simplifying directory deployment. Note that the DS operator remains in technology preview status for CDM deployments.

  • The cdk install command incorporates Secret Agent and DS operator installation. Separate commands are no longer required to install these CDK components.

You’ll find the documentation for the new technology CDK here.

DS operator technology preview

The DS operator uses the Kubernetes operator design pattern to let you easily deploy and manage DS instances running in a Kubernetes cluster. After you install the ds-operator custom resource definition (CRD) in a cluster, you can use it to create DS instances, scale them, and manage backup and restore.

For more information, see the DS operator README.

New RCS Agent pod in the CDM

The CDM now includes an RCS Agent pod. The RCS Agent is a reliable websocket proxy between remote connector servers and the IDM instances in the CDM.

For more information, refer to CDM architecture.

Cloud Deployment Quickstart (CDQ)

The CDQ is a very quick, single-command deployment of the ForgeRock Identity Platform on a Kubernetes cluster. The CDQ has very limited capabilities.

New Secret Agent operator

The new Secret Agent operator provides secret generation and management services for ForgeRock Identity Platform deployments on Kubernetes. The new Secret Agent operator replaces the deprecated forgeops-secret job, which previously was invoked when you deployed the platform using Skaffold.

By default, the operator examines your namespace to determine whether it contains all the secrets required for ForgeRock Identity Platform deployment. If any of the required secrets are not present, the operator generates them. Configuration options that let you change this default behavior are available.

In addition to secret generation, the new operator also integrates with Google Cloud Secret Manager, AWS Secrets Manager, and Azure Key Vault, providing cloud backup and retrieval for secrets.

For more information about secret generation options and secret management, see the Secret Agent project README.

New cluster provisioning scripts

This release of the forgeops repository introduces the cluster-up.sh and cluster-down.sh scripts, which you use to create and delete CDM clusters. These scripts replace the Pulumi scripts previously in the repository.

The new scripts are designed to be lightweight, and easy to use and modify. For GKE and AKS, the scripts call the cloud providers' SDKs. For EKS, the scripts call the eksctl CLI.

Instructions for creating clusters using the new scripts are available in the CDM Cookbooks for GKE, EKS, and AKS.

The deprecated Pulumi scripts are still available in the forgeops repository, in the /path/to/forgeops/cluster/pulumi-deprecated directory. They are no longer being maintained or upgraded. You can still use them with Pulumi 2.7.1 before you move to the new scripts.

Small, medium, and large CDM cluster sizing

This release restores the ability to create sized CDM clusters. Before deploying the CDM, you specify one of three cluster sizes:

  • A small cluster with capacity to handle 1,000,000 test users

  • A medium cluster with capacity to handle 10,000,000 test users

  • A large cluster with capacity to handle 100,000,000 test users

August 10, 2020

Docker- and Kubernetes-ready DS

This release lifts restrictions on running DS servers in Docker and Kubernetes deployments. Many individual improvements make this possible:

  • Replication improvements let you scale the number of DS replicas in your stateful sets up and down.

  • The new dsrepl command runs well in Docker containers.

DS backup to cloud storage

The CDM supports the new dsbackup command. This command lets you back up directory data to, and restore data from cloud storage.

AM and IDM integration

AM and IDM are integrated in CDK and CDM deployments:

  • AM authenticates IDM administrator and end user logins.

  • AM and IDM share a single, replicated DS user store.

  • IDM REST API users must now obtain an authorization code from AM to make API calls. refer to Access the IDM REST APIs for an example.

DS as IDM’s repository

IDM now uses DS for repository services. In previous versions, IDM used a PostgreSQL repository.

AM file-based configuration

Kubernetes deployments of the ForgeRock Identity Platform now use file-based configuration, available in AM 7. Implementing file-based configuration necessitated some changes to how AM static and dynamic configuration are managed:

  • AM configuration data is now stored in the am Docker image.

  • AM configuration data is copied to the /home/forgerock/openam/config directory when AM starts.

  • AM run-time data continues to be stored in the amster Docker image (as it was in previous versions).

  • After AM starts, an Amster job loads AM run-time data to the application and policy store.

  • Amster jobs are triggered as needed to import and export AM run-time data. The amster pod has been removed from the CDK and CDM deployments.

For more information about customizing the AM and Amster Docker images with configuration and run-time data, see Docker Image Development.

Revised DevOps documentation

The DevOps documentation is now deployed as a single site, rather than as a set of guides. Find your way around the DevOps documentation set using the navigation menu on the left side of the page. Use the tables of contents on the right side of each page to help you make your way around longer pages.

May 18, 2020

forgeops repository release tags

The method for obtaining the forgeops repository has changed. We now recommend that users clone the repository, and then create a branch based on the current release tag. Sections titled forgeops Repository in the CDK and CDM documentation provide steps you can use to create a branch based on a release tag.

A new page in the documentation describes how to work with the forgeops repository. The page covers release tags and repository forks. It also describes the repository’s contents, and provides strategies for updating forgeops repository clones.

February 20, 2020

Docker images include the AM, IDM, and IG configuration

In this version, the AM, IDM, and IG configurations are incorporated into the am, idm, and ig Docker images.

This change improves ForgeRock Identity Platform startup times. It also eliminates the startup dependency on the availability of an external Git repository.

Configurations for AM, IDM, and IG now reside in the forgeops repository’s config directory. Before building a customized Docker image for the ForgeRock Identity Platform, you run the new config.sh script. This script copies a configuration to a staging area in the forgeops repository’s docker directory.

For information about customizing Docker images for the ForgeRock Identity Platform, see Docker Image Development.

Skaffold framework support

The forgeops repository contains new artifacts that let you deploy the ForgeRock Identity Platform using the Skaffold framework. Deploying with Skaffold lets you:

  • Quickly and easily start the ForgeRock Identity Platform.

  • Modify the AM, IDM, and IG configurations.

  • Build updated Docker images that include your configuration changes.

  • Restart the ForgeRock Identity Platform with the updated Docker images.

Before you can use Skaffold with ForgeRock Identity Platform, you’ll need to install Skaffold software on your local computer. Refer to any of the Setup sections in the CDK or CDM documentation for more information.

Kustomize framework support

This revision uses the Kustomize framework to orchestrate AM, DS, IDM, and IG on Kubernetes. You no longer use Helm charts to orchestrate the ForgeRock Identity Platform.

Before you can use the Kustomize framework with ForgeRock Identity Platform, you’ll need to install Kustomize software on your local computer. Refer to any of the Environment Setup sections in the CDK or CDM documentation for more information.

The ForgeRock Cloud Developer’s Kit

The ForgeRock Identity Platform documentation now uses the term Cloud Developer’s Kit to describe what was previously referred to as the Kubernetes Examples.

For more information about the Cloud Developer’s Kit, refer to the following:

Identical configurations for the CDK and the CDM

The CDK and the CDM now use uniformly comprehensive AM, IDM, and IG configurations. Examples in the documentation now illustrate full-featured configurations, and are no longer based on minimally viable configurations. See Configuration in the forgeops repository’s top-level README file for more information about the configurations.

In earlier versions, different configurations were used for CDK and CDM deployments. The Kubernetes Examples used a minimal configuration for AM, IDM, and IG, while the CDM used a more full-featured configuration.

Pulumi scripts for cluster creation

This revision uses Pulumi scripts to create clusters for CDM deployments.

For information about how to create Kubernetes clusters for the CDM using Pulumi, refer to the Setup sections in the CDM documentation.

The previous version used a set of bash scripts for cluster creation. These scripts have been removed from the forgeops repository.

Secrets generator

The ForgeRock secrets generator randomly generates all secrets for AM, IDM, and DS services running in the CDK and the CDM. Random secrets generation greatly improves security for CDK and CDM deployments from previous versions.

The secrets generator runs as a Kubernetes job before AM, IDM, and DS are deployed.

Completely revised AKS Cookbook

Because of the previous lack of support in AKS for multiple availability zones for AKS clusters, ForgeRock formerly recommended against deploying the platform on Azure in production. With support for zones now available in AKS, Azure is now a supported platform for production deployments, and the CDM documentation for AKS is no longer designated "evaluation-only."

Changes from the evaluation-only version of the CDM documentation include:

  • The CDM deployment topology on Azure now matches the CDM deployment topology on Google Cloud and AWS.

  • Pulumi scripts demonstrate AKS cluster creation.

  • Benchmark results are available for a sample deployment with 10,000,000 users.