Ansible roles to install ForgeRock's OpenDJ LDAP server



Ansible is a really nice "dev-ops" automation tool in the spirit of Chef, Puppet, etc.  It's virtues are simplicity, an "agentless" installation model and a very active and growing community.

One of the neat features of Ansible is the concept of "roles". These are reusable chunks of dev-ops code that perform a specific task. Ansible "Playbooks" orchestrate a number of roles together to perform software installation and configuration.


Roles by themselves are not sufficient to drive reusability.  We need a way to collaborate and share roles.    Enter Ansible Galaxy, the central repository for Ansible roles.

If you have ever used apt or yum, galaxy will appear quite familiar. For example, to install and use the "opendj" role, you issue the following command:

$ ansible-galaxy install warren.strange.opendj

(Roles are prefixed with a contributor name to avoid name collisions).


If you want to install ForgeRock's OpenDJ server, here are two new Ansible roles:


  • opendj  - Downloads and installs the OpenDJ server
  • opendj-replication - sets up replication between two OpenDJ instances.



Here is a sample Ansible playbook that installs two instances on a single host and replicates between them:


--- 
# Example of installing two OpenDJ instances on the same host (different ports)
# and enabling replication between them
# Most of the variables here are defaulted (see the role opendj/defaults/main.yml for defaults)
- remote_user: fr
  sudo: yes
  hosts: ois
  roles:
   - { role: warren.strange.opendj, install_root: "/opt/a" }
   - { role: warren.strange.opendj, install_root: "/opt/b", opendj_admin_port: 1444, opendj_ldap_port: 2389,
            opendj_ldaps_port: 2636 , opendj_jmx_port: 2689, opendj_service_name: "opendj2" }
   - { role: warren.strange.opendj-replication, install_root: "/opt/a", opendj_host2: localhost, opendj_admin_port2: 1444 }






This is my first attempt at an Ansible role. Feedback is most welcome! 
































Comments

















Balajee Nanduri said…




This comment has been removed by the author.






June 4, 2020 at 11:18 PM




















Post a Comment

























Popular posts from this blog









Introducing ds-operator,  the ForgeRock Directory Services Operator for Kubernetes




















Image







ForgeRock Directory Services 7.0 was a big achievement for the Grenoble Directory team.  It is the only "Kubernetes native" directory where you can add a new replica using kubectl: kubectl scale sts/ds-idrepo --replicas=3 The 7.0 deployment is assembled using standard Kubernetes primitives such as StatefulSets , Persistent Volume Claims, and Services.  This is all built and orchestrated using Skaffold  and Kustomize .  An emerging pattern in the Kubernetes world is the use of Custom Resources and Operators .  Broadly speaking, a custom resource is the declaration of the desired system state, and the operator's job is to observe the current state and bring the system into alignment with the declared state: source: https://blog.container-solutions.com/kubernetes-operators-explained The Kubernetes API server (the thing that responds to your kubectl commands) can be extended to handle new custom types.  A custom resource definition (CRD) describes to the API server the syntax








Read more










Automating OpenDJ backups on Kubernetes




















Image







  Kubernetes   StatefulSets  are designed to run "pet" like services such as databases.   ForgeRock's OpenDJ LDAP server  is an excellent fit for StatefulSets as it requires stable network identity and persistent storage.   The ForgeOps  project contains a Kubernetes Helm chart to deploy DJ  to a Kubernetes cluster. Using a StatefulSet, the cluster will auto-provision persistent storage for our pod. We configure OpenDJ to place its backend database on this storage volume.   This gives us persistence that survives container restarts, or even restarts of the cluster. As long as we don't delete the underlying persistent volume, our data is safe.   Persistent storage is quite reliable, but we typically want additional offline backups.   The high level approach to accomplish this is as follows:   Configure the OpenDJ container to support scheduled backups to a volume.  Configure a Kubernetes volume to store the backups.  Create a sidecar container that archives the backups








Read more










Deploying the ForgeRock platform on Kubernetes using Skaffold and Kustomize




















Image







     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 advantage of this approach is that the docker container for a product can be (relatively) stable. Usually it is the configuration that is changing, not the product binary.     This approach seemed like a good idea at the time, but in retrospect it created a lot of c








Read more