• author

第83节 Jenkins X

⬆️上一节🔗 ⬇️下一节🔗

❤️💕💕新时代拥抱云原生，云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.top

---

[TOC]

开始

之前讨论过 Prow 的实现，以及 prow 的部署方式，相比较而言，prow 的部署是非常非常难的。

• 官网地址：https://jenkins-x.io/
• GitHub 地址：https://github.com/jenkins-x/jx

描述：

你只需要处理你的代码，让Jenkins X自动化其他一切

• 基于GitOps的Tekton管道：Jenkins X不需要深入了解Kubernetes、容器或Tekton，它将为您的项目自动化令人敬畏的Tekton管道，这些项目完全实现了CI和CD，您可以通过GitOps进行管理
• 通过GitOps促进变革：每个团队都有一套环境。然后，Jenkins X通过GitOps和Pull Request自动化环境管理和环境之间应用程序新版本的推广
• 合并请求预览环境：Jenkins X会自动为你的Pull Request启动预览环境，这样你就可以在更改合并到主分支之前获得快速反馈。
• 关于问题和合并请求的反馈和聊天： Jenkins X会自动对您的提交、问题和合并请求进行评论，并在代码准备预览、升级到环境或自动生成合并请求以升级版本时提供反馈

安装

1. 设置 Kubernetes 集群

   在开始之前，请确保你有一个运行的 Kubernetes 集群并配置了 kubectl 来与其交互。

2. 安装 jx CLI 工具

   Jenkins X 提供了一个命令行工具 jx，用于安装和管理 Jenkins X。你可以从 Jenkins X 的 GitHub 仓库或其官方网站下载并安装这个工具。

3. 使用 jx 安装 Jenkins X

   执行以下命令以安装 Jenkins X：

   jx boot
   

   这个命令将启动 Jenkins X 的安装过程，并会安装所需的所有资源和 CRDs。

   注意：根据 Jenkins X 的版本和你的选择，安装过程可能会稍有不同。例如，早期版本的 Jenkins X 使用 jx install 命令进行安装，而后来的版本使用 jx boot。请根据你使用的版本和官方文档进行相应的操作。

4. 验证 CRD 安装

安装完成后，你可以使用 kubectl 验证 Jenkins X 的 CRDs 是否已成功安装。例如：

kubectl get crd | grep jenkins.io

会列出 Jenkins X 创建的所有 CRDs。

介绍：

Jenkins X采用流行的开源项目，自动化设置和管理，提供集成的Cloud Native解决方案，团队可以使用它来开发更好的软件，比传统的非云解决方案更快，更可靠。

Jenkins X集成的开源项目：

• Kubernetes目标平台Jenkins X安装到，可选地部署和运行使用Jenkins X构建的应用程序
• Tekton Cloud Native管道编排
• Kuberhealthy系统的定期健康检查
• Grafana [可选] 集中式日志和可观察性
• Jenkins [可选]传统管道编排
• Nexus [可选]工件存储库

infra

Jenkins X的目标是很好地使用云，Kubernetes托管核心服务，长期存储的存储桶，容器注册表和托管服务，如秘密管理器。所有这些都需要创建和管理。Jenkins X遵从Terraform来设置和管理Jenkins X所需的云基础设施。

• https://www.terraform.io/

Terraform 是由 HashiCorp 开发的开源“基础设施即代码”（IaC）工具。它允许用户使用声明式配置语言定义、提供和管理云资源。以下是 Terraform 的主要特点和应用场景：

1. 声明式语言：Terraform 使用其自己的声明式配置语言——HCL (HashiCorp Configuration Language)。用户只需要描述他们想要的资源状态，而 Terraform 将确定如何达到这个状态。
2. 提供器模型：Terraform 通过提供者来支持各种云服务和平台。这些提供者（例如 AWS、Azure、GCP 等）允许 Terraform 与不同的云服务交互。
3. 状态管理：Terraform 跟踪资源的当前状态，并将其与用户定义的目标状态进行比较。这确保了基础设施的一致性和可预测性。
4. 模块化：Terraform 代码可以组织成模块，使其易于重用和共享。
5. 安全计划和更改：在应用更改之前，Terraform 允许用户预览计划中的更改，确保只有预期的更改被应用。

有什么用？

1. 基础设施自动化：Terraform 可以自动化创建、更新和删除云资源。
2. 版本控制和协作：由于 Terraform 配置是代码，所以可以使用版本控制工具（如 Git）进行管理。这还允许团队协同工作和审查基础设施更改。
3. 多云和混合云策略：Terraform 支持多个云提供者，使得多云和混合云部署成为可能。

GitOps

整个Jenkins X体验都基于Git。您开发的安装，扩展和应用程序通过集群Git存储库进行管理，这是Kubernetes集群的理想状态。

