Essential ICM Elements
As of release 2023.3 of InterSystems IRIS, InterSystems Cloud Manager (ICM) is deprecated; it will be removed from future versions.
The page describes the essential elements involved in using ICM.
InterSystems Cloud Manager Image
ICM is provided as a Docker image, which you run to start the ICM container. Everything required by ICM to carry out its provisioning, deployment, and management tasks — for example Terraform, the Docker client, and templates for the configuration files — is included in this container. See Launch ICM for more information about the ICM container.
The system on which you launch ICM must be supported by Docker as a platform for hosting Docker containers, have Docker installed, and have adequate connectivity to the provisioning platform on which you intend to provision infrastructure and deploy containers, or the existing infrastructure on which you intend to deploy.
Provisioning Platforms
ICM can provision virtual host nodes and associated resources on the following platforms:
-
Amazon Web Services (AWS)
-
Google Cloud Platform (GCP)
-
Microsoft Azure (Azure)
-
Tencent Cloud (Tencent)
-
VMware vSphere (vSphere)
Note:To address the needs of the many users who rely on VMware vSphere, it is supported by this release of ICM. Depending on your particular vSphere configuration and underlying hardware platform, the use of ICM to provision virtual machines may entail additional extensions and adjustments not covered in this guide, especially for larger and more complex deployments, and may not be suitable for production use. Full support is expected in a later release.
On AWS, GCP, Azure, and Tencent, ICM can provision and deploy a single configuration across multiple zones within a region, across multiple regions, or even across cloud provider platforms.
Before using ICM with one of these platforms, you should be generally familiar with the platform. You will also need account credentials; see Obtain Security Credentials for more information.
ICM can also configure existing virtual or physical clusters (provider PreExisting) as needed and deploy containers on them, just as with the nodes it provisions itself.
Deployment Platforms
Container images from InterSystems comply with the Open Container Initiative (OCIOpens in a new tab) specification, and are built using the Docker Enterprise Edition engine, which fully supports the OCI standard and allows for the images to be certified and featured in the Docker Hub registry.
InterSystems images are built and tested using the widely popular container Ubuntu operating system, and ICM therefore supports their deployment on any OCI-compliant runtime engine on Linux-based operating systems, both on premises and in public clouds.
Defining Nodes in the Deployment
ICM deploys one InterSystems IRIS instance per provisioned node, and the role that each instance plays in an InterSystems IRIS configuration is determined by the Role field value under which the node and the instance on it are provisioned, deployed, and configured.
In preparing to use ICM, you must define your target configuration (see Define the Deployment) by selecting the types and numbers of nodes you want to include. If you want to deploy an InterSystems IRIS sharded cluster, for example, you must decide beforehand how many data nodes and (optionally) compute nodes will be included in the cluster, and whether the data nodes are to be mirrored. The specifications for the desired nodes are then entered in the definitions file (see Configuration, State, and Log Files) to provide the needed input to ICM. This is shown in the following simplified example defining four data nodes and eight compute nodes:
[
{
"Role": "DATA",
"Count": "4",
"LicenseKey": "ubuntu-sharding-iris.key"
},
{
"Role": "COMPUTE",
"Count": "8",
"StartCount": "5",
"LicenseKey": "ubuntu-sharding-iris.key"
}
]
The Mirror field, which determines whether the data nodes are mirrored, appears in the defaults file. Mirror deployment is covered at length in ICM Cluster Topology and Mirroring.
Field Values
The provisioning, deployment, and configuration work done by ICM is determined by a number of field values that you provide. For example, the Provider field specifies the provisioning platform to use; if its value is AWS, the specified nodes are provisioned on AWS.
There are two ways to specify field values:
-
Some can be specified on the command line (see Command Line).
-
All can be included in the two configuration files (see Configuration, State and Log Files), although some can appear only in the defaults.json file, and others intended for the definitions file only.
There are also defaults for most ICM fields. In descending order of precedence, these specifications are ranked as follows:
-
Command line option
-
Entry in definitions.json configuration file
-
Entry in defaults.json configuration file
-
ICM default value
This avoids repeating commonly used fields while allowing flexibility. The defaults file (defaults.json) can be used to provide values (when a value is required or to override the defaults) for multiple deployments in a particular category, for example those that are provisioned on the same platform. The definitions file (definitions.json) provides values for a particular deployment, such as specifying the nodes in the cluster and the labels that identify them, but can also contain fields included in the defaults file, in order to override the defaults.json value for a particular node type in a particular deployment. Specifying a field value as a command line options let you override both configuration files in the context of a particular command in a particular deployment.
The following illustration shows two deployments sharing a single defaults.json file, with different definitions.json files — the first for a distributed cache cluster, the second for a sharded cluster.
For comprehensive lists of the required and optional fields that can be specified in these files, see ICM Configuration Parameters.
Command Line
The ICM command line interface allows users to specify an action in the orchestration process — for example, icm provision to provision infrastructure, or icm run to deploy by running the specified containers — or a container or service management command, such as upgrading a container or connecting to InterSystems IRIS. ICM executes these commands using information from configuration files. If either of the input configuration files (see Configuration, State and Log Files) is not specified on the command line, ICM uses the file (definitions.json or defaults.json) that exists in the current working directory; if one or both are not specified and do not exist, the command fails.
The command line can be also used to specify options, which have several purposes, as follows:
-
To override information that is in a configuration file for a single command only, for example to deploy a different Docker image than the one provided in the configuration files, as shown in the following:
icm run –image image
-
To supply information that is not in the configuration files because you do not want it persisted, for instance a password, as follows:
icm run -iscPassword password
-
To supply information relevant to a command executed on one or more nodes in the deployment, for example a query, as shown:
icm sql -role DATA -namespace namespace -command "query"
Options can have different purposes when used with different commands. For example, with the icm run command, the -container option provides the name for the new container being started from the specified image, whereas with the icm ps command it specifies the name of the existing deployed containers for which you want to display state information.
For comprehensive lists of ICM commands and command-line options, see ICM Commands and Options.
Configuration, State, and Log Files
ICM uses JSON files as both input and output, as follows:
-
As input, configuration files provide the information ICM needs to execute tasks, such as the provisioning platform to use and the types and numbers of nodes to provision. These files are provided by the user; they can be adapted from the template provided with ICM, created manually, or produced by the output of a script or UI.
-
As output, files generated by ICM describe the results of ICM’s tasks.
When an ICM task results in the generation of new or changed data (for example, an IP address), that information is recorded in JSON format for use by subsequent tasks. ICM ignores all fields which it does not recognize or that do not apply to the current task, but passes these fields on to subsequent tasks, rather than generating an error. This behavior has the following advantages:
-
Information specified during an earlier phase (such as provisioning) to be used during a later phase (such as deployment) without having to edit or maintain more than one configuration file.
-
A degree of forward- and backward-compatibility among ICM versions is supported.
-
The work required to use one configuration file with multiple providers is minimized.
-
Although the JSON standard does not provide a formal means of commenting out content, fields can be “commented out” by altering their names.
The JSON files used by ICM include the following:
-
The definitions file and the defaults file, provided by the user as input to ICM’s provisioning and deployment phases. By default these files are assumed to be in the current working directory. (For comprehensive lists of the required and optional fields that can be specified in these files, see ICM Configuration Parameters.)
-
The instances file, generated by ICM at the end of the provisioning phase and used as input to the deployment phase. By default this file is created in the current working directory.
-
The Terraform state files, generated by ICM during the provisioning phase and used as input to future infrastructure-related operations, such as unprovisioning. By default these files are placed in a state directory generated by ICM under the current working directory.
ICM also generates a number of other log, output, and error files, which are located in the current working directory or the state directory.
The Definitions File
The definitions file (definitions.json) describes a set of host nodes to be provisioned for a particular deployment. ICM uses the definitions file found in the current working directory.
The definitions file consists of a series of JSON objects representing node definitions, each of which contains a list of attributes as well as a count to indicate how many nodes of that type should be created. Some fields are required, others are optional, and some are provider-specific (that is, for use with AWS, Google Cloud Platform, Microsoft Azure, Tencent, VMware vSphere, or PreExisting).
Most fields can appear in this file, repeated as needed for each node definition. Some fields, however, must be the same across a single deployed configuration, and therefore cannot be changed from the default, or specified if there is no default, by entries in the definitions file. The Provider field is a good example, for obvious reasons. Other fields that cannot be included in the definitions.json file and will cause an error if they are included are Label and Tag.
Fields that vary between node types (for example, Role) must be included in the node definitions in definitions.json. The definitions.json is also used to override either ICM defaults or settings in the defaults.json file for specific node types. For instance, in the following example, which shows the contents of a sample definitions.json file for provisioning a distributed cache cluster consisting of a mirrored data server ("Role": "DM""), three application servers ("Role": "AM"), and a mirror arbiter node ("Role": "AR") on AWS:
-
The DataVolumeSize field appears only for the DM nodes because the others use the ICM default value.
-
The DM node and AR node definitions include an InstanceType field overriding the default instance type specified in defaults.json.
-
The AR node definition includes a DockerImage field overriding the one in defaults.json because an arbiter container is to be deployed on it, rather than an InterSystems IRIS container.
Some fields must be in definitions.json because they are restricted to certain node types; for example, the AM node definition here includes "LoadBalancer": "true" to automatically provision a load balancer for the AM nodes. This setting can also be used with WS nodes, but applying it to other node types causes errors.
[
{
"Role": "DM",
"Count": "2",
"DataVolumeSize": "50",
"InstanceType": "m4.xlarge"
},
{
"Role": "AM",
"Count": "3",
"StartCount": "3",
"LoadBalancer": "true"
},
{
"Role": "AR",
"Count": "1",
"StartCount": "6",
"InstanceType": "t2.small",
"DockerImage": "intersystems/arbiter:latest-em"
}
]
By modifying the definitions.json file, then reprovisioning and/or redeploying, you can elastically scale and alter an existing configuration by adding or removing nodes or modifying existing nodes.
The image tags shown in this document are examples only. Please go to the InterSystems Container RegistryOpens in a new tab (ICR) to browse current repositories and tags.
The Defaults File
Generally, the defaults file defines fields that are the same across all deployments of a particular type, such as those provisioned on a particular cloud platform. ICM uses the defaults file found in the current working directory.
As noted in The Definitions File, while most fields can be in either input file, some must be the same across a deployment and cannot be specified separately for each node type, for example Provider. In addition to these, there may be other fields that you want to apply to all nodes in all deployments, overriding them when desired on the command line or in the definitions file. Fields of both types are included in the defaults.json file. Including as many fields as you can in the defaults file keeps definitions files smaller and more manageable.
The format of the defaults file is a single JSON object; the values it contains are applied to every field whose value is not specified (or is null) in a command line option or the definitions file.
The following shows the contents of a sample defaults.json file to be used with the definitions.json file shown in The Definitions File, Some of the defaults specified in the former are overridden by the latter, including OSVolumeSize, DataVolumeSize, and InstanceType.
{
"Provider": "AWS",
"Label": "Sample",
"Tag": "TEST",
"DataVolumeSize": "10",
"SSHUser": "ubuntu",
"SSHPublicKey": "/Samples/ssh/insecure-ssh2.pub",
"SSHPrivateKey": "/Samples/ssh/insecure",
"DockerRegistry": "https://containers.intersystems.com",
"DockerImage": "containers.intersytems.com/intersystems/iris:some-tag",
"DockerUsername": "xxxxxxxxxxxx",
"DockerPassword": "xxxxxxxxxxxx",
"TLSKeyDir": "/Samples/tls/",
"LicenseDir": "/Samples/license/",
"Region": "us-east-1",
"Zone": "us-east-1a",
"AMI": "ami-07267eded9a267f32",
"DockerVersion": "5:20.10.17~3-0~ubuntu-jammy",
"InstanceType": "m5.large",
"Credentials": "/Samples/AWS/sample.credentials",
"ISCPassword": "",
"Mirror": "false",
"UserCPF": "/Samples/cpf/iris.cpf"
}
The Instances File
The instances file (instances.json), generated by ICM during the provisioning phase, describes the set of host nodes that have been successfully provisioned. This information provides input to the deployment and management phase, and the file must therefore be available during this phase, and its path provided to ICM if it is not in the current working directory. The instances file is created in the current working directory.
While the definitions file contains only one entry for each node type, including a Count value to specify the number of nodes of that type, the instances file contains an entry for reach node actually provisioned. For example, the sample definitions file provided earlier contains three entries — one for three application servers, one for two data servers, and one for an arbiter — but the resulting instances file would contain six objects, one for each provisioned node.
All of the parameters making up each node’s definition — including those in the definitions and defaults file, those not specified in the configuration files that have default values, and internal ICM parameters — appear in its entry, along with the node’s machine name constructed from the Label, Role, and Tag fields), its IP address, and its DNS name. The location of the subdirectory for that node in the deployment’s state directory is also included.
The State Directory and State Files
ICM writes several state files, including logs and generated scripts, to the state subdirectory, for use during the lifetime of the provisioned infrastructure. The state subdirectory is created in the current working directory. by default.
State files generated during provisioning include the Terraform overrides file and state file, terraform.tfvars and terraform.tfstate, as well as Terraform output, error and log files. A set of these Terraform-related files is created in a separate subdirectory for each node type definition in the definitions file, for example:
./state/Acme-DM-TEST
./state/Acme-AM-TEST
./state/Acme-AR-TEST
If you prefer to create your own state directory with a different name or in a different location, you can use the -stateDir command line option with the icm provision command to override the default location, but you must then continue using the -stateDir option to specify that location in all subsequent provisioning commands, for example when you unprovision the infrastructure.
ICM relies on the state files it creates for accurate, up to date information about the infrastructure it has provisioned; without them, the provisioning state may be difficult or impossible to for ICM to reconstruct, resulting in errors, and perhaps even the need for manual intervention. For this reason, InterSystems strongly recommends making sure the state directory is located on storage that is reliable and reliably accessible, with an appropriate backup mechanism in place.
Log Files and Other InterSystems Cloud Manager Files
ICM writes several log, output and error files to the current working directory and within the state directory tree. The icm.log file in the current working directory records ICM’s informational, warning, and error messages. Other files within the state directory tree record the results of commands, including errors. For example, errors during the provisioning phase are typically recorded in the terraform.err file.
When an error occurs during an ICM operation, ICM displays a message directing you to the log file in which information about the error can be found. Before beginning an ICM deployment, familiarize yourself with the log files and their locations.
Docker Repositories
Each image deployed by ICM is pulled (downloaded) from a Docker repository. Many Docker images can be freely downloaded from public Docker repositories; private repositories such as the InterSystems repository, however, require a Docker login.
Logging Into a Docker Repository
As part of the deployment phase, ICM logs each node into the Docker respository you specify, using credentials supplied by you, before deploying the image specified by the DockerImage field in one of the configuration files or on the command line using the -image option. (The repository name must be included in the image specification.) You can include the following three fields in the defaults.json file to provide the needed information:
-
DockerRegistry
The DNS name of the server hosting the Docker repository storing the image specified by DockerImage. If this field is not included, ICM uses Docker’s public registry at docker.comOpens in a new tab.
If the repository specified by DockerImage does not exist on the server specified by DockerRegistry, deployment fails and returns an error.
For information about using the InterSystems Container Registry (ICR), see Downloading the ICM Image.
-
DockerUsername
The username to use for Docker login. Not required for public repositories. If this field is not included and the repository specified by DockerImage is private, login fails.
-
DockerPassword
The password to use for Docker login. Not required for public repositories. If this field is not included and the repository specified by DockerImage is private. ICM prompts you (with masked input) for a password.
Note:If the value of the DockerPassword field contains special characters such as $, |, (, and ), they must be escaped with two \ characters; for example, the password abc$def must be specified as abc\\$def.
Setting Up a Docker Repository
You may want to set up a Docker repository so you can store InterSystems images (and your own images) locally rather than relying on the network availability for critical applications. For information on doing this, see Deploy a registry serverOpens in a new tab in the Docker documentation.