【问题标题】:Redundance in gitlab runnersgitlab 运行器中的冗余
【发布时间】:2021-10-13 23:49:42
【问题描述】:

我想在我的 GitLab 运行器中实现冗余。

在创建新服务器之前,我正在尝试使用本地计算机。

我的存储库上的当前设置:

  • 工作运行器(来自服务器)
  • 非工作运行器(来自本地计算机)

我希望 GitLab 在所选的跑步者不起作用时选择另一个跑步者。

问题是 GitLab 正在选择非工作运行器,并且在没有尝试与其他运行器一起运行的情况下使管道失败。

我怎样才能使它工作?

添加了两个跑步者:

但由于选择了本地运行器(不工作),管道失败:

【问题讨论】:

    标签: gitlab gitlab-ci gitlab-ci-runner runner


    【解决方案1】:

    这是一个有趣的边缘案例,因为 runner 进程本身仍然是健康的,但是在运行作业时出现了一些问题。 runner 进程在检索到作业并尝试运行它之前不会知道发生这种情况,因此它将继续尝试运行作业,并一直失败。

    由于 Runner 进程和 Gitlab 都无法捕捉到这种边缘情况,我能看到的唯一选择是,当您看到由于这个原因而失败的作业时,请暂停项目中的 Runner(如您的屏幕截图中所示),或者如果您重新成为管理员(或可以询问管理员),为整个实例暂停它,假设您是自托管 Gitlab。这将阻止任何新作业在该 Runner 上运行,以便您解决问题。

    这将允许您在不同的主机上运行多个 Runner 进程(甚至通过指定单独的 config.toml 文件在同一主机上),这样您仍然可以获得冗余并加快您的管道。

    一些快速搜索显示导致此问题的常见问题是运行程序的主机磁盘空间不足,或者可能通过更新到最新版本来解决的 Docker 问题。确保 Gitlab 和运行程序是最新的可用版本也不会受到伤害。

    您的另一个选择是使用 Gitlab submit a new Issue 看看他们是否可以解决这个问题。理想的情况是,在运行器系统发生故障时,运行器应该变得不健康并且不再处理进一步的作业。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-12-16
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多