这篇博文将带您了解通过 Dockerhub 和 Github 以及通过 Github Actions 构建 Docker 映像的持续集成的设置过程。它还包含文档中重要说明的简明摘要。

目标:了解 CI 并实际使用它来自动构建为我的数据科学工具箱构建的 docker 镜像。

本质上,我希望能够检查我正在维护的 docker 容器的状态。最终,我想设置一系列检查我使用的库和软件工具是否按预期工作。尽管 dockerhub 允许在提交上构建容器,但我还希望设置一个 CI/CD 管道,以便了解它的实际工作方式。

先决条件:一个 dockerhub 帐户和一些可以使用的 dockerhub 映像。 dockerfile 和相关的源代码应该在 github 存储库中可用。

我将使用的 github 存储库是shrysr/sr-ds-docker和 dockerhub 映像shrysr/shiny。在 github 存储库中,闪亮文件夹包含构建闪亮图像所需的所有文件。请注意,要构建闪亮的图像,需要 rbase 图像。

计划[3⁄3]

1. 完整阅读Github 文档 github 操作。

1.设置一个github托管的运行器

2. [-] 设置一个自托管运行器:低优先级推迟,因为在允许任何 github 代码在我的 VPS 上运行之前,最好了解运行器如何使用 github 代码。

3. 在 Dockerhub 和 Github 之间创建 CI 集成

4. 将 CI 设置扩展到数据科学 docker 容器。

设置 Github Runner[0/1]

github runner 本质上是使用 Actions 选项卡创建的。有一个可以免费使用的 Actions 市场。许多流行的工作流程已经存在操作,例如构建 docker 映像并将其推送到某个注册表。

显然,第一个操作必须是检查存储库。没有这一步,该过程将无法进行。我花了很长时间在

将构建上下文指定到特定文件夹。即不要使用build .因为那样上下文和路径将不起作用,因此COPY类型的函数将不起作用。

显然 Github 只会重新识别.github/workflows位置内的 yaml 文件,尽管我可能错了。如果使用他们对操作设置的自动建议,则会自动创建文件夹。但是,幸运的是,在此文件夹中创建的任何 YAML 文件都将由 Github 操作运行。请参阅以下有关 API 限制的说明。由于这个 YAML 文件似乎不能用于 Travis 或 CircleCI,因此无论如何最好将它们放在 github 文件夹中。

开始使用就像在打开存储库时使用操作选项卡一样简单。提供了一个基本的 YAML 模板,实际上足以让我快速入门。

在这种情况下,构建上下文由文件的位置指定,并且可以指定标签。目前,我正在使用临时容器。

• 测试的一个想法是:运行一个 ubuntu docker 容器,然后在其中调用闪亮的容器。让容器运行,然后通过 R 脚本设计一些输出。一种方法是加载一堆包。另一种方法是让闪亮的应用程序运行并提供某种临时输出。这需要进一步细化。 <!--听-->

name: Docker Image CI

on: [push]

jobs:

  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: shiny
      run: docker build . --file /shiny/Dockerfile --tag my-image-name:$(date +%s)q

通过单击各个作业可以找到构建详细信息。可以下载原始日志以获得详细日志,以实现良好的文本搜索。在实时构建过程中,日志更新和网页刷新之间存在一些滞后,但目前看来在可容忍的范围内。

关于构建和队列的注意事项

免费构建时间较长,服务器配置未知。在本地构建镜像并将它们推送到 dockerhub 可能要快得多。但是,较小的映像更新和小型映像构建很快就会发生。关键是从 github 提交中获得一个成功的构建,然后建立上下文,新层不需要花费相同的时间。

综上所述,与通过 Github 上的操作进行构建的排队时间相比,dockerhub 中的排队时间非常长。免费层实际上非常慷慨,提供了很多玩耍和实验的空间。看起来 github 计算机服务器比 Dockerhub 更快。

通过 Dockerhub 和 Github 设置 CI

前提条件当然是您的存储库中有一个 docker 映像。

这个过程比较简单。登录到您的 Dockerhub 帐户,然后单击类似指纹的图标以进入帐户设置。使用链接帐户选项卡并使用您的登录凭据设置 github。

接下来,选择您的 docker 映像存储库,然后单击 Builds 选项卡,然后单击设置自动构建。

现在您可以选择一个 github 存储库,并且可以使用设置来指向特定的分支或特定的 Dockerfile。

请注意为存储库链接的基本映像启用选项。如果您的图像依赖于另一个图像,则可以将其设置为启用。假设基础镜像已更新,那么将为您的镜像触发构建。

source 选项可以设置为命名分支或标签,并且还必须指定 docker 标签。如果您将个多个 docker 配置存储在一起,则构建上下文会有所帮助。

另请注意,可以指定环境变量,从而启用更自定义的映像部署。该变量可用于指定用户名和密码、Rstudio 版本或 r-base 版本等内容。Docker 映像标签通常用于更轻松地划分这些内容。

以下是 Dockerhub 上构建活动的样子:

一般说明

组件概览

要运行任何代码,必须有一台服务器或一台计算机来运行它。这称为运行器,可以在自托管平台上创建,也可以在具有不同层的服务上放置运行器。

参考:Github docs

GitHub Actions 使您能够直接在 GitHub 存储库中创建自定义软件开发生命周期 (SDLC) 工作流。 GitHub Actions 可用于 GitHub Free、GitHub Pro、GitHub Team、GitHub Enterprise Cloud 和 GitHub One

工作流在 Linux、macOS、Windows 和 GitHub 托管机器上的容器中运行,称为“运行器”。或者,您也可以托管自己的运行器,以便在您拥有或管理的机器上运行工作流。有关更多信息,请参阅“关于自托管运行器”。

