Xray HA OpenShift Installation

Xray on OpenShift is available from version 3.80.9 onwards.

Before proceeding with the installation, review the system requirements.

Xray's system requirements are dependent on the scale of your environment.

Sizings

Non-Kubernetes Deployment

Up to 100K indexed artifacts. No High Availability

Up to 1M indexed artifacts

Up to 2M indexed artifacts

Up to 10M indexed artifacts

Over 10M indexed artifacts

Contact JFrog Support.

For Xray HA (High Availability) installations (more than one node and 100k indexed artifacts), we recommend installing RabbitMQ and Xray on separate servers using split mode. For more information, see our page here.

RabbitMQ Note

RabbitMQ is a crucial component of the Xray architecture, acting as a message broker for communication between various application services. Multiple queues facilitate communication channels between producers and consumers. For more information, please refer to our page here.

Kubernetes Deployment

We have included YAML files with different sizing configurations for Artifactory, Xray, and Distribution in our GitHub pages. You can use these YAML files when you set up your cluster.

Note: From Helm chart 103.124 version of JFrog Xray, JFrog added support for Quorum Queues in RabbitMQ. This requires a minimum of three nodes of RabbitMQ and ensures fault tolerance of at least one node.  A non-HA setup of 1 node is also supported.

Note: We recommend a three-node cluster of RabbitMQ for Xray. Large clusters increase the overhead of replication and could affect the throughput. Our application has been tuned to work in a three-node setup.

To mitigate performance bottlenecks, avoid port conflicts, and prevent unusual configurations, use a dedicated node for Xray and RabbitMQ with no other software running.Scalability

Xray

You can create a high-availability cluster by adding multiple nodes (1, 2, 3, ...n) to distribute the workload and increase capacity.

RabbitMQ

An odd number of servers is required for RabbitMQ to work effectively for Quorum Queues. We recommend a three-node cluster for RabbitMQ, and if additional capacity is needed, this can be met through vertical scaling. Connect with us if you see a need for this.

Quorum Queues Notes

Starting with version 3.124.x Xray supports Quorum Queues.RabbitMQ has discontinued support for Classic Queue mirroring in version 3.0 and deprecated it in version 4.0. With this, JFrog will be deprecating Classic Queue support in upcoming releases.

A highly available RabbitMQ cluster with Quorum Queues requires a minimum of three nodes.A two-node cluster with RabbitMQ Quorum Queues will not be fault-tolerant.More than three node clusters won’t add fault tolerance and can weaken RMQ performance.

For more information, please refer to the RabbitMQ Quorum Queues documentation here.

In most cases, our recommendation is to use an SSD drive for Xray to have better performance and it is not recommended to use an NFS drive, as it is a disk I/O-intensive service, a slow NFS server can suffer from I/O bottlenecks and NFS is mostly used for storage replication.

Xray stores node-specific files, such as configuration and temporary files, to the disk. These files are exclusively used by Xray and not shared with other services. Since the local storage used for Xray services is temporary, it does not require replication between the different nodes in a multi-node/HA deployment.

Use the following command to determine the current file handle allocation limit.

cat /proc/sys/fs/file-max

Then, set the following parameters in your /etc/security/limits.conf file to the lower of 100,000 or the file handle allocation limit determined above.

The example shows how the relevant parameters in the /etc/security/limits.conf file are set to 100000. The actual setting for your installation may be different depending file handle allocation limit in your system.

root hard nofile 100000
root soft nofile 100000
xray hard nofile 100000
xray soft nofile 100000
postgres hard nofile 100000
postgres soft nofile 100000

The following table lists the supported operating systems and their versions:

📘

Note

Debian 12.x and Ubuntu 24.04 are supported from Artifactory 7.104 and Distribution 2.28.

Windows 2022 is supported from Artifactory 7.125.

Supported Platforms

The following table lists the supported platforms:

Installation on Kubernetes environments is through Helm Charts. Supported Helm version is Helm 3.17+.

✅

Kubernetes Sizing Requirements

We have included YAML files with different sizing configurations for Artifactory , Xray, and Distribution in our GitHub pages. You can use these YAML files when you set up your cluster.

📘

ARM64 Support for Container-Based Installations

Artifactory, Xray, and Distribution support installation on ARM64 architecture specifically through Helm and Docker installations. When deploying a product on an ARM64 platform, an external database must be set up as Artifactory does not support the bundled database for ARM64 installations. The appropriate ARM64 Container Image is automatically pulled during the Helm or Docker installation process.

Database

Every artifact and build indexed by Xray is broken down into multiple components. These components and their interrelationships are represented in a checksum-based components graph. Xray uses PostgreSQL to store and query this component's graph.

Xray supports the following PostgreSQL versions:

RabbitMQ

RabbitMQ is installed as part of the Xray installation for every node. In an HA architecture, Xray utilises queue mirroring and replication between different RabbitMQ nodes. The recommended installation method involves using split mode and setting up a separate 3-node RabbitMQ cluster with Xray HA.

Note: JFrog has added support for RabbitMQ Quorum Queues, available as an optional parameter in the system.yaml, because RabbitMQ has deprecated Classic Queue mirroring in version 4.x. Consequently, JFrog will also deprecate Classic Queue support and transition to Quorum Queues. We recommend enabling Quorum Queues in Xray, as JFrog plans to fully transition to RabbitMQ 4.x and discontinue Classic Queue support in upcoming versions.

Xray encompasses multiple flows, including scanning, impact analysis, and database synchronisation. These flows require processing by various Xray microservices. Flows comprise multiple steps completed by the Xray services. Xray uses RabbitMQ to manage these different flows and track synchronous and asynchronous communication between microservices.

Erlang

Xray incorporates Erlang and DB-Util as third-party dependencies. These packages are bundled with all Xray installers except for the Linux Archive.

Use the correct Erlang version corresponding to your Xray version:

• Xray versions 3.124.x requires Erlang 26. For more information on RabbitMQ and Erlang compatibility, please refer to the RabbitMQ and Erlang/OTP Compatibility Matrix.
• Xray 3.124 and later versions need Erlang 27 if we have enabled the RabbitMQ 4.x using properties.

Xray uses the 8082 port by default for external communication.

Xray uses the following internal ports by default for communication with JFrog Platform microservices.

📘

Note

Currently, it is not possible to connect a JFrog product that is within a Kubernetes cluster with another JFrog product that is outside of the cluster, as this is considered a separate network. Therefore, JFrog products cannot be joined together if one of them is in a cluster.

📘

Note

External RabbiMQ instances are not officially supported; the recommended method of installation is to use the bundled RabbitMQ.

Related Topics

• Xray HA Installation
• Xray Installation
• Xray HA Helm Installation
• Xray Single Node OpenShift Installation
• PostgreSQL for Xray
• Quorum Queue Enablement for Xray and Platform Helm Charts
• Upgrading Xray