Kubernetes操作员在集群内运行，并轮询Git存储库中的更改，应用经过验证和批准的更新。集群Git仓库使用Helmfile来描述安装软件时应该使用的helm charts。Jenkins X生成Helmfiles中定义的Kubernetes资源，并将其提交回Git，以便始终可以通过Git看到确切的状态。

• helm file

helmfile 声明地将Kubernetes manifest、Kustomize configs和Charts部署为Helm版本。生成用于 ArgoCD 的一体化清单。

Helmfile是一个用于部署helm charts的声明性规范。它能让你...

• 保留图表值文件的目录，并在版本控制中维护更改。
• 将CI/CD应用于配置更改。
• 定期同步以避免环境中的偏差。

为了避免对 helm 的每次迭代进行升级， helmfile 可执行文件委托给 helm -因此，必须安装 helm 。

使用GitOps意味着在对集群进行任何更改时可以遵循熟悉的流程，使用审查，自动化，可追溯性和回滚来给予对消费更改的更好控制。

Jenkins X还使用GitOps作为升级的方式，包括新版本的图像，Helm Charts和包。

helmfile 入门

假设表示您的头盔释放的期望状态的 helmfile.yaml 看起来像：

repositories:
- name: prometheus-community
  url: https://prometheus-community.github.io/helm-charts

releases:
- name: prom-norbac-ubuntu
  namespace: prometheus
  chart: prometheus-community/prometheus
  set:
  - name: rbac.create
    value: false

通过运行以下命令将Kubernetes集群状态同步到所需状态：

helmfile apply

恭喜你！现在，您的第一个Prometheus部署已经在集群中运行。

通过引用在 helmfile.yaml 上迭代：

• Configuration 配置
• CLI reference CLI参考
• Helmfile Best Practices Guide

Secret Management

如上所述使用GitOps确实存在一个挑战，即在哪里存储集群的秘密，因为将它们保存在Git中是不安全的。有一种方法可以加密秘密并将其存储在Git中，但存在一个可用性问题，这使得该方法使用起来并不容易。Jenkins X更喜欢使用真实的秘密提供商解决方案，如Vault或可能的云托管解决方案，如Google，Azure或Amazon Secrets管理器。

Jenkins X GitOps与External Secrets一起提供集成的体验，因此您的秘密的真实来源是秘密管理器，并且在需要时将值复制到集群中。

Pipelines

默认情况下，Jenkins X与Tekton一起提供了一种干净的声明性云原生方式来描述管道。结合Lighthouse Jenkins X，可以通过Git轻松继承版本化的共享管道步骤，简单的语法提供了灵活性和易于维护。

Jenkins X也可以很好地与Jenkins一起工作，为具有传统工作负载的用户提供支持。这不是默认安装，但与Jenkins X很容易安装任何掌舵图，所以设计与我们的鼓舞人心的项目Jenkins伟大。

ChatOps

随着越来越多的微服务需要自动化，Jenkins X提供了通过对pull request的注释与pipeline进行交互的能力。Lighthouse是从Prow演变而来的，Prow在Kubernetes生态系统中被大量使用，为触发测试、批准、保持和开发人员在日常活动中使用的其他常见命令提供一致的开发人员工作流程。

Developer experience

沿着上面提到的ChatOps，Jenkins X旨在帮助开发人员以一致的方式使用他们的微服务，使用CLI或GUI开发人员可以利用加速书推荐的经过验证的方法。

无论是创建还是导入新项目，都可以自动设置CI和CD，打包应用程序，以便它们可以在Kubernetes上部署和运行，或者只是作为库发布供下游应用程序使用。

Jenkins X帮助团队在构建、开发和改进的方式上保持一致性。

jx CLI帮助开发人员使用他们的终端与Jenkins X交互。

对于GUI，Jenkins X有一个Octant插件。Octant在集群外部运行，并使用用户必须与Kubernetes资源交互的身份验证和权限。

Tekton 介绍：

Tekton 是一个强大而灵活的 Kubernetes 原生开源框架，可用于创建持续集成和交付 (CI/CD) 系统。该框架可让您跨多个云服务商或本地系统进行构建、测试和部署，无需操心基础实现细节。

Tekton 提供开源组件来帮助您标准化 CI/CD 工具和跨不同供应商、语言和部署环境的流程。Tekton 提供的流水线、版本、工作流和其他 CI/CD 组件所遵循的行业规范均适用于 Jenkins、Jenkins X、Skaffold、Knative 等现有的 CI/CD 工具。

Tekton 提供的内置最佳做法可让您快速创建云原生 CI/CD 流水线。其目标是让开发者创建和部署不可变映像、管理基础架构的版本控制机制，或者更轻松地执行回滚。借助 Tekton，您还可以利用高级部署模式，例如滚动部署、蓝/绿部署、Canary 部署或 GitOps 工作流。

