helm部署jenkins_将Helm Charts转换为Jenkins X Apps

helm部署jenkins

您的群集必然会运行许多第三方应用程序。 他们需要以某种方式安装和管理。 本文提供了一种使用Jenkins X Apps安装和维护第三方应用程序的可能方法。 我们将以Istio为例，说明如何将其官方Helm图表转换为Jenkins X Apps，并在此过程中探索它们提供的一些好处。

如果希望运行本文中的示例，则需要一个使用Jenkins X Boot安装了Jenkins X的Kubernetes集群。

如果您阅读Istio文档 ，您会发现需要安装两个图表。 istio-init和istio 。 您还将发现https://storage.googleapis.com/istio-release/releases/1.3.2/charts/中提供了存储图表的存储库。 给定一个Jenkins X App引用一个Helm图表的情况，我们需要添加两个App； 一个用于istio-init ，另一个用于istio 。 有了这些知识，我们可以添加两个应用程序中的第一个。 命令如下。

 jx add app istio-init \ 
     --repository https: //storage.googleapis.com/istio-release/releases/1.3.2/charts/ 

与之前一样，该命令的输出将有所不同，具体取决于您是否将Jenkins X Boot与dev库一起使用。

您应该看到指向新创建的拉取请求的链接。 打开它，然后单击“ 文件已更改”选项卡，以便我们查看建议的更改。

通过添加istio-init ，更改了与Prometheus相同的文件，除了两个（三个）位于不同的目录中。

env/istio-init/README.MD文件包含有关应用程序的信息以及来自原始图表的整个README。 接下来，我们有env/istio-init/templates/app.yaml ，它是App的定义，其中包含关于存储库jenkins.io/chart-repository的信息，即图表的名称（ jenkins.io/app-name ）和版本（ jenkins.io/app-version ）。 最后， istio-init与其他依赖项一起添加到env/requirements.yaml 。

如您所见，是从Jenkins X社区支持的目录中添加应用程序，还是从任何可用的Helm图表中添加应用程序都没关系。 在所有情况下，它都是基于Helm图表的，只要Jenkins X拥有有关图表的名称，版本和存储库的信息，它就会将其转换为App。

要完成此过程，请选择“ 对话”选项卡，然后单击“ 合并”拉取请求 ，然后单击“ 确认合并”按钮。 如您所知，这将触发一个Webhook，该Webhook将通知集群其中一个存储库发生了更改，结果将创建一个新的管道活动。

 CLUSTER_NAME=[...] # Replace `[...]` with the name of your cluster  jx get activity \ 
     --filter environment-$CLUSTER_NAME-dev/master \ 
     --watch 

成功完成活动后，请按ctrl + c停止观看活动。

最后，我们将通过输出名称中包含istio.io的自定义资源定义（CRD）来确认istio-init是否已正确安装。 如果您不熟悉Istio，则istio-init所做的就是安装这些CRD。 其余的设置随后出现。

 kubectl get crds | grep kubectl get crds | grep 'istio.io' 

除非自从我写这篇文章以来（2019年10月）以来Istio一直没有更改，否则输出中应该有23个CRD，我们可以得出结论，Istio设置的第一部分已正确完成。

而已。 您了解了如何通过jx add app命令创建Jenkins X Apps。 我们还探讨了如何更新或删除这些应用。 如果您使用的是dev存储库，则可以看到Apps的一些优势，主要是它们对GitOps流程的支持。 每次添加或删除应用程序时， jx都会创建一个新的分支和一个拉取请求，它会等待您通过将其合并到主数据库中来审查和批准更改。

但是，在某些情况下，您可能希望跳过审阅和合并请求请求。 您可能也想让Jenkins X为您做到这一点。 在这种情况下，您可以添加--auto-merge参数。

由于问题5761 ，-- --auto-merge参数可能不起作用。 随时监视它以查看是否已解决。

您应该了解， jx add app和jx delete app命令仅在dev存储库中处理文件并将其推送到Git。 其他一切都由集群中运行的Jenkins X完成。 这意味着您不必使用这些命令。 将它们更多地视为“帮助者”，而不是使用Apps的要求。 没有他们，我们也可以做到。 我们可以创建所需的文件并将其推送到Git。 结果，将在不执行任何命令（ git除外）的情况下添加新的App。

