About the forgeops
Repository
Use ForgeRock’s forgeops
repository
to customize and deploy the ForgeRock Identity Platform on a Kubernetes cluster.
The repository contains files needed for customizing and deploying the ForgeRock Identity Platform on a Kubernetes cluster:
-
Files used to build Docker images for the ForgeRock Identity Platform:
-
Dockerfiles
-
Scripts and configuration files incorporated into ForgeRock’s Docker images
-
Canonical configuration profiles for the platform
-
-
Kustomize bases and overlays
-
Skaffold configuration files
In addition, the repository contains numerous utility scripts and sample files. The scripts and samples are useful for:
-
Deploying ForgeRock’s CDM quickly and easily
-
Exploring monitoring, alerts, and security customization
-
Modeling a CI/CD solution for cloud deployment
See Repository Reference for information about the files in the repository, recommendations about how to work with them, and the support status for the files.
Repository Updates
Every several weeks, ForgeRock tags the forgeops
repository. Each tag marks a
new release of the repository, with enhancements and bug fixes.
The current release tag is 2020.08.07-ZucchiniRicotta.1
.
When you start working with the forgeops
repository:
-
Clone the
forgeops
repository.Depending on your organization’s setup, you’ll clone the repository either from ForgeRock’s public repository on GitHub, or from a fork. See Git Clone or Git Fork? for more information.
-
Check out the current release tag and create a branch based on the tag. For example:
$ git checkout tags/2020.08.07-ZucchiniRicotta.1 -b my-working-branch
-
Start watching the repository on GitHub, so that you’ll receive notifications about new releases.
ForgeRock recommends that you regularly incorporate changes from newer release tags into your working branch. When GitHub notifies you that a new release is available:
-
Read the Release Notes, which contain information about the new release tag.
-
Use the
git fetch --tags
command to fetch newforgeops
repository tags into your clone. -
Create a new branch based on the new release tag:
$ git checkout tags/new-release-tag -b releases/new-release-tag
-
Rebase the commits from the new branch into your working branch in your
forgeops
repository clone.If you like, you can remove the branch based on the new release tag when you’ve finished rebasing.
It’s important to understand the impact of rebasing changes from a new release
tag from ForgeRock into your branches. Repository Reference
provides advice about which files in the forgeops
repository to change, which
files not to change, and what to look out for when you rebase. Follow the advice
in Repository Reference to reduce merge conflicts, and to better
understand how to resolve them when you rebase changes from a new release tag.
Repository Reference
Directories
bin
-
Example scripts you can use or model for a variety of deployment tasks.
Recommendation: Don’t modify the files in this directory. If you want to add your own scripts to the
forgeops
repository, create a subdirectory underbin
, and store your scripts there.Support Status: Sample files. Not supported by ForgeRock.
cicd
-
Example files for working with several CI/CD systems, including Tekton and Google Cloud Build.
Recommendation: Don’t modify the files in this directory. If you want to add your own CI/CD support files to the
forgeops
repository, create a subdirectory undercicd
, and store your files there.Support Status: Sample files. Not supported by ForgeRock.
cluster
-
Example scripts and artifacts that automate cluster creation.
Recommendation: When you deploy the CDM, you run
pulumi config set
commands to configure your cluster. The configuration is stored in YAML files in thecluster/pulumi
subdirectory. Your modifications will cause merge conflicts when you rebase changes from a new release tag into your branches. When you resolve merge conflicts after a rebase, be sure to keep the modifications to the YAML files if you need them.Don’t make any additional modifications to the files in this directory.
When you’re ready to automate cluster creation for your own deployment, create a subdirectory under
cluster
, and store your scripts and other files there.Support Status: Sample files. Not supported by ForgeRock.
config
-
Configuration profiles, including the canonical
cdk
profile from ForgeRock and user-customized profiles.Recommendation: Add your own profiles to this directory using the
config.sh
command. Do not modify the canonicalcdk
profile.Support Status: Configuration profiles. Support is available from ForgeRock for the canonical
cdk
configuration profile, but not for customized configuration profiles you’ve added to theconfig
directory. docker
-
Dockerfiles and other support files needed to build Docker images for version 7.0 of the ForgeRock Identity Platform.
Recommendation: When customizing ForgeRock’s default deployments, you’ll need to add files under the
docker/7.0
directory. For example, to customize the AM WAR file, you might need to add plugin JAR files, user interface customization files, or image files.If you only add new files under the
docker/7.0
directory, you should not encounter merge conflicts when you rebase changes from a new release tag into your branches. However, if you need to modify any files from ForgeRock, you might encounter merge conflicts. Be sure to track changes you’ve made to any files in thedocker
directory, so that you’re prepared to resolve merge conflicts after a rebase.Support Status: Dockerfiles and other files needed to build Docker images for the ForgeRock Identity Platform. Support is available from ForgeRock.
etc
-
Files used to support several examples, including the CDM.
Recommendation: Don’t modify the files in this directory (or its subdirectories). If you want to use CDM automated cluster creation as a model or starting point for your own automated cluster creation, then create your own subdirectories under
etc
, and copy the files you want to model into the subdirectories.Support Status: Sample files. Not supported by ForgeRock.
jenkins-scripts
-
For ForgeRock internal use only. Do not modify or use.
kustomize
-
Artifacts for orchestrating the ForgeRock Identity Platform using Kustomize.
Recommendation: Common deployment customizations, such as changing the deployment namespace and providing a customized FQDN, require modifications to files in the
kustomize/7.0
directory. You’ll probably change, at minimum, thekustomize/7.0/all/kustomization.yaml
file.Expect to encounter merge conflicts when you rebase changes from a new release tag into your branches. Be sure to track changes you’ve made to files in the
kustomize
directory, so that you’re prepared to resolve merge conflicts after a rebase.Support Status: Kustomize bases and overlays. Support is available from ForgeRock.
- legacy-docs
-
Documentation for deploying the ForgeRock Identity Platform using DevOps techniques. Includes documentation for supported and deprecated versions of the
forgeops
repository.Recommendation: Don’t modify the files in this directory.
Support Status:
Documentation for supported versions of the
forgeops
repository: Support is available from ForgeRock.Documentation for deprecated versions of the
forgeops
repository: Not supported by ForgeRock.
Files in the Top-Level Directory
.gcloudignore
,.gitchangelog.rc
,.gitignore
-
For ForgeRock internal use only. Do not modify.
cloudbuild.yaml
-
Example files for working with Google Cloud Build.
Recommendation: Don’t modify this file. If you want to add your own Cloud Build configuration to the
forgeops
repository, use a different file name.Support Status: Sample file. Not supported by ForgeRock.
LICENSE
-
Software license for artifacts in the
forgeops
repository. Do not modify. Makefile
-
For ForgeRock internal use only. Do not modify.
notifications.json
-
For ForgeRock internal use only. Do not modify.
README.md
-
The top-level
forgeops
repository README file. Do not modify. skaffold.yaml
-
The declarative configuration for running Skaffold to deploy version 7.0 of the ForgeRock Identity Platform.
Recommendation: If you need to customize the
skaffold.yaml
file, you might encounter merge conflicts when you rebase changes from a new release tag into your branches. Be sure to track changes you’ve made to this file, so that you’re prepared to resolve merge conflicts after a rebase.Support Status: Skaffold configuration file. Support is available from ForgeRock.
Git Clone or Git Fork?
For the simplest use cases—a single user in an organization installing
the CDK or CDM for a proof of concept, or exploration of the
platform—cloning ForgeRock’s public forgeops
repository from
GitHub provides a quick and adequate way to access the repository.
If, however, your use case is more complex, you might want to fork the
forgeops
repository, and use the fork as your common upstream repository. For
example:
-
Multiple users in your organization need to access a common version of the repository and share changes made by other users.
-
Your organization plans to incorporate
forgeops
repository changes from ForgeRock. -
Your organization wants to use pull requests when making repository updates.
If you’ve forked the forgeops
repository:
-
You’ll need to synchronize your fork with ForgeRock’s public repository on GitHub when ForgeRock releases a new release tag.
-
Your users will need to clone your fork before they start working instead of cloning the public
forgeops
repository on GitHub. Because procedures in the Cloud Developer’s Kit Documentation and the Cloud Deployment Model Documentation tell users to clone the public repository, you’ll need to make sure your users follow different procedures to clone the forks instead. -
The steps for initially obtaining and updating your repository clone will differ from the steps provided in the documentation. You’ll need to let users know how to work with the fork as the upstream instead of following the steps in the documentation.