Tekton 可让您跨多个环境（例如虚拟机、无服务器、Kubernetes 或 Firebase 环境）进行构建、测试和部署。您还可以使用 Tekton 流水线跨多个云服务商或混合环境进行部署。

Tekton 赋予您充分的灵活性，您可以使用自己偏好的 CI/CD 工具创建功能强大的流水线。Tekton 让您无需操心基础实现，只需根据团队的要求选择构建、测试和部署工作流即可。

Source Repositories

源代码控制管理（SCM）已配置为使用Jenkins X运行CI/CD管道的存储库表示为源代码存储库。Source Repositories是Kubernetes自定义资源（CR），作用域为命名空间，并在开发命名空间/环境中创建。

💡简单的一个案例如下：

apiVersion: jenkins.io/v1
kind: SourceRepository
metadata:
  labels:
    gitops.jenkins-x.io/pipeline: namespaces
    owner: jenkins-x
    provider: github
    repository: jx
  name: jenkins-x-jx
  namespace: jx
spec:
  httpCloneURL: https://github.com/jenkins-x/jx.git
  org: jenkins-x
  provider: https://github.com
  providerKind: github
  providerName: github
  repo: jx
  url: https://github.com/jenkins-x/jx

这显示了命名空间 jx 中名为 jenkins-x-jx 的源存储库。它表示 jenkins-x 组织中名为 jx 的存储库，该存储库托管在 github 中。

您可以通过运行以下命令查看集群中的所有源资料库：

kubectl get sourcerepositories -A

Environments

Environment是Jenkins X中的Kubernetes自定义资源（CR），应用程序代码位于其中。环境的例子包括开发、测试、试运行和生产。环境的范围是kubernetes命名空间，本质上是用额外的Jenkins X相关元数据扩展命名空间。

安装Jenkins X后，将创建一个开发环境。这是安装所有Jenkins X相关资源的环境，如灯塔，构建控制器，nexus，图表博物馆。默认情况下，开发环境位于 jx 命名空间中，但它是可配置的。这也是所有管道运行的环境。

其他环境（如登台和生产环境）可以与开发环境位于同一个集群中，也可以位于远程集群中。

环境可以是不同的类型：

• Permanent 永久
• Preview 预览
• Test 测试
• Edit 编辑
• Development 发展

apiVersion: jenkins.io/v1
kind: Environment
metadata:
  labels:
    env: dev
  name: dev
  namespace: jx
spec:
  kind: Development
  label: Development
  namespace: jx
  promotionStrategy: Never
  source:
    ref: master
    url: https://github.com/jenkins-x/jx3-eks-vault.git
  webHookEngine: Lighthouse

这是一个类型为 Development 的环境，位于命名空间 jx 中。它的提升策略设置为 never ，不允许在此开发命名空间中部署应用程序特定的代码。

您可以通过运行以下命令查看群集中的所有环境：

kubectl get environments -A

Pipeline activites

Jenkins X为作业创建管道活动。它是一个Kubernetes自定义资源（CR），作用域为命名空间。

• 只需修改 .lighthouse/jenkins-x 文件夹中的Task、Pipeline或PipelineRun文件，即可轻松编辑任何git仓库中的任何管道
• 在任何git仓库中添加新的pipeline，以重用从仓库中的tekton目录等地方找到的任何任务文件

Catalog 目录

随着我们创建越来越多的软件，我们往往会看到Git存储库和微服务的数量爆炸式增长。

每个存储库都需要自动化的CI和CD;但是我们如何管理我们需要的数百个管道-同时还可以轻松地跨存储库共享管道并允许每个存储库在需要时进行自定义？

Jenkins X解决了这个问题：

• 管道、任务和步骤通过Tekton YAML定义，允许您使用任何Tekton工具，如IDE完成和验证
• 我们支持一个 image: uses:sourceURI 符号，它允许你从git仓库中继承步骤，而不必将源代码复制/粘贴到仓库中。

比如说，你创建一个新的 channel：

tasks:
- name: from-build-pack
  taskSpec:
    stepTemplate:
      image: uses:jenkins-x/jx3-pipeline-catalog/tasks/javascript/release.yaml@versionStream
    steps:
    - image: uses:jenkins-x/jx3-pipeline-catalog/tasks/git-clone/git-clone.yaml@versionStream
    - name: next-version
    - name: jx-variables
    - name: build-npm-install
    - name: build-npm-test
    - name: build-container-build
    - name: promote-changelog
    - name: promote-helm-release
    - name: promote-jx-promote

你可能想知道这些 uses: 字符串是什么意思。

引用任务或步骤

我们可以在任务中引用 Task 或 Step ，而不是在存储库之间复制粘贴任务和步骤YAML，如下所示：

• 引用任务中的所有步骤

taskSpec:
  steps:
  - image: uses:sourceURI