我们仍然需要应用第二张图表（ istio ），因此我们将以此为借口尝试在不执行jx命令的情况下添加App。

由于我们将要在dev存储库的本地副本中创建和修改一些文件，因此我们应该首先从GitHub获取最新的代码库。

 git pull 

现在我们有了该存储库最新版本的本地副本，我们可以创建一个新的App。 记住，这一次，我们正在探索如何通过自己创建文件而不是使用jx add app命令来做到这一点。

我们可以从两个方向应对这一挑战。 一种选择是从头开始创建所有文件。 另一种是复制其中一个现有应用程序的目录，并对其进行修改以适合我们的需求。 我们将选择第二个选项，因为它可能更简单。 鉴于我们已经拥有使用istio-init的应用程序，其文件可能是用作istio基础的最佳候选istio 。

 cp -r env/istio-init env/istio 

现在，我们将istio-init目录复制为istio ，我们要做的就是更改一些文件。 我们将跳过修改自述文件。 它仅对人类重要（我们可能会读），但在此过程中不起作用。 在“现实世界”的情况下，我希望您也进行更改。 但是，由于这不是“现实世界”，而是学习体验，因此我们无需花时间在上面。

我们可能需要更改三个文件。 如果我们想更改图表的任何默认值，则可以创建env/istio/templates/values.yaml 。 我们将跳过那个，因为istio很好。 相反，我们将专注于其他两个文件。

 cat env/istio/templates/app.yaml 

这就是我们要添加到集群中的应用程序的定义。 它是istio-init的副本，因此我们要做的就是将jenkins.io/app-name和name值从istio-init更改为istio 。 我们还将更改jenkins.io/chart-description 。 它仅用于提供信息。 但是，由于我们是很好的人，并且不想让其他人感到困惑，因此更改它可能为以后可能会探索它的人提供更多的清晰度。

进行这些更改的命令如下。

 cat env/istio/templates/app.yaml \ 
     | sed -e | sed -e 's@istio-init@istio@g' \ 
     | sed -e \ 
     's@initialize Istio CRDs@install Istio@g' \ 
     | tee env/istio/templates/app.yaml 

一个应用程序的定义本身是没有用的。 它的存在不会导致它在集群中运行。 我们需要将它添加为env/requirements.yaml另一个依赖项。 因此，让我们快速浏览一下其中的内容。

 cat env/requirements.yaml 

输出如下。

 dependencies:  - name: jxboot-resources 
   repository: http: //chartmuseum.jenkins-x.io  - alias: tekton 
   name: tekton 
   repository: http: //chartmuseum.jenkins-x.io  - alias: prow 
   condition: prow.enabled 
   name: prow 
   repository: http: //chartmuseum.jenkins-x.io  - alias: lighthouse 
   condition: lighthouse.enabled 
   name: lighthouse 
   repository: http: //chartmuseum.jenkins-x.io  - name: jenkins-x-platform 
   repository: http: //chartmuseum.jenkins-x.io  - name: istio-init 
   repository: https: //storage.googleapis.com/istio-release/releases/1.3.2/charts/ 
   version: 1.3 . 2 

除了最后一个依赖关系外，所有依赖关系都是系统默认配置下的依赖关系。 稍后，我们使用jx add app将istio-init添加到混合中。 现在我们也缺少istio的条目。 repository和version相同，唯一的区别在于name 。

 echo "- name: istio 
   repository: https: //storage.googleapis.com/istio-release/releases/1.3.2/charts/ 
   version: 1.3 . 2 " \ 
   | tee -a env/requirements.yaml 

剩下的就是将更改推送到GitHub，并使系统将实际状态收敛到所需状态，我们刚刚通过附加的App进行了扩展。 通常，我们将创建一个分支，将更改推送到该分支，创建一个拉取请求，然后将其合并到master分支。 那将是处理此更改或任何其他更改的正确方法。 但是，为了节省时间，我们以您已经知道如何创建PR的假设为前提，略过这一点。 如果不这样做，那么您就处于错误的行业。

 git add .  git commit -m "Added Istio"  git push  jx get activity \ 
     --filter environment-$CLUSTER_NAME-dev/master \ 
     --watch 

