Automated Deployment of InterSystems IRIS Containers

Containers lend themselves to automated deployment in many ways. InterSystems IRIS data platform provides two methods for automated deployment of multicontainer topologies (such as sharded clusters, distributed cache clusters, and mirrors) that are fully operational following deployment. Advanced methods include the following:

• The InterSystems Kubernetes Operator

  KubernetesOpens in a new tab is an open-source orchestration engine for automating deployment, scaling, and management of containerized workloads and services. You define the containerized services you want to deploy and the policies you want them to be governed by; Kubernetes transparently provides the needed resources in the most efficient way possible, repairs or restores the deployment when it deviates from spec, and scales automatically or on demand. The InterSystems Kubernetes Operator (IKO) extends the Kubernetes API with the IrisCluster custom resource, which can be deployed as an InterSystems IRIS sharded cluster, distributed cache cluster, or standalone instance (all optionally mirrored) on any Kubernetes platform. The IKO also adds InterSystems IRIS-specific cluster management capabilities to Kubernetes, enabling automation of tasks like adding nodes to a cluster, which you would otherwise have to do manually by interacting directly with the instances.

  For more information on using the IKO, see Using the InterSystems Kubernetes OperatorOpens in a new tab.

• Configuration merge

  The configuration merge feature, available on Linux and UNIX® systems, lets you vary the configurations of InterSystems IRIS containers deployed from the same image (or local instances installed from the same kit) by simply applying the desired declarative configuration merge file (or files) to each instance in the deployment.

  A merge file, which can also be applied to an existing instance, updates an instance’s configuration parameter file (CPF), which contains most of its configuration settings; these settings are read from the CPF at every startup, including the first one after an instance is deployed. When you apply configuration merge during deployment, you in effect replace the default CPF provided with the instance with your own updated version. This enables you to deploy containers with varying configurations from the same image, or install differently-configured instances from the same kit, directly into a multi-instance topology, rather than having to configure the instances into the desired topology after deployment. For example, in automated containerized deployment of a sharded cluster with compute nodes, you can apply different merge files for data node 1, the remaining data nodes, and the compute nodes in that order; when all of the instances are up and running, so is the sharded cluster. In similar fashion, when deploying a mirror, you would apply different configuration merge files for the primary, backup, and async members. Even a mirrored sharded cluster is easily deployed using this approach.

  The IKO, described in the preceding sections, incorporates the configuration merge feature.

  For information about using configuration merge, including examples of use cases for automated deployment using configuration merge, see Automating Configuration of InterSystems IRIS with Configuration Merge, Useful Update Parameters in Automated Deployment, and Useful Action Parameters in Automated Deployment.

  Important:

  When a container is deployed with configuration merge using the ISC_CPF_MERGE_FILE environment variable to specify one or more merge files, those merge files are continuously monitored for updates, which are immediately merged when they occur, as long as the container is running. This means that you can update the configuration of a containerized instance at any time simply by updating the relevant merge file. For more information, see Reconfigure an Existing Instance Using Configuration Merge in Automating Configuration of InterSystems IRIS with Configuration Merge.