• 引用任务中的单个命名步骤

  taskSpec:
    stepTemplate:
      image: uses:sourceURI
    steps:
    - name: mystep

SourceURI表示法

源URI表示法通过特殊的 image 前缀uses：on step启用，或者如果步骤上的图像为空，则 stepTemplate: 具有 image 前缀uses：

我们从ko和mink那里借鉴了这个想法;在图像URI上使用自定义前缀的想法。

- image: uses:owner/repository/pathToFile@version

这引用了https://github.com存储库中的 owner/repository 和@version，可以是git标签、分支或SHA。

- image: uses:lighthouse:owner/repository/pathToFile@version

Environments

Jenkins X支持多种环境来托管应用程序，例如 Development ， Staging 和 Production 。

1. Development (开发环境)
   • 目的：这是开发者用来编写、测试和调试代码的环境。在这里，新的功能、bug修复和代码更新首先被实现和验证。
   • 稳定性：由于它是一个实验性的环境，所以可能相对不稳定。开发者可能会频繁地更改和更新代码。
   • 数据：通常使用模拟数据或者复制的生产数据（但是经过脱敏处理）。
   • 访问：通常只有开发团队可以访问。
2. Staging (预生产或者测试环境)
   • 目的：这是一个模拟生产环境的地方，主要用于在上线到真正的生产环境之前进行测试和验证。它帮助确保应用程序在生产环境中的行为与预期相符。
   • 稳定性：应该尽量与生产环境保持一致，以便进行真实的测试。
   • 数据：可能使用与生产环境相似的数据来进行测试，确保测试的真实性。但在使用真实数据之前，通常会进行脱敏处理。
   • 访问：测试团队、质量保证(QA)团队和部分开发团队成员可以访问。
3. Production (生产环境)
   • 目的：这是真正的运行环境，用于为最终用户提供应用程序或服务。所有的功能和更新，在经过开发和预生产测试后，最终会部署到这里。
   • 稳定性：这是所有环境中最重要和最稳定的。任何在此环境中的变更都需要经过严格的测试和验证。
   • 数据：包含真实和实时的数据。
   • 访问：最终用户、运营团队、部分开发团队和IT支持团队可以访问。

您还可以使用不同类型的测试环境：系统、集成、负载、浸泡或回归测试。

默认配置是单个集群设置，其中 Staging 和 Production 环境映射到同一集群内的本地命名空间 jx-staging 和 jx-production 。

但是，对于真实的企业设置，我们建议使用多集群设置，其中您的 Production 和 Staging 环境设置在单独的集群中;理想情况下，使用单独的云提供商帐户，以便它们可以彼此完全隔离。

Git

每个kubernetes集群都有一个git仓库，这样所有命名空间中的所有kubernetes资源都可以由GitOps管理。每个集群还可以有一个单独的基础设施git存储库（例如，用于Terraform）来定义云资源（存储桶、IAM角色、kubernetes集群、节点池、VPN、防火墙等）。

因此，如果您使用多集群设置，则每个集群都有git repository来定义该集群中所有命名空间中的kubernetes资源。

例如如果将 Dev 、 Staging 和 Production 放在单独的集群中，那么你将有3个包含 helmfile.yaml 文件的git仓库。如果你使用一个集群，你将有一个git仓库。

Configuration 配置

在你的开发集群git仓库中，jx-requirements.yml文件被用来定义哪些是默认环境，用于在你的仓库上进行升级。

环境的默认配置如下所示：

apiVersion: core.jenkins-x.io/v4beta1
kind: Requirements
spec:
  ...
  environments:
  - key: dev
  - key: staging
  - key: production

这默认意味着 Staging 和 Production 是本地集群中的命名空间（ jx-staging 和 jx-production ）。 Staging 将使用 Auto 促销， Production 将使用 Manual 促销（稍后将详细介绍）。

Multi cluster 多集群

当您为 Staging 或 Production 设置远程群集时，可以删除这些环境的上述条目。

然后，当您将远程集群存储库导入到开发环境中时（在拉取请求上设置CI/CD并启用升级），生成的拉取请求将修改您的 jx-requirements.yml 以添加远程集群的远程条目。

例如在通过jx项目导入和pull请求合并导入远程 production 环境之后，它应该看起来像：

apiVersion: core.jenkins-x.io/v4beta1
kind: Requirements
spec:
  ...
  environments:
    - key: dev
      repository: my-dev-environment
    - key: staging
    - key: production
      owner: myowner
      repository: my-prod-repo
      remoteCluster: true

每个存储库的自定义环境

END 链接

• ⬆️上一节🔗 ️下一节🔗

• Ⓜ️回到目录🏠

• 🫵参与贡献💞❤️‍🔥💖)

• ✴️版权声明 © ：本书所有内容遵循CC-BY-SA 3.0协议（署名-相同方式共享）©