编程语言
首页 > 编程语言> > 基于 Conan 的 C/C++ 持续交付流水线

基于 Conan 的 C/C++ 持续交付流水线

作者:互联网

背景


在当下软件应用的开发过程当中,单枪匹马或者小作坊式的模式已经很少见了,协作式的开发成为主流。相应的,应用的代码也不再是从零开始,而是基于或引用很多已有的、共享的模块,如各种开源的框架和共用库,或者协作团队中开发的自研库,这就是软件开发中常说的“依赖”。为了更好地管理这种依赖关系,各种开发语言都逐渐发展出了自己的依赖管理系统,如 Java 的 Maven、NodeJS 的 NPM、Python 的 Pypi 等。这些依赖管理系统的日渐完善和广泛应用,使得相应语言的应用开发更加简洁、高效,大大推动了软件应用的发展和普及。


然而相对的,作为软件开发重要组成部分的 C/C++ 语言,由于其编译型语言的特性,即应用最终要编译成为目标机器可直接执行的程序,使得 C/C++ 的依赖管理一直是一个众所周知的难题和痛点。这主要体现在:

  • 应用二进制接口不兼容。C/C++ 的依赖不仅仅体现在代码上,还包括操作系统、架构、编译器等环境配置上,为了确保一个共享库与其他库、整个应用的兼容性,必须通过各种配置来描述这些配置的依赖信息。

  • 编译构建慢。由于头文件和预处理机制,以及上面提到的兼容性,需要额外的机制来提升编译效率,才能保证只编译那些需要重新编译的代码。

  • 代码链接和内嵌。一个静态的 C/C++ 库能够被另一个库通过头文件包含的方式引用,而一个共享库也能嵌入另一个静态库。在两种情形中,当任何依赖变更时,都必须管理哪些库是需要重新构建的。

  • 生态系统的快速发展。针对不同平台、不同构建任务及应用场景的编译器、构建系统层出不穷,导致解决上述问题的工作量不断地增加。


当然,针对 C/C++ 的依赖管理,业界也开展了很多研究和实践工作,可惜大多数的效果并不理想。而本文将会介绍一种当前已逐步得到业界关注和认可,并得到大力推广的 C/C++ 依赖管理方案--Conan,以及如何基于 Conan、持续集成(CI)工具 Jenkins 和全语言制品库 Artifactory,实现 C/C++ 应用的持续交付流水线。



Conan--C/C++ 的包管理器


Conan 是一个开源项目(FOSS,Free Open Source Software),https://conan.io ,为 C/C++ 的依赖包管理构建了非中心化的管理架构,开发者可以像 Docker Registry 一样搭建自己专属的依赖包仓库。Conan 是跨平台的解决方案,同时兼容各种构建工具,以依赖包的二进制文件为基础来定义、管理依赖关系,使得依赖包的获取和消费更加符合目标环境和配置的特点,提升了整体编译的效率。Conan 是基于 Python 语言的,上手门槛较低,也易于扩展。在被 JFrog 收购之后,Conan 在保持开源特性的同时,还结合了 JFrog 产品在制品管理、DevOps 工具集成等方面的能力,为开发者提供了更为全面的支持。Conan 在当前 C/C++ 依赖管理领域已得到广泛关注和快速发展。


通常之前介绍的像 Maven 这样的依赖管理系统,都包含以下几个部分:

  • 依赖包仓库,用以存储需要引用的依赖包,即各种通用框架或共享模块;

  • 依赖访问协议,用以描述如何在依赖包仓库中定位、获取或上传共享模块;

  • 依赖描述语言,用以描述如何定义依赖关系,以及后台对依赖关系的自动解析;

  • 客户端,根据描述语言中的定义,遵照访问协议,从仓库中获取或上传相应的依赖包。


Conan 也在这几方面提供了成熟的解决方案:


  • 依赖包仓库

