Install Artifactory Single Node on OpenShift

JFrog Installation & Setup Documentation

Content Type
Installation & Setup
ft:sourceType
Paligo

Artifactory installation on OpenShift uses the Artifactory Helm chart for installation. The installation follows a similar approach as the Helm installation with certain changes specific for OpenShift.

Before you proceed with the installation, review the system 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

Xray

10.x, 11.x

8.x, 9.x

20.04, 22.04

Distribution

10.x, 11.x

8.x, 9.x

20.04, 22.04

Insight

10.x, 11.x

8.x, 9.x

20.04, 22.04

Amazon Linux 2023

Pipelines

8.x

20.04, 22.04

Amazon Linux 2023

Build nodes only

Supported Platforms

The following table lists the supported platforms.

Product

x86-64

ARM64

Kubernetes

OpenShift

Artifactory

1.19+

4.13+

Xray

1.19+

4.13+

Distribution

1.19+

4.13+

Insight

1.19+

Pipelines

1.19+

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

Starting from version 7.41.4, Artifactory supports installation on ARM64 architecture through Helm and Docker installations. You must set up an external database as the Artifactory database since Artifactory does not support the bundled database with the ARM64 installation. Artifactory installation pulls the ARM64 image automatically when you run the Helm or Docker installation on the ARM64 platform.

ARM64 support is also available for Xray, Distribution and Insight.

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

Customized YAML File

When using a customized values.yaml file, remember to attach a -f flag to each upgrade command in the file.

Installation Steps

Follow these steps to install the product:

  1. Add JFrog Helm Charts repository to your Helm client.

    helm repo add jfrog https://charts.jfrog.io
  2. Update the repository.

    helm repo update
  3. Create a unique Master Key (Artifactory requires a unique master key) and pass it to the template during installation.

    # Create a key
    export MASTER_KEY=$(openssl rand -hex 32)echo ${MASTER_KEY}

    Custom Master Key in Production Installations

    For production grade installations, we strongly recommend that you use a custom master key. If you initially use the default master key it will be very hard to change the master key at a later stage. Therefore, generate a unique key and pass it to the template at install/upgrade time.

    Alternatively, you can manually create a secret containing the master key and pass it to the template during installation.

    # Create a key
    export MASTER_KEY=$(openssl rand -hex 32)
    echo ${MASTER_KEY}
     
    # Create a secret containing the key. The key in the secret must be named master-key
    kubectl create secret generic my-masterkey-secret -n artifactory --from-literal=master-key=${MASTER_KEY}

    In either case, make sure to pass the same master key on all future calls to Helm install and Helm upgrade. This means always passing --set artifactory.masterKey=${MASTER_KEY} (for the custom master key) or --set artifactory.masterKeySecretName=my-masterkey-secret (for the manual secret) and verifying that the contents of the secret remain unchanged.

  4. Next, create a unique join key.

    # Create a key
    export JOIN_KEY=$(openssl rand -hex 32)
    echo ${JOIN_KEY}

    By default the chart has one set in the values.yaml (artifactory.joinKey). However, this key is for demonstration purposes only and should not be used in a production environment. Generate a unique key and pass it to the template during installation.

    Alternatively, you can manually create a secret containing the join key and pass it to the template during installation.

    # Create a key
    export JOIN_KEY=$(openssl rand -hex 32)
    echo ${JOIN_KEY}
     
    # Create a secret containing the key. The key in the secret must be named join-key
    kubectl create secret generic my-joinkey-secret -n artifactory --from-literal=join-key=${JOIN_KEY}

    In either case, make sure to pass the same join key on all future calls to Helm install and Helm upgrade. This means always passing --set artifactory.joinKey=${JOIN_KEY} (for the custom join key) or --set artifactory.joinKeySecretName=my-joinkey-secret (for the manual secret) and verifying that the contents of the secret remain unchanged.

  5. You need to set the securityContext of Artifactory and containerSecurityContext as false in the values.yaml file to proceed with the installation.

    containerSecurityContext:
      enabled: false
    artifactory:
      podSecurityContext:
        enabled: false
  6. To make PostgreSQL work on OpenShift, disable the securityContext in the pod and container level in the values.yaml file.

    postgresql:
      securityContext:
        enabled: false
      containerSecurityContext:
        enabled: false
  7. Artifactory version 7.77.3 and later supports Nginx. Update the following values in the values.yaml file to use Nginx.

    nginx:
      podSecurityContext:
        enabled: false
      containerSecurityContext:
        enabled: false
  8. Install the chart with the release name artifactory and with master key and join key, and pass the values.yaml file.

    helm upgrade --install artifactory --set artifactory.masterKey=${MASTER_KEY} --set artifactory.joinKey=${JOIN_KEY} --namespace artifactory jfrog/artifactory -f --values.yaml

    Change Internal PostgreSQL Password

    If you are using an internal PostgreSQL, it is recommended to change the PostgreSQL password. For more information, see Auto-generated Passwords (Internal PostgreSQL).

    The following example shows a sample values.yaml file.

    containerSecurityContext:
      enabled: false
    artifactory:
      podSecurityContext: 
        enabled: false
    postgresql:
      securityContext:
        enabled: false
      containerSecurityContext:
        enabled: false
    nginx:
      podSecurityContext:
        enabled: false
      containerSecurityContext:
        enabled: false
  9. Connect to Artifactory.

    It may take a few minutes for Artifactory's public IP to become available. Follow the instructions that are output by the install command above to get the Artifactory IP to access it. Below you will find a sample instruction of what to look for to pick the URL to reach Artifactory (in the following example, art77 is the release name and art is the namespace).

    NOTE: You are installing Artifactory in Openshift Environment.
    
    Open Artifactory in your browser
    Default credential for Artifactory:
    user: admin
    password: password
  10. To access the logs, find the name of the pod using the following command.

    kubectl --namespace <your namespace> get pods
  11. To get the container logs, run the following command.

    kubectl --namespace <your namespace> logs -f <name of the pod>
  12. Optional Steps

    1. Customize the product configuration including database, Java Opts, and filestore.

      Filestore Options

      Helm filestore (storage) installations require certain modifications. For more information, see Advanced Storage Options.

      Note

      Unlike other installations, Helm Chart configurations are made to the values.yaml file and are then applied to the system.yaml file.

      Follow these steps to apply the configuration changes:

      1. Make the changes to values.yaml.

      2. Run the command.

    2. To configure Artifactory for Helm, you will need to override the default system.yaml configuration. For more information, see Overriding the Default System YAML File.

    3. By default, Helm deploys Artifactory with PostgreSQL (running in a separate pod).

