If you are following along with the ForgeOps repository, you will see some significant changes in the way we deploy the ForgeRock IAM platform to Kubernetes. These changes are aimed at dramatically simplifying the workflow to configure, test and deploy ForgeRock Access Manager, Identity Manager, Directory Services and the Identity Gateway.
To understand the motivation for the change, let’s recap the current deployment approach:
- The Kubernetes manifests are maintained in one git repository (forgeops), while the product configuration is another (forgeops-init).
- At runtime, Kubernetes init containers clone the configuration from git and make it available to the component using a shared volume.
- The runtime configuration is complex, requiring orchestration (init containers) to make the configuration available to the product.
- It creates a runtime dependency on a git repository being available. This isn’t a show stopper (you can create a local mirror), but it is one more moving part to manage.
- The helm charts are complicated. We need to weave git repository information throughout the deployment. For example, putting git secrets and configuration into each product chart. We had to invent a mechanism to allow the user to switch to a different git repo or configuration – adding further complexity. Feedback from users indicated this was a frequent source of errors.
- Iterating on configuration during development is slow. Changes need to be committed to git and the deployment rolled to test out a simple configuration change.
- Kubernetes rolling deployments are tricky. The product container version must be in sync with the git configuration. A mistake here might not get caught until runtime.
This blog post was first published @ warrenstrange.blogspot.ca, included here with permission.