Search


Cloud customer?
Upgrade in MyJFrog >


Working with an older version?

JFrog Artifactory 6.x
JFrog Xray 2.x
JFrog Mission Control 3.x
JFrog Distribution 1.x
JFrog Enterprise+ (Pre-Platform Release)




Overview

Each JFrog service requires filestore and database services.

  • The filestore is where binaries are physically stored.
  • The database maps a file’s checksum to its physical storage, and many operations on files within repositories are implemented as transactions in the database.


Page Contents

The following table summarizes the options for storing binaries and shared resources.


JFrog ArtifactoryJFrog XrayJFrog Mission ControlJFrog DistributionJFrog Pipelines
Filestore
  • Local file system in which binaries are stored with redundancy using a binary provider which manages synchronizing files between the cluster nodes according to the redundancy defined. 
  • Cloud storage
    Amazon S3 and Google Cloud Storage
  • Network File System (NFS)

The storage used by Xray is not a common resource. Only node specific files, such as configuration and temporary files, are saved to the disk.

Local file system is used to store information specific to the node. The main file that is used here is the mc.key which is used to encrypt the database content.

This need to be synchronized between the nodes manually.

N/APipelines makes use of the Artifactory filestore for performing storage functions such as step caching.
Database

You can configure your own database from the following list:

  • MySQL
  • Oracle
  • MS SQL
  • PostgreSQL
  • MariaDB

Artifactory HA requires an external database, which is fundamental to management of binaries and is also used to store cluster wide configuration files.

Since Artifactory HA contains multiple Artifactory cluster nodes, your database must be powerful enough to service all the nodes in the system. Moreover, your database must be able to support the maximum number of connections possible from all the Artifactory cluster nodes in your system.

If you are replicating your database you must ensure that at any given point in time all nodes see a consistent view of the database, regardless of which specific database instance they access. Eventual consistency, and write-behind database synchronization is not supported.

PostgreSQL

Every artifact and build indexed by Xray is broken down into multiple components.

These components and the relationships between each other are represented in a checksum based components graph.
Xray uses PostgreSQL to store and query this components graph.

PostgreSQL

An external database is required, which is fundamental to management of Mission Control database and is also used to store cluster wide configuration files. Currently PostgreSQL is supported, and any change to configuration requires restarting all Mission Control nodes for changes to take effect. 

PostgreSQL

Distribution HA requires an external database. Currently PostgreSQL is supported, and any change to configuration only requires restarting a single Distribution node for changes to take effect for the whole Distribution cluster.

PostgreSQL

For a single node installation of Pipelines, the PostgreSQL database is by default installed on the same node as Pipelines. It may be optionally configured as an external database.

Pipelines HA requires an external database for common use by all HA nodes.

Third Party ApplicationN/A

RabbitMQ (Microservice Communication and Messaging)

Automatically installed.

RabbitMQ is installed as part of the Xray installation for every node and in case of HA architecture, it uses queue mirroring between the different RabbitMQ nodes.

Xray has multiple flows, such as scanning, impact analysis, and database sync. These flows require processing completed by the different Xray services listed above. Flows contain multiple steps that are completed by the Xray services.

Xray uses RabbitMQ to manage these different flows and track synchronous and asynchronous communication between the services.

N/AN/A

RabbitMQ (Microservice Communication and Messaging)

Automatically installed.

RabbitMQ is installed as part of the Pipeline installation for every node and in case of HA architecture, it uses queue mirroring between the different RabbitMQ nodes.

Copyright © 2020 JFrog Ltd.