Artifactory version 6.x to 7.x upgrade with Helm

JFrog Installation & Setup Documentation

Content Type
Installation & Setup
ft:sourceType
Paligo

Before you proceed, see System Requirements for information on supported platforms, supported browsers, and other requirements.

Operating Systems and Platform Support

The following table lists the supported operating systems and the versions.

Product

Debian

RHEL

Ubuntu

Amazon Linux

Windows Server

Artifactory

10.x, 11.x

8.x, 9.x

20.04, 22.04

Amazon Linux 2023

2016 or 2019

Supported Platforms

The following table lists the supported platforms.

Product

x86-64

ARM64

Kubernetes

OpenShift

Artifactory

1.19+

4.13+

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

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

Starting from version 7.41.4, Artifactory supports installation on ARM64 architecture specifically through Helm and Docker installations. When deploying Artifactory 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.

Additionally, ARM64 support is available for Xray and Distribution all through container-based Installations.

Artifactory Database Requirements

Artifactory supports the following databases:

  • PostgreSQL

    Tip

    JFrog highly recommends using PostgreSQL for all products in the JFrog Platform. For more information, see Choose the right database.

  • Oracle

  • MySQL

  • Microsoft SQL Server

  • MariaDB

Artifactory HA requires an external database, which is fundamental for the 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.

Artifactory Filestore

The filestore is where the binaries are physically stored.

Artifactory provides the following options to store binaries:

  • Local file system stores binaries with redundancy, using a binary provider that manages the synchronization of files between cluster nodes according to the defined redundancy settings.

  • Cloud storage is done using Amazon S3, Microsoft Azure, and Google Cloud Storage.

  • Network File System (NFS)

For more information, see Filestore Configuration.

Binary Storage

While Artifactory can use a Networked File System (NFS) for its binary storage, you should not install the application itself on an NFS. The Artifactory application needs very fast, reliable access to its configuration files. Any latency from an NFS will result in poor performance when the application fails to read these files. Therefore, install Artifactory on a local disk mounted directly to the host.

To use an NFS to store binaries, use the file-system binarystore.xml configuration with the additional <baseDataDir> setting.

Working with Very Large Storage

In most cases, our recommendation for storage is at least 3 times the total size of stored artifacts, in order to accommodate system backups.Backups

However, when working with a very large volume of artifacts, the recommendation may vary greatly according to the specific setup of your system. Therefore, when working with over 10 TB of stored artifacts, contact JFrog support, who will work with you to provide a recommendation for storage that is customized to your specific setup.

Allocated storage space may vary

Xray downloads and then deletes fetched artifacts after indexing. However, in order to have more parallel indexing processes, and thereby more temporary files at the same time would require more space.

This is especially applicable for large BLOBs such as Docker images.

Artifactory Network Ports

Artifactory uses external network ports to communicate with services outside Artifactory and internal network ports to communicate with Artifactory and other JFrog Platform microservices.

External Network Ports

Artifactory uses the following external network ports by default:

  • 8081

  • 8082

Internal Network Ports

Artifactory uses the following internal network ports.

Microservice

Port

Artifactory

HTTP: 8081, 8091

Access

HTTP: 8040, 8015

gRPC: 8045, 8016

Frontend

HTTP: 8070

Metadata

HTTP: 8086

Router

HTTP: 8082, 8046, 8049

gRPC: 8047

Event

HTTP:8061

gRPC: 8062

JFConnect

HTTP: 8030

gRPC: 8035

Observability

HTTP: 8036

gRPC: 8037

Mission Control

HTTP: 8080

In addition, review the Helm Chart requirements.

Helm Chart Requirements

For installing Helm Charts, JFrog services need the following requirements:

  • Kubernetes 1.19+ (for installation instructions, see Kubernetes installation)

  • Kubernetes cluster with:

    • Dynamic storage provisioning enabled

      Note

      When deploying a JFrog application on an AWS EKS cluster, the AWS EBS CSI Driver is required for dynamic volume provisioning. However, this driver is not included in the JFrog Helm Charts. For more information, see Store Kubernetes volumes with Amazon EBS.

    • Default StorageClass set to persistent storage

  • Kubectl installed and set up to use the cluster

  • Helm v3 installed

