AnyLogic
Expand
Font size

Private Cloud configuration files

The Private Cloud installation package creates a profile for an administrator user and places the configuration files within their directory. The default location for these files (provided the administrator user has the default name alcadm) is as follows:

/home/alcadm/alc

Within this directory, all Cloud data and configuration files are preserved for further usage.

The alc directory includes the following sub-directories:

  • anylogic-private-cloud — Contains the registry data, as well as the Docker images that are used to create Docker containers that run Private Cloud services.
  • cache — Contains data of all Cloud services. Includes the following directories that correspond to specific service components:
    • balancer
    • cassandra — stores persistent data
    • dynproxy
    • executor
    • executor-multi-run
    • experiment-results
    • fileserver — stores persistent data
    • frontend — stores persistent data
    • postgres — stores persistent data
    • rabbitmq — stores persistent data
    • rest
    • statistics
    In addition, each of these directories is attached to a corresponding Cloud Docker container as a Docker volume.
  • controller — Stores configuration files of the controller service and other Cloud components. For more information, see Controller configuration files and Service configuration files below.

Controller configuration files

The controller folder includes multiple configuration files in the JSON format. The example content snippets below include comments that identify the purpose of each JSON field.

applications.json

This file lists all service components — applications — of Cloud, in the form of a JSON array.

Each service component is represented as a separate JSON object which has the following format:

{
  "deployOrder" : 55, // The order in which this application will be started by controller.
  "name" : "rest", // The name of the application.
  "image" : "com.anylogic.cloud/rest:2.2.0", // A Docker image to use to create the application.
  "cmdArgs" : "", // Arguments to append to the Docker run command in the very end.
  "volume" : null, // A Docker volume to attach to the application container.
  "envVars" : [ ], // Environment variables to set using the -e run option of Docker. Example: "envVars" : [ "var1=xx", "var2=yy" ]
  "portMappings" : [ { // An array of ports which you want to forward into the container using the -p run option of Docker.
    "host" : 9101, // The port to open on the node (the machine that hosts the application).
    "container" : 9101, // The port inside the container.
    "protocol" : null // A protocol to use — may be tcp or udp, set to null to use both.
  } ],
  "stateEndpoint" : null, // If the application has a REST endpoint that can be used to identify its state, put it there. Example: "/state".
  "javaArgs" : [ ] // an array of the Java virtual machine arguments that you want to append to the Java command executed inside the container. Example: "javaArgs" : [ "-Xmx256M", "-Xms128M" ].
  "dockerArgs" : [ ] // An array of Docker arguments that you want to be passed within the container launch command. Example: "dockerArgs" : [ "--cidfile=/tmp/rest-cid", "--net=host" ].
}
Although controller is present within the application list, it is only for consistency — and proper handling of restart commands and the like. Any context-specific values specified within the controller object within applications.json are ignored.

nodes.json

This file contains an array of JSON objects which represent nodes — host machines that run Cloud service components. Each such object also includes a list of services that run on that specific machine.

The format of the node object is as follows:

[ {
  "host" : "10.0.103.66", // The DNS name or IP address of the host.
  "sshAccess" : {
    "method" : "PRIVATE_KEY", // The method you want to use to connect to the host’s SSH interface. Possible options: PRIVATE_KEY, PASSWORD. Default value: PRIVATE_KEY — it is highly recommended to use this option.
    "user" : "alcadm", // The user name you want to use while connecting to the host.
    "key" : "id_rsa" // If method is set to "PRIVATE_KEY", this value specifies the name of the key file you want to use to connect to the host. You can find these files within the keys directory. If method is set to "PASSWORD", this value specifies a plain text password you want to use to connect to the host.
  },
  "volumeRoot" : "/home/alcadm/alc/cache", // The root directory where the container volumes will be stored.
// An array of the names of applications that will run on this node:
  "labels" : [ "controller", "rest", "balancer", "fileserver", "cassandra", "experiment-results", "executor", "executor-multi-run", "dynproxy", "rabbitmq", "postgres", "frontend", "statistics" ],
  "stoppable" : false, // This is ignored in Private Cloud.
  "manageable" : true // Whether the controller should monitor this node and start services there or not. It is not recommended to modify this value in Private Cloud instances.
} ]

secrets.json

This file stores passwords for PostgreSQL and MinIO file servers that are used across updates.

If during an update other configuration files are recreated, the passwords from this file will be used.

