Applies to AnyLogic Cloud 2.5.1. Last modified on December 09, 2024.

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

/home/alcadm/alc

Within this directory, all Cloud data and configuration files are kept for future use.

The alc directory contains the following subdirectories:

• anylogic-private-cloud — Contains the registry data and the Docker images that are used to create Docker containers that run the Private Cloud services.
• cache — Contains data for all Cloud services. Includes the following directories that correspond to specific service components:
  • balancer
  • 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
  • cassandra (legacy) — stores persistent data
  In addition, each of these directories is attached to a corresponding Cloud Docker container as a Docker volume.
• controller — Stores configuration files for the controller service and other Cloud components. For more information, see Controller configuration files and Service configuration files below.

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

This file lists all the 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 build 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 to redirect to the container using Docker’s -p run option.
    "host": 9101, // The port to open on the node (the machine hosting the application).
    "container": 9101, // The port inside the container.
    "protocol": null // A protocol to use — can 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" ].
}

This file contains an array of JSON objects representing nodes — host machines running Cloud service components. Each of these objects also contains a list of services running on that particular 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 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 username used when 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. These files can be found in the keys directory. If method is set to "PASSWORD", this value specifies a plain text password you want to use when connecting to the host.
  },
  "volumeRoot": "/home/alcadm/alc/cache", // The directory in which the container volumes are stored on the node itself. If such a directory does not exist, it will be created. 
// An array of the names of applications to 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 or not controller should monitor this node and start services on it. It is not recommended to change this value in Private Cloud instances.
} ]

Private Cloud supports the following types of encryption:

Cloud version	RSA-2048	RSA-3072	ECDSA	Ed25519
2.5.0	check	check	check	check
2.5.1	check	check	check	check

This file stores passwords for the 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%"
}

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 to 127.0.0.1.
  "environment": "private", // Do not change this value in Private cloud.
  "controllerAddress": { // The address of the node running 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 RabbitMQ log server address.
    "host": "-", // The - character, when specified as a value of host, indicates the absence of a dedicated log server. In this case, logs are obtained by executing the Docker logs command.
    "port": 0   
  },
  "nodeCheck": { // The interval at which the periodic service status checks occur.
    "period": 10, // At such interval the controller service will connect to the nodes via the SSH interface and check whether any service needs to be started.
    "unit": "SECONDS"
  },
  "nodesMonitorCheck": { // The interval for periodically checking nodes.
    "period": 5, // Not used in Private Cloud.
    "unit": "SECONDS"
  }

This file stores the settings for the cookie consent message, localization packages, and social network sharing buttons.

{
    "cookieConsentMessage": {
        "enable": true, // Set to false to disable the cookie consent message.
        "position": "top", // Defines where to display the cookie consent message in the Private Cloud UI. Possible values: "top", "bottom". 
        "width": "narrow" // Sets the vertical width of the cookie consent message. Possible values: "narrow", "wide".
    },
    "i18n": {
        "languages": [ // Defines the languages available in the Private Cloud instance. The appropriate language pack should be installed — see the "Custom Localization" article for reference.
            "en",
            "ru",
            "zh"
        ],
        "defaultLanguage": "en" // Defines the default language of the instance.
    },
    "documentTitle": "AnyLogic Cloud", // Defines the main part of the AnyLogic Cloud page title in a web browser.
    "sharingButtons": { 
        "enable": true, // Defines whether the social network sharing buttons are available on the "General" tab of the model screen. 
        "buttons": [ // The values for the "name" fields are predefined and should not be changed. If you need to disable an individual social network’s sharing button, set the value of its "visible" field to false.
            {
                "name": "facebook",
                "visible": true
            },
            {
                "name": "twitter",
                "visible": true
            },
            {
                "name": "linkedin",
                "visible": true
            },
            {
                "name": "telegram",
                "visible": true
            },
            {
                "name": "wechat",
                "visible": true
            }
        ]
    }
}

The controller folder contains the following subdirectories:

• keys — Contains private SSH keys for the nodes.
• email-templates — Contains the service email notification templates that can be sent from Cloud.
• preload — Contains service files that are copied to the cache directory of the running application. Each subdirectory in preload must be named after its application.
  Currently, this subdirectory only contains the frontend directory. In there, the NGINX configuration of the Cloud web interface resides.

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 can be used by multiple service components.

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

