github托管_在5分钟内创建您的自托管Github Action Runner

github托管

Github actions are great! However the free tier of 2000 minutes / month in private repositories can quickly run out if your workflow requires your CI/CD pipeline to be ran frequently.

Github的动作很棒！ 但是，如果您的工作流程需要频繁运行CI / CD管道，则私人存储库中2000分钟/月的免费套餐可以很快用完。

Thankfully, Github offers the possibilty to use a self-hosted Github Action Runner. More information here. They may be a good idea to optimize costs (especially if you have cloud credit!).

值得庆幸的是，Github提供了使用自托管的Github Action Runner的可能性。 更多信息在这里 。 他们可能是一个优化成本的好主意(尤其是如果您拥有云信用！)。

In this article we will go through the three steps needed to create one and talk about some of the challenges VS using Github’s default runner

在本文中，我们将完成创建一个步骤所需的三个步骤，并讨论使用Github的默认运行程序VS所面临的一些挑战

步骤1：建立执行个体 (Step 1: Create an instance)

Here we only cover creating a VM on GCP’s Compute Engine, but the next steps are exactly the same for other cloud providers like AWS EC2

在这里，我们仅介绍在GCP的Compute Engine上创建VM ，但是接下来的步骤与其他云提供商(如AWS EC2)完全相同

Go to https://console.cloud.google.com → Your project → Compute Engine → Vm instances → Create, with the following settings:

转到https: //console.cloud.google.com→您的项目→Compute Engine→Vm实例→创建，并使用以下设置：

• Name: github-action-runner

  名称： github-action-runner

• Machine configuration: The E2 serie offers the best cost / performance value for general purpose instances. I recommend the e2-medium (2 vCPUs / 4GB of memory) for ~$25 / month, we can always scale up or down as needed later on.

  机器配置：E2系列为通用实例提供最佳的性价比。 我建议使用e2-medium (2个vCPU / 4GB内存)，价格约为每月25美元，以后我们可以随时根据需要扩展或缩小规模。

• Boot disk: Ubuntu 18.04 with 20Gb. Best to start smaller on the disk because we can increase but not decrease its size later on.

  引导盘： 具有20Gb的Ubuntu 18.04。 最好从较小的磁盘开始，因为以后可以增加但不能减小其大小。

• Firewall: Allow HTTP and HTTPS traffic. We need that to connect with Github’s backend

  防火墙： 允许HTTP和HTTPS通信。 我们需要它与Github的后端连接

Hit Create and wait a few seconds.

点击创建并等待几秒钟。

步骤2：配置实例 (Step 2: Configure the instance)

The default Ubuntu setup we get from a fresh VM is missing just a few dependencies before we can install the runner:

在安装运行程序之前，我们从新VM获得的默认Ubuntu安装程序缺少一些依赖关系：

• We need the latest version of Git (by default an older version is installed)
  我们需要最新版本的Git(默认情况下安装的是旧版本)
• We may need to install Docker (if it is part of CI/CD)
  我们可能需要安装Docker(如果它是CI / CD的一部分)
• We may need sudo access
  我们可能需要sudo访问
• And of course we want the latest patches and security updates
  当然，我们需要最新的补丁程序和安全更新

Here is a script to automate those steps:

这是一个自动化这些步骤的脚本：

sh -c "$(curl -fsSL https://gist.githubusercontent.com/gjgd/5a08da85a98bf147294f331461e44d1f/raw/a63bf0f4169a8ab651adfa0a56e676e6bc465876/setup-github-action-runner.sh)"

# sh -c "$(curl -fsSL https://gist.githubusercontent.com/gjgd/5a08da85a98bf147294f331461e44d1f/raw/a63bf0f4169a8ab651adfa0a56e676e6bc465876/setup-github-action-runner.sh)"


# Update instance
sudo apt update -y
sudo apt upgrade -y


# Install latest version of git
sudo add-apt-repository ppa:git-core/ppa -y
sudo apt-get update
sudo apt-get install git -y


# Install and setup docker
sudo apt install docker.io docker-compose -y
sudo systemctl enable docker
sudo gpasswd -a $USER docker
newgrp docker


