Enterprise software packages quickly become a struggle to install, configure and maintain. Complex products often required multiple components in different tiers, and initial configurations to deployed on often several instances of the same server. For a production environment, you are looking at high availability and hardening the products during installation. A job that quickly becomes tedious if not impossible to do. Once an enterprise software product is deployed and installed it is common practice to keep it static for months or even years without changing its configuration because of the complex process of testing and putting a new release into production

Caring and feeding multiple servers requires an automated way of doing this. The term is Configuration management and is a common aspect of DevOps methodologies.

As of ForgeRock Identity Management 5.0, pre-made containerized images are available along with a DevOps guide (For those customers and partners with access to backstage) to aid in deploying using DevOps strategies. The samples and guide utilize components such as Kubernetes, Docker and Amazon EC2 Container Service. This article, however, offers some alternative thoughts and software suggestions that might complement or offer an alternate strategy.

CFengine was one of the first configuration management systems that were deployed in anything approaching widespread use and was followed later by Puppet and Chef. A bit over two years ago, Salt Stack‘s “Salt” entered the market, and took a radically different approach to the problem of “configure all of my servers to do X.”

Many of these Configuration management solutions sits on top of SSH to perform a remote execution. SSH being the de facto standard for secure and encrypted network traffic but with the drawback of being rather computation expensive - other solutions have proprietary protocols with agents deployed or leverage HTTPS.

The goal is to get ForgeRock Identity Management to install in an automated fashion with the required components configured and ready.

Some of the reasons why you would want to have an automated installation are because it is great for quickly setting up environments for development, testing and trying out different aspects and versions of a product. Troubleshooting configurations, collaborative build with support for cloud deployments. A consistent approach that is quick to setup and quick to tear down.

Efforts put into setting up the automated installation will provide a lot of leverage down the road, reaching the goal of a fully hands-off deployment and installation.

Tools and frameworks

Chef

Chef is a company & configuration management tool written in Ruby and Erlang. It uses a pure-Ruby, domain-specific language (DSL) for writing system configuration "recipes". Chef is used to streamline the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms such as Rackspace, Internap, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer, and Microsoft Azure to automatically provision and configure new machines. Chef contains solutions for both small and large scale systems, with features and pricing for the respective ranges.

Chef uses a master-agent setup, and in addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the ‘knife’ tool that uses SSH for deployment to ease installation. Chef configs are packaged into JSON files called ‘recipes’, and the software can run in client-server (called Chef-server) or standalone mode (called ‘Chef-solo’).

Resources: https://github.com/MattMencel/chef-openidm

Puppet

Puppet is an open-source configuration management utility. It runs on many Unix-like systems as well as on Microsoft Windows, and includes its own declarative language to describe system configuration.

Resources: https://github.com/ConductAS/puppet-openidm

Ansible/Vagrant

Ansible is a free software platform for configuring and managing computers. It combines multi-node software deployment, ad hoc task execution, and configuration management. It manages nodes over SSH or PowerShell and requires Python (2.4 or later) to be installed on them. Modules work over JSON and standard output and can be written in any programming language. The system uses YAML to express reusable descriptions of systems.

Vagrant is computer software that creates and configures virtual development environments. It can be seen as a higher-level wrapper around virtualization software such as VirtualBox, VMware, KVM and Linux Containers (LXC), and around configuration management software such as Ansible, Chef, Salt and Puppet.

Resources: https://github.com/ForgeRock/frstack

CFEngine

CFEngine is an open-source configuration management system, written by Mark Burgess. Its primary function is to provide automated configuration and maintenance of large-scale computer systems, including the unified management of servers, desktops, consumer and industrial devices, embedded networked devices, mobile smartphones, and tablet computers. CFEngine is written in C and claims to be the fastest and leanest solution on the market for Configuration Management.

Salt

Salt leverages the ZeroMQ message bus, a lightweight library that serves as a concurrency framework. It establishes persistent TCP connections between the Salt master and the various clients, over which communication takes place. Messages are serialized using msgpack, (a more lightweight serialization protocol than JSON or Protocol Buffers), resulting in severe speed and bandwidth gains over traditional transport layers, resulting in in the ability to fit far more data quickly through a given pipe. This translates into a non-technical statement of, “Salt establishes a persistent data pipe between servers in your environment that’s extremely fast and low-bandwidth.”

Salt also has a Vigrant add-on allowing you to spawn up virtual machines similar as to the Ansible/Vigrant combination discussed above.

Software Version Control and Management

ForgeRock Identity Management supports to be started pointing to a particular folder for its configuration files. This means for example that the software can be installed for instance under /opt/openidm and configuration files can be stored under /etc/openidm. ForgeRock Identity Management can then be started with the argument -p <directory of conf files>. This separates the default files from the customer specific ones, provides easier upgrades and a better overview.

To keep track of configuration files during development, test and QA as well as the finished production artifacts a software versioning control system is highly recommended. Software version control is the practice of deploying consistent software versions. This practice improves the chance for validation and testing and limits the amount of software defects and interoperability issues. The Software Version Control system should be integrated with the configuration management system to pull the appropriate branch. This pattern makes deployment easier, faster, less complex and easier to support.

Configuration Upgrade Procedures

The Upgrade procedure for ForgeRock Identity Management helps to ensure that the process of lifting ForgeRock Identity Management from one version to a newer one occurs smoothly and with minimal downtown. With the help of a configuration management system such as those listed and discussed above, assists in testing out the procedure. Since ForgeRock Identity Management acts as a hub component in the infrastructure, testing out integrations is also important during these upgrades and would, therefore, require in-depth planning.

Once the ForgeRock Identity Management upgrade procedure is defined and validated, the upgrade procedure should be referenced in all change documentation appropriate to the particular upgrade. The ForgeRock Identity Management Release Notes always contains valuable clues to important changes and information about a particular release.

Some discovered challenges

EULA Acceptance (You need to accept license during installation)
Download production binaries from Backstage requires login.
OpenIDM servers are unable to start if the OpenIDM JDBC repository is unavailable. Therefore, it is imperative that the JDBC repository is up and running before you attempt to start OpenIDM in a DevOps deployment.
Clustered OpenIDM servers are not removed from the cluster node list when they are brought down or when they fail. In elastic deployments, with servers frequently added to and removed from clusters, the cluster node list can grow to be quite large.

Conclusions

When you have the infrastructure to proactively manage change using a configuration management system, the fast pace of development no longer leaves you behind. Being able to quickly setup and deploy a new ForgeRock Identity Management system allows you to scale quickly in a known and repeatable manner as well as allows you to test out new features and capabilities and upgrades. Leveraging a DevOps philosophy and a configuration management system, although heavy initially in setting up, is an opportunity to get ahead.

Although there is an abundance of tools available to support your configuration management needs, there are available sample cookbooks or recipes to get ForgeRock Identity Management deployed and configured on the forgerock.org website. Picking one of these as a starting point will save time and effort.