我们将更改提交并推送到master分支，并开始观察活动以确认更改已应用于集群。 新活动完成后，请按ctrl + c停止观看。

Istio应该完全正常运行。 我们可以通过列出所有名称中包含istio来确认这一点。

 kubectl get pods | grep istio 

这既不是时间，也不是深入Istio的地方。 那不是目标。 我仅将其用作将Jenkins X Apps添加到系统的不同方法的示例。

说到应用程序，让我们看看集群中当前正在运行哪些应用程序。 您已经看到jx具有几乎所有功能的辅助程序命令，因此发现检索apps也可用并不奇怪。

 jx get apps 

输出如下，至少对于使用Boot安装Jenkins X的用户而言。

 Name      Version Chart Repository                                                   Namespace Status              Description  istio-init 1.3 . 2 https: //storage.googleapis.com/istio-release/releases/1.3.2/charts/          READY FOR DEPLOYMENT Helm chart to initialize Istio CRDs  istio 1.3 . 2 https: //storage.googleapis.com/istio-release/releases/1.3.2/charts/          READY FOR DEPLOYMENT Helm chart to install Istio 

而已。 我们探索了几种添加，管理和删除Jenkins X Apps的常用方法。 我们很快将围绕它们进行简短的讨论。 现在，我们将删除istio和istio-init因为我们不再需要它们。

 git pull  jx delete app istio 

你知道下一步该怎么做。 合并PR，以便将更改（删除istio ）应用于系统。 通过对env/requirements.yaml文件的建议更改，我们可以看到。

您会注意到，无论是通过jx add app还是直接在Git中摆弄文件， jx delete app命令都可以使用。 它总是通过Git运行（除非您不使用dev仓库）。

下一个要消除的行是istio-init ，过程相同。

 git pull  jx delete app istio-init 

我会让您自己做剩下的事情（如果您使用的是Boot）。 合并那个公关！

而已。 您通过添加Apps学习了扩展Jenkins X平台的基础知识。 实际上，这不仅涉及扩展Jenkins X，而且还涉及具有可靠的方式将任何第三方应用程序添加到您的集群中。 但是，并非所有人都同样适合成为Jenkins X Apps。

Jenkins X Apps在至少两种情况下很有用。 当我们想要扩展Jenkins X时，毫无疑问，添加Apps是最佳选择。 鉴于应用可以是任何Helm图表，我们可以将任何应用转换为应用。

除了那些旨在扩展Jenkins X的图表之外，优秀的候选者是不需要在多个存储库中的图表。 例如，如果我们要运行两个Prometheus实例（一个用于测试，另一个用于生产），则最好将它们添加到关联的永久环境存储库中。 但是，许多都不适合在测试中运行或不值得验证。 普罗米修斯可能就是这种情况。 如果我们对其进行升级，但事实证明这是一个错误的选择，则不会对集群造成损害。 我们可能无法检索某些指标，但这只是暂时的，直到我们回滚到以前的版本为止。 例外是，如果我们将Horizo​​ntalPodAutoscaler挂钩到Prometheus指标，在这种情况下，在将新版本部署到生产中之前对其进行测试是至关重要的。 因此， 当应用程序仅应在生产环境中运行时（没有用于测试的第二个实例），由于应用程序提供了一些额外的好处，因此应用程序是一种更好的管理方式。

从本质上讲，Jenkins X Apps遵循与其他任何GitOps相同的原则。 它们的定义存储在Git中，我们可以创建拉取请求并查看更改，只有合并到master分支才能更改集群的状态。 使用Apps与定义登台，生产或任何其他永久环境存储库中的依赖项没有太大不同。 使它们“特别”的原因是增加了一些帮助程序功能和一些使管理更容易的约定。 我们有一个定义更好的管道。 分支和请求请求是自动创建的。 机密存储在保险柜中。 依存关系组织得更好。 等等等等。 我们仅探索了其中一些功能。 稍后，我们将看到更多活动，社区一定会随着时间的推移增加更多。

DevOps 2.6工具包：Jenkins X

您刚刚阅读的文章是The DevOps 2.6 Toolkit的摘录：JenkinsX。

翻译自: https://www.javacodegeeks.com/2019/10/converting-helm-charts-into-jenkins-x-apps.html

helm部署jenkins