DevOps tools comparison: Artifactory vs. NXRM3
There are many repository management tools on the market and it is difficult to choose the best one. To facilitate this choice, we have prepared a comparison of the two most popular solutions, JFrog Artifactory and NXRM3 (Nexus Repository Manager). In order to be objective, we decided to set certain criteria. The comparison is based on the official documentation and official price lists only. We only compared selected parameters of the self-hosted version for both tools.
Architecture
The first part of the comparison includes architecture. Artifactory gains the upper hand right from the start. The system architecture is shown in the diagram below, and the complete description can be easily found in the documentation. Additionally, the user is informed that each service should be installed separately, according to the installation guide.
Meanwhile, the Nexus documentation doesn’t include the system architecture. After entering “architecture” in the search engine on the NXRM3 documentation page, we get the following result:
High Availability Architecture
Both products can be installed on a single server as well as in a highly available architecture. As for a single instance, it’s already available as a free version for both products. The High Availability Architecture for both Artifactory and Nexus is only available in the paid version. For Nexus Repository Manager, this is at least a Pro license. For Artifactory it’s only available from the Enterprise edition.
When it comes to the level of HIGH complexity, both solutions are quite straightforward. But Artifactory has the advantage of 2 nodes that are enough for the HA architecture to work. Additionally, its shared resource (database) officially supports more provider-independent types, such as MySQL, MS SQL, PostgreSQL, and Oracle (doesn’t support Docker and Docker Compose). Nexus shares storage between nodes but supports only NFS v4 or AWS EFS.
HA in Arifactory
JFrog services can be configured for High Availability with a cluster of 2 or more active nodes on the same Local Area Network (LAN). High Availability configuration ensures continuous synchronization, which includes data, configuration, cached objects, and scheduled job changes on all nodes. The highly available architecture in Artifactory is implemented by using Load Balancer (LB) and launching nodes. Artifactory itself has no built-in Load Balancer (LB). To ensure optimal resilience and uptime, LB divides the traffic between the nodes of Artifactory, which are also the UI for other JFrog products: Xray, Mission Control, Distribution, Pipelines. As only Artifactory is the subject of the comparison, we won’t be discussing HA for the rest of JFrog products in this article.
The resources shared between nodes should be at least a database. The database types supported for HA are:
- Oracle (not for Docker or Docker Compose),
- MySQL,
- MS SQL,
- PostgreSQL.
Individual nodes must also be able to communicate with each other on dedicated ports in the TCP/IP protocol.
HA in NXRM3
High Availability Clustering (HA-C) secures uptime by creating nodes clusters. In this way, the system remains available even if a node fails. Similar to Artifactory, implementation of a highly available architecture for NXRM3 includes setting up an LB by the client (Nexus also doesn’t have a built-in LB) and implementing at least 3 nodes (official minimum requirement from SonaType). Similar to Artifactory, in NXRM3, nodes should be able to communicate on selected ports in the TCP/IP protocol.
NXRM3, however, unlike Artifactory, doesn’t share the database, but the Blob repository. Active-Active synchronization is performed for individual databases to nodes. The recommendation from Sonatype, when it comes to sharing Blob repository, applies only to NFS v4 or AWS Elastic Filesystem. Sonatype also points out that since the Blob Repo sharing uses the POSIX mechanism, this sharing doesn’t work for the GlusterFS filesystem and FUSE-based userspace filesystems.
System Requirements
It’s hard to compare minimal storage in both tools because both companies don’t provide us with specific numbers. In Artifactory the recommendation is based on the expected artifact storage volume. According to the official documentation, we should use a fast disk with free space that is at least 3 times the total size of the stored artifact. In the case of 100–200 users, backup SAN is strongly recommended.
Nexus Repository Manager is a bit more complex solution because this tool supports several types of blob stores. The decision on which types to use should be based on the repository’s size, growth rate, and storage space availability.
Management and configuration
The configuration of Artifactory is done through both the UI and the YAML configuration file. The main configuration elements in the YAML file are architecture elements such as:
- databases,
- repositories,
- replication,
- general settings (mail server, URL, LDAP, password settings, etc.),
- security (General security, Password Policy, LDAP, SAML, OAuth, HTTP SSO, Crowd),
- service configuration (Backups, Maven Indexer),
- and advanced.
From the administration section in UI, we can manage repositories, access and authorization, security, licenses, general settings, proxies, monitoring, and artifactory.
In NXRM3, configuration, and management, with few exceptions, is done via the administration panel in the UI. The administration panel is divided into:
- repositories,
- IQ Server,
- security,
- support,
- and system.
In both tools, the management and configuration are transparent and intuitive. The advantage of Artifactory, however, is the ability to configure the product to a large extent in one file. This makes it extremely easy to manage and control such a configuration (versioning, IaC). The comparison doesn’t include the automation of the installation of both products, e.g. with an ansible.
Authorization and access
Monitoring mechanisms
Artifactory has several monitoring mechanisms built-in:
- monitoring disk space (monitoring storage),
- monitoring replication (in the Enterprise version),
- monitoring the status of services (Artifactory, Access, Event, Frontend, Replicator, Metadata).
Additionally, there is also the API Health Check, which is normally available via REST API after proper authorization.
NXRM3 is inferior to Artifactory in many ways when it comes to monitoring. NXRM3 has Repository Health Check built-in, but apart from this mechanism and API Health Check, there is no other monitoring mechanisms built-in. The many built-in monitoring mechanisms in Artifactory compared to just one in NXRM3 make Artifactory a winner of this category.
Repository cleanup policy
Artifactory, according to the source, has no built-in special mechanisms for removing artifacts after specific parameters, e.g. last use, path, tag, etc. The only exception is cache clearing in proxy repositories and the maximum number of unique “snapshots” for 6 repository types: Maven, NuGet, Gradle, Ivy, Docker, SBT.
Artifactory recommends using one of the available plugins, artifactCleanup, thanks to which we can either remove the artifacts in cron or via REST API based on when they were last downloaded.
Nexus Repository Manager has a built-in mechanism to support cleaning up repositories, which is well described, has examples and FAQ sections.
Cleaning the repository is done by configuring the repository cleaning policy run at a given frequency. There is one task (Administration → System → Tasks) of type “Admin Cleanup repositories using their associated policies” that triggers cleaning policies for all of the repositories. The given cleanup policy is added to the selected repository in the editing screen of this repository (Administration → Repository → Repositories → selected repository).
However, the triggered cleaning policy is implemented only by the so-called “soft delete”. Proper freeing up of disk space after the “soft delete” is done in the “Admin Compact Blob” task, which must be configured to run at any frequency in the section Administration → System → Tasks.
To delete the remaining images, i.e. those without tags, run the “Docker Delete unused manifests and images” task in Administration → System → Tasks. We recommend deleting such images at least once a week. In addition to the “Docker Delete unused manifests and images” task, we recommend running the “Docker Delete incomplete uploads” task once a week, which, as the name suggests, removes unfinished publications of docker images.
Filtering parameters for docker images to be removed are:
- the time elapsed since the artifact was published,
- the time elapsed since the last download of the artifact,
- the Docker image tag matching the regular expression for the given artifacts.
Pricing and Licenses
Nexus offers 2 packages: Nexus Repository OSS and Nexus Repository Pro. The first one is free and allows us to centralize and manage all of the components and binaries, and to build artifacts. According to the Nexus website, the free package includes:
- unlimited number of users,
- unlimited proxy, host, and group repositories,
- universal format coverage,
- possibility of integration with other CI/CD tools,
- container registry,
- community formats and plugins,
- cloud storage: Amazon S3.
Nexus Repository Pro costs 120$ per user per year and provides us with enterprise artifact management, multi-cloud storage, and high availability. Other features contained in the Pro package are SAML single sign-on, advanced metadata tagging, staging and build promotion, group Blob store, group deployment (Docker), and enterprise 24/7 support.
Artifactory offers us a Pro package for an unlimited number of users and repositories. Similar to Nexus, it contains container registry, binary replication, SAML Single Sign-on, and ecosystem integration. This option includes also such features as REST API, Universal Artifact Support, and free upgrades. It’s hard to compare the costs because the price of a Pro package depends on the number of servers and it costs 3200$ for 1 server per year.
Summary
Both Nexus Repository Manager and JFrog Artifactory are very good tools that help us managing repositories and improve efficiency. Each of them has its advantages and disadvantages, and the choice should be dictated by which tool will better adapt to the individual requirements of the project and the team. JFrog Artifactory wins primarily in terms of architecture, system requirements, and monitoring mechanisms, while Nexus Repository Manager is definitely better in areas such as Repository Cleanup Policy or Prices & Licenses.
DevOps tools aren’t just limited to managing repositories. Discover the galaxy of DevOps tools on our website and see how else we can make DevOps processes even more effective. Also, read more on our Technology-Driven Blog:
