您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
CI/CD 流水线创建方法:Monad、Arrow 还是 Dart ?
 
作者:Thomas Leonard 译者:吴留坡
  1467  次浏览      15
2021-5-13 
 
编辑推荐:
本文将用三种方法来创建 CI/CD 流水线。Monad 不能对流水线进行静态分析,Arrow 语法很难用,我称之为 Dart(不知道它是否已经有名字了)的一种轻量级的 Arrow 方法可以像 Arrow 一样进行静态分析,但语法比 Monad 更简单。
本文来自于infoq,由火龙果软件Anna编辑推荐。

我需要构建一个用于创建 CI/CD 流水线的系统。它起初是为了构建一个 CI 系统,测试 Github 上的 OCaml 项目(针对多个版本的 OCaml 编译器和多个操作系统,测试每个提交)。下面是一个简单的流水线,获取某个 Git 分支最新的提交,构建,并执行测试用例。

【译者注】CI/CD:持续集成(Continuous Integration)和持续部署(Continuous Deployment)简称,指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率,在新代码从开发到部署的过程中,尽量减少人工的介入。

这里的配色标识是:绿色的方框是已经完成,橙色的是正在进行,灰色的意味着这一步还不能开始。

这里有一个稍微复杂点的例子,它还下载了一个 Docker 基础镜像,使用两个不同版本的 OCaml 编译器并行构建提交,然后测试得到的镜像。红框表示此步骤失败:

一个更复杂的例子是测试项目本身,然后搜索依赖它的其他项目,并根据新版本测试这些项目:

在这里,圆圈意味着在检查反向依赖项之前,我们应该等待测试通过。

我们可以用 YAML 或类似的方法来描述这些管道,但这将是非常有限的。相反,我决定使用一种特定于领域的嵌入式语言,这样我们就可以免费使用宿主语言的特性(例如字符串操作、变量、函数、导入、类型检查等)。

最明显的方法是使每个框成为正则函数。然后上面的第一个例子可以是(这里,使用 OCaml 语法):

let example1 commit =
let src = fetch commit in
let image = build src in
test image

第二个可能是:

let example2 commit =
let src = fetch commit in
let base = docker_pull "ocaml/opam2" in
let build ocaml_version =
let dockerfile = make_dockerfile ~base ~ocaml_version in
let image = build ~dockerfile src ~label:ocaml_version in
test image
in
build "4.07";
build "4.08"

第三个可能是这样的:

let example3 commit =
let src = fetch commit in
let image = build src in
test image;
let revdeps = get_revdeps src in
List.iter example1 revdeps

不过,我们想在语言中添加一些附加功能:

管道步骤应尽可能并行运行。上面的 example2 函数将一次完成一个构建。

管道步骤应在其输入更改时重新计算。e、 当我们作出新的承诺时,我们需要重建。

用户应该能够查看每个步骤的进度。

用户应该能够为任何步骤触发重建。

我们应该能够从代码中自动生成图表,这样我们就可以在运行管道之前看到它将做什么。

一步的失败不应该使整个管道停止。

对于这篇博客文章来说,确切的附加功能并不重要,因此为了简单起见,我将重点放在同时运行步骤上。

Monad 方法

【译者注】Monad:函子,单子,来自 Haskell 编程语言,是函数式编程中,一种定义将函数(函子)组合起来的结构方式,它除了返回值以外,还需要一个上下文。常见的 Monad 有计算任务,分支任务,或者 I/O 操作。

如果没有额外的功能,我们有如下功能:

val fetch : commit -> source
val build : source -> image

您可以将其理解为“build 是一个获取源值并返回(Docker)镜像的函数”。

这些函数很容易组合在一起,形成一个更大的函数来获取提交并构建它:

let fab c =
let src = fetch c in
build src

我们还可以将其缩短为 build(fetch c)或 fetch c |>build。OCaml 中的|>(pipe)运算符只调用其右侧的函数,而参数在其左侧。

为了将这些函数扩展为并发的,我们可以让它们返回承诺,例如,

val fetch : commit -> source promise
val build : source -> image promise

但是现在我们无法使用 let(或|>)轻松组合它们,因为 fetch 的输出类型与 build 的输入不匹配。

但是,我们可以定义一个类似的操作,let(或>>=)来处理承诺。它立即返回对最终结果的承诺,并在第一个承诺实现后调用 let* 的主体。那么我们有:

let fab c =
let* src = fetch c in
build src

换句话说,通过在周围撒上几个星号字符,我们可以将简单的旧管道变成一个新的并发管道!使用 let* 编写 promise returning 函数的时间规则与使用 let 编写常规函数的时间规则完全相同,因此使用 promise 编写程序与编写常规程序一样简单。

仅仅使用 let *不会在我们的管道中添加任何并发(它只允许它与其他代码并发执行)。但是我们可以为此定义额外的函数,比如 all 一次计算一个列表中的每个承诺,或者使用 and 运算符指示两个事物应该并行运行:

除了处理承诺外,我们还可以为可能返回错误的函数(只有在第一个值成功时才调用 let 的主体)或为实时更新(每次输入更改时都调用主体)或为所有这些东西一起定义 let*。这是单子的基本概念。

这其实很管用。在 2016 年,我用这种方法做了 DataKitCI,它最初用于 Docker-for-Mac 上的 CI 系统。之后,Madhavapeddy 用它创建了 opam-repo-ci,这是 opam-repository 上的 CI 系统,OCaml 上主要的软件仓库。这将检查每个新的 PR 以查看它添加或修改了哪些包,针对多个 OCaml 编译器版本和 Linux 发行版(Debian、Ubuntu、Alpine、CentOS、Fedora 和 OpenSUSE)测试每个包,然后根据更改的包查找所有包的所有版本,并测试这些版本。

使用 monad 的主要问题是我们不能对管道进行静态分析。考虑上面的 example2 函数。在查询 GitHub 以获得测试提交之前,我们无法运行该函数,因此不知道它将做什么。一旦我们有了 commit,我们就可以调用 example2commit,但是在 fetch 和 docker_pull 操作完成之前,我们无法计算 let* 的主体来找出管道接下来将做什么。

换言之,我们只能绘制图表,显示已经执行或正在执行的管道位,并且必须使用和 * 手动指示并发的机会。

Arrow 方法

Arrow 使管道的静态分析成为可能。而不是我们的一元函数:

val fetch : commit -> source promise
val build : source -> image promise

我们可以定义箭头类型:

type ('a, 'b) arrow
val fetch : (commit, source) arrow
val build : (source, image) arrow

a('a,'b)arrow 是一个接受 a 类型输入并生成 b 类型结果的管道。如果我们定义类型('a,'b)arrow='a->'b promise,则这与一元版本相同。但是,我们可以将箭头类型抽象化,并对其进行扩展,以存储我们需要的任何静态信息。例如,我们可以标记箭头:

type ('a, 'b) arrow = {
f : 'a -> 'b promise;
label : string;
}

这里,箭头是一个记录。f 是旧的一元函数,label 是“静态分析”。

用户看不到 arrow 类型的内部,必须使用 arrow 实现提供的函数来构建管道。有三个基本功能可用:

val arr : ('a -> 'b) -> ('a, 'b) arrow
val ( >>> ) : ('a, 'b) arrow -> ('b, 'c) arrow -> ('a, 'c) arrow
val first : ('a, 'b) arrow -> (('a * 'c), ('b * 'c)) arrow

arr 接受纯函数并给出等价的箭头。对于我们的承诺示例,这意味着箭头返回已经实现的承诺。>>>把两个箭头连在一起。首先从“a”到“b”取一个箭头,改为成对使用。该对的第一个元素将由给定的箭头处理,第二个组件将原封不动地返回。

我们可以让这些操作自动创建带有适当 f 和 label 字段的新箭头。例如,在 a>>>b 中,结果 label 字段可以是字符串{a.label}>>{b.label}。这意味着我们可以显示管道,而不必先运行它,如果需要的话,我们可以很容易地用更结构化的内容替换 label。

我们的第一个例子是:

let example1 commit =
let src = fetch commit in
let image = build src in
test image

to

let example1 =
fetch >>> build >>> test

虽然我们不得不放弃变量名,但这似乎很令人愉快。但事情开始变得复杂,有了更大的例子。例如 2,我们需要定义几个标准组合:

(** Process the second component of a tuple, leaving the first unchanged. *)
let second f =
let swap (x, y) = (y, x) in
arr swap >>> first f >>> arr swap
(** [f *** g] processes the first component of a pair with [f] and the second
with [g]. *)
let ( *** ) f g =
first f >>> second g
(** [f &&& g] processes a single value with [f] and [g] in parallel and
returns a pair with the results. *)
let ( &&& ) f g =
arr (fun x -> (x, x)) >>> (f *** g)

Then, example2 changes from:

let example2 commit =
let src = fetch commit in
let base = docker_pull "ocaml/opam2" in
let build ocaml_version =
let dockerfile = make_dockerfile ~base ~ocaml_version in
let image = build ~dockerfile src ~label:ocaml_version in
test image
in
build "4.07";
build "4.08"

to:

let example2 =
let build ocaml_version =
first (arr (fun base -> make_dockerfile ~base ~ocaml_version))
>>> build_with_dockerfile ~label:ocaml_version
>>> test
in
arr (fun c -> ((), c))
>>> (docker_pull "ocaml/opam2" *** fetch)
>>> (build "4.07" &&& build "4.08")
>>> arr (fun ((), ()) -> ())

我们已经丢失了大多数变量名,而不得不使用元组,记住我们的值在哪里。这里有两个值并不是很糟糕,但是随着更多的值被添加并且我们开始嵌套元组,它变得非常困难。我们还失去了在 build~dockerfile src 中使用可选标记参数的能力,而是需要使用一个新操作,该操作接受 dockerfile 和源的元组。

假设现在运行测试需要从源代码获取测试用例。在原始代码中,我们只需使用:src 将测试图像更改为测试图像。在 arrow 版本中,我们需要在生成步骤之前复制源代码,使用带 dockerfile 的 first build_ 运行生成,并确保参数是新测试使用的正确方法。

Dart 方法

我开始怀疑是否有一种更简单的方法来实现与箭头相同的静态分析,但是没有无点语法,而且似乎有。考虑示例 1 的一元版本。我们有:

val build : source -> image promise
val test : image -> results promise
let example1 commit =
let* src = fetch commit in
let* image = build src in
test image

如果你不知道蒙娜兹的事,你还有别的办法。您可以定义 build 和 test,将 promises 作为输入,而不是使用 let* 等待获取完成,然后使用源调用 build:

val build : source promise -> image promise
val test : image promise -> results promise

毕竟,fetching 给了你一个源代码承诺,你想要一个图像承诺,所以这看起来很自然。我们甚至可以以承诺为例。然后看起来是这样的:

let example1 commit =
let src = fetch commit in
let image = build src in
test image

很好,因为它和我们刚开始的简单版本是一样的。问题是效率低下:

我们用承诺的方式调用 example1(我们还不知道它是什么)。

我们不必等待找出要测试的提交,而是调用 fetch,获取某个源的承诺。

不需要等待获取源代码,我们就调用 build,获取图像的承诺。

不用等待构建,我们调用 test,得到结果的承诺。

我们立即返回测试结果的最终承诺,但我们还没有做任何真正的工作。相反,我们建立了一长串的承诺,浪费了记忆。

但是,在这种情况下,我们希望执行静态分析。i、 我们想在内存中建立一些表示流水线的数据结构……这正是我们对 monad 的“低效”使用所产生的结果!

为了使其有用,我们需要基本操作(比如 fetch)来为静态分析提供一些信息(比如标签)。OCaml 的 let 语法没有为标签提供明显的位置,但是我能够定义一个运算符(let**),该运算符返回一个接受 label 参数的函数。它可用于生成如下基本操作:

let fetch commit =
"fetch" |>
let** commit = commit in
(* (standard monadic implementation of fetch goes here) *)

因此,fetch 接受一个提交的承诺,对它执行一个单字节绑定以等待实际的提交,然后像以前一样继续,但它将绑定标记为一个 fetch 操作。如果 fetch 包含多个参数,则可以使用 and* 并行等待所有参数。

理论上,let**In fetch 的主体可以包含进一步的绑定。如果那样的话,我们在一开始就无法分析整个管道。但是,只要原语在开始时等待所有输入,并且不在内部进行任何绑定,我们就可以静态地发现整个管道。

我们可以选择是否将这些绑定操作公开给应用程序代码。如果 let*(或 let**)被公开,那么应用程序就可以使用 monad 的所有表达能力,但是在某些承诺解决之前,我们将无法显示整个管道。如果我们隐藏它们,那么应用程序只能生成静态管道。

到目前为止,我的方法是使用 let* 作为逃生舱口,这样就可以建造任何所需的管道,但我后来用更专业的操作来代替它的任何用途。例如,我添加了:

val list_map : ('a t -> 'b t) -> 'a list t -> 'b list t

这将处理运行时才知道的列表中的每个项。然而,我们仍然可以静态地知道我们将应用于每个项的管道,即使我们不知道项本身是什么。list_map 本来可以使用 let* 实现,但这样我们就无法静态地看到管道。

下面是另外两个使用 dart 方法的示例:

let example2 commit =
let src = fetch commit in
let base = docker_pull "ocaml/opam2" in
let build ocaml_version =
let dockerfile =
let+ base = base in
make_dockerfile ~base ~ocaml_version in
let image = build ~dockerfile src ~label:ocaml_version in
test image
in
all [
build "4.07";
build "4.08"
]

与原来相比,我们有一个 all 来合并结果,并且在计算 dockerfile 时有一个额外的 let+base=base。let+ 只是 map 的另一种语法,在这里使用,因为我选择不更改 make_dockerfile 的签名。或者,我们可以让你的 dockerfile 接受一个基本图像的承诺,并在里面做地图。因为 map 需要一个纯实体(make_dockerfile 只生成一个字符串;没有承诺或错误),所以它不需要在图表上有自己的框,并且我们不会因为允许使用它而丢失任何东西。

let example3 commit =
let src = fetch commit in
let image = build src in
let ok = test image in
let revdeps = get_revdeps src in
gate revdeps ~on:ok |>
list_iter ~pp:Fmt.string example1

这显示了另一个自定义操作:gate revdeps~on:ok 是一个承诺,只有在 revdeps 和 ok 都解决后才能解决。这将阻止它在库自己的测试通过之前测试库的 revdeps,即使如果我们希望它可以并行地这样做。而对于 monad,我们必须在需要的地方显式地启用并发(使用和 *),而对于 dart,我们必须在不需要的地方显式地禁用并发(使用 gate)。

我还添加了一个 list-iter 便利函数,并为它提供了一个漂亮的 printer 参数,这样一旦知道列表输入,我们就可以在图表中标记案例。

最后,虽然我说过不能在原语中使用 let*,但仍然可以使用其他一些 monad(它不会生成图)。实际上,在实际系统中,我对原语使用了一个单独的 let>操作符。这就要求主体使用底层 promise 库提供的非图生成承诺,因此不能在原语的主体中使用 let*(或 let>)。

和 Arrow 进行比较

给定一个“dart”,您可以通过定义例如。

type ('a, 'b) arrow = 'a promise -> 'b promise

 

那么 arr 就是 map,f>>>g 就是有趣的 x->g(fx)。第一个也可以很容易地定义,假设你有某种函数来并行地做两件事(比如上面的和我们的)。

因此,dart API(即使有 let*hidden)仍然足以表示任何可以使用箭头 API 表示的管道。

Haskell 箭头教程 使用一个箭头是有状态函数的示例。例如,有一个 total 箭头,它返回它的输入和以前调用它的每个输入的总和。e、 g. 用输入 1 2 3 调用三次,产生输出 1 3 6。对输入序列运行管道将返回输出序列。

本教程使用 total 定义 mean1 函数,如下所示:

mean1 = (total &&& (arr (const 1) >>> total)) >>> arr (uncurry (/))

因此,此管道复制每个输入编号,将第二个编号替换为 1,将两个流相加,然后用其比率替换每对。每次将另一个数字放入管道时,都会得到迄今为止输入的所有值的平均值。

使用 dart 样式的等效代码是(OCaml 使用 /。对于浮点除法):

let mean values =
let t = total values in
let n = total (const 1.0) in
map (uncurry (/.)) (pair t n)

这对我来说更容易理解。通过定义标准运算符 let+(对于 map)和 +(对于 pair),我们可以稍微简化代码:

let (let+) x f = map f x
let (and+) = pair
let mean values =
let+ t = total values
and+ n = total (const 1.0) in
t /. n

无论如何,这不是一个很好的箭头示例,因为我们不使用一个状态函数的输出作为另一个状态函数的输入,所以这实际上只是一个简单的 applicative.

不过,我们可以很容易地用另一个有状态函数扩展示例管道,也许可以添加一些平滑处理。这看起来像箭头符号中的 mean1>>>平滑,省道符号中的值|>平均值|>平滑(或平滑(平均值))。

注意:Haskell 还有一个 Arrows 语法扩展,它允许 Haskell 代码编写为:

mean2 = proc value -> do
t <- total -< value
n <- total -< 1
returnA -< t / n

这更像是飞镖符号。

更多示例

我在 ocurrent/ocurrent 上建立了一个使用这些思想的稍微扩展版本的库。子目录 lib_term 是与这篇博客文章相关的部分,在 TERM 中描述了各种组合词。

