【问题标题】:How to determine if GitLab installation is Omnibus or via source?如何确定 GitLab 安装是 Omnibus 还是通过源?
【发布时间】:2017-03-04 04:06:10
【问题描述】:

我正在研究将 GitLab 从旧服务器迁移到新服务器的过程。我需要做的第一件事是确定 GitLab 位于哪个安装中(综合与源),但我无法确定。

这篇文章 (omnibus or source - can't decide which one to use for gitllab backup/restore) 提到在 GitLab 根文件夹 (/home/git/gitlab) 中寻找 .git 文件 - 我在那里没有看到 .git 文件。因此,根据该评论,安装是 Omnibus。

但是,看着这个帖子 (Checking of GitLab version),我无法运行:

sudo gitlab-rake gitlab:env:info(显示为 Omnibus 安装)

但我可以跑:

bundle exec rake gitlab:env:info RAILS_ENV=production(显示为源安装)

我看到了相互矛盾的答案。我怎样才能知道 GitLab 在哪个安装中?

无论如何,当我运行最后一个命令时,我会得到以下结果(如果有帮助的话):

系统信息 系统:Debian 7.10 当前用户:git 使用 RVM:否 红宝石版本:2.0.0p247 宝石版本:2.0.3 捆绑器版本:1.7.2 耙版本:10.1.0

GitLab 信息 版本:6.0.2 修订:10b0b8f 目录:/home/git/gitlab 数据库适配器:mysql2 网址:http://107.178.218.39 HTTP 克隆 URL:http://107.178.218.39/some-project.git SSH克隆网址:git@107.178.218.39:some-project.git 使用 LDAP:否 使用 Omniauth:否

GitLab 外壳 版本:1.7.0 存储库:/home/git/repositories/ 钩子:/home/git/gitlab-shell/hooks/ git:/usr/bin/git

【问题讨论】:

  • 我的猜测是,如果这个人没有克隆 git repo 来下载源代码,而是下载了一个 zip 文件,那么即使它不是OmniBus 安装……想想为什么 .git 策略可能不可靠。
  • 嗯,我不确定。不幸的是,设置一切的人已经不在了,所以这让事情在这方面有点挑战。

标签: gitlab gitlab-omnibus


【解决方案1】:

您应该检查此文件是否可用:

/etc/gitlab/gitlab.rb

如果不是,则从源代码安装。我的建议是将您的安装更改为综合安装,这样会更容易升级。

阅读本文了解有关升级到综合安装的更多信息:https://docs.gitlab.com/omnibus/update/README.html#upgrading-from-a-non-omnibus-installation-to-an-omnibus-installation

更新 1

注意如果 MySQL 用作数据库,您必须进行转换,请参阅文档https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/mysql_to_postgresql.md

要从源升级安装,您有 2 个选项:

确保您有一个与您当前的 GitLab 版本相匹配的 omnibus-gitlab 包。 (如果可能的话,我会最后一次从源代码升级)

1.在同一台服务器上安装 gitlab 和综合。

开始之前,请从服务器创建快照,以确保您始终可以返回到工作点。还要确保关闭 gitlab。

您应该使用综合选项安装 gitlab:

sudo apt-get install curl openssh-server ca-certificates postfix
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash sudo apt-get install gitlab-ce

综合源安装可以同时安装在服务器上。如果出现问题,您可以随时更改回源安装。

然后按照文档中的说明进行操作:https://docs.gitlab.com/omnibus/update/README.html#upgrading-from-non-omnibus-postgresql-to-an-omnibus-installation-in-place

2。通过备份安装gitlab。

当您使用备份时,您甚至可以将 gitlab 安装转移到新服务器。我用过这个方法,很简单。

在进行备份之前,请关闭 gitlab,以确保备份和还原过程之间没有任何变化

首先,请进行备份:

sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

另请参阅documenation 此报道以了解更多信息。

之后,您可以将备份移动到新的 gitlab 服务器或稍后使用它来导入它。

在综合安装中导入它(简而言之,但请阅读documentation):

sudo cp 1393513186_gitlab_backup.tar /var/opt/gitlab/backups/
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
# Verify
sudo gitlab-ctl status

sudo gitlab-rake gitlab:backup:restore BACKUP=1393513186

sudo gitlab-ctl start
sudo gitlab-rake gitlab:check SANITIZE=true

既然你说它是关于一个现场环境。您可以执行以下操作,设置一个小型服务器/或在您的本地计算机上进行升级过程,这样您就可以放心了。之后,您可以在实时环境中执行相同操作。

【讨论】:

  • /etc/gitlab 不存在。我猜这意味着它是从源代码安装的?
  • 现有设置/配置/存储/等是否有任何复杂性?升级到综合安装?这是一个活生生的环境,如果可以避免的话,宁愿不要以这种方式破坏任何东西。
  • 感谢您的详细回复。听起来我有点头疼,特别是因为我们的 GitLab 实例正在运行 MySQL。我希望不必触及数据库。这是因为omnibus 只适用于PostgreSQL吗?
  • @DexterJ。你可以使用mysql,但只有当你有enterprice,见gitlab.com/gitlab-org/omnibus-gitlab/blob/master/…我必须说转换并不难,文档很清楚,从mysql到postgresql很容易转换。我花了大约 20 分钟来修复它。我建议您在本地计算机上尝试一下,看看是否可以正常工作。
  • 你可以从 gitlab 得到一个报价它自己 about.gitlab.com/consultancy 我相信他们可以帮助你,但我不知道价格是多少。
猜你喜欢
  • 1970-01-01
  • 2014-06-24
  • 1970-01-01
  • 2013-01-03
  • 1970-01-01
  • 2011-07-03
  • 1970-01-01
  • 2020-11-05
  • 2019-05-29
相关资源
最近更新 更多