You must uniquely identify MA servers and deployments using schemes.
In a Common-Named Multiple Server and Deployment configuration that has more than one MA deployment within an environment access by a common name, each server and deployment must be uniquely identifiable. This identity allows coordination services, peers servers, and orchestration ecosystems to differentiate one deployment and server from another when necessary.
Topics:
serverID and deploymentID is required for each of your servers and deployments. Deployment and server UUIDs are generated by default if you don’t define them.Parent topic: Securing the Microservices Architecture
Universally Unique IDs are synonymous with Globally Unique IDs (UUID/GUID).
These IDs provide a standardized format for creating and interpreting identifiers that is a 128–bits long, RFC4122. It can guarantee uniqueness across space and time. Several operating systems provide mechanisms to generate UUIDs including:
$ cat /proc/sys/kernel/random/uuid $ uuidgen
UUID can be used to identify distinct deployments and even specific servers within a deployment. The primary issue with UUIDs is that once generated, they can not be regenerated. If the UUID value is lost, there is no way of deterministically recreating it. This is an issue if the UUID is used in a distributed fashion and it is held as reference to a specific deployment. If that deployment loses the value of it originally generated UUID, there is no way of regenerating the UUID. You must take care when safeguarding the UUID.
Parent topic: Server and Deployment Identities
A deployment’s identity can be deterministically calculated and be unique within a local scope.
This would create a unique ID based on a combination of hardware and file system signatures. For example, the calculated ID could be generated based on the MAC Address of the network interface and the real absolute file system paths that make-up the deployment. Any relocation of the deployment within the file system invalidates the deterministic regeneration of the ID, as would any change in the network interface.
Parent topic: Server and Deployment Identities
You can use explicit naming to avoid the problem of guaranteed uniqueness to administrators.
While this addresses any potential shortcoming of other schemes with recreation of an ID, this scheme is not recommended in large organizations with a large deployment count.
Parent topic: Server and Deployment Identities
A serverID and deploymentID is required for each of your servers and deployments. Deployment and server UUIDs are generated by default if you don’t define them.
In general, these values are not changed once assigned. These values are also of limited use directly because their application is dependent on the context and requirements of the request or operation.
serverID
Each servers generates a unique ID during first start if it finds an absent or null server ID. The server ID is then used to generate a short unique label that can be used as name or tag in cases where the 3- character UUID is to long. Both the serverID and short name are expected to be globally unique. It can be used to identify a server without prefixing it with a deployment. The serverID is held in each server’s local configuration context and only accessible by the owning server.
You can use the serverID to limit certain request or action targets to only the server. For example, by including the serverID in server generated payloads, the server can validated that it was the originator of the payload by comparing the presented serverID with the held serverID.
"config" : {
"serverID": "96bc6cab-abb8-4a05-aeff-6d0d385262af"
"serverIDShortLabel": "lrxsq6u4SgWu/20NOFJirw"
}
deploymentID
The first server starting within a deployment generates a unique ID if it finds an absent or null deployment ID. The deploymentID is a a containment ID and serves to identify a group of related servers. The deploymentID is held in the deployment global configuration context and is accessible by all servers within that deployment.
The deploymentID can be used to limit server requests or actions to only the servers within the deployment. For example, by including the short label version of the serverID in UDP/UDT data, a server can filter and qualify only the information that originated from a server within its own deployment.
"global": {
"deploymentID": "f1df4a18-d0a8-4ba1-9ad0-18da9458baef"
}
affiliateDeploymentIDs
Affiliated deployments are deployments that coordinate or cooperate share specific information or contexts. The affiliateDeploymentIDs value is a JSON Array type that is initially null (empty). As deployments define actions or operations that should apply to or be valid in other deployments, the deploymentIDs of the affiliated deployments are added to the JSON Array of the affiliateDeploymentIDs. Specific behaviors or actions can qualify a presented deploymentIDs against the list of affiliateDeploymentIDs and grant access or operation to the foreign deployment.
For example, an authorization cookie includes a deploymentIDs as part of its specification. If the authorization cookie is presented to an foreign deployment that has the originating deployment's deploymentIDs listed in its affiliateDeploymentIDs list, then the authorization cookie is qualified rather then being filtered out as not originating from the receiving servers.
"global": {
"affiliateDeploymentIDs": [ "deafa2f6-6ee7-48b1-862a-97a9b6d5b9df" ]
}
You can update the global configuration using either a bootstrap configuration file or the command-line overrides, for example:
$ bin/adminsrvr '{"global": { "affiliateDeploymentIDs": ["deafa2f6-6ee7-48b1-862a-97a9b6d5b9df"]}}'
Parent topic: Server and Deployment Identities