After installing and before running Artifactory, you may set the following configurations:

  • System YAML Configuration File

    Where to find system.yaml?

    You can configure all your system settings using the system.yaml file located in the $JFROG_HOME /artifactory/var/etc folder. For more information, see Artifactory YAML Configuration.

    If you don't have a System YAML file in your folder, copy the template available in the folder and name it system.yaml.

    For the Helm charts, the system.yaml file is managed in the chart’s values.yaml.

  • Configuring Database

    If you're planning to use it in production, it is highly recommended to first Configure the Database, and then start Artifactory.

  • Customize Java Opts (optional)

    Remember to modify your JVM Parameters as needed by setting JAVA_OPTIONS in Shared Configurations. The property to pass extra Java opts is artifactory.extraJavaOpts. It is highly recommended to set your Java memory parameters as follows:

    Tip

    The larger your repository or number of concurrent users, the larger you need to make the -Xms and -Xmx values accordingly. If you can reserve at least 512MB for Artifactory, the recommended minimal values are:

    -server -Xms512m -Xmx2g -Xss256k -XX:+UseG1GC

    For more recommendations about your hardware configuration (especially the -Xmx parameter), see System Requirements

  • Additional Settings

    These include: customizing ports, joinKey (join.key), masterKey (master.key).

  • Configuring the Filestore

    By default, Artifactory is configured to use the local file system as its filestore. Artifactory supports a variety of additional filestore configurations to meet a variety of needs for binary storage providers, storage size and redundancy.

Enable TLS 1.0 and 1.1 for Connectivity with Older Databases

Artifactory version 7.25.2 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. Download the java.security file that has TLS 1.0 and 1.1 enabled.

  2. Create the directory, ${JFROG_HOME}/artifactory/var/bootstrap/artifactory/java.

  3. Copy the java.security file into ${JFROG_HOME}/artifactory/var/bootstrap/artifactory/java.

  4. Provide the appropriate permissions to the directory.

    Note

    Artifactory startup takes a backup of the existing java.security file and bootstraps custom java.security into the ${JFROG_HOME}/artifactory/app/third-party/java/conf/security folder.

Configure Java Security File for Helm Installations
  1. Create the following local directory.

    mkdir -p java/configmap
  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, see Using Config Maps.

    kubectl create configmap java-security-config --from-file=java/configmap/java.security
  5. Pass the following custom config map to your Helm install. For more information, see Using Config Maps.

    artifactory:
      preStartCommand: "mkdir -p /opt/jfrog/artifactory/var/bootstrap/artifactory/java && cp -Lrf /tmp/java/* /opt/jfrog/artifactory/var/bootstrap/artifactory/java/"
      customVolumes: |
       - name: java-security-config
         configMap:
           name: java-security-config
      customVolumeMounts: |
        - name: java-security-config
          mountPath: /tmp/java/java.security
          subPath: java.security