JFrog validates compatibility with the core Kubernetes distribution. Since Kubernetes distribution vendors may apply additional logic or hardening (for example Rancher) JFrog Platform deployment with such platform vendors might not be fully supported.

Artifactory Upgrade from 6.x to 7.x

Upgrading from 6.x to 7.x requires a one time migration process. You have to enable the migration in the values.yaml file:

artifactory:
  migration:
    enabled: true

It is possible to configure the migration timeout with the following configuration in extreme cases. The default provided should be more than enough for completion of the migration.

artifactory:
  migration:
    enabled: true
    timeoutSeconds: 3600
Migrating the Master Key from Version 6.x to 7.x

Version 6.x only supports a masterKey with 16 hex (32 characters) and if you have set a masterKey using openssl rand -hex 32 (64 characters) in 6.x, only the first 32 characters are used and rest are ignored. When migrating from 6.x to 7.x, we trim the first 32 characters and set the masterkey, which implies that 7.x still uses the trimmed masterkey of 6.x. Therefore, the artifactory.masterKey should not be passed during migration from 6.x to 7.x.

Upgrading from 8.x to 11.x and Above Chart Versions

If you are upgrading from 8.x to 11.x and above chart versions, remember to delete the existing PostgreSQL statefulset before upgrading the chart due to breaking changes in PostgreSQL subchart.

Run the following command.

kubectl delete statefulsets <OLD_RELEASE_NAME>-postgresql

Once you have a new chart version, you can upgrade your deployment.

Single Node Upgrade
  1. Use the following command to upgrade.

    helm upgrade artifactory --namespace artifactory jfrog/artifactory
  2. If Artifactory was installed without providing a value to postgresql.postgresqlPassword (if the password was auto-generated), run the following command to get the current password.

    POSTGRES_PASSWORD=$(kubectl get secret -n <namespace> <myrelease>-postgresql -o jsonpath="{.data.postgresql-password}" | base64 --decode)
  3. Upgrade the release by passing the previously auto-generated secret.

    helm upgrade <myrelease> jfrog/artifactory --set postgresql.postgresqlPassword=${POSTGRES_PASSWORD} --namespace <namespace>

    This applies any configuration changes on your existing deployment.

HA Upgrade with the artifactory-ha chart
  1. Use the following command to upgrade.

    helm upgrade artifactory-ha --namespace artifactory-ha jfrog/artifactory-ha
  2. If Artifactory was installed without providing a value to postgresql.postgresqlPassword (if the password was auto-generated), run the following command to get the current password.

    POSTGRES_PASSWORD=$(kubectl get secret -n <namespace> <myrelease>-postgresql -o jsonpath="{.data.postgresql-password}" | base64 --decode)
  3. Upgrade the release by passing the previously auto-generated secret.

    helm upgrade <myrelease> --namespace artifactory-ha jfrog/artifactory-ha --set postgresql.postgresqlPassword=${POSTGRES_PASSWORD}

    This applies any configuration changes on your existing deployment.

Artifactory version 7.25.5 onwards includes OpenJDK version 11.0.11 and later. TLS 1.0 and TLS 1.1 are disabled by default from OpenJDK 11.0.11 onwards. If your database version does not support TLS 1.2, the Artifactory startup fails.

If you are unable to upgrade your database to a version that supports TLS 1.2 or later, perform the following steps to run Artifactory:

  1. Create the following local directory.

  2. Download the java.security file that has TLS 1.0 and 1.1 enabled.

  3. Copy the java.security file to java/configmap.

  4. Run the following command to create a custom config map. For more information, refer to Using Config Maps.

  5. Pass the following custom config map to your Helm install. For more information, refer to Using Config Maps.