Conan 在 JFrog 的公网制品分发平台 JFrog Bintray 上搭建了公共的依赖包仓库conan-center(https://conan.bintray.com),开发者可以直接在这里获取所需的各种公共依赖包。


同时,开发者还可以在本地搭建原生的 conan_server,或者直接利用 JFrog Artifactory 制品仓库,做为私有的依赖包仓库。


  • 依赖访问协议

Conan 通过“<包名>/<版本号>@<所有者>/<成熟度>”的命名规则来定位一个依赖包,其中“<所有者>/<成熟度>”(user/channel)定义了一个类似于命名空间(NameSpace)的机制,用于区分针对同一个共享库的不同实现。


每一个依赖包都分为 recipe 和 package 两个部分。 recipe 定义了依赖包的基本信息、依赖关系、构建方法等基本信息,package 则根据目标环境和配置,如操作系统、架构、编译器等(即 Conan 中的 setting)的不同,保存对应的二进制实现。这样,客户端访问时,先根据命名规则定位到 recipe,再根据目标 setting 的不同选择对应的二进制 package 来下载、使用。


在 conan-center 中,各种公共库都根据目标 setting 的不同提供了大量的二进制 package 供开发者直接使用,大大提高了 C/C++ 应用的编译效率。


  • 依赖描述语言

Conan提供了简单明了的依赖关系描述方式,在后续的示例中会做详细解读。


  • 客户端

Conan 的客户端提供了丰富的命令行命令,能够方便地实现依赖关系的解析和依赖包的管理。


Conan 客户端的安装也非常简便,大家可以参考文档自己实践(https://docs.conan.io/en/latest/installation.html)。


安装好之后,我们可以运行第一个命令:

可以看到 Conan 客户端已经预先配置好了与公共库 conan-center 的连接,开发者可以直接使用其中的公共依赖包。


本文后续将通过示例来展示 Conan 如何利用这些解决方案来提供服务。



Conan 应用示例


本文将基于一个简单的 C++ 应用来展示如何使用 Conan,其代码可以在https://github.com/xingao0803/demo-poco-timer.git  中获得,供大家参考。


  • 描述依赖关系

示例中的 C++ 应用,timer.cpp,是一个简单的 timer 程序,引用了公共库 POCO:

为了在 Conan 中描述与 POCO 的依赖关系,需要编写 conanfile.txt,这就是上一节提到的依赖描述语言。

其中,[requires] 部分列出了本应用需要的依赖包,这里是 POCO,1.8.0.1版本,而且是由 pocoproject 提供的稳定(stable)版本。


[generators] 则列出了编译本应用使用的编译器类型。Conan 提供的公开示例大多是基于 cmake 的,这里改用更为通用的 compiler_args,不限定编译器的类型。


当然,这里只是一个简单的例子,conanfile.txt 的更多内容请参考 Conan 官方文档https://docs.conan.io/en/latest/reference/conanfile_txt.html。


我们知道,在软件开发中,除了代码中的直接依赖,还会有各种传递依赖。而 conanfile.txt 里只列出了直接依赖。Conan 的客户端提供了“conan info”命令来解析所有的依赖关系。


在 conanfile.txt 所在目录执行:

本应用相关的各种依赖传递关系就会在 denpendencies.html 里展示出来,如下图:

此时再执行:

可以看到,相关依赖包的 recipe 已经下载到本地 cache 里了。


  • 下载依赖包二进制文件

“conan info” 命令只是下载了依赖包的 recipe。要下载对应 setting 的 package 二进制包,用以编译,还需要执行 “conan install” 命令。


在 conanfile.txt 所在目录创建构建子目录,并执行 “conan install”:

从运行结果可以看出,Conan 的客户端根据本地的 setting 设置和依赖包的 recipe,自动从 conan-center 上获取对应的二进制 package,下载到本地 cache 里。


当然,由于 C/C++ 生态系统的快速发展,Conan 现有的二进制 package 不一定能够覆盖所有的 setting 组合。“—build=missing” 参数就是指定在没有 setting 对应的二进制 package 时,根据 recipe 中定义的方法,自动从依赖包的源代码编译出对应的二进制包,存储在本地 cache 中。例如:当我在 macbook 上执行上述操作时,POCO 就需要进行重新编译:

当我们再次运行 “conan install” 命令时可以发现,此时相关的依赖包已经可以直接从本地 cache 获取了,避免了重复的网络访问和编译工作。


  • 上传到私有依赖包仓库

在当前团队协作开发的模式下,仅仅把依赖包下载到本地 cache 是远远不够的,我们还需要让整个团队都能够分享这些依赖包。这样即避免了重复的网络访问和编译,又保证了团队中依赖引用的一致性。此时就需要引入私有的依赖包仓库。


Conan 提供了原生的 conan_server 作为本地化部署的私有仓库,可以参考文档https://docs.conan.io/en/latest/uploading_packages/running_your_server.html。


而这里我们要推荐 JFrog 的 Artifactory 全语言制品仓库。Artifactory 不仅仅可以做为 Conan 仓库,其全语言的支持能力还使其能够同时提供 Maven、NPM、Docker 等依赖仓库的服务。 Artifactory 还提供元数据的能力,也就是可以在仓库存储制品的属性上记录整个 DevOps 过程中的关键数据。此外,Artifactory 还可以和 Jenkins 紧密集成,在 Jenkins Pipeline 中提供针对各种开发语言的 DSL,方便持续交付流水线的开发与编排。Artifactory 全语言、元数据,以及集成 Jenkins 的优势在后续示例中都能够得到体现。


Artifactory 的相关信息可以参见文档https://www.jfrog.com/confluence/display/RTF/Welcome+to+Artifactory ,“JFrog 杰蛙 DevOps” 微信公众号上也有很多相关文章和视频课程供大家参考。此外,JFrog Artifactory 还针对 Conan 的应用推出了社区版-- Artifactory CE,https://docs.conan.io/en/latest/uploading_packages/artifactory_ce.html,供大家使用。


为了使用 Artifactory 建设私有的 Conan 依赖包仓库,我们需要在 Artifactory 创建一个 Conan 类型的 local repository。创建方法参见https://www.jfrog.com/confluence/display/RTF/Conan+Repositories 。


然后,我们需要执行 Conan 的客户端命令 “conan remote add” 和 “conna user” 加入这个私有仓库。具体的执行方法在 Artifactory Repository 的  “Set Me Up” 部分有清晰的描述:

其中 <REMOTE> 作为这个私有仓库的别名,会在后续的命令中用来指定使用该仓库。


私用仓库创建好之后,我们可以使用 “conan upload” 命令来上传下载到本地 cache 的依赖包:

其中 -r <REMOTE> 用以指定目标私有仓库,--all 指定同时上传 recipe 和 package。

运行之后,在 Artifactory 的 Conan repository 里就可以看到上传的依赖包了。

之后当再次需要使用这些依赖包时,就可以在执行 “conan install” 时利用 “-r <REMOTE>” 参数指定从私有仓库获取了。


  • 编译C++应用

执行 “conan install” 之后,除了会下载相应依赖包的二进制 package 之外,还会自动生成编译相关的参数引用文档。如在前面的示例中,build 目录下会自动生成 conanbuildinfo.args 文件,其中包含了编译过程中如何引用相应依赖包的参数设置。当编译时,可以直接引用这些参数:

可以看出,基于 Conan 的依赖管理,只要通过 conanfile.txt 描述依赖关系,通过 conan install 命令下载依赖包 package,我们就可以便捷地完成 C++ 应用的编译。


  • 管理C++应用

当然,从应用开发过程来看,仅仅完成编译还是不够的,我们还需要管理好编译产出的可执行程序,供后续测试、部署、发布等环节使用。


通常会把应用编译好的可执行程序存储到代码管理系统,如 git 或 svn 中,或者文件服务器,如 ftp 上。但这种方式会丢失掉应用程序特定的 setting 信息,而且会对现有系统造成性能上的影响。


这里我们还是推荐使用 Artifactory,利用其 Generic repository 来存储可执行程序。Artifactory 全语言的支持使得能够在同一个仓库中统一管理 Conan 依赖包和编译好的可执行程序。而其企业级高可用的特性能够保证制品访问的性能和稳定。


在 Artifactory 里创建一个 Generic 的 local repository,在其 “Set Me Up” 部分可以看到如何利用 Artifactory 的 rest api 来上传和下载相应的可执行程序:

同时,我们可以在 repository 里通过设置不同的目录来记录可执行程序的版本。

针对可执行程序特定的 setting,也可以通过Artifactoy 的元数据能力记录到对应程序的属性上。


在执行完 “conan install” 之后,build 目录里还会自动生成 conaninfo.txt 文件,记录了本应用及其依赖相关的各种配置参数,其中 [settings]、[full_settings] 部分记录了相关的 setting 信息:

可以将这些 setting 参数提取出来,利用 Artifactory 的 rest api 写入属性:

在 Artifactory 的 repository 里就可以看到这些属性了:

此外,Artifactory 还提供了 AQL(Artifactory Query Language),使得我们能够基于这些元数据属性设置查询条件,从而定位与目标 setting 匹配的可执行程序。


设置 aql 文件 1timer.aql 如下:

再利用 Artifactory 的查询 rest api,我们就可以定位和下载符合 setting 需求的可执行程序,供后续的测试、部署等环节使用了。

同时,我们还可以利用 Artifactory 元数据的能力,将后续环节的关键数据,如测试结果,也记录在该程序的属性中,从而为质量监控审批、出错回溯检查等提供数据支持。



C/C++持续交付流水线


前面的示例,我们利用 Conan 依赖管理和 Artifactory 私有仓库实现了完整的 C++ 应用开发流程。在当前 DevOps 应用背景下,我们还需要能够自动化地重复执行这一流程,以实现 C++ 应用的持续交付。这就需要利用 Conan、Artifactory 和 Jenkins 这一类工具的集成来实现。


Artifactory 提供了 Jenkins 的插件,支持 Jenkins Pipeline 中针对 Artifactory 和 Conan 的 DSL,可以很方便、直观的实现 Artifactory 和 Conan 的各种操作。前面示例中的各种操作,都可以利用相应的 DSL 语句,集成到 Jenkins Pipeline 当中,如:

完整的 Jenkins Pipeline 代码在https://github.com/xingao0803/demo-poco-timer.git  中可以找到,供大家参考。


在 Jenkins 中执行该 Pipeline,就可以实现 timer 应用的自动化持续交付流水线:



总结


C/C++ 的依赖管理一直是软件开发领域的痛点。本文介绍了当前得到广泛关注和迅速发展的 C/C++ 依赖管理解决方案--Conan 的基本原理和应用流程。同时,利用 timer 应用示例,展示了如何基于 Conan、Artifactory 和 Jenkins,实现C/C++应用的持续交付流水线。


当然,本文中的示例只展示了 Conan 最基本的应用场景,大家可以根据相关资料,学习和研究 Conan 更多的案例。我们也会陆续推出后续文章,为大家进一步展示 Conan 的特性和应用方式。



文章作者:高欣,JFrog中国高级架构师



参考文献

  • Conan 官网https://conan.io

  • JFrog 官网 http://www.jfrogchina.com

  • Artifactory 文档 https://www.jfrog.com/confluence/display/RTF/Welcome+to+Artifactory

  • Artifactory社区版 https://docs.conan.io/en/latest/uploading_packages/artifactory_ce.html

  • 示例代码 https://github.com/xingao0803/demo-poco-timer.git



标签:C++,Conan,流水线,Conan,依赖,Artifactory,conan,C++
来源: http://blog.51cto.com/jfrogchina/2342439