使用Helm和Jenkins为基于微服务的应用程序部署Kubernetes

Question

我们正在开发一个Web应用程序，该应用程序在同一存储库中具有多个微服务。

对于我们现有的整体应用程序，我们正在使用Helm和Jenkins将应用程序部署到Kubernetes。当涉及微服务时，我们正在努力定义CI / CD管道策略。以下是不清楚的问题：

• 对于整体应用程序，我有一个Dockerfile，一个Jenkinsfile和一个Helm Chart。对于构建阶段，我正在使用以下命令构建映像。

  docker.build("registry/myrepo/image:${env.BUILD_NUMBER}"
  

• 对于整体应用程序，我有一个包含多个values.yaml的图表，例如为多个环境配置的values.dev.yaml，values.prod.yaml。

所以我们的问题是

1。在微服务的Jenkinsfile中，我们应该如何为多个Dockerfile构建和推送多个容器？目前，每个微服务都在其根目录中拥有自己的Dockerfile。

2。Jenkins是否有可能区分我们要部署的微服务？我的意思是，有时我们可能仅针对特定服务进行了一些更改，我们希望部署此更改。那么我们应该组织独立的管道还是有什么方法可以处理相同的管道？

3。我们应该如何组织Helm图表来部署微服务Kubernetes？我们应该为每个服务创建多个图表还是创建仅引用一个values.yaml的多个模板？

Answer 1

好像你快到了。

1. 具有用于微服务的单独管道，这将构建，验证Docker映像并将其部署到Docker注册表。有一个单独的管道用于使用helm验证和部署整个堆栈。
2. 我假设您将使用git事件来识别更改？当微服务发生更改时，我认为它将被提交到单个存储库。这将触发一个git事件，您可以使用该事件触发相应微服务的管道。
3. 由于掌舵代表了整个应用程序堆栈，因此建议将其作为单个图表显示。如果微服务的复杂性增加，则将其拆分为子图。

当与每个微服务相关联的团队可以独立部署升级而不影响整个堆栈的可用性时，多个图表可以成为将来的成熟级别。

Answer 2

1. 每个微服务的jenkins都有单独的工作。
2. 有一个单独的工作，可以使用Helm chart部署整个应用程序