# Add current user to sudoer file
# https://linuxize.com/post/how-to-add-user-to-sudoers-in-ubuntu/
echo "${USER}  ALL=(ALL) NOPASSWD:ALL" | sudo tee "/etc/sudoers.d/${USER}"

步骤3：在执行个体上安装动作执行器 (Step 3: Install the action runner on the instance)

In this step, we will download the action runner software on our instance, so that Github can communicate to our instance which workflow to run, and when.

在此步骤中，我们将在实例上下载ActionRunner软件，以便Github可以与实例通信，以运行哪个工作流程以及何时运行。

Github’s documentation on the topic is fantastic, just follow theses steps to link your repository with your runner instance: https://docs.github.com/en/actions/hosting-your-own-runners/adding-self-hosted-runners

Github关于该主题的文档很棒，只需按照以下步骤将存储库与运行器实例链接即可： https : //docs.github.com/en/actions/hosting-your-own-runners/adding-self-hosted-runners

Lastly, use runs-on: self-hosted in your workflow in order to use your instance instead of the default runner:

最后，使用运行：在您的工作流中自托管 ，以便使用您的实例而不是默认运行器：

name: CI
on: [push]
jobs:
  ci:
    runs-on: self-hosted
    steps:
      (...)

Now you’re all set 🚀

现在你都准备好了🚀

Note that, as mentioned in the documentation, you can setup the runner in a specific private repository, or organization wide!

请注意，如文档中所述，您可以在特定的私有存储库或组织范围内设置运行器！

使用自己的跑步机时要考虑的几件事 (A few things to consider when using your own runner)

花费额外的Github分钟可能更便宜 (It may be cheaper to pay for extra Github minutes)

Depending on your compute requirements or CI/CD build time / frequency, using a dedicated VM may be more expensive than to just pay for the extra Github minutes. More on Github minutes pricing here

根据您的计算要求或CI / CD的构建时间/频率，使用专用VM可能比仅花费额外的Github分钟要贵。 有关Github分钟定价的更多信息，请点击这里

你需要自己清理 (You need to cleanup after yourself)

When using Github’s default runner, you will get a new VM for each workflow execution, however if you use your own self-hosted runner, it is your responsibility to clean up your environment in between workflow runs (kill running processes, remove build artifacts, etc…)

使用Github的默认运行程序时，每次工作流程执行都会获得一个新的VM，但是，如果您使用自己的自托管运行程序，则有责任在工作流程运行之间清理环境(杀死正在运行的进程，删除构建构件，等等…)

I personally ran into two complications:

我个人遇到了两个并发症：

• Docker containers created as part of your Github Workflow are not automatically stopped, so you need to do it manually at the end of your workflow. For that, I found the always() workflow function extremely helpful.

  作为Github工作流程一部分创建的Docker容器不会自动停止，因此您需要在工作流程结束时手动进行操作。 为此，我发现always()工作流程功能非常有用。

  This last step will always run, even if a previous step failed

  即使上一步失败，最后一步也将始终运行

steps:
  (...)
  - name: Cleanup
    if: ${{ always() }}
    run: docker ps -q | xargs -n 1 -P 8 -I {} docker stop {}

• Build artifacts and other generated files may need to be cleanup as well at the end of the workflow execution
  在工作流执行结束时，可能还需要清理构建工件和其他生成的文件

请勿使用自托管的跑步者进行公共回购 (DO NOT use a self-hosted runner for a public repo)

Here are some reasons why it is a bad idea.

这是一个坏主意的一些原因。

Moreover, there is really no reason to do it since Github minutes on public repositories are free, yay!

而且，由于Github在公共存储库上的会议记录是免费的，真的没有理由这样做！

最后的想法 (Final thoughts)

Building your dedicated self-hosted Github Action runner is really easy, and it may be a good solution to reduce CI/CD costs depending on your requirements, however it requires to think about how to reset the environment in between workflow run.

构建您自己的专用自托管Github Action运行程序确实很容易，并且它可能是根据您的要求降低CI / CD成本的好解决方案，但是它需要考虑如何在工作流运行之间重置环境。

Please comments with questions or feedback!

请提出问题或反馈意见！

翻译自: https://medium.com/@gjgd/create-your-self-hosted-github-action-runner-in-5-minutes-a9eff615edc4

github托管