GitLab 11.5 将支持 Elasticsearch 6,放弃支持 5.5 及更低版本

局长
 局长
发布于 2018年11月19日
收藏 5

近日,GitLab 发表的一篇博客表示,在 Gitlab 11.5(将于2018年11月22日发布)中,GitLab 集成的 Elasticsearch 将支持 Elasticsearch 6,并且将不再支持 5.5 或更低版本。请在升级到 GitLab 11.5 之前立即制定将 Elasticsearch 升级到 5.6 或 6.x 版的计划。升级 GitLab 后,还需要执行 reindex,因为支持这些 Elasticsearch 版本所需的更改与以前版本的索引不兼容。

总的来说,从 11.5 开始,GitLab 只支持:

  • Elasticsearch 5.6

  • Elasticsearch 6.x

GitLab 使用 Elasticsearch 进行 高级全局搜索 和 高级语法搜索

至于为何做出这个决定,主要是使用 Elasticsearch 6 与当前的索引存在不兼容的变化。详情请查看发布公告

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:GitLab 11.5 将支持 Elasticsearch 6,放弃支持 5.5 及更低版本
加载中

精彩评论

Feng_Yu
Feng_Yu

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢
是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

最新评论(14

Feng_Yu
Feng_Yu

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。

引用来自“Feng_Yu”的评论

为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?

引用来自“宿命”的评论

首先是你先用过再说,几个G的docker? 1.3G而已,docker的主要作用不应该被轻重所掩盖。 1,依赖隔离,2,资源隔离,3,方便运维。我从内网拉一个镜像来,不过几秒钟而已。。

引用来自“Feng_Yu”的评论

我用docker的时间很久了,2013年就开始用了,还在公司推行过,另外我就是做运维出身,docker的特性和优劣我清楚的很。gitlab最早也是我在公司推行过换掉以前的gerrit的,和jenkins的集成我也搞过。我最早维护和部署gitlab的时候就是用的docker。后来废弃掉了。原因我也说过了,第一容量太大,每次更新上GB的玩意,远不如omnibus的仓库快捷方便,而且清华大学有镜像站,大大减少了维护量。其次持久化的需求。docker的持久化功能一直做的不够人性化,这方面严重限制了docker的推广。最早我用docker跑mysql,后来因为维护持久化部分内容实在太麻烦了,远不如直接apt install方便,果断放弃了。我觉得国内把docker神话过头了,一切为了向docker靠拢显得高大上,完全本末倒置。我觉得用官方仓库软件包安装部署更加规范化与更加方便处理备份内容和数据,出现故障更容易维护。就这样。一味鼓吹docker没什么意思。

引用来自“宿命”的评论

理解,如果你接触的比较早,确实会有这样的阵痛。但现在,gitlab的docker镜像封装的很好,所有需要持久化的内容都在一起,映射出来即可。另外比较重要的一点,gitlab依赖的一些环境和组件,我不想让他们污染我的环境,也不想造成什么冲突。。所以docker的意义就很明显了。既然你提了tuna的镜像,那么几百兆和一千几百兆,在阿里云的加速器面前区别也不大。

引用来自“宿命”的评论

我并不是要说哪种方式一定就更好,既然存在肯定合理,各有各的用处。只是为docekr打个不平罢了。
我没说docker一无是处啊,我自己给用户交付的部署用的还是docker-compose编排的呢,官方维护的一些镜像还有我贡献的Dockerfile呢(比如apache,redmine等等)。我最初也是用docker跑mysql,以及gitlab,但我没有觉得docker给我带来维护管理上的简便性,反而带来了更多的麻烦,远不如直接apt安装这些软件方便。比如gitlab的定时备份,你可能会说docker支持exec,但我觉得这样看的特别怪异。mysql更不用说了,修改配置,备份,集群搭建都比直接软件包安装更费事,更加难以维护。另外gitlab ominibus打包版本隔离了系统环境,你不用担心污染你的环境,它的依赖都放在/var/opt下了,自己用自己的,并且监听的基本都是unix domian socket,不会占用系统端口。唯一会占用端口的服务就是nginx,你也可以修改gitlab.rb文件让nginx只监听unix domain socket,你用系统的nginx做反向代理即可。而且我的gitlab放在独立的一台服务器上,包管理都是现成的,我不需要为了gitlab单独再安装一个docker。
宿命
宿命

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。

引用来自“Feng_Yu”的评论

为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?

引用来自“宿命”的评论

首先是你先用过再说,几个G的docker? 1.3G而已,docker的主要作用不应该被轻重所掩盖。 1,依赖隔离,2,资源隔离,3,方便运维。我从内网拉一个镜像来,不过几秒钟而已。。

引用来自“Feng_Yu”的评论

我用docker的时间很久了,2013年就开始用了,还在公司推行过,另外我就是做运维出身,docker的特性和优劣我清楚的很。gitlab最早也是我在公司推行过换掉以前的gerrit的,和jenkins的集成我也搞过。我最早维护和部署gitlab的时候就是用的docker。后来废弃掉了。原因我也说过了,第一容量太大,每次更新上GB的玩意,远不如omnibus的仓库快捷方便,而且清华大学有镜像站,大大减少了维护量。其次持久化的需求。docker的持久化功能一直做的不够人性化,这方面严重限制了docker的推广。最早我用docker跑mysql,后来因为维护持久化部分内容实在太麻烦了,远不如直接apt install方便,果断放弃了。我觉得国内把docker神话过头了,一切为了向docker靠拢显得高大上,完全本末倒置。我觉得用官方仓库软件包安装部署更加规范化与更加方便处理备份内容和数据,出现故障更容易维护。就这样。一味鼓吹docker没什么意思。

引用来自“宿命”的评论

理解,如果你接触的比较早,确实会有这样的阵痛。但现在,gitlab的docker镜像封装的很好,所有需要持久化的内容都在一起,映射出来即可。另外比较重要的一点,gitlab依赖的一些环境和组件,我不想让他们污染我的环境,也不想造成什么冲突。。所以docker的意义就很明显了。既然你提了tuna的镜像,那么几百兆和一千几百兆,在阿里云的加速器面前区别也不大。
我并不是要说哪种方式一定就更好,既然存在肯定合理,各有各的用处。只是为docekr打个不平罢了。
宿命
宿命

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。

引用来自“Feng_Yu”的评论

为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?

引用来自“宿命”的评论

首先是你先用过再说,几个G的docker? 1.3G而已,docker的主要作用不应该被轻重所掩盖。 1,依赖隔离,2,资源隔离,3,方便运维。我从内网拉一个镜像来,不过几秒钟而已。。

引用来自“Feng_Yu”的评论

我用docker的时间很久了,2013年就开始用了,还在公司推行过,另外我就是做运维出身,docker的特性和优劣我清楚的很。gitlab最早也是我在公司推行过换掉以前的gerrit的,和jenkins的集成我也搞过。我最早维护和部署gitlab的时候就是用的docker。后来废弃掉了。原因我也说过了,第一容量太大,每次更新上GB的玩意,远不如omnibus的仓库快捷方便,而且清华大学有镜像站,大大减少了维护量。其次持久化的需求。docker的持久化功能一直做的不够人性化,这方面严重限制了docker的推广。最早我用docker跑mysql,后来因为维护持久化部分内容实在太麻烦了,远不如直接apt install方便,果断放弃了。我觉得国内把docker神话过头了,一切为了向docker靠拢显得高大上,完全本末倒置。我觉得用官方仓库软件包安装部署更加规范化与更加方便处理备份内容和数据,出现故障更容易维护。就这样。一味鼓吹docker没什么意思。
理解,如果你接触的比较早,确实会有这样的阵痛。但现在,gitlab的docker镜像封装的很好,所有需要持久化的内容都在一起,映射出来即可。另外比较重要的一点,gitlab依赖的一些环境和组件,我不想让他们污染我的环境,也不想造成什么冲突。。所以docker的意义就很明显了。既然你提了tuna的镜像,那么几百兆和一千几百兆,在阿里云的加速器面前区别也不大。
Feng_Yu
Feng_Yu

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。

引用来自“Feng_Yu”的评论

为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?

引用来自“宿命”的评论

首先是你先用过再说,几个G的docker? 1.3G而已,docker的主要作用不应该被轻重所掩盖。 1,依赖隔离,2,资源隔离,3,方便运维。我从内网拉一个镜像来,不过几秒钟而已。。

引用来自“Feng_Yu”的评论

我用docker的时间很久了,2013年就开始用了,还在公司推行过,另外我就是做运维出身,docker的特性和优劣我清楚的很。gitlab最早也是我在公司推行过换掉以前的gerrit的,和jenkins的集成我也搞过。我最早维护和部署gitlab的时候就是用的docker。后来废弃掉了。原因我也说过了,第一容量太大,每次更新上GB的玩意,远不如omnibus的仓库快捷方便,而且清华大学有镜像站,大大减少了维护量。其次持久化的需求。docker的持久化功能一直做的不够人性化,这方面严重限制了docker的推广。最早我用docker跑mysql,后来因为维护持久化部分内容实在太麻烦了,远不如直接apt install方便,果断放弃了。我觉得国内把docker神话过头了,一切为了向docker靠拢显得高大上,完全本末倒置。我觉得用官方仓库软件包安装部署更加规范化与更加方便处理备份内容和数据,出现故障更容易维护。就这样。一味鼓吹docker没什么意思。
另外清华大学的gitlab镜像还是我申请提交的呢,你可以去看看清华大学镜像站的issue,还给官方递交过issue在主页上加入清华大学镜像站的链接。如果软件包部署没有docker方便我根本不会去浪费精力干这个事。
Feng_Yu
Feng_Yu

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。

引用来自“Feng_Yu”的评论

为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?

引用来自“宿命”的评论

首先是你先用过再说,几个G的docker? 1.3G而已,docker的主要作用不应该被轻重所掩盖。 1,依赖隔离,2,资源隔离,3,方便运维。我从内网拉一个镜像来,不过几秒钟而已。。
我用docker的时间很久了,2013年就开始用了,还在公司推行过,另外我就是做运维出身,docker的特性和优劣我清楚的很。gitlab最早也是我在公司推行过换掉以前的gerrit的,和jenkins的集成我也搞过。我最早维护和部署gitlab的时候就是用的docker。后来废弃掉了。原因我也说过了,第一容量太大,每次更新上GB的玩意,远不如omnibus的仓库快捷方便,而且清华大学有镜像站,大大减少了维护量。其次持久化的需求。docker的持久化功能一直做的不够人性化,这方面严重限制了docker的推广。最早我用docker跑mysql,后来因为维护持久化部分内容实在太麻烦了,远不如直接apt install方便,果断放弃了。我觉得国内把docker神话过头了,一切为了向docker靠拢显得高大上,完全本末倒置。我觉得用官方仓库软件包安装部署更加规范化与更加方便处理备份内容和数据,出现故障更容易维护。就这样。一味鼓吹docker没什么意思。
宿命
宿命

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。

引用来自“Feng_Yu”的评论

为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?
首先是你先用过再说,几个G的docker? 1.3G而已,docker的主要作用不应该被轻重所掩盖。 1,依赖隔离,2,资源隔离,3,方便运维。我从内网拉一个镜像来,不过几秒钟而已。。
Feng_Yu
Feng_Yu

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。

引用来自“宿命”的评论

docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。
为docker而docker。我还是强调我说过的,docker不适合做重量级应用的容器化方案,更不是虚拟机。我不认为升降级每次都去pull一个好几个GB的image是一个好方案。放着现成的rpm/deb才300MB不用,非要去追求更大更慢的image,不是舍近求远吗?
宿命
宿命

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。
docker升级是无感的。。没觉得哪里煎熬了,等几分钟而已。。
paddy235
paddy235
这个是好消息
Rwing
Rwing

引用来自“霡霂”的评论

用rpm包安装的是不是ES自动升级呢

引用来自“Feng_Yu”的评论

是的,因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本,直接运行gitlab-cli相关的migrate子命令就行了

引用来自“Rwing”的评论

用docker呢?

引用来自“Feng_Yu”的评论

不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍,升级维护都是煎熬。我一直强调过,docker适合的是轻量的(只有一个进程运行),无状态的(不需要持久化的)服务部署,对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker,反而带来使用和维护的困难性。
"使用和维护的困难性"是指什么?我现在就是docker里跑的,只要docker run一下就好了呀,不然还要装一堆东西。。。。不太明白。。。
返回顶部
顶部