Artifactory 5.倍

使用Artifactoryx ?
JFrog Artifactoryx用户指南

全部展开 全部折叠

有问题吗?想要报告问题?联系JFrog支持

跳到元数据的末尾
进入元数据的开始

概述

升级Artifactory的过程取决于您的安装类型。我们强烈建议您在继续升级之前阅读此页。针对以下安装类型，有专门的页面提供详细的升级说明:

  • ZIP文件
  • RPM
  • Debian
  • 码头工人

此外，在每个安装类型中，如果从较旧版本的Artifactory升级，则说明可能会有轻微的变化。

在继续之前

升级前

我们强烈建议您采取以下措施，以确保在升级过程中遇到任何问题时可以回滚系统:

  1. 做一个完整的系统出口在开始升级过程之前。如果在任何时候决定回滚到当前版本，可以使用导出来完整地再现当前系统。
  2. 备份数据库。

在继续之前，有几点你需要解决:

  1. JDK版本
    从版本4.0开始，Artifactory需要JDK 8。如果您的当前版本是v3。在升级到Artifactory 5之前。x，请确保您安装了JDK 8，并更新您的JAVA_HOME环境变量以指向您的JDK 8安装。详情请参阅系统需求．

  2. 具有多种包类型的存储库
    从4.0版本开始，Artifactory将只对单个包类型存储库进行索引，并与相应的客户机一起工作。如果您的当前版本是3。X和安装包括支持多种包类型的存储库，您需要将它们迁移到单一包类型的存储库。您可以在升级之前或之后这样做。详情请参阅单一包类型存储库．
  3. NPM构建的'斜杠'字符编码
    处理'斜杠'字符编码的NPM已从artifactory.system.properties文件到catalina.properties您的Tomcat文件。详情请参阅Npm范围包．
页面内容

了解更多

升级人工企业/ HA

升级Artifactory HA有不同的说明

升级HA集群时，升级每个节点的过程与升级单个实例(非HA)安装类似，但是，要使节点作为高可用性集群运行，还需要执行其他操作。

如果升级的是Artifactory HA集群，请参考升级企业HA集群．

升级到最新版本

从版本4升级。X或5。X到最新版本是一个简单的过程。请参考下面的章节，了解您的安装类型的具体说明。

