Note
This feature is supported with Enterprise X and Enterprise+ licenses with Artifactory versions 7.18.3 or later.
Artifactory enables you to create Federated repositories, which mirror artifacts and their metadata with other Federated repositories on remote JFrog Platform Deployments (JPDs) in a multi-site environment. 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.
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.
Federated Topology
Federated repositories employ a topology with two separate but integrated mechanisms, whereby artifact metadata is replicated continuously but separately from the binary content. This is done to enable fast synchronization of the metadata, which is replicated rapidly in bulk, while the binary content is brought asynchronously using a separate mechanism based on workers. Priority can always be given to specific binaries on user demand as required.
Having the metadata replicated quickly is critical because file properties cannot be uploaded before the file itself is uploaded. This is especially true when working with Docker manifests, which cannot be uploaded before the layers listed in the manifest are uploaded.
Dividing the federation of the metadata and the binaries into two separate mechanisms also provides a solution with excellent scalability.
 |