Note
This feature is supported with Enterprise X and Enterprise+ licenses with Artifactory versions 7.18.3 or later.
Federated repositories enable enterprises that operate across multiple sites to maintain a single source of truth for their binaries. A Federated repository functions similarly to a local repository on the local JPD but is grouped logically with other Federated members located on remote JPDs to create a Federation. Artifacts and metadata in one JFrog Platform Deployment (JPD) are mirrored to the Federated repositories in the remote JPDs that together comprise the Federation. Changes made to an artifact on one Federation member are replicated asynchronously to the other members.
Once you have created a Federation, changes made to artifacts on one member of the Federation will be replicated asynchronously to the other Federated members. The Federated repository configuration is also aligned across all members of the Federation.
For example, if Federated repository A in "JPD A" and Federated repository B in "JPD B" are members of the same Federation, deploying a file to Federated Repository A in "JPD A", will trigger a copy of the file action to the Federated Repository B in "JPD B".
Similarly, deploying a file to Federated Repository B in "JPD B", will trigger a copy of the file action to the Federated Repository A in "JPD A". The configuration changes are also synchronized based on the latest update (e.g. latest update to the configuration is propagated to all members of the Federation).
Important
A file that is replicated from one Federation member (the source) to a different Federation member (the target) cannot be downloaded by users from the target member until it receives the metadata.
The arrival of the metadata can be verified by seeing the file displayed in the tree browser or the database of the target member.
Starting from version 7.74, Cloud customers can confirm the file's arrival by looking for the following log message:
"Finished the handle mirror event for repo <repo_key> and message: <message>"
Use Cases
Federated repositories provide Enterprise organizations divided across multiple geographical sites with a single source of truth for their binaries as if they were one seamless unit. They support the following use cases:
Distributed development teams
Remote production environment
Increased artifact availability in a multi-site environment
Defining Characteristics
Federated repositories have the following characteristics:
Federated repositories use a persistent queue to ensure that events are maintained even in the event of a system failure or restart.
Metadata events are updated asynchronously among Federated repositories. However, because of the persistent queue, the repository Federation mechanism ensures that all events will be synchronized among all Federation members. For example, an event might not be sent immediately to a different Federation member due to a server failure or network delays, but the system ensures that the event will be sent eventually.
There is no dependency among Federation members, nor is there member priority when synchronizing the metadata. This means that a member which is slow to respond or experiencing heavy traffic will not impact the other members.
When the same file is sent from two locations simultaneously, conflict resolution is performed based on timestamps where the last event received overrides previous events. This is why clock synchronization is critical to the proper functioning of the Federation (see Setup Prerequisites for Federated Repositories).
Synchronized Metadata
Federated repositories synchronize the following metadata among members:
Folders | Files |
|---|---|
|
|
Note
Synchronization of the metadata that was introduced as part of the 7.90.1 release (uploadedBy, lastFileModified, deploymentDate) is controlled by the system property, artifactory.federated.mirror.events.upload.info.propagate.enabled. By default, this flag is set to false. Set this flag to true on both the source and target JPDs to synchronize this metadata to other members.
Settings that are not Synchronized
The following repository configuration settings are not synchronized among Federation members:
proxy
maxNumberOfThreads
modificationDate
blackedOut
repoLayout
key
primaryKeyPairDescriptor
secondaryKeyPairDescriptor
xrayConfig
cdnRedirectConfig
propertySets
cdnRedirectRepo
downloadRedirect
For more information about these settings, see Repository Configuration JSON.