压缩安装

  1. 解压Artifactory分发归档文件。

  2. 如果ARTIFACTORY_HOME美元/ / conf / tomcat server.xml已被修改保存在临时位置。

  3. 根据以下条件将文件备份到临时位置:
    1. 在所有情况下，备份美元ARTIFACTORY_HOME / bin /工件ory.default
    2. 如果将Artifactory配置为使用非Derby的数据库，则备份ARTIFACTORY_HOME美元JDBC / tomcat / lib / < >司机。
  4. 从您的文件夹中删除以下文件和文件夹ARTIFACTORY_HOME美元文件夹:

    • webapps / artifactory.war

    • webapps /访问。战争(这将只会出现如果你的当前版本是5.4.0及以上由于添加访问服务）

    • tomcat

    • 箱子

    • misc

  5. 将已删除的文件和文件夹替换为新解压缩版本中的相应文件和文件夹。

  6. 存储在临时位置的任何文件现在都应该返回到新安装下的原始位置。

    以ROOT身份运行Artifactory

    如果您已经将Artifactory配置为在Tomcat中作为根应用程序运行，那么在继续之前，您需要遵循中所描述的步骤这篇知识库文章．

    特定版本的特殊说明

    为了适应不同版本升级中Artifactory的内部更改，您需要根据目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

    升级至5.4.0及以上版本

    从5.4.0版本开始，Artifactory对访问令牌的管理被移动到一个单独的服务Access，作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您使用的是以前安装的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

    ．.．<引擎名称="Catalina" defaultHost="localhost"> <主机名称="localhost" appBase="webapps" startStopThreads="2"/> …

    升级到5.6.1及以上版本

    在版本5.6.1中，对Artifactory中嵌入的Tomcat版本进行了升级。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase为每一个Tomcat连接器在server.xml文件中，如下例所示:

    <连接器端口="8081" sendReasonPhrase="true"/>

    升级至5.7.0及以上版本

    从版本5.7.0开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

    <连接器端口="8040" sendReasonPhrase="true" maxThreads="50"/>
  7. 如果您将Artifactory安装为服务，那么现在需要运行该服务

    1. 对于Linux服务，浏览到美元ARTIFACTORY_HOME / bin并执行以下命令作为根：$ARTIFACTORY_HOME/bin/installService.sh [USER [GROUP]]

    2. 对于Windows服务，浏览到%ARTIFACTORY_HOME%\bin。首先运行卸载服务uninstallService.bat，然后运行重新安装服务installService.bat．您现在可以通过Windows UI或中所述的方式运行服务运行Artifactory．

Debian安装

  1. 以根用户身份登录(或使用Sudo su -）.

  2. 执行如下命令:

    DPKG -i $jfrog-artifactory--5.y.z.deb
管理配置文件

升级Debian安装升级过程将覆盖以下配置文件集:

  • system.properties
  • config . xml
  • 默认的
  • logback.xml
  • mimetypes.xml
  • 所有档案opt / jfrog / artifactory / misc
  • 所有档案opt / jfrog / artifactory / webapps

如果这些文件中的任何一个被修改，将自动创建一个备份文件，并在升级日志中通知。如果需要恢复配置更改，可以从创建的备份中恢复它们。

以ROOT身份运行Artifactory

如果您已经将Artifactory配置为Tomcat中的ROOT应用程序，在继续操作之前，您需要遵循中描述的步骤这篇知识库文章．

特定版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级至5.4.0及以上版本

从5.4.0版本开始，Artifactory对访问令牌的管理被移动到一个单独的服务Access，作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您使用的是以前安装的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

．.．<引擎名称="Catalina" defaultHost="localhost"> <主机名称="localhost" appBase="webapps" startStopThreads="2"/> …

升级到5.6.1及以上版本

在版本5.6.1中，对Artifactory中嵌入的Tomcat版本进行了升级。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase为每一个Tomcat连接器在server.xml文件中，如下例所示:

<连接器端口="8081" sendReasonPhrase="true"/>

升级至5.7.0及以上版本

从版本5.7.0开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

<连接器端口="8040" sendReasonPhrase="true" maxThreads="50"/>

码头工人安装

为了在不同版本之间保持数据和配置，在升级Artifactory Docker映像时，您需要使用下面所述的外部挂载卷管理数据持久性．

要升级Artifactory Docker镜像，请遵循以下步骤:

  1. 停止电流容器
  2. 使用相同的数据和配置启动一个新版本的容器
  3. 移除旧容器

下面的示例展示了将Artifactory从v5.0.0升级到v5.1.0的过程。

$ #停止当前运行的容器$ docker Stop artifactory-5.0.0 $ #从新版本镜像中启动一个新容器$ docker run -d——name artifactory-5.1.0——volume -from=artifactory-5.0.0 -p 8081:8081 docker.bintray.io/jfrog/artifactory-pro:5.1.0 $ #删除旧容器$ docker rm artifactory-5.0.0

一旦这些命令成功完成，您就可以使用从旧版本中删除的数据和配置运行新版本(在上面的示例中为5.1.0)。

以ROOT身份运行Artifactory

如果您已经将Artifactory配置为Tomcat中的ROOT应用程序，您需要按照这篇知识库文章．

特定版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级至5.4.0及以上版本

从5.4.0版本开始，Artifactory对访问令牌的管理被移动到一个单独的服务Access，作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您使用的是以前安装的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

．.．<引擎名称="Catalina" defaultHost="localhost"> <主机名称="localhost" appBase="webapps" startStopThreads="2"/> …

升级到5.6.1及以上版本

在版本5.6.1中，对Artifactory中嵌入的Tomcat版本进行了升级。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase为每一个Tomcat连接器在server.xml文件中，如下例所示:

<连接器端口="8081" sendReasonPhrase="true"/>

升级至5.7.0及以上版本

从版本5.7.0开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

<连接器端口="8040" sendReasonPhrase="true" maxThreads="50"/>

RPM的安装

确保您是从v3.6或更高版本升级

当作为RPM安装运行时，只能升级到v5。如果您的当前版本是3.6或以上。如有必要，请先将当前版本升级到3.6，然后再升级到v5。x。

如果您试图升级到3.6以下的版本，使用rpm——力你最终可能会删除你所有的数据。

  1. 下载Artifactory Pro RPM Installer。最新版本可从JFrog Artifactory Pro下载页面．以前的版本可以从JFrog Bintray．
  2. 以根用户身份登录(或使用Sudo su -）.

  3. 执行如下命令:

    rpm -U jfrog-artifactory-pro . 5.y.z.rpm

    从Artifactory OSS切换到Pro

    如果只是从Artifactory OSS切换到版本号相同的Pro，则需要在命令中添加——force——nodeps，如下所示:
    rpm -U jfrog-artifactory-pro . 5.y.z.rpm--force --nodeps

在升级RPM安装期间，可能会备份不同的文件，其中备份文件附加了.rpmorig或者一个.rpmnew扩展。

一个.rpmorig扩展名意味着安装中的原始文件(在执行升级之前存在的文件)在升级过程中被替换之前已进行了备份。

一个.rpmnew扩展名意味着安装中的原始文件是不在升级中被替换，相反，备份了具有相同文件名的新文件。

无论哪种情况，Artifactory都会显示如下消息:

警告:“/etc/opt/jfrog/artifactory/default”保存为“/etc/opt/jfrog/artifactory/default.rpmorig”

在这种情况下，我们建议将升级完成后安装的文件与备份的文件进行比较，以确定哪个最适合您的需求，并在最终设置中使用该文件。

如果您做了任何更改，您可能需要重新启动Artifactory以应用更改。

使用YUM升级

从版本3升级Artifactory的简单方法。X或4。将YUM和Bintray Artifactory存储库一起使用。下面的代码片段显示了如何根据当前版本是低于3.6，还是3.6及以上版本来执行此操作。

升级Artifactory HA集群?

如果您正在升级一个Artifactory HA集群，并且您正在运行一个比version旧的版本5.4.6，你应复习有关的说明升级企业HA集群升级之前。

Curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpm。Repo && sudo mv bintray-jfrog-artifactory-pro-rpm。回购/etc/yum.repos.安装jfrog-artifactory-pro . 5.y.z

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-pro
Curl https://bintray.com/jfrog/artifactory-pro-rpms/rpm -o bintray-jfrog-artifactory-pro-rpm。Repo && sudo mv bintray-jfrog-artifactory-pro-rpm。回购/etc/yum.repos.安装jfrog-artifactory-pro . 5.y.z

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-pro

以ROOT身份运行Artifactory

如果您已经将Artifactory配置为Tomcat中的ROOT应用程序，在继续操作之前，您需要遵循中描述的步骤这篇知识库文章．

特定版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级至5.4.0及以上版本

从5.4.0版本开始，Artifactory对访问令牌的管理被移动到一个单独的服务Access，作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您使用的是以前安装的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

．.．<引擎名称="Catalina" defaultHost="localhost"> <主机名称="localhost" appBase="webapps" startStopThreads="2"/> …

升级到5.6.1及以上版本

在版本5.6.1中，对Artifactory中嵌入的Tomcat版本进行了升级。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase为每一个Tomcat连接器在server.xml文件中，如下例所示:

<连接器端口="8081" sendReasonPhrase="true"/>

升级至5.7.0及以上版本

从版本5.7.0开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

<连接器端口="8040" sendReasonPhrase="true" maxThreads="50"/>

RPM网管安装

  1. 下载Artifactory OSS RPM安装程序。最新版本可从JFrog开源页面．以前的版本可以从JFrog Bintray．
  2. 以根用户身份登录(或使用Sudo su -）.

  3. 执行如下命令:

    rpm -U jfrog-artifactory-oss-5.y.z.rpm

在升级RPM安装期间，可能会备份不同的文件，其中备份文件附加了.rpmorig或者一个.rpmnew扩展。

一个.rpmorig扩展名意味着安装中的原始文件(在执行升级之前存在的文件)在升级过程中被替换之前已进行了备份。

一个.rpmnew扩展名意味着安装中的原始文件是不在升级中被替换，相反，备份了具有相同文件名的新文件。

无论哪种情况，Artifactory都会显示如下消息:

警告:“/etc/opt/jfrog/artifactory/default”保存为“/etc/opt/jfrog/artifactory/default.rpmorig”

在这种情况下，我们建议将升级完成后安装的文件与备份的文件进行比较，以确定哪个最适合您的需求，并在最终设置中使用该文件。

如果您做了任何更改，您可能需要重新启动Artifactory以应用更改。

使用YUM升级

从版本3升级Artifactory的简单方法。X或4。将YUM和Bintray Artifactory存储库一起使用。下面的代码片段显示了如何根据当前版本是低于3.6，还是3.6及以上版本来执行此操作。

Curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpms。回购&& sudo mv bintray-jfrog-artifactory-rpm。回购/etc/yum.repos.安装jfrog-artifactory-oss-5.x.y

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-oss
Curl https://bintray.com/jfrog/artifactory-rpms/rpm -o bintray-jfrog-artifactory-rpms。回购&& sudo mv bintray-jfrog-artifactory-rpm。回购/etc/yum.repos.D / yum upgrade artifactory yum install jfrog-artifactory-oss-5.y.z

要安装最新版本的Artifactory，您可以运行:

Yum安装jfrog-artifactory-oss

以ROOT身份运行Artifactory

如果您已经将Artifactory配置为Tomcat中的ROOT应用程序，在继续操作之前，您需要遵循中描述的步骤这篇知识库文章．

特定版本的特殊说明

为了适应不同版本升级中Artifactory的内部更改，您需要根据目标升级版本执行或确保对Artifactory的server.xml进行某些更改。请注意，下面列出的更改是随着版本的进展而累积的。

升级至5.4.0及以上版本

从5.4.0版本开始，Artifactory对访问令牌的管理被移动到一个单独的服务Access，作为一个单独的web应用程序安装在与Artifactory相同的Tomcat下。这需要将Tomcat的server.xml配置为允许运行2个进程。如果您使用的是以前安装的server.xml文件，那么在返回该文件时，请确保将其配置为允许启动/停止线程如下所示(参见):

．.．<引擎名称="Catalina" defaultHost="localhost"> <主机名称="localhost" appBase="webapps" startStopThreads="2"/> …

升级到5.6.1及以上版本

在版本5.6.1中，对Artifactory中嵌入的Tomcat版本进行了升级。为了适应这次升级后的YUM客户端，一个新的属性，sendReasonPhrase为每一个Tomcat连接器在server.xml文件中，如下例所示:

<连接器端口="8081" sendReasonPhrase="true"/>

升级至5.7.0及以上版本

从版本5.7.0开始，Artifactory直接通过端口将请求路由到其Access服务，这需要对server.xml文件进行以下修改

<连接器端口="8040" sendReasonPhrase="true" maxThreads="50"/>

使用SHA256校验和

从5.5版开始，Artifactory原生支持SHA-256。上传的新工件将自动计算其SHA-256校验和，但是，在升级之前已经托管在Artifactory中的工件将不会在数据库中有其SHA-256校验和。

为了在升级到5.5及以上版本后充分利用Artifactory的SHA-256功能，您需要运行一个迁移Artifactory数据库的进程，以确保每个工件的记录都包含其SHA-256校验和。有关Artifactory SHA-256支持的完整细节以及如何迁移数据库的说明，请参阅sha - 256支持．

从OSS升级到Pro

即使您只是将当前版本的Artifactory OSS切换到相同版本的Artifactory Pro，也请遵循下面的说明升级到最新版本根据您的安装类型(ZIP, RPM, Debian或Docker)。

添加您的许可证

后升级到最新版本，请确保您为Artifactory安装提供了许可证。只需创建一个名为artifactory.lic,复制您从JFrog收到的许可证，并将其粘贴到artifactory.licLicense文件，并将其放在$ ARTIFACTORY_HOME /等文件夹中。

从版本3.x升级

单一包类型存储库

单包类型

使用版本4。X或5。X，您需要确保您的存储库只包含具有相同包类型的工件。可以在。上找到检查这一点的脚本JFrog GitHub．

在版本3中。Artifactory支持多种包类型的存储库。您可以将不同类型的包上传到同一个存储库，Artifactory将为这些包计算元数据。尽管如此，维护每个存储库的单一包类型始终是优化性能并在系统中产生更有组织的存储库结构的最佳实践。从版本4.0开始，您需要指定单个包类型用于创建存储库时。Artifactory只会为工件计算元数据，并被相应的客户端软件所识别包类型为该存储库指定。(Artifactory不会阻止您上传不同类型的包，但是，它不会为这些包计算元数据，并且不同包类型的客户端不会识别存储库)。

如果您当前拥有配置为支持多种包类型的存储库，那么您需要将它们迁移到单一包类型存储库，但是，您可以在运行升级过程之前或之后这样做。

若要在升级前迁移存储库，请参阅迁移到单一包类型存储库．

如果您希望在升级后迁移存储库，或者已经升级，请参考修复多个包类型存储库．

通用存储库

在版本4中。X和5。X，如果您需要一个存储库来保存几种不同类型的包，您可以将其包类型指定为通用的。Artifactory不计算通用存储库的元数据，实际上，它们的行为就像存储包的简单文件系统。

迁移到单一包类型存储库

将具有多个包类型的存储库迁移到单一包类型的存储库，请执行以下步骤:

  1. 更改原始存储库的配置，使其只支持一种包类型。
  2. 对于所需的每一个额外的包类型，使用相应的包类型创建一个新的存储库
  3. 使用REST API或UI将包从原始存储库移动到创建的新存储库，直到所有存储库只包含相同类型的包。
    在使用REST API时，请确保包含suppressLayouts = 1查询参数，以防止工件路径转换。

Npm存储库

如果将数据移动到Npm存储库，请确保包含。npm文件夹中。这将保留使用npm客户端部署包时可能已经存储的额外信息。

修复多个包类型存储库

如果升级时没有迁移到单一包类型的存储库，那么Artifactory将正常启动，但是，包含多个包类型的存储库将正常启动随机从原始存储库中指定一个包类型，并将相应的消息输出到美元ARTIFACTORY_HOME /日志/ artifactory.log文件。

例如，如果lib -release-local包含三种不同的包类型:RubyGems, Npm和NuGet，升级后，你的美元ARTIFACTORY_HOME /日志/ artifactory.log可能包含与以下内容类似的信息:

2015-06-28 10:10:47,656 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:42)将存储库转换为单个包类型2015-06-28 10:10:47,663 [art-init] [ERROR] (o.a.v.c.v.SingleRepoTypeConverter:155)禁用包'Gems'回购'lib -release-local'，因为只允许一种打包类型!2015-06-28 10:10:47,664 [art-init] [ERROR] (o.a.v.c.v.s singlerepotypeconverter:155)禁用包'Npm'回购'lib -release-local'，因为只允许一种打包类型!2015-06-28 10:10:47,664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'lib -release-local'到NuGet类型2015-06-28 10:10:47,664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'lib - snappolocal '到Maven类型2015-06-28 10:10:47,664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'plugins-release-local'到Maven类型2015-06-28 10:10:47,664 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'plugin -snapshot-local'到Maven类型2015-06-28 10:10:47,665 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'ext-release-local'到Maven类型2015-06-28 10:10:47,665 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'ext-snapshot-local'到Maven类型2015-06-28 10:10:47,666 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'jcenter'到Maven类型2015-06-28 10:10:47,666 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)(o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库' remo- repo'到Maven类型2015-06-28 10:10:47,668 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'lib -snapshot'到Maven类型2015-06-28 10:10:47,668 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:128)设置存储库'p2'到p2类型2015-06-28 10:10:47,668 [art-init] [INFO] (o.a.v.c.v.SingleRepoTypeConverter:56)完成转换存储库到单一包类型

在本例中，Artifactory设置了包类型NuGet。

要修复此情况，可以简单地执行中所述的步骤迁移到单一包类型存储库，或升级后使用packageType实用程序在JFrog Github上找到4。x迁移．

从v3.0以下的任何版本升级

要从3.0之前的版本升级，首先需要升级到3.9版本。X，如在Artifactory 3文档中升级Artifactory．

临时版本

根据您的当前版本，升级到版本3.9。X可能要求您首先升级到临时版本。

下调Artifactory

降级Artifactory的过程可能因所使用的版本而异。详情请联系JFrog支持．