Within the balancer.json file, you configure the queue rules. In addition, this file defines the number of attempts to assign the task that the balancer component will make 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 it is rejected.
  "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, it will use the least loaded node.
  "executorRequestTimeout": 2000, // The request timeout for communicating with executors, in milliseconds.
  "executorConnectionTimeout": 2000 // The connection timeout for communicating with executors, in milliseconds.
}

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

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

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

This file contains the configuration of the email server. In order For Cloud to send email notifications, you need to configure the SMTP relay server there.

Keep in mind the following requirements:

• Cloud supports only the SMTP relay servers that don’t require authorization
• Only port 25 is supported for communication with the SMTP server

{  
  "smtpServer": "192.168.0.4", // The IP address or FQDN of an SMTP server.
  "supportMailbox": "support@acme.com", // The email address to receive support requests messages.
  "internalNotificationsMailbox": "no-reply@acme.com" // The email address of a server administrator.
}

To modify the templates of the emails automatically sent by the Private Cloud instance, go to the email-templates subdirectory of the controller folder and edit them there.

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

Most of these options should not be changed.

{
    "appsRootDir": "/opt/anylogic/", // The directory inside the executor container where the JAR file of the executor component is stored.
    // 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 will stop the animation sessions that are inactive for the specified period
    "securityManagerEnabled": false, // Allows you to specify whether Private Cloud should use Java Security Manager.
    // If true, the models will be launched in a "sandbox", using Java Security Manager. This can have a huge impact on the model execution performance, reducing the speed by 2-3 times
    "totalOutputFilesSizeLimitMB": 256 // The maximum allowed size (in MB) for files that can be used as model output.
}

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

{
  "provider": "MINIO",
  "bucket": "anylogic-cloud",
  "root": "",
  "amazonConfiguration": {
    "region": "",
    "accessKey": "<key string>",
    "secretKey": "<key string>"
  }
}

This file contains the UUID and optional name for the highlighted user: models that 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 on their profile page, their first and last names will be displayed instead.

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

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

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

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

This file contains an option that determines 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 to use the functionality of the corresponding tab in the administrator panel.

In addition, the enableGuestAccess option determines whether 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 will be unavailable. To use Cloud, your users will need to sign up first.

The providers object lists the authentication providers supported by the Private Cloud instance. Currently, 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.
• oauth — enables the authentication via the OAuth 2 compliant identity provider. The settings must be specified in oauth.json.

Providers in the enterprise field are listed in order of priority. If anylogic is listed first, Private Cloud will try to identify the authenticating user in its own database first, and then check the ldap database.

The passwordPolicy object specifies the password requirements for users who register through the signup form. Certain restrictions apply:

• Only Latin characters are supported in passwords.
• minLength specifies the total length of the passwords. It should be an integer between 6 and 40.
• For any other field, the value should be a positive integer, while 0 means this option is disabled.
• Each field specifying the number of characters of a particular type is handled separately.
• If the specified number of characters is logically incorrect (say, the number of digits exceeds the maximum length, and another field requires that other type of characters to be present in the password as well), the rest service component will not be able to start up.

{
  "enabled": true, // Specifies whether a user can use the built-in signup form to create a profile in the instance
  "enableGuestAccess": true, // Specifies whether guests (non-authorized users) have access to the instance
  "providers": {
    "enterprise": "anylogic" // Specifies the list of available providers, a string containing the comma-separated list of providers.
    // May include "anylogic" (for built-in user management system of Cloud), "ldap" (for LDAP integration),
    // "ad" (for Active Directory integration), "oauth" (for OAuth 2.0 compliant providers) 
  },
  "passwordPolicy": {
    "minLength": 6, // the minimum length of the password, should be an integer between 6 and 40
    "numberOfDigits": 1, // the minimum number of digits in the password, a positive integer
    "numberOfUpperCaseCharacters": 1, // the minimum number of uppercase Latin characters in the password, a positive integer
    "numberOfLowerCaseCharacters": 3, // the minimum number of lowercase Latin characters in the password, a positive integer
    "numberOfSpecialCharacters": 1 // the minimum number of special (non-alphanumeric) characters in the password, a positive integer
  }
}

