ForgeRock DevOps and Cloud Deployment
Kubernetes deployment for the ForgeRock platform.
** IMPORTANT: The current supported branch is release/6.5.2. The master branch is under development **
This GitHub repository is a read-only mirror of ForgeRock's [https://stash.forgerock.org/projects/CLOUD/repos/forgeops] (Bitbucket Server repository). Users with BackStage accounts can make pull requests on our Bitbucket Server repository. ForgeRock does not accept pull requests on this GitHub mirror.
These samples are provided on an “as is” basis, without warranty of any kind, to the fullest extent permitted by law. ForgeRock does not warrant or guarantee the individual success developers may have in implementing the code on their development platforms or in production configurations. ForgeRock does not warrant, guarantee or make any representations regarding the use, results of use, accuracy, timeliness or completeness of any data or information relating to these samples. ForgeRock disclaims all warranties, expressed or implied, and in particular, disclaims all warranties of merchantability, and warranties related to the code, or any service or software related thereto. ForgeRock shall not be liable for any direct, indirect or consequential damages or costs of any type arising out of any action taken by you or others related to the samples.
The master branch targets features that are still in development and may not be stable. Please checkout the branch that matches the targeted release.
For example, if you have the source checked out from git:
git checkout release/6.5.2
Skaffold preview branch
skaffold-6.5 is a preview of the upcoming 7.x workflow that simplifies deployment
by bundling the product configuration into the docker image for deployment. This workflow speeds iterative
development and greatly simplifies the Kubernetes runtime manifests. It eliminates the need for "git" init containers
and the complexity around configuring different git repositories and branches in the helm charts.
The new workflow combines the previously
forgeops-init into a single git repository that holds configuration and Kubernetes
manifests. See README-skaffold.md.
Documentation for this workflow is in progress. Please see the early access documentation.
This preview branch enables the use of supported ForgeRock binaries in your deployment. Adopting this workflow is recommended as it will ease transition to the 7.x platform.
kustomize- Kustomize manifests for deploying the platform. See README-skaffold.md
helm/- contains Kubernetes helm charts to deploy those containers. See the helm/README.md
etc/- contains various scripts and utilities
bin/- Utility shell scripts to deploy the helm charts and create and manage clusters.
The Draft ForgeRock DevOps Guide tracks the master branch, including information on the newer Kustommize/ Skaffold workflow.
The documentation for the current release can be found on backstage.
Setting a namespace
If you do not want to use the 'default' namespace, set your namespace using:
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
kubens utilities are recommended.
Refer to the toubleshooting chapter in the DevOps Guide.
- The script
bin/debug-log.shwill generate an HTML file with log output. Useful for troubleshooting.
- Simplify. Deploy a single product at a time (for example, ds), and make sure it is working correctly before deploying the next product.
- Describe a failing pod using
kubectl get pods; kubectl describe pod pod-xxx
- Look at the event log for failures. For example, the image can't be pulled.
- Examine all the init containers. Did each init container complete with a zero (success) exit code? If not, examine the logs from that failed init container using
kubectl logs pod-xxx -c init-container-name
- Did the main container enter a crashloop? Retrieve the logs using
kubectl logs pod-xxx.
- Did a docker image fail to be pulled? Check for the correct docker image name and tag. If you are using a private registry, verify your image pull secret is correct.
- You can use
kubectl logs -p pod-xxxto examine the logs of previous (exited) pods.
- If the pods are coming up successfully, but you can't reach the service, you likely have ingress issues:
kubectl describe ingand
kubectl get ing ingress-name -o yamlto view the ingress object.
- Describe the service using
kubectl get svc; kubectl describe svc xxx. Does the service have an
Endpoint:binding? If the service endpoint binding is not present, it means the service did not match any running pods.
- Determine if your cluster is having issues (not enough memory, failing nodes). Watch for pods killed with OOM (Out of Memory). Commands to check:
kubectl describe node
kubectl get events -w
- Most images provide the ability to exec into the pod using bash, and examine processes and logs. Use
kubectl exec pod-name -it bash.
- If you wish to backup the directory server, the Kubernetes cluster must support a read-write-many (RWX) volume type, such as NFS, or Minikube's hostpath provisioner. You can describe persistent volumes using
kubectl describe pvc. If a PVC is in a pending state, your cluster may not support the required storage class.