For this blog I am sharing my experience of deploying #ForgeRock #accessmanager rolling updates with zero-downtime onto #Kubernetes
About Juan Redondo
I am a full stack developer with experience across #IAM, #Kubernetes, #Cloud, and #DevOps. I am accredited on #ForgeRock Access Manager and has Mentor Status.
For any queries, feedback you may have please contact me on juan@midships.io
The aim of this post is to provide an overview on how Midships can help you manage AM rolling updates providing zero-downtime on your services.
Due to the tight dependency between the DS-configstore and AM, it is very complex to manage a rolling update that provides a zero-downtime on a Kubernetes multi-server deployment.
This is caused by the distinct nature of this components, being AM a stateless component that will fetch the stored data from a stateful set (DS-configstore). This causes that once a configuration change wants to be introduced to the AM platform, in order to persist the change, the DS-configstore which is storing the data will also need to be updated to reflect this change.
In order to solve this issue, Midships has implemented an architecture for AM and DS-configstore which handles this and provides a reliable way of updating (and persisting) the configuration in AM with zero downtime. This implementation makes use of a multi-container strategy where the AM and DS-configstore share the same pod and gracefully handle replication with other AM instances in the cluster by using the replication protocol.
The following diagram depicts the rolling upgrade progress that is triggered for each AM instance once the helm chart for AM is upgraded to newer version:
As the diagrams reflect, the Midships accelerator will handle the rolling upgrade of the pod, by gracefully deleting in a sequence all the replicas of the older version of AM. Once the last replica of the set is upgraded (in reverse order), the new changes that have been introduced and persisted in the first DS-configstore will be replicated across, keeping the new configuration data at sync. Similar behaviour happens once the stateful set is auto-scaled (as per the autoscaling policy defined based on traffic load/CPU consumption of the pods) and a new AM replica is added to the set.
The following demo shows how, after triggering a helm chart rolling update, the AM pod (with DS-configstore attached) is successfully updated as a standard rolling deployment, and how the replication configured by Midships team will take care of propagating the changes to the rest of the replicas while the AM service is up and running:
I hope that this post provided a thorough understanding on how you can implement in Forgerock a rolling update strategy using the ForgeRock accelerator and avoiding the cost of maintaining additional infrastructure resources as required by more traditional methods such as blue-green architectures.
To learn more about our ForgeRock rolling update or see a demo please contact us at sales@midships.io