{
  "postgres": "%random string%",
  "minioAccess": "%random string%",
  "minioSecret": "%random string%"
}

controller.json

The main configuration file of the controller component.

The file has the following format:

{
  "registry" : "local.cloud.registry:5000", // The Docker Registry server. The controller service pulls Cloud Docker images from there. By default, local.cloud.registry in /etc/hosts points at 127.0.0.1.
  "environment" : "private", // Do not modify this value in Private cloud.
  "controllerAddress" : { // The address of the node which runs the controller and the controller port. These values are passed to other Cloud services as environment variables.
    "host" : "10.0.103.66",
    "port" : 9000
  },
  "logServiceAddress" : { // The address of the RabbitMQ log server.
    "host" : "-", // The - character, when set as a value of host, indicates the absence of a dedicated log server. In this case, logs are received by executing the Docker logs command.
    "port" : 0   },   "nodeCheck" : { // The interval at which the periodic service status checks occur.
    "period" : 10, // At such an interval, the controller service will connect to the nodes through the SSH interface and check whether any service needs to be started.
    "unit" : "SECONDS"
  },
  "nodesMonitorCheck" : { // The interval for nodes’ periodic check.
    "period" : 5, // Not used in Private Cloud.
    "unit" : "SECONDS"
  }

Controller sub-directories

The controller folder includes the following sub-directories:

  • keys — Contains private SSH keys for the nodes. To establish an SSH connection, Cloud uses the JSch library.
  • email-templates — Contains the templates of service email notifications that can be sent from Cloud.
  • preload — Contains service files that are copied to the running application’s cache directory. Each sub-directory in preload must be named after the corresponding application.
    As of now, this sub-directory contains only the frontend directory. In there, the NGINX configuration of the Cloud web interface resides.

Service configuration files

These configuration files are located in the controller data directory. By default, their location is as follows:

/home/alcadm/alc/controller/conf

Each of these files may be used by multiple service components.

To apply any changes made in these files, restart the controller component by executing the following command:
sudo docker restart controller rest

balancer.json

The balancer service component uses this file. It holds RabbitMQ queues consisting of model run tasks — these tasks are submitted to executor service components.

Within the balancer.json file, you configure the queue rules. In addition, this file defines the number of attempts to allocate the task the balancer component performs before dropping the task.

{
  "minAvailableTasksThreshold" : 0,     // Not used in Private Cloud.
  "rebalanceDelay" : 5000,              // The delay for rejected tasks, in milliseconds.
  "maxRejectAttempts" : 5000,           // The number of attempts to rebalance the task before dropping.
  "mostLoadedFirst" : true,             // The balancing strategy. If true, the balancer component will attempt to execute the model run task on the most loaded node. If false, the least loaded node will be used.
  "executorRequestTimeout" : 2000,      // The request timeout for communication with executors, in milliseconds.
  "executorConnectionTimeout" : 2000    // The connection timeout for communication with executors, in milliseconds.
}

default-policy-groups.json

Cloud has policies that define resource limits for subscription and free users in public Cloud.

For Private Cloud instances, there is no point in modifying the default configuration of these policies, since there is no difference between subscription and free users. Given that, no additional limits are actually in effect.

{
  "experimentRunLimits": "experimentRunLimits:privateCloud",
  "sandboxing": "sandboxing:soft",
  "accountType": "accountType:free",
  "experimentRunMaxMemoryMB": "experimentRunMaxMemoryMB:privateCloud"
}

email.json

This file contains the email server configuration. For Cloud to be able to send email notifications, you have to supply the data of an SMTP relay server in there.

{
  "smtpServer" : "", // The IP address or FQDN of an SMTP server.
  "supportMailbox" : "", // The email address that will receive the messages with support requests.
  "internalNotificationsMailbox" : "" // The email address of a server administrator.
}

executor.json

This file contains configuration options for the executor service component which runs the models.

Most of these options should not be modified.

{
    "appsRootDir" : "/opt/anylogic/", // The directory inside the executor container that stores the JAR file of the executor component.
    // Should not be edited in any way.
    "s3CacheDir" : "/var/cache/executor/", // The directory inside the executor container where executor stores the JAR file of the model and its resources
    "logsDir" : "/var/log/executor/", // The directory inside the executor container where executor stores the model execution logs
    "sessionsDir" : "/var/run/executor/", // The directory inside the executor container where executor creates temporary environments for model execution
    "sessionTimeout" : "300", // The timeout (in seconds) for the animation session activity. The executor component stops the animation sessions that are inactive for the specified period period
    "securityManagerEnabled" : false, // Allows to specify whether Private Cloud should use Java Security Manager.
    // If true, the models are launched in a "sandbox", using Java Security Manager. This may have a huge impact on the model execution performance, reducing the speed in 2-3 times
    "totalOutputFilesSizeLimitMB" : 256 // The maximum allowed size (in MB) for files that can be used as model output. Due to restrictions in the internal Cloud policies, cannot be increased, but you can reduce it as you see fit
}

file-storage.json

This file contains the S3 backend configuration. Private Cloud uses the MinIO server (a file server Docker container) for S3.

There is usually no need to modify this configuration. The access key and secret key are generated randomly during the installation of Cloud.

Any modification to these case will prevent Cloud from connecting to MinIO and break the expected workflow of Cloud.

{
  "provider" : "MINIO",
  "s3Configuration" : {
    "bucket" : "",
    "root" : "",
    "amazonConfiguration" : {
      "region" : "",
      "accessKey" : "",
      "secretKey" : ""
    }
  },
  "minioConfiguration" : {
    "bucket" : "anylogic-cloud",
    "accessKey" : "NS7GKSEk",
    "secretKey" : "Y8wdZ7hm0SiEgTuH"
  }
}

highlighted-user.json

This file contains the UUID and optional name for the highlighted user: models this user uploads to Cloud will appear in the Selected Models section of the title screen of Cloud.

If this user does not have a username specified in their profile page, their first and last name will be displayed instead.

public.json

This file contains the external public address of the Cloud installation. By using this URL, your users will be able to open the Cloud web interface. The same URL will be used in AnyLogic desktop installations to export models to Cloud.

A proper Cloud instance URL must start with the protocol specified explicitly — that is, http:// or https://.

It is not recommended to switch between protocols without reinstalling Private Cloud. There are cases when it may be necessary, for example, when using the HTTPS proxy set up on an Elastic Load Balancer — but in general, you should avoid modifying the protocol and address of your instance in the file.

You may choose to specify a non-default port: in that case, specify it at the end of the address. Provided the port is not specified, the default port is used — 80 for HTTP, 443 for HTTPS.

{
  "gatewayHost" : "http://10.0.0.1:8080"
}

registration.json

This file contains an option that defines whether the registration via the web interface is available in the Private Cloud instance. Set the option to false to disable the registration form on the login screen and the corresponding API.

If the registration is disabled, the only way to add new users to the Cloud instance is by using the functionality of the corresponding tab on the administrator panel.

Additionally, the enableGuestAccess option defines if Private Cloud is available to guests. If this option is set to false, the Guest tab on the login screen and guests’ access to public models become unavailable. To use Cloud, your users will need to sign up first.

The providers object lists the authentication providers the Private Cloud instance supports. As of now, the following providers are supported:

  • anylogic — enables user management functionality of AnyLogic Cloud
  • ldap — enables the authentication via the LDAP server associated with the Private Cloud instance; the server should be specified in ldap.json
  • ad — enables the authentication via the Active Directory server associated with the Private Cloud instance; the server should be specified in ad.json

Providers in the enterprise field are listed based on their priority. If anylogic is listed first, Private Cloud attempts to identify the authenticating user in its own database first, and only after that checks the ldap database.

To learn more about how to set up LDAP or AD authentication for your instance, see Private Cloud: LDAP and AD authentication.
{
  "enabled" : true,
  "enableGuestAccess" : true,
  "providers": {
    "enterprise": "anylogic, ldap"
  }
}

ldap.json

This file specifies the settings of the LDAP server associated with the Private Cloud instance. For more information about LDAP configuration, see Private Cloud: LDAP and AD authentication.

The service account term refers to the user profile whose credentials Private Cloud uses to access the LDAP database.

It is possible to specify that certain fields on the server are binary-encoded. To do that, add b: to the beginning of the JSON string, for example:

"providerSpecificUid" : "b:objectGUID"
{
  "serverAddress" : "ldap://ldap.example.com:389/dc=company,dc=com", // The URL of the LDAP server.
  "cloudUserDN" : "cn=admin,dc=company,dc=com", // The distinguished name (dn) of the service account.
  "cloudUserPassword" : "xxx", // The password of the service account.
  "userSearchBase" : "ou=users", // The LDAP organizational unit which Private Cloud processes to identify a user.
  "userSearchFilter" : "(mail={0})", // The filtering expression for user identification. Upon an authentication attempt by the user, {0} is replaced with the username of this user.
  "groupSearchBase" : "ou=groups", // The LDAP organizational unit that Private Cloud processes to identify groups the user belongs to.
  "groupSearchFilter" : "member={0}", // The filtering expression for group identification. After the successful identification of the user, {0} is replaced with the distinguished name of this user.
  "cloudAdminGroupName" : "Cloud Admins", // The common name (cn) of the group whose members should have administrator permissions in the Private Cloud instance.
  "cloudUserGroupName" : "Cloud Users", // The common name (cn) of the group whose members should be users of the Private Cloud instance.
  "mapping" : { // This object establishes a value mapping between LDAP-specific fields and Private Cloud fields. Upon authentication of the LDAP user, their Cloud profile will be populated with information according to this mapping. Mapped fields won’t be editable via Cloud web UI.
    "providerSpecificUid" : "entryUUID", // The LDAP field whose value Private Cloud should use to unambiguously identify the LDAP user.
    "email" : "mail", // The LDAP field containing the user’s email.
    "firstName" : "givenName", // The LDAP field containing the user’s first name.
    "lastName" : "sn", // The LDAP field containing the user’s last name.
    "company" : "", // The LDAP field containing the name of the user’s company.
    "personalPage" : "", // The LDAP field containing the link to the user’s personal page.
    "linkedIn" : "", // The LDAP field containing the link to the user’s LinkedIn page.
    "description" : "" // The LDAP field containing supplementary information about the user.
  }
}
For LDAP authentication to work, all top-level fields in ldap.json must be filled with correct information, and the providerSpecificUid and email fields must be mapped properly.
The rest of the mapping fields are optional.

This file specifies the settings of the Active Directory server associated with the Private Cloud instance. For more information about Active Directory configuration, see Private Cloud: LDAP and AD authentication.

It is possible to specify that certain fields on the server are binary-encoded. To do that, add b: to the beginning of the JSON string, for example:

"providerSpecificUid" : "b:objectGUID"
{
  "serverAddress" : "ldap://ad.example.com", // The URL of the Active Directory server.
  "domain" : "domain.example.com", // The Active Directory domain name.
  "cloudAdminGroupName" : "Administrators", // The name of the group whose members should have administrator permissions in the Private Cloud instance.
  "cloudUserGroupName" : "Cloud Users", // The name of the group whose members should be users of the Private Cloud instance.
  "mapping" : { // This object establishes a value mapping between AD-specific fields and Private Cloud fields. Upon authentication of the AD user, their Cloud profile will be populated with information according to this mapping. Mapped fields won’t be editable via Cloud web UI.
    "providerSpecificUid" : "b:objectGUID", // The AD field whose value Private Cloud should use to unambiguously identify the LDAP user.
    "email" : "userPrincipalName", // The AD field containing the user’s email.
    "firstName" : "givenName", // The AD field containing the user’s first name.
    "lastName" : "sn", // The AD field containing the user’s last name.
    "company" : "", // The AD field containing the name of the user’s company.
    "personalPage" : "", // The AD field containing the link to the user’s personal page.
    "linkedIn" : "", // The AD field containing the link to the user’s LinkedIn page.
    "description" : "" // The AD field containing supplementary information about the user.
  }
}
For AD authentication to work, all top-level fields in ad.json must be filled with correct information, and the providerSpecificUid and email fields must be mapped properly.
The rest of the mapping fields are optional.

statistics-db.json and rest.json

These two files contain references to Cloud SQL databases: names and authentication credentials.

By default, Cloud has two databases: anylogic_cloud holds the metadata (that is, users, models, options, comments, and so on), while anylogic_cloud_statistics serves as storage for model run results, logins, and information on nodes’ operation.

Do not modify rest.json in any way. Doing so will make your Private Cloud instance unusable.

You may choose to modify data in statistics-db.json, provided you are well aware of the possible results of your actions.

{
  "dbname" : "anylogic_cloud_statistics",
  "username" : "postgres",
  "password" : "JuP7spIzL3im7VGN"
}

multi-run.json

This file contains the configuration of the executor-multi-run service component.

{
  "maxTasks": 1024, // The maximum amount of tasks a single multi-run-executor will process simultaneously. Tasks that don’t get into this limit will be retried.
  "maxSingleRunsInMultiRun": 65534 // The maximum amount of single runs in one multi-run experiment.
}
How can we improve this article?