您可以使用存储库中定义的操作、GitHub 上公共存储库中的开源操作或已发布的 Docker 容器映像来创建工作流。默认情况下,分叉存储库中的工作流不会运行。

您可以创建配置为在特定事件上运行的工作流文件。有关更多信息,请参阅“配置工作流程”和“GitHub 操作的工作流程语法”。

GitHub Marketplace 是您查找、共享和使用 GitHub 社区构建的操作的中心位置。

关于 API 限制

这些限制中的大多数不适用于自托管的跑步者。上述例外:“您可以在一小时内针对存储库中的所有操作执行多达 1000 个 API 请求。”

GitHub Actions 的使用有一些限制。除非另有说明,否则以下限制仅适用于 GitHub 托管的运行器,而不适用于自托管的运行器。这些限制可能会发生变化。

• 每个存储库最多可以同时执行 20 个工作流。如果超过,任何其他工作流都会排队。

• 工作流中的每个作业最多可以运行 6 小时的执行时间。如果作业达到此限制,则作业将终止并且无法完成。

• 您可以在帐户中的所有存储库中运行的并发作业数量取决于您的 GitHub 计划。如果超过,任何其他作业都将排队。

您可以在一小时内针对存储库中的所有操作执行多达 1000 个 API 请求。此限制也适用于自托管运行器。如果超过,其他 API 调用将失败,这可能会导致作业失败。

除了这些限制之外,GitHub Actions 不应用于:

• 非法或我们的服务条款或社区准则禁止的内容或活动。

• 挖矿

• 无服务器计算

• 危害 GitHub 用户或 GitHub 服务的活动。

• 与使用 GitHub Actions 的存储库关联的软件项目的生产、测试、部署或发布无关的任何其他活动。换句话说,冷静点,不要以你知道不应该的方式使用 GitHub Actions。

您可以在一小时内针对存储库中的所有操作执行多达 1000 个 API 请求。此限制也适用于自托管运行器。如果超过,其他 API 调用将失败,这可能会导致作业失败。

GitHub计划

并发作业总数

最大并发 macOS 作业

自由的

20

5

临

40

5

团队

60

5

企业

180

15

自托管运行器与 github 托管运行器

自托管运行器可以是物理的、虚拟的、容器的、本地的或云中的。只要满足以下要求,您就可以将任何机器用作自托管运行器:

• 您可以在机器上安装和运行 GitHub Actions 运行器应用程序。有关更多信息,请参阅“自托管运行器支持的操作系统”。

• 机器可以与 GitHub Actions 通信。有关更多信息,请参阅“自托管运行器与 GitHub 之间的通信”。

GitHub 托管的运行器提供了一种更快、更简单的方式来运行您的工作流,而自托管的运行器是一种在您自己的自定义环境中运行工作流的高度可配置的方式。

GitHub 托管的跑步者:

• 自动更新。

• 由 GitHub 管理和维护。

##- 为每个作业执行提供一个干净的实例。

自营跑步者:

• 可以使用您已经付费的云服务或本地机器。

• 可根据您的硬件、操作系统、软件和安全要求进行定制。

• 不需要为每个作业执行都有一个干净的实例。

• 根据您的使用情况,可能比 GitHub 托管的跑步者更具成本效益。

设置注意事项:使用 .env 文件

如果设置环境变量不实用,您可以在自托管运行器应用程序目录中名为 .env 的文件中设置代理配置变量。例如,如果您想将运行器应用程序配置为系统帐户下的服务,这可能是必需的。当 runner 应用程序启动时,它会读取 .env 中为代理配置设置的变量。

.env 代理配置示例如下所示:

https_proxyu003dhttp://proxy.local:8080no_proxyu003dexample.com,myserver.local:443

自托管运行器安全性:关于公共存储库 - 本质上,这意味着 github 上的一些代码存储库能够在您的计算机上运行。因此,除非代码受到信任和审查,否则允许这样做是危险的。分叉可以通过打开拉取请求导致恶意工作流运行。

将公共存储库与 github 托管的运行器一起使用会更安全。

我们建议您不要在公共存储库中使用自托管运行器。

通过创建在工作流中执行代码的拉取请求,公共存储库的分支可能会在您的自托管运行器机器上运行危险代码。

这不是 GitHub 托管的运行程序的问题,因为每个 GitHub 托管的运行程序始终是一个干净的隔离虚拟机,并且在作业执行结束时被销毁。

在您的自托管运行器上运行的不受信任的工作流程会给您的机器和网络环境带来重大的安全风险,尤其是当您的机器在作业之间保持其环境时。一些风险包括:

• 机器上运行的恶意程序。

• 逃离机器的运行沙箱。

• 暴露对机器网络环境的访问。

• 在机器上保留不需要或危险的数据。

CI

持续集成:使提交能够触发构建,从而增强错误发现和纠正过程。

CI 服务器可以与运行器在同一台服务器上运行。因此它可以是 github 托管或自托管 CI 服务器。

Github 在设置 CI 时分析存储库,并根据使用的语言推荐基本模板。

当您将代码提交到存储库时,您可以持续构建和测试代码,以确保提交不会引入错误。您的测试可以包括代码检查(检查样式格式)、安全检查、代码覆盖率、功能测试和其他自定义检查。

构建和测试代码需要服务器。您可以在将代码推送到存储库之前在本地构建和测试更新,或者您可以使用 CI 服务器检查存储库中的新代码提交。

您可以将 CI 工作流程配置为在 GitHub 事件发生时(例如,当新代码被推送到您的存储库时)、按照设定的时间表运行,或者在使用存储库调度 webhook 发生外部事件时运行。