其他目录处理更具体的细节,例如与 Lwt promise 库的集成,提供管理 web UI 或 Cap’n Proto RPC 接口,以及带有用于使用 Git、GitHub、Docker 和 Slack 的原语的插件。

OCaml Docker 基础镜像构建

ocurrent/docker-base-images 包含一个管道,用于为各种 Linux 发行版、CPU 架构、OCaml 编译器版本和配置选项构建 OCaml 的 Docker 基本映像。例如,要在 Debian 10 上测试 OCAML4.09,可以执行以下操作:

$ docker run --rm -it ocurrent/opam:debian-10-ocaml-4.09
:~$ ocamlopt --version
4.09.0
:~$ opam depext -i utop
[...]
:~$ utop
----+--------+------------------
| Welcome to utop version 2.4.2 (using OCaml version 4.09.0)! |
+---------------------------+
Type #utop_help for help about using utop.
-( 11:50:06 )-< command 0 > -------------{ counter: 0 }-
utop #

以下是管道的外观(单击可查看完整尺寸)

它每周提取 opam 存储库的最新 Git 提交,然后为每个发行版构建包含该内容的基本映像和 opam 包管理器,然后为每个受支持的编译器变体构建一个映像。许多图片是建立在多个架构(amd64、arm32、arm64 和 ppc64)上的,并被推到 Docker Hub 的一个暂存区。然后,管道将所有散列组合起来,将一个多架构清单推送到 Docker Hub。还有一些别名(例如,debian 表示 debian-10-ocaml-4.09)。最后,如果有任何问题,则管道会将错误发送到松弛通道。

您可能想知道,我们是否真的需要一个管道来实现这一点,而不是从 cron 作业运行一个简单的脚本。但是拥有一个管道可以让我们在运行它之前看到管道将要做什么,观察管道的进度,单独重新启动失败的作业,等等,几乎与我们编写的代码相同。

如果你想看完成的流水线,可以阅读 pipeline.ml。

OCaml CI

ocurrent/ocaml-ci 是一个用于测试 OCaml 项目的(实验性的)GitHub 应用程序。管道获取应用程序的安装列表,获取每个安装的已配置存储库,获取每个存储库的分支和 PRs,然后针对多个 Linux 发行版和 OCaml 编译器版本测试每个存储库的头部。如果项目使用 ocamlformat,它还会检查提交的格式是否与 ocamlformat 的格式完全相同。

结果作为提交状态被推回到 GitHub,并记录在 web 和 tty ui 的本地索引中。这里有很多红色,主要是因为如果一个项目不支持特定版本的 OCaml,那么构建会被标记为失败,并在管道中显示为红色,尽管在生成 GitHub 状态报告时会过滤掉这些失败。我们可能需要一个新的颜色跳过阶段。

结论

编写 CI/CD 管道很方便,就好像它们是一次连续运行这些步骤并始终成功的单点脚本一样,然后只要稍作更改,管道就会在输入更改时运行这些步骤,同时提供日志记录、错误报告、取消和重建支持。

使用 monad 可以很容易地将任何程序转换为具有这些特性的程序,但是,与常规程序一样,在运行某些数据之前,我们不知道该程序将如何处理这些数据。特别是,我们只能自动生成显示已经开始的步骤的图表。

传统的静态分析方法是使用箭头。这比单元格稍微有限,因为流水线的结构不能根据输入数据而改变,尽管我们可以增加有限的灵活性,例如可选的步骤或两个分支之间的选择。但是,使用箭头符号编写管道是很困难的,因为我们必须使用无点样式(没有变量)编程。

通过以一种不寻常的方式使用 monad(这里称为“dart”),我们可以获得静态分析的相同好处。我们的函数不是接受纯值并返回包装值的函数,而是接受并返回包装值。这导致语法看起来与普通编程相同,但允许静态分析(代价是无法直接操作包装的值)。

如果我们隐藏(或不使用)monad 的 let*(bind)函数,那么我们创建的管道总是可以静态地确定的。如果我们使用绑定,那么管道中会有随着管道运行而扩展到更多管道阶段的孔。

基本步骤可以通过使用单个“标签绑定”创建,其中标签为原子组件提供静态分析。

我以前从未见过使用过这种模式(或者在 arrow 文档中提到过),它似乎提供了与 arrow 完全相同的好处,而且难度要小得多。如果这个名字是真的,告诉我!

这项工作由 OCaml 实验室资助。

   
1467 次浏览       15
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试