This file specifies the settings of the LDAP server associated with the Private Cloud instance. For more information on 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 service account password.
  "userSearchBase": "ou=users", // The LDAP organizational unit that Private Cloud processes to identify a user.
  "userSearchFilter": "(mail={0})", // The user identification filter expression. If the user attempts to authenticate, {0} will be replaced with that user's username.
  "groupSearchBase": "ou=groups", // The LDAP organizational unit that Private Cloud processes to identify the groups to which the user belongs.
  "groupSearchFilter": "member={0}", // The group identification filter expression. Upon successful identification of the user, {0} will be replaced with the distinguished name of that 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 user’s company name.
    "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.
  }
}

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.
  "rootDn": "dc=example,dc=com", // Optional. Specifies the root distinguished name. Useful in the rare case where the authenticating user’s username contains a domain name that differs from the Active Directory server’s 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 user’s company name.
    "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.
  }
}

This file specifies the settings of the OAuth 2 compatible identity provider associated with the Private Cloud instance. For more information on OAuth configuration, see OAuth authorization.

The example below shows settings taken from the PingOne identity provider. You must manually adjust them to use another provider.

You can find more example configurations in the corresponding article.

{
  "oauthProviders": [
      {
              "registrationId": "ping",// The registration ID part of the redirect URI you set in the provider console
          "name": "Ping Cloud",
          "providerConfiguration": { // The identity provider mapping
              "authorization-uri": "https://auth.pingone.eu/{yourInternalId}/as/authorize", 
              "issuer-uri": "https://auth.pingone.eu/{yourInternalId}/as",
              "token-uri": "https://auth.pingone.eu/{yourInternalId}/as/token",
              "user-info-uri": "https://auth.pingone.eu/{yourInternalId}/as/userinfo",
              "jwk-set-uri": "https://auth.pingone.eu/{yourInternalId}/as/jwks"
          },
          "registrationConfiguration": {
              "authorization-grant-type": "authorization_code",
              "client-id": "{yourClientId}",// Your identity provider client ID
              "client-secret": "{yourClientSecret}", // Your identity provider client secret 
              "redirect-uri":"https://test.anylogic.run/api/oauth/ping", // The full redirect URI 
              "scope": [
                  "openid", "profile", "email" // The list of scopes depends on the identity provider
              ]
          }
      }
  ],
  "oauthAttributes": {
      "email": "email",
      "name": "name"
  }
}

These two files contain references to the 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 about node operations.

You can modify data in statistics-db.json if you understand the possible consequences of your actions.

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

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

The size of a batch — a set of model runs (<batch size>) is calculated as <number of iterations> / preferredCount.

The initial number of batches created is equal to the initialCount field, meaning the number of incomplete runs at that point is equal to initialCount * <batch size>. A batch is then created every creationWindowMillis period. The size of this new batch is calculated as follows: min(<batch size> * initialCount - <number of incomplete runs>, <batch size>). The value of the minSize field is ignored in this calculation.

{
  "maxTasks": 1024, // The maximum number of tasks that a single multi-run executor will process simultaneously. Tasks that don’t reach this limit will be retried.
  "maxSingleRunsInMultiRun": 65534, // The maximum number of single runs in one multi-run experiment.
  "batches": {
    "minSize": 5, // If the batch size is less than this number, it will be scaled to this number. The last batch can ignore this rule.
    "maxSize": 20, // If the batch size is greater than this number, it will be scaled to this number.
    "initialCount": 8, // The initial number of batches created at the start of the experiment. 
    "preferredCount": 8, // The preferred number of batches.
    "creationWindowMillis": 5000 // The timeout before a new batch is created, in milliseconds. 
  }
}

Settings in this file determine the availability of certain features of the Private Cloud UI.

As of now, it allows to disable the custom UI for Cloud models.

{
  "enableCustomUI": true // set to false to disable the custom UI
}

This is a service file that stores the credentials that the instance uses to access the animation engines, in case your model uses the non-default animation engine. It should not be modified in any way.

{
  "keystores": [ {
    "filename": "webjar.truststore", // the name of the truststore file
    "password": "changeme", // the truststore password
    "aliases": [ "webjarTestKey" ] // public key aliases
  } ]
}

How can we improve this article?

Send