近日，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 与当前的索引存在不兼容的变化。详情请查看发布公告。
引用来自“霡霂”的评论
用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的镜像，那么几百兆和一千几百兆，在阿里云的加速器面前区别也不大。引用来自“霡霂”的评论
用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没什么意思。引用来自“霡霂”的评论
用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没什么意思。引用来自“霡霂”的评论
用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，方便运维。我从内网拉一个镜像来，不过几秒钟而已。。引用来自“霡霂”的评论
用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，不是舍近求远吗？引用来自“霡霂”的评论
用rpm包安装的是不是ES自动升级呢引用来自“Feng_Yu”的评论
是的，因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本，直接运行gitlab-cli相关的migrate子命令就行了引用来自“Rwing”的评论
用docker呢？引用来自“Feng_Yu”的评论
不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍，升级维护都是煎熬。我一直强调过，docker适合的是轻量的(只有一个进程运行)，无状态的(不需要持久化的)服务部署，对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker，反而带来使用和维护的困难性。引用来自“宿命”的评论
docker升级是无感的。。没觉得哪里煎熬了，等几分钟而已。。引用来自“霡霂”的评论
用rpm包安装的是不是ES自动升级呢引用来自“Feng_Yu”的评论
是的，因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本，直接运行gitlab-cli相关的migrate子命令就行了引用来自“Rwing”的评论
用docker呢？引用来自“Feng_Yu”的评论
不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍，升级维护都是煎熬。我一直强调过，docker适合的是轻量的(只有一个进程运行)，无状态的(不需要持久化的)服务部署，对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker，反而带来使用和维护的困难性。引用来自“霡霂”的评论
用rpm包安装的是不是ES自动升级呢引用来自“Feng_Yu”的评论
是的，因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本，直接运行gitlab-cli相关的migrate子命令就行了引用来自“Rwing”的评论
用docker呢？引用来自“Feng_Yu”的评论
不适合。光docker镜像的容量就比rpm/deb包的容量大了不止一倍，升级维护都是煎熬。我一直强调过，docker适合的是轻量的(只有一个进程运行)，无状态的(不需要持久化的)服务部署，对于gitlab,hadoop,jenkins这种依赖非常重的或者有状态的(比如数据库)应用不适合用docker，反而带来使用和维护的困难性。引用来自“霡霂”的评论
用rpm包安装的是不是ES自动升级呢引用来自“Feng_Yu”的评论
是的，因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本，直接运行gitlab-cli相关的migrate子命令就行了引用来自“Rwing”的评论
用docker呢？引用来自“霡霂”的评论
用rpm包安装的是不是ES自动升级呢引用来自“Feng_Yu”的评论
是的，因此非常推荐使用omnibus维护的仓库安装部署方案。这个方案内置有迁移脚本，直接运行gitlab-cli相关的migrate子命令就行了引用来自“霡霂”的评论
用rpm包安装的是不是ES自动升级呢