TURNKEYGNU / LINUX
中文

准备使用服务器

GitLab

自主机 Git 管理 & DevOps 工具链

Developer toolsContinuous IntegrationTestingRevision controlGitMonitoringNginxRubyWikiIssue trackingProject management
GitLab - 仓库GitLab - 仓库 GitLab - 前页GitLab - 前页 GitLab - 行政区域GitLab - 行政区域

吉特拉布语Name 是一个用于软件开发整个生命周期的单一应用程序。从项目规划和源代码管理到CI/CD、监测和安全。 GitLab 提供了基于 Git 的版本控制, 并用一个完整的 DevOps 工具链包装。 有点像 GitHub, 但更多 。

此 应用设备 包含所有标准特性 。 TurnKey Core 密码,此外,

  • GitLab 配置 :

    • GitLab、RubyGems、PostgreSQL、Nginx和从上游安装的所有其他所需组件 总括软件包.

      安全说明: GitLab 的更新可能需要监督,因此 ARE NOT 配置为自动安装。 更新 GitLab 时, 请见下文。 And/ or see GitLab 文档.

    • 设置 GitLab 管理员用户密码( root) 和首选项( 召集, 安全) 的电子邮件 。

    • 设定 GitLab 域名为第一个启动( convenence) 服务 。

    • 通过 Confconsole 插件(在"Lets Encrypt"下)启用 GitLab Omnibus 内置 Let's Encrypt 证书 。

  • 包括后缀 MTA(绑定到localhost)发送电子邮件(如密码恢复),同时包括webmin后缀模块,以方便.

监督手册 GitLab 更新

检查已安装的和符合条件的版本而不修改 应用设备 :

gitlab-update --check

更新前请查阅 GitLab 升级路径 和特定释放 GitLab 文档. GitLab 需要中间升级停止。备份 应用设备,然后明确安装下一个合格版本:

apt update
apt install gitlab-ce=<version>

重复应用程序接受检查,然后再进行另一要求的停止。 缓存 迈迪森 gi-ce 编辑 GitLab 发布博客.

APT 报告过期的仓库密钥, 或者 NO_PUBKEY 密码,跟着 存储器键旋转程序。它保存每个存储器 签字 限制并验证了GitLab的完整公布指纹.

全权证书 (密码设定在第一靴子)

  • Webmin, SSH: username 根号

  • GitLab: 用户名 根号

行政使用详情和登录

没有默认密码:出于安全原因,没有默认密码。所有密码都设置在 系统初始化 时间

忽略 SSL 浏览器警告:浏览器不喜欢自签名的 SSL 证书, 但这是唯一可以自动生成的证书。 如果您配置了域, 然后通过 Confconsole 高级菜单,可以免费生成 让我们输入 SSL/ TLS 证书.

网页 - 将浏览器对准其中之一:

  1. http://12.34.56.789/ 密码 - 没有加密,所以没有浏览器警告
  2. https://12.34.56.789/ 密码 - 加密后自签SSL证书

注:一些 应用设备 自动直接 https 。

gitlab 的用户名:

登录为用户名 根号

OS 系统管理用户名:

登录为 根号 除外 AWS市场 使用用户名 管理员.

  1. 指向浏览器 :
  2. 登录 SSH 客户端 :
    ssh root@12.34.56.789

    AWS市场的特殊案例 :

    ssh admin@12.34.56.789

* 将12.34.56.789改为有效的IP或主机名称。

文档

v15.2+: 总括包

截至v15.2,TurnKey GitLab 应用设备包括了通过该机安装的GitLab. 总括软件包。TurnKey GitLab的上一个版本提供了 源安装不幸的是,这一改变对现有用户来说有点痛苦,因为它需要一种 手动迁移 从源到源. 预计这种短期疼痛会很好,而且真正被GitLab的维护/更新更方便地前进(既有终端用户,也有TurnKey)所抵消. 改变是在用户大量反馈后开始的,一些伟大的对话权衡利弊,加上持续维持源安装的痛苦 应用设备 (英语).

从以前的 TurnKey GitLab 实例中移走

不幸的是,没有简单的方法可以从GitLab的源安装转移到Omnibus的GitLab的安装上. 它需要稍微在周围进行调色,包括后端 DB 从MySQL DB后端(如TurnKey v15.1和之前使用)到PostgreSQL后端(如Omnibus提供)的迁移. 安装于 TurnKey v15.2 及以后).

报告主要详细内容载于本报告。 GitLab 文档。理想的做法是,将您的数据迁移到一个手动安装的 Omnibus 上,然后 手动生成 GitLab 备份。然后可以将您创建的备份加上您的 /etc/gitlab 目录(或至少您的 gitlab-secrets.json 文件) , 转到新的 吉特拉布语Name 服务器。将 /etc 文件放在相关位置,并 恢复备份 和GitLab文件一样。

值得注意的是,如果你有一个非常古老的GitLab版本,你可能需要先做一些源代码更新。 论坛上的线程,其中用户从GitLab v5.0.2(TurnKey GitLab v13.0)升级到当前GitLab(在撰写时为v11.x). 如果你也需要做这样的事,那么希望这个线程会有用。如果你需要一些支持,请随意。 启动新线程 (需要登录 - 如果您没有 TurnKey 论坛用户账户, 请访问 注册 ：国家

由于备份过程的限制和变化,在创建备份并将数据移到您的新程序之前,最好至少更新到 GitLab v9.3.0 。 服务器(尽管在此之前应该可以迁移到您旧服务器上的Omnibus)。 请注意,备份只有在进入/从完全相同的版本GitLab. I.e.时才有效。 相同的安装方法(源代码或Omnibus),版本编号和发布通道(Enterprise Edition aka "ee";或 Community Edition aka "ce"). 一旦您迁移到 Omnibus 并且正在 v9. 3 或 伟大的, 您可以迁移数据, 并在需要时降低 GitLab 版本的级别 。 下调 TurnKey 上的 GitLab 版本如下所示: 手动还原全局 节。

FWIW,从非TurnKey GitLab服务器迁移到TurnKey GITLab 应用设备(v15.2+)的过程将基本上与从TurnKey服务器迁移到TurnKey QQ v15.1的过程相同.

TurnKey GitLab and TKLBAM

恢复先前版本的TurnKey(XXv15.1)

不幸的是,在v15.2之前,GitLab 应用设备的TKLBAM备份(即. 包含从源装入的GitLab的应用设备)无法自动恢复到TurnKey GitLab v15.2+使用TKLBAM. 如上文关于“从“从“到”的一节所讨论的那样,必须首先手动迁移到“从“到”的“从“到”的”的“从“到”的”的”“从“到”的”的“从“到”的”的”“从“到”的”“从“到”的”的”“从“到”的”“从“到”的”的”“从“到”的”的”“从“到”的”的”“从“到”的”的”“从“到”的”的”“从”到”的”的“从”到”的”“从“到”的”的“从”到”的“从”到”的“从“从”到”的“从”到”的“从”到”的“从“到”的“从”的”的“从“到”的”“从“到”的”“从“到”的“从“到”的”的“到”的“从”“到”的”“到“到”的”“的“从”“的”“到“的” 人工迁移.

手动恢复 Omnibus 备份

要恢复一个 GitLab 备份, 您必须精确匹配该备份来自的 GitLab 版本, 与您正在恢复的版本 。 由于担心可能出现的问题,最好用人工操作。 TKLBAM确实有 实验 支持尝试自动这样做,如果你想尝试,请阅读以下关于 自动磁像版本匹配。如果你想继续手动恢复(建议),请阅读。

实验:自动磁场版本匹配