操纵Tekton的云原生CI/CD

我们都知道每个重大的项目都需要CI/CD，我很确定没有必要解释为什么。不过，在决定在何处构建CI/CD时，有很多工具、平台和解决方案可供选择。您可以选择Jenkins、Travis、CircleCI、Bamboo和许多其他的，但是如果您正在为运行在Kubernetes上的云本地应用程序构建CI/CD，那么使用适当的工具同时运行云本地CI/CD是很有意义的。

其中一个允许您在Kubernetes上本机运行CI/CD的解决方案是Tekton，因此在本文中，我们将开始关于使用Tekton构建CI/CD的系列文章，首先介绍、安装和定制Tekton，以开始我们在Kubernetes上使用云本地CI/CD的旅程。

TL;DR:使用Tekton启动您的CI/CD所需的所有资源、脚本和文件都可以在https://github.com/MartinHeinz/tekton-kickstarter找到。

正如标题和介绍所暗示的，Tekton是云原生CI/CD工具。它最初是在谷歌开发的，被称为Knative管道。它在Kubernetes上作为一组自定义资源(crd)运行，如管道或任务，其生命周期由Tekton的控制器管理。事实上，它本机运行在Kubernetes上，这使它成为管理/构建/部署任何部署在Kubernetes上的应用程序和资源的理想选择。

这表明它适合管理Kubernetes的工作负载，但是为什么不使用其他更流行的工具呢?

常用的CI/CD解决方案，如Jenkins、Travis或Bamboo并不是为了在Kubernetes上运行而构建的，或者缺乏与Kubernetes的适当集成。这使得部署、维护和管理CI/CD工具本身以及使用它来部署任何kubernetes本地应用程序变得困难和/或令人烦恼。

另一方面，由于Kubernetes运营商与所有其他容器化应用程序并排在一起，因此Tekton可以非常轻松地进行部署，并且每个Tekton管道都是另一个Kubernetes资源，其管理方式与旧式Pod或Deployments相同。

这也使Tekton可以很好地与GitOps做法配合使用，因为您可以采用所有管道和配置并以git的形式进行维护，而对于至少一种上述工具则不能这么说。资源消耗也是如此-考虑到整个Tekton部署只是几个pod-与其他CI / CD工具相比，在管道不运行时消耗很少的内存和CPU。

话虽如此，很显然，如果您要在Kubernetes上运行所有工作负载，那么最好在CI / CD中使用一些Kubernetes原生工具。Tekton是唯一的选择吗?不，当然，您可以使用其他工具，其中之一就是JenkinsX，这是从本地开始使用Kubernetes进行持续交付的一种自以为是的方式。

它包含许多工具，如果您对替代工具没有强烈的偏好，可以使您的生活更轻松，但是如果您要自定义技术堆栈，也可能会很烦人。尽管JenkinsX仍然在后台使用Tekton，所以您最好还是学习使用Tekton，然后再决定是否还需要JenkinsX提供的所有其他组件

另一个选择是Spinnaker，它是一个多云解决方案，已经存在了很长一段时间。它使用插件来集成各种各样的提供商，其中之一就是Kubernetes。但是，它不是一个构建引擎——它不提供测试代码、构建应用程序映像或将它们推送到registry的工具，对于这些任务，您仍然需要一些其他CI工具。

现在，让我们仔细看看Tekton的组成-Tekton的核心仅包含几个CustomResourceDefinitions(CRD)，它们是Tasks和Pipelines，它们充当TaskRuns和PipelineRuns的蓝图。这四个(加上其他一些即将被弃用或现在不相关的)足以开始运行一些管道和任务。

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!