ARTIFACTORY: How to scale Artifactory chart to HA

Introduction

When deploying a High Availability (HA) Artifactory instance using a Helm chart, you generally have two primary options: deploying via the dedicated artifactory-ha chart, or deploying via the standard artifactory chart with artifactory.replicaCount set to a value greater than one. Both methods effectively create an Artifactory HA cluster, allowing you to easily scale up or down as long as you possess the necessary licenses.

However, if you initially deploy Artifactory with the standard Artifactory chart ( or platform chart which uses Artifactory chart ) with a replica count of 1 and intend to transition to an HA cluster later, you may encounter challenges if you simply scale it up.



The Issue

It is important to note that deploying the standard Artifactory chart with artifactory.replicaCount set to 1 results in a standalone instance. If you attempt to scale up the replicas using the kubectl scale command to convert the deployment into an HA configuration, you will face critical issues.

For example, Artifactory may stop because the local server is running as PRO/OSS but detects other servers in the registry. This occurs because the scale command simply attempts to launch another standalone pod, resulting in two standalone instances simultaneously trying to connect to the same database.

Furthermore, while a standalone instance with a single replica typically does not require a specific binary store provider, scaling to an HA cluster demands a shared binary provider. Failing to choose an appropriate, HA-compatible binary provider can lead to erratic "500 binary not found" errors and build failures.



Resolution & Best Practices

Caution: Transitioning from a Standalone to a High Availability (HA) architecture requires careful planning. Always review your binary store and database configurations to ensure they are fully compatible with an HA environment before scaling up.

We recommend that for HA environments, you start your deployment with at least 2 replicas as best practice.

To successfully scale your deployment and avoid these errors, you must update your values.yaml and execute a helm upgrade before attempting any manual scaling. Ensure the following settings are updated:

YAML

artifactory:
  replicaCount: 2  # Any value greater than 1 will designate this as an HA cluster
  persistence:
    type: s3-storage-v3-direct  # Must be an HA-compatible provider type
  extraEnvironmentVariables:
    - name: JF_SHARED_NODE_HAENABLED
      value: "true"

Note:

The persistence.type variable will not function if you are overriding the binarystore.xml configuration directly in values.yaml or a secret.

While replicaCount > 1 ensures that JF_SHARED_NODE_HAENABLED is true. Adding the JF_SHARED_NODE_HAENABLED environment variable explicitly ensures that Artifactory continues to operate in HA mode and prevents configuration drift. It safeguards your cluster against unexpected behavior, such as an accidental Helm upgrade or instances where the original StatefulSet is deleted and re-evaluated under a single replica count.

For an HA cluster, your supported persistence.type options include:

file-system (only if all HA pods share the same PVC)

```
cluster-file-system
```

nfs (essentially a file-system with one shared PVC)

google-storage-v2-direct (Recommended for Google Cloud Storage)

```
cluster-google-storage-v2
```

s3-storage-v3-direct (Recommended for AWS S3)

```
cluster-s3-storage-v3
```
```
azure-blob-storage-direct
```

azure-blob-storage-v2-direct (Recommended for Azure Blob Storage)

```
cluster-azure-blob-storage
```

If you are using a custom binary provider instead of the predefined types above, ensure that it fully supports concurrent access for an HA cluster.

After updating the values and running helm upgrade, verify the change by confirming that the HA flag is present. The following command should return the environment variable block:

Bash

kubectl describe pod <pod_name> -n <namespace> | grep -A 1 "JF_SHARED_NODE_HAENABLED"

Once your HA deployment is properly configured and successfully deployed via Helm, you can scale replicas up and down for day-to-day operations using the kubectl scale command instead of running a full helm upgrade.