Skip to main content

Platform Federation

Info

Platform Federation for self-managed deployments is available in early access. Contact JFrog Customer Success to join.

Overview

JFrog Platform Federation connects multiple JFrog Platform sites into a single mesh of peers that keeps the platform configuration identical on every site.

Changes made on any member site are automatically synced to all other member sites, so you can scale globally and stay consistent everywhere, without manual cross-site updates.

In earlier multi-site setups, Access Federation and Federated Repositories synced users and artifacts, while everything else (such as Projects, policies and repository configurations) had to be managed per site, usually with scripts or IaC. Platform Federation is the next generation federation solution. It extends federation to additional platform entities and configuration, and orchestrates the federation of repositories, including local, remote and virtual repositories.

For the full announcement, see the blog post Introducing JFrog Platform Federation.

Why

  • Member sites share one platform configuration, so they do not drift apart
  • A change on any member site syncs to the other member sites

How

Key Capabilities

  • Manage once, apply everywhere: Automate global administration across all distributed sites and eliminate manual overhead
  • Repository provisioning (future release): Map the global stages to sites once. Repositories are provisioned automatically on every site mapped to their stage
  • Zero configuration drift: Monitor the federation in real time and reconcile drift as soon as it appears

What Gets Synced

  • Global Entities: Platform entities and configurations, including Projects, stages and roles, access control and policies
  • Repositories (future release): Repositories will be provisioned on the member sites from the main site, according to the Stage to Site mapping:
    • Local repositories: Configuration and artifacts are federated. The artifacts are kept in sync using Federated Repositories
    • Remote and virtual repositories: Configuration only is federated
  • Curation policies: Already supported as part of Curation Federation, currently as a standalone solution. Curation Federation is planned to be included in Platform Federation

Architecture

Platform Federation is implemented by the following services, together with the Artifactory service on each site:

  • Grid Service: Runs on the main site and orchestrates the Platform Federation. It manages the member sites, validates them before they join (health, connectivity, Circle of Trust and entitlement), and monitors the sync events. In a future release, it will also orchestrate the repositories, provisioning them on the member sites through the Artifactory service, according to the Stage to Site mapping
  • PFED (Platform Federation Service): Runs on every member site. Syncs the Global Entities directly with the other member sites. Messages are queued and retried, so a site that was offline catches up automatically when it returns
  • RTFS (Artifactory Federation Service): Runs on every member site. Syncs the artifacts of the provisioned local repositories between the sites
flowchart LR
    A["JFrog Self-Managed<br/>Main Site<br/>(Artifactory, Grid, PFED, RTFS)"]
    B["JFrog Self-Managed<br/>Site B<br/>(Artifactory, PFED, RTFS)"]
    C["JFrog Self-Managed<br/>Site C<br/>(Artifactory, PFED, RTFS)"]
    A <-- "Global Entities" --> B
    B <-- "Global Entities" --> C
    A <-- "Global Entities" --> C
    A -. "Repository provisioning" .-> B
    A -. "Repository provisioning" .-> C

Each site is a single JFrog Platform deployment built from several microservices: Artifactory, PFED and RTFS on every site, plus the Grid Service on the main site. Solid lines are the Global Entities sync by PFED, a full mesh between all member sites. Dotted lines are the repository provisioning by the Grid Service.

  • Every member site must be able to reach all other member sites, as the PFED and RTFS services sync peer-to-peer
  • Each site must have a unique base URL. See Multi-Site considerations for using a common URL across sites

Resources

The Grid, PFED, and RTFS services that operate Platform Federation run on every member site, and the JFBus service is also required. These services add to the site footprint, and their sizing files are included in the Grid Helm Chart used for Kubernetes installation.

Operations and Site Availability

Global Entities are synced in a mesh of peers, but not all operations are handled the same way:

OperationsWhere they runWhen the main site is down
Mission critical, such as managing Global Entities and uploading and downloading artifacts in existing repositoriesOn any member site, without depending on the other sitesAvailable. Changes are eventually consistent, and are synced to the other sites once they are reachable
Stage to Site mapping updates, which provision the repositories to the sitesOn the main site onlyNot available
Repository creation and configuration updatesRequires the main site, and all the sites the repository is provisioned to, to be availableNot available

When the main site is down, the member sites keep serving mission critical operations, while some non-critical operations are not available until the main site is back.

Where It Fits in the Use Cases

Platform Federation is the foundation of a Multi-Site deployment, keeping all sites complete and uniform peers.

Use caseRole of Platform Federation
Active-Passive and Disaster RecoveryRecommended. The passive site is a live copy of the platform configuration, so a failover does not require reconfiguring access, Projects or repositories
Active-ActiveRecommended. Every site serves its developers with the same configuration and repositories, so regional teams work in the same logical workspace with local performance. New sites (a new region, an acquisition or a business unit) receive the platform context (such as Projects) when they join
CI/CD SeparationUse when the CI and CD sites share the same Projects and access model
Main Site with EdgesUse for the full sites. Edge nodes are not members of a Platform Federation; use Access Federation for them
Subsidiaries and VendorsPlatform Federation keeps the configuration uniform across all member sites. When each site requires its own users or permissions, use Access Federation with filters

Implementation Guidelines

  • Prerequisites: Enterprise+ subscription with the Platform Federation entitlement, and all sites live and in the same Circle of Trust
  • Align before joining: When a Platform Federation is created, or a site is added to it, the most recent value of each Global Entity is applied to all member sites. Overwritten values cannot be restored, so align the configuration of the sites in advance
  • Mesh topology and uniform configuration: All member sites sync with each other as peers, and all Global Entities are synced to all of them, with no filtering or mapping per site
  • One Platform Federation per site: A site can be a member of only one Platform Federation
  • Existing federation: Federated Repositories and Curation Federation keep working on sites that join a Platform Federation
  • Impact of removing a site: A removed site keeps the last synced configuration, and stops sending and receiving updates