Tip
This is one of many methods for migrating JFrog Artifactory. For a complete understanding of the overall migration process, we recommend reviewing our main article:
Comprehensive Guide to Migrating JFrog Artifactory
Introduction
Artifactory can be installed using many different methods.
The goal of this Knowledge base is to instruct you on how to switch an existing Artifactory from one installation method to another.
For example to switch from a VM installed Artifactory to K8S.
This operation will switch only the Artifactory application layer, while keeping the DB and filestore the same.
Artifactory possible installation methods:
Helm on Kubernetes environment
Helm on OpenShift environment
Docker Compose
Docker
RPM
Debian
Linux Archive
Mac (Darwin)
Windows
Steps:
Note
If Derby DB or an internal bundled Postgres is being used, the switching method mentioned in this article will not be possible, as it relies on an external DB.
If that is the case, please choose a different migration method available here.
For this tutorial, we will need to set 2 Terms:
Source Instance - The current old version of Linux server running Artifactory.
Target Instance - The new node running the desired new installation method.
Note
If an IP of hostname field set in the system.yaml.file, make sure to adjust it to the correct ip or hostname of the new server
Here are step-by-step instructions on how to switch installation type:
1. Initialization: Create a new instance using the desired installation method.
This will be our target Instance
2. Artifactory Installation: Install Artifactory on the newly created instance, ensuring it matches the exact version of the existing setup.
Do not start the Artifactory service after installation.
3. Security Configuration: Transfer the master.key from the source instance to $JFROG_HOME/var/etc/security/master.key on the target instance.
(The master.key is being used to decrypt all configuration files which are saved in the DB, in addition to passwords saved on the filesystem and more)
Note that the join key will automatically be retrieved from the database.
4.System Configuration: Copy the system.yaml from the source instance to the target instance, to keep the configurations of the source instance.
(Can be found at $JFROG_HOME/artifactory/var/etc/system.yaml)
4.b Database Connector Configuration: Make sure that the connection string to the existing DB was copied properly:
For example With PostgreSQL:
url: "jdbc:postgresql://<DB_IP>:5432/artifactory"
If a non-postgresql DB server is in use, please make sure to transfer its driver to $JFROG_HOME/artifactory/var/bootstrap/artifactory/tomcat/lib directory.
Warning
Make sure that the new server is allowed to access the existing DB.(Bypass Firewalls, Allow List etc).
5. Storage Configuration Part 1
- (If using local storage): You will need to manually move the content of your filestore (Default location $JFROG_HOME/artifactory/var/data/artifactory/filestore ) to the Target instance.
- (If using NFS/NAS): Mount the NAS/NFS storage to your target instance
- If using cloud storage (S3, AzureBlob, Google Storage): Make sure the target server has correct permissions and credentials to access the cloud storage resource.
6. Storage Configuration: Copy the binarystore.xml from the source instance to $JFROG_HOME/var/etc/artifactory/binarystore.xml on the target instance.
Single instance Artifactory:
7. Switch instances - (Downtime unavoidable) : Stop Artifactory service on the source Instance and start Artifactory on the target instance.
High Availability Artifactory - Multiple Nodes:
7. Switch instances - HA No Downtime Possibility: In a HA environment where a Load Balancer is properly distributing traffic between the nodes - There is a possibility of avoiding downtime by migrating only one node at any given time. While having a Load Balancer forwarding requests to other working nodes.
Warning
This no-downtime method can not be used when switching between a VM installation and k8s, as we do not support a mixed k8s VM cluster. Switching between these methods will require a downtime.
Both Single Node and HA:
8. Health Check: The target integration into the cluster via the Artifactory UI (Monitoring → Service Status → Nodes) - Make sure it is present and healthy.
9. License Validation: Make sure that the node has been assigned a license. (How to check my licenses?)
10. Operational Validation: Check everything works correctly. (Download/Upload via the target node, etc)
11. Load Balancer Validation: (If exists):Update the Load Balancer configuration to include the IP address of the target node, ensuring network continuity and load balancing within the HA environment.
11b. Check the node via the Load balancer (Download/upload).
Revert option (Only if required)
In case of any failure, you can revert back to the source instance, by stopping the Artifactory service on the target instance, and starting it back again on the source instance.