如何为 Gitlab 运行器启用通过 SSH 克隆? [英] How do I enable cloning over SSH for a Gitlab runner?

问题描述

我在我的 Windows Gitlab 运行器上通过 HTTP 克隆大型存储库时遇到了一些问题.我尝试了几种方法来进行浅克隆或禁用克隆压缩.还是没有运气.

通过 SSH 克隆相同的存储库作为一种临时解决方案非常有效，我想让它在我们的 Gitlab CI 流程中运行.

现在的问题是我不知道如何使用 SSH 作为 gitlab-multi-runner 的克隆方法.它似乎只是默认使用 HTTP，而我关于克隆的唯一选择是它是否会进行完整克隆或获取.

谁能解释我如何让克隆/获取通过 SSH 而不是 HTTP 在运行器上工作?

Gitlab 版本:GitLab 社区版 8.10.7

谢谢！

解决方案

作为 gitlab 的新手，我已经设法解决了这个问题，因为我还没有找到一个内置的方法来更改默认值克隆过程(尽管 这是最近关于如何完成的评论).

通过禁用自动克隆过程，您可以只需在 before_script 中编写您自己的克隆过程，即可有效地完全覆盖其行为.仅出于示例的目的，下面显示了如何为 HTTP 克隆完成此操作，但可以适用于 ssh 克隆(如果您尝试使用 HTTP 克隆，您应该使用内置克隆过程和 config.toml):

1. 创建一个名为gitlab-runner"的新用户；并生成他们的用户身份验证令牌以供以后使用(或者在您的情况下，您将生成 ssh 密钥).

2. 通过在您的项目或组设置中添加以下变量来禁用运行器的克隆过程:.../settings/ci_cd

   键:GIT_STRATEGY

   值:无

3. 在 before_script 中克隆你的 repo，例如:

<上一页>before_script:##清理工作目录- BUILD_DIR=/home/gitlab-runner/builds/$RUNNER_TOKEN/0- CLONE_DIR="$BUILD_DIR/$CI_PROJECT_PATH"- cd $BUILD_DIR-rm -rf $CLONE_DIR- mkdir -p $CLONE_DIR## 每次都克隆项目(效率低下，如果已经存在，请考虑执行 fetch 代替)- git clone http://gitlab-runner:$GITLABRUNNER_USER_AUTH_TOKEN@server:8888/${CI_PROJECT_PATH}.git $CLONE_DIR- cd $CLONE_DIR

注意:这里是我在第 2 步中也配置的相关变量，而不是在脚本中硬编码它们:

• RUNNER_TOKEN:Runner Token"；管理员跑步者"中列出的值您尝试运行的特定跑步者的菜单.
• GITLABRUNNER_USER_AUTH_TOKEN:这是您在步骤 1 中生成的身份验证令牌.

进一步阅读:

您可以通过发出 部署密钥.或者，如果访问任何项目的安全隐患是一个问题，部署令牌是具有更多安全控制的替代方案.为了比较，查看文档:

<块引用>

部署密钥可在不相关或不属于同一组的项目之间共享.部署令牌属于项目或组.

<块引用>

部署密钥是您需要在计算机上自己生成的 SSH 密钥.部署令牌由您的 GitLab 实例生成，并且仅提供给用户一次(在创建时).

<块引用>

只要注册并启用部署密钥，它就有效.部署令牌可能具有时间敏感性，因为您可以通过为其设置过期日期来控制其有效性.

<块引用>

您无法使用部署密钥登录注册表，或对其执行读/写操作，但使用部署令牌可以做到这一点.您需要一个 SSH 密钥对才能使用部署密钥，但不需要部署令牌.

I am having some trouble cloning large repositories over HTTP on my Windows Gitlab runner. I've tried several methods to do shallow clones or disable clone compression. Still no luck.

Cloning the same repository over SSH works great as a temporary solution and I would like to get this working on our Gitlab CI process.

The issue now stands where I have no idea how to use SSH as a clone method for the gitlab-multi-runner. It just seems to use HTTP as a default, and my only options regarding cloning is whether it will do a full clone or a fetch.

Can someone explain how I could get that clone/fetch to work on a runner over SSH instead of HTTP?

Gitlab Version: GitLab Community Edition 8.10.7

Thanks!

解决方案

As a newcomer to gitlab, I've managed to hack a workaround to this issue as I also haven't found a built-in way to change the default cloning process (although here is a recent comment about how it can be done).

By disabling the automatic cloning process, you can effectively override its behavior completely by simply writing your own cloning process in a before_script. Only for the purposes of example does the below show how to accomplish this for HTTP cloning but could be adapted for ssh cloning (if you're trying to use HTTP cloning you should use the built-in cloning process and the config.toml):

1. Create a new user called "gitlab-runner" and generate their user auth token for later use (or in your case, you would generate ssh keys).

2. Disable cloning process for runner by adding the following variable in either your project or group settings: .../settings/ci_cd

   key: GIT_STRATEGY

   value: none

3. Clone your repo in a before_script such as:

before_script:
  ## clean the working directory
  - BUILD_DIR=/home/gitlab-runner/builds/$RUNNER_TOKEN/0
  - CLONE_DIR="$BUILD_DIR/$CI_PROJECT_PATH"
  - cd $BUILD_DIR
  - rm -rf $CLONE_DIR
  - mkdir -p $CLONE_DIR

  ## clone the project each time (inefficient, consider performing fetch instead if it already exists)
  - git clone http://gitlab-runner:$GITLABRUNNER_USER_AUTH_TOKEN@server:8888/${CI_PROJECT_PATH}.git $CLONE_DIR
  - cd $CLONE_DIR

Note: Here are the relevant variables I also configured in step 2 rather than hard coding them in the script:

• RUNNER_TOKEN: "Runner Token" value listed in the Admin "Runners" menu for the particular runner you are trying to run.
• GITLABRUNNER_USER_AUTH_TOKEN: This is the auth token you generated in step 1.

Further Reading:

You can avoid the fake account approach taken above by instead issuing Deploy Keys. Or if security implications of access to any project is a concern, Deploy Tokens are an alternative with more security control. For comparison, see the docs:

Deploy keys are shareable between projects that are not related or don’t even belong to the same group. Deploy tokens belong to either a project or a group.

A deploy key is an SSH key you need to generate yourself on your machine. A deploy token is generated by your GitLab instance, and is provided to users only once (at creation time).

A deploy key is valid as long as it’s registered and enabled. Deploy tokens can be time-sensitive, as you can control their validity by setting an expiration date to them.

You can’t log in to a registry with deploy keys, or perform read / write operations on it, but this is possible with deploy tokens. You need an SSH key pair to use deploy keys, but not deploy tokens.

这篇关于如何为 Gitlab 运行器启用通过 SSH 克隆?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！