网络研讨会系列:使用Helm的Kubernetes包管理和使用JenkinsX的CI/CD
网络研讨会系列
本文补充了 使用 Kubernetes 进行 CI/CD 的网络研讨会系列。 该系列讨论了如何采用云原生方法来构建、测试和部署应用程序,涵盖发布管理、云原生工具、服务网格和可与 Kubernetes 一起使用的 CI/CD 工具。 它旨在帮助有兴趣将 CI/CD 最佳实践与 Kubernetes 集成到他们的工作流程中的开发人员和企业。
本教程包括本系列第二部分的概念和命令,使用 Helm 进行 Kubernetes 包管理和使用 Jenkins X 进行 CI/CD。
警告: 本教程中的过程仅用于演示目的。 因此,他们没有遵循生产就绪部署所需的最佳实践和安全措施。
介绍
为了在部署应用程序时减少错误和组织复杂性,CI/CD 系统必须包括用于包管理/部署的强大工具和具有自动化测试的管道。 但在现代生产环境中,基于云的基础设施日益复杂,可能会给构建可靠的 CI/CD 环境带来问题。 为解决这个问题而开发的两个 Kubernetes 特定工具是 Helm 包管理器和 Jenkins X 管道自动化工具。
Helm 是专为 Kubernetes 设计的包管理器,由 Cloud Native Computing Foundation (CNCF) 与 Microsoft、Google、Bitnami 和 Helm 贡献者社区合作维护。 在高层次上,它实现了与 APT 或 YUM 等 Linux 系统包管理器相同的目标:在后台管理应用程序和依赖项的安装,并向用户隐藏复杂性。 但是对于 Kubernetes,对这种管理的需求更加明显:安装应用程序需要对 YAML 文件进行复杂而繁琐的编排,升级或回滚版本可能非常困难,甚至不可能。 为了解决这个问题,Helm 运行在 Kubernetes 之上,将应用程序打包成预先配置好的资源,称为 charts,用户可以通过简单的命令进行管理,使共享和管理应用程序的过程更加人性化。友好。
Jenkins X 是一个 CI/CD 工具,用于自动化 Kubernetes 的生产管道和环境。 使用 Docker 镜像、Helm 图表和 Jenkins 管道引擎,Jenkins X 可以自动管理发布和版本,并在 GitHub 上的环境之间推广应用程序。
在 CI/CD with Kubernetes 系列 的第二篇文章中,您将通过以下方式预览这两个工具:
- 使用 Helm 管理、创建和部署 Kubernetes 包。
- 使用 Jenkins X 构建 CI/CD 管道。
尽管各种 Kubernetes 平台都可以使用 Helm 和 Jenkins X,但在本教程中,您将运行在本地环境中设置的模拟 Kubernetes 集群。 为此,您将使用 Minikube,该程序允许您在自己的机器上试用 Kubernetes 工具,而无需设置真正的 Kubernetes 集群。
在本教程结束时,您将对这些 Kubernetes 原生工具如何帮助您为云应用程序实现 CI/CD 系统有一个基本的了解。
先决条件
要遵循本教程,您将需要:
- 具有 16 GB RAM 或以上的 Ubuntu 16.04 服务器。 由于本教程仅用于演示目的,因此命令从 root 帐户运行。 请注意,此帐户的无限制权限不符合生产就绪的最佳实践,可能会影响您的系统。因此,建议在虚拟机或虚拟机等测试环境中执行这些步骤DigitalOcean Droplet。
- 一个 GitHub 帐户 和 GitHub API 令牌。 请务必记录此 API 令牌,以便您可以在本教程的 Jenkins X 部分中输入它。
- 熟悉 Kubernetes 概念。 详情请参考文章【X28X】Kubernetes简介【X61X】。
第 1 步 — 使用 Minikube 创建本地 Kubernetes 集群
在设置 Minikube 之前,您必须安装它的依赖项,包括 Kubernetes 命令行工具 kubectl、双向数据传输中继 socat 和容器程序 Docker[X222X ]。
首先,确保系统的包管理器可以使用 apt-transport-https
通过 HTTPS 访问包:
apt-get update apt-get install apt-transport-https
接下来,为了确保 kubectl 下载有效,请将 Google 官方存储库的 GPG 密钥添加到您的系统中:
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
添加 GPG 密钥后,通过在文本编辑器中打开文件来创建文件 /etc/apt/sources.list.d/kubernetes.list
:
nano /etc/apt/sources.list.d/kubernetes.list
打开此文件后,添加以下行:
/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
这将向您的系统显示下载 kubectl 的源。 添加该行后,保存并退出文件。 使用 nano 文本编辑器,您可以通过按 CTRL+X
、键入 y
并按 ENTER
来执行此操作。
最后,更新 APT 的源列表并安装 kubectl
、socat
和 docker.io
:
apt-get update apt-get install -y kubectl socat docker.io
注意: Minikube 要模拟 Kubernetes 集群,您必须下载 docker.io
包,而不是较新的 docker-ce
版本。 对于生产就绪环境,docker-ce
将是更合适的选择,因为它在官方 Docker 存储库中得到更好的维护。
现在您已经安装了 kubectl,您可以继续 安装 Minikube。 首先,使用 curl
下载程序的二进制文件:
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.28.0/minikube-linux-amd64
接下来,更改刚刚下载的文件的访问权限,以便您的系统可以执行它:
chmod +x minikube
最后,将 minikube
文件复制到 /usr/local/bin/
的可执行路径并从主目录中删除原始文件:
cp minikube /usr/local/bin/ rm minikube
在您的机器上安装 Minikube 后,您现在可以启动该程序。 要创建 Minikube Kubernetes 集群,请使用以下命令:
minikube start --vm-driver none
标志 --vm-driver none
指示 Minikube 使用容器而不是虚拟机在本地主机上运行 Kubernetes。 以这种方式运行 Minikube 意味着您不需要下载 VM 驱动程序,但也意味着 Kubernetes API 服务器将以 root 身份运行不安全。
警告: 因为具有root权限的API服务器将无限制地访问本地主机,所以不建议在个人工作站上使用none
驱动运行Minikube。
现在您已经启动了 Minikube,请检查以确保您的集群正在使用以下命令运行:
minikube status
您将收到以下输出,其中您的 IP 地址代替了 your_IP_address
:
minikube: Running cluster: Running kubectl: Correctly Configured: pointing to minikube-vm at your_IP_address
现在您已经使用 Minikube 设置了模拟 Kubernetes 集群,您可以通过在集群顶部安装和配置 Helm 包管理器来获得 Kubernetes 包管理的经验。
第 2 步 — 在集群上设置 Helm 包管理器
为了协调 Kubernetes 集群上应用程序的安装,您现在将安装 Helm 包管理器。 Helm 由一个在集群外运行的 helm
客户端和一个在集群内管理应用程序发布的 tiller
服务器组成。 您必须安装和配置两者才能在集群上成功运行 Helm。
要安装 Helm 二进制文件,首先使用 curl
从官方 Helm GitHub 存储库下载以下 安装脚本 到名为 get_helm.sh
的新文件中:
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
由于此脚本需要 root 访问权限,因此更改 get_helm.sh
的权限,以便文件的所有者(在本例中为 root)可以读取、写入和执行它:
chmod 700 get_helm.sh
现在,执行脚本:
./get_helm.sh
脚本完成后,您将 helm
安装到 /usr/local/bin/helm
和 tiller
安装到 /usr/local/bin/tiller
。
虽然现在安装了 tiller
,但它还没有正确的角色和权限来访问 Kubernetes 集群中的必要资源。 要将这些角色和权限分配给 tiller
,您必须创建一个名为 tiller
的 服务帐户 。 在 Kubernetes 中,服务帐户代表在 pod 中运行的进程的身份。 进程通过服务帐户进行身份验证后,它可以联系 API 服务器并访问集群资源。 如果 pod 没有分配特定的服务帐户,它会获得默认服务帐户。 您还必须创建授权 tiller
服务帐户的 基于角色的访问控制 (RBAC) 规则。
在 Kubernetes RBAC API 中,role 包含确定一组权限的规则。 角色可以定义为 namespace
或 cluster
的范围,并且只能授予对单个命名空间内资源的访问权限。 ClusterRole
可以在集群级别创建相同的权限,授予对集群范围资源(如节点)和命名空间资源(如 Pod)的访问权限。 要为 tiller
服务帐户分配正确的角色,请创建一个名为 rbac_helm.yaml
的 YAML 文件并在文本编辑器中打开它:
nano rbac_helm.yaml
将以下行添加到文件中以配置 tiller
服务帐户:
rbac_helm.yaml
apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system - kind: User name: "admin" apiGroup: rbac.authorization.k8s.io - kind: User name: "kubelet" apiGroup: rbac.authorization.k8s.io - kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io
在前面的文件中,ServiceAccount
允许 tiller
进程作为经过身份验证的服务帐户访问 apiserver。 ClusterRole
授予角色某些权限,ClusterRoleBinding
将该角色分配给 subjects
列表,包括 tiller
服务帐户、[ X153X] 和 kubelet
用户,以及 system:serviceaccounts
组。
接下来,使用以下命令在 rbac_helm.yaml
中部署配置:
kubectl apply -f rbac_helm.yaml
部署了 tiller
配置后,您现在可以使用 --service-acount
标志初始化 Helm 以使用您刚刚设置的服务帐户:
helm init --service-account tiller
您将收到以下输出,表示初始化成功:
OutputCreating /root/.helm Creating /root/.helm/repository Creating /root/.helm/repository/cache Creating /root/.helm/repository/local Creating /root/.helm/plugins Creating /root/.helm/starters Creating /root/.helm/cache/archive Creating /root/.helm/repository/repositories.yaml Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com Adding local repo with URL: http://127.0.0.1:8879/charts $HELM_HOME has been configured at /root/.helm. Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy. To prevent this, run `helm init` with the --tiller-tls-verify flag. For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation Happy Helming!
这会在 kube-system
命名空间中创建一个 tiller
pod。 它还在 $HOME
目录中创建 .helm
默认存储库,并在 https://kubernetes-charts.storage.googleapis.com
和本地 Helm 存储库 http://127.0.0.1:8879/charts
配置默认 Helm 稳定图表存储库。
要确保 tiller
pod 正在 kube-system
命名空间中运行,请输入以下命令:
kubectl --namespace kube-system get pods
在您的 pod 列表中,将出现 tiller-deploy
,如以下输出所示:
OutputNAME READY STATUS RESTARTS AGE etcd-minikube 1/1 Running 0 2h kube-addon-manager-minikube 1/1 Running 0 2h kube-apiserver-minikube 1/1 Running 0 2h kube-controller-manager-minikube 1/1 Running 0 2h kube-dns-86f4d74b45-rjql8 3/3 Running 0 2h kube-proxy-dv268 1/1 Running 0 2h kube-scheduler-minikube 1/1 Running 0 2h kubernetes-dashboard-5498ccf677-wktkl 1/1 Running 0 2h storage-provisioner 1/1 Running 0 2h tiller-deploy-689d79895f-bggbk 1/1 Running 0 5m
如果 tiller
pod 的状态为 Running
,它现在可以代表 Helm 从集群内部管理 Kubernetes 应用程序。
要确保整个 Helm 应用程序正常工作,请在 Helm 包存储库中搜索 MongoDB 等应用程序:
helm search mongodb
在输出中,您将看到适合您的搜索词的可能应用程序列表:
OutputNAME CHART VERSION APP VERSION DESCRIPTION stable/mongodb 5.4.0 4.0.6 NoSQL document-oriented database that stores JSON-like do... stable/mongodb-replicaset 3.9.0 3.6 NoSQL document-oriented database that stores JSON-like do... stable/prometheus-mongodb-exporter 1.0.0 v0.6.1 A Prometheus exporter for MongoDB metrics stable/unifi 0.3.1 5.9.29 Ubiquiti Network's Unifi Controller
现在您已经在 Kubernetes 集群上安装了 Helm,您可以通过创建示例 Helm 图表并从中部署应用程序来了解有关包管理器的更多信息。
第 3 步 — 创建图表并使用 Helm 部署应用程序
在 Helm 包管理器中,单个包称为 charts。 在图表中,一组文件定义了一个应用程序,该应用程序的复杂性可以从一个 pod 到一个结构化的全栈应用程序。 您可以从 Helm 存储库下载图表,也可以使用 helm create
命令创建自己的图表。
要测试 Helm 的功能,请使用以下命令创建一个名为 demo
的新 Helm 图表:
helm create demo
在您的主目录中,您将找到一个名为 demo
的新目录,您可以在其中创建和编辑自己的图表模板。
移动到 demo
目录并使用 ls
列出其内容:
cd demo ls
您将在 demo
中找到以下文件和目录:
演示
charts Chart.yaml templates values.yaml
使用文本编辑器打开 Chart.yaml
文件:
nano Chart.yaml
在里面,你会发现以下内容:
演示/Chart.yaml
apiVersion: v1 appVersion: "1.0" description: A Helm chart for Kubernetes name: demo version: 0.1.0
在这个 Chart.yaml
文件中,您会发现像 apiVersion
这样的字段,它必须始终是 v1
,一个 description
提供有关 [ X155X] 是图表的 name
,以及 Helm 用作发布标记的 version
编号。 检查完文件后,关闭文本编辑器。
接下来,打开 values.yaml
文件:
nano values.yaml
在此文件中,您将找到以下内容:
演示/values.yaml
# Default values for demo. # This is a YAML-formatted file. # Declare variables to be passed into your templates. replicaCount: 1 image: repository: nginx tag: stable pullPolicy: IfNotPresent nameOverride: "" fullnameOverride: "" service: type: ClusterIP port: 80 ingress: enabled: false annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" paths: [] hosts: - chart-example.local tls: [] # - secretName: chart-example-tls # hosts: # - chart-example.local resources: {} # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user. This also increases chances charts run on environments with little # resources, such as Minikube. If you do want to specify resources, uncomment the following # lines, adjust them as necessary, and remove the curly braces after 'resources:'. # limits: # cpu: 100m # memory: 128Mi # requests: # cpu: 100m # memory: 128Mi nodeSelector: {} tolerations: [] affinity: {}
通过更改 values.yaml
的内容,图表开发人员可以为图表中定义的应用程序提供默认值,控制副本数、图像库、入口访问、秘密管理等。 图表用户可以使用 helm install
使用自定义 YAML 文件为这些参数提供自己的值。 当用户提供自定义值时,这些值将覆盖图表的 values.yaml
文件中的值。
关闭 values.yaml
文件并使用以下命令列出 templates
目录的内容:
ls templates
在这里,您将找到可以控制图表不同方面的各种文件的模板:
模板
deployment.yaml _helpers.tpl ingress.yaml NOTES.txt service.yaml tests
现在您已经探索了 demo
图表,您可以通过安装 demo
来试验 Helm 图表安装。 使用以下命令返回您的主目录:
cd
使用 helm install
安装名为 web
的 demo
Helm 图表:
helm install --name web ./demo
您将获得以下输出:
OutputNAME: web LAST DEPLOYED: Wed Feb 20 20:59:48 2019 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE web-demo ClusterIP 10.100.76.231 <none> 80/TCP 0s ==> v1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE web-demo 1 0 0 0 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE web-demo-5758d98fdd-x4mjs 0/1 ContainerCreating 0 0s NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=demo,app.kubernetes.io/instance=web" -o jsonpath="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080:80
在此输出中,您将找到应用程序的 STATUS
,以及集群中相关资源的列表。
接下来,使用以下命令列出由 demo
Helm 图表创建的部署:
kubectl get deploy
这将产生列出您的活动部署的输出:
OutputNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE web-demo 1 1 1 1 4m
使用命令 kubectl get pods
列出您的 pod 将显示正在运行您的 web
应用程序的 pod,如下所示:
OutputNAME READY STATUS RESTARTS AGE web-demo-5758d98fdd-nbkqd 1/1 Running 0 4m
要演示 Helm 图表中的更改如何发布应用程序的不同版本,请在文本编辑器中打开 demo/values.yaml
并将 replicaCount:
更改为 3
和 image:tag:
从 stable
到 latest
。 在以下代码块中,您将看到 YAML 文件在完成修改后的样子,其中突出显示了更改:
演示/values.yaml
# Default values for demo. # This is a YAML-formatted file. # Declare variables to be passed into your templates. replicaCount: 3 image: repository: nginx tag: latest pullPolicy: IfNotPresent nameOverride: "" fullnameOverride: "" service: type: ClusterIP port: 80 . . .
保存并退出文件。
在部署 web
应用程序的这个新版本之前,请使用以下命令列出您的 Helm 版本,就像它们现在一样:
helm list
您将收到以下输出,其中包含您之前创建的一个部署:
OutputNAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE web 1 Wed Feb 20 20:59:48 2019 DEPLOYED demo-0.1.0 1.0 default
请注意,REVISION
被列为 1
,表明这是 web
应用程序的第一个版本。
要使用对 demo/values.yaml
所做的最新更改部署 web
应用程序,请使用以下命令升级应用程序:
helm upgrade web ./demo
现在,再次列出 Helm 版本:
helm list
您将收到以下输出:
OutputNAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE web 2 Wed Feb 20 21:18:12 2019 DEPLOYED demo-0.1.0 1.0 default
请注意,REVISION
已更改为 2
,表示这是第二次修订。
要查找 web
的 Helm 版本历史记录,请使用以下命令:
helm history web
这将显示 web
应用程序的两个版本:
输出
REVISION UPDATED STATUS CHART DESCRIPTION 1 Wed Feb 20 20:59:48 2019 SUPERSEDED demo-0.1.0 Install complete 2 Wed Feb 20 21:18:12 2019 DEPLOYED demo-0.1.0 Upgrade complete
要将您的应用程序回滚到修订版 1
,请输入以下命令:
helm rollback web 1
这将产生以下输出:
OutputRollback was a success! Happy Helming!
现在,调出 Helm 发布历史:
helm history web
您将收到以下列表:
OutputREVISION UPDATED STATUS CHART DESCRIPTION 1 Wed Feb 20 20:59:48 2019 SUPERSEDED demo-0.1.0 Install complete 2 Wed Feb 20 21:18:12 2019 SUPERSEDED demo-0.1.0 Upgrade complete 3 Wed Feb 20 21:28:48 2019 DEPLOYED demo-0.1.0 Rollback to 1
通过回滚 web
应用程序,您创建了与修订 1
具有相同设置的第三修订。 请记住,您始终可以通过在 STATUS
下找到 DEPLOYED
项来判断哪个版本处于活动状态。
为了准备下一部分,通过使用 helm delete
命令删除 web
版本来清理测试区域:
helm delete web
再次检查 Helm 发布历史:
helm history web
您将收到以下输出:
OutputREVISION UPDATED STATUS CHART DESCRIPTION 1 Wed Feb 20 20:59:48 2019 SUPERSEDED demo-0.1.0 Install complete 2 Wed Feb 20 21:18:12 2019 SUPERSEDED demo-0.1.0 Upgrade complete 3 Wed Feb 20 21:28:48 2019 DELETED demo-0.1.0 Deletion complete
REVISION 3
的STATUS
变成了DELETED
,说明你部署的web
实例已经被删除。 但是,尽管这确实删除了该版本,但它并没有从存储中删除它。 为了完全删除版本,运行带有 --purge
标志的 helm delete
命令。
helm delete web --purge
在此步骤中,您已使用 Helm 在 Kubernetes 上管理应用程序发布。 如果您想进一步学习 Helm,请查看我们的 Helm 简介,Kubernetes 包管理器 教程,或查看官方 Helm 文档。
接下来,您将使用 jx
CLI 设置和测试管道自动化工具 Jenkins X,以创建一个 CI/CD 就绪的 Kubernetes 集群。
第 4 步 — 设置 Jenkins X 环境
使用 Jenkins X,您可以使用内置的管道自动化和 CI/CD 解决方案从头开始创建 Kubernetes 集群。 通过安装 jx
CLI 工具,您将能够有效地管理应用程序发布、Docker 映像和 Helm 图表,此外还可以在 GitHub 中跨环境自动推广您的应用程序。
由于您将使用 jx
创建集群,因此您必须首先删除已有的 Minikube 集群。 为此,请使用以下命令:
minikube delete
这将删除本地模拟的 Kubernetes 集群,但不会删除您首次安装 Minikube 时创建的默认目录。 要清除机器上的这些,请使用以下命令:
rm -rf ~/.kube rm -rf ~/.minikube rm -rf /etc/kubernetes/* rm -rf /var/lib/minikube/*
从机器上完全清除 Minikube 后,您可以继续安装 Jenkins X 二进制文件。
首先,使用 curl
命令从官方 Jenkins X GitHub 存储库 下载压缩的 jx
文件,然后使用 tar
命令解压:
curl -L https://github.com/jenkins-x/jx/releases/download/v1.3.781/jx-linux-amd64.tar.gz | tar xzv
接下来,将下载的jx
文件移动到/usr/local/bin
处的可执行路径:
mv jx /usr/local/bin
Jenkins X 带有一个在 Kubernetes 集群中运行的 Docker Registry。 由于这是一个内部元素,因此自签名证书等安全措施可能会给程序带来麻烦。 要解决此问题,请将 Docker 设置为对本地 IP 范围使用不安全的注册表。 为此,创建文件 /etc/docker/daemon.json
并在文本编辑器中打开它:
nano /etc/docker/daemon.json
将以下内容添加到文件中:
/etc/docker/daemon.json
{ "insecure-registries" : ["0.0.0.0/0"] }
保存并退出文件。 要使这些更改生效,请使用以下命令重新启动 Docker 服务:
systemctl restart docker
要验证您是否已使用不安全的注册表配置 Docker,请使用以下命令:
docker info
在输出的末尾,您应该看到以下突出显示的行:
OutputContainers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 15 Server Version: 18.06.1-ce Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true . . . Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 0.0.0.0/0 127.0.0.0/8 Live Restore Enabled: false
现在您已经下载了 Jenkins X 并配置了 Docker 注册表,使用 jx
CLI 工具创建具有 CI/CD 功能的 Minikube Kubernetes 集群:
jx create cluster minikube --cpu=5 --default-admin-password=admin --vm-driver=none --memory=13314
在这里,您正在使用 Minikube 创建一个 Kubernetes 集群,使用标志 --cpu=5
设置 5 个 CPU 和 --memory=13314
为您的集群提供 13314 MB 内存。 由于 Jenkins X 是一个强大但大型的程序,这些规范将确保 Jenkins X 在此演示中正常工作。 此外,您正在使用 --default-admin-password=admin
将 Jenkins X 密码设置为 admin
和 --vm-driver=none
以在本地设置集群,就像您在步骤 1 中所做的那样。
当 Jenkins X 启动您的集群时,您将在整个过程的不同时间收到各种提示,这些提示为您的集群设置参数并确定它将如何与 GitHub 通信以管理您的生产环境。
首先,您将收到以下提示:
Output? disk-size (MB) 150GB
按 ENTER
继续。 接下来,系统将提示您输入您希望与 git 一起使用的名称、您希望与 git 一起使用的电子邮件地址以及您的 GitHub 用户名。 出现提示时输入其中的每一个,然后按 ENTER
。
接下来,Jenkins X 会提示你输入你的 GitHub API 令牌:
OutputTo be able to create a repository on GitHub we need an API Token Please click this URL https://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user:email,write:repo_hook,delete_repo Then COPY the token and enter in into the form below: ? API Token:
在此处输入您的令牌,或使用前面代码块中突出显示的 URL 创建具有适当权限的新令牌。
接下来,Jenkins X 会问:
Output? Do you wish to use GitHub as the pipelines Git server: (Y/n) ? Do you wish to use your_GitHub_username as the pipelines Git user for GitHub server: (Y/n)
两个问题都输入 Y
。
之后,Jenkins X 会提示你回答以下问题:
Output? Select Jenkins installation type: [Use arrows to move, type to filter] >Static Master Jenkins Serverless Jenkins ? Pick workload build pack: [Use arrows to move, type to filter] > Kubernetes Workloads: Automated CI+CD with GitOps Promotion Library Workloads: CI+Release but no CD
前者选择Static Master Jenkins
,后者选择Kubernetes Workloads: Automated CI+CD with GitOps Promotion
。 当提示为您的环境存储库选择组织时,请选择您的 GitHub 用户名。
最后,您将收到以下输出,验证安装成功并提供您的 Jenkins X 管理员密码。
OutputCreating GitHub webhook for your_GitHub_username/environment-horsehelix-production for url http://jenkins.jx.your_IP_address.nip.io/github-webhook/ Jenkins X installation completed successfully ******************************************************** NOTE: Your admin password is: admin ******************************************************** Your Kubernetes context is now set to the namespace: jx To switch back to your original namespace use: jx namespace default For help on switching contexts see: https://jenkins-x.io/developing/kube-context/ To import existing projects into Jenkins: jx import To create a new Spring Boot microservice: jx create spring -d web -d actuator To create a new microservice from a quickstart: jx create quickstart
接下来,使用 jx get
命令接收显示应用程序信息的 URL 列表:
jx get urls
此命令将生成类似于以下内容的列表:
Name URL jenkins http://jenkins.jx.your_IP_address.nip.io jenkins-x-chartmuseum http://chartmuseum.jx.your_IP_address.nip.io jenkins-x-docker-registry http://docker-registry.jx.your_IP_address.nip.io jenkins-x-monocular-api http://monocular.jx.your_IP_address.nip.io jenkins-x-monocular-ui http://monocular.jx.your_IP_address.nip.io nexus http://nexus.jx.your_IP_address.nip.io
您可以通过在浏览器中输入地址并输入您的用户名和密码,使用这些 URL 通过 UI 查看有关您的 CI/CD 环境的 Jenkins X 数据。 在这种情况下,这将是两者的“管理员”。
接下来,为了确保命名空间 jx
、jx-staging
和 jx-production
中的服务帐户具有管理员权限,请使用以下命令修改您的 RBAC 策略:
kubectl create clusterrolebinding jx-staging1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:expose --namespace=jx-staging
kubectl create clusterrolebinding jx-staging2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:default --namespace=jx-staging
kubectl create clusterrolebinding jx-production1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:expose --namespace=jx-productions
kubectl create clusterrolebinding jx-production2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:default --namespace=jx-productions
kubectl create clusterrolebinding jx-binding1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:expose --namespace=jx
kubectl create clusterrolebinding jx-binding2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:default --namespace=jx
现在您已经创建了内置 Jenkins X 功能的本地 Kubernetes 集群,您可以继续在平台上创建应用程序以测试其 CI/CD 功能并体验 Jenkins X 管道。
第 5 步 — 在您的 Jenkins X 环境中创建测试应用程序
在 Kubernetes 集群中设置 Jenkins X 环境后,您现在拥有可以帮助您自动化测试管道的 CI/CD 基础设施。 在此步骤中,您将通过在正常工作的 Jenkins X 管道中设置测试应用程序来尝试这一点。
出于演示目的,本教程将使用 CloudYuga 团队创建的示例 RSVP 应用程序。 您可以在 DO-Community GitHub 存储库 中找到此应用程序以及其他网络研讨会材料。
首先,使用以下命令从存储库中克隆示例应用程序:
git clone https://github.com/do-community/rsvpapp.git
克隆存储库后,进入 rsvpapp
目录并删除 git 文件:
cd rsvpapp rm -r .git/
要为新应用初始化 git 存储库和 Jenkins X 项目,您可以使用 jx create
从头开始或模板,或 jx import
从本地项目或 git 导入现有应用存储库。 对于本教程,通过在应用程序的主目录中运行以下命令来导入示例 RSVP 应用程序:
jx import
Jenkins X 将提示您输入您的 GitHub 用户名、是否要初始化 git、提交消息、您的组织以及您想要的存储库名称。 回答“是”以初始化 git,然后向其余提示提供您的个人 GitHub 信息和偏好。 当 Jenkins X 导入应用程序时,它将在应用程序的主目录中创建 Helm 图表和 Jenkinsfile。 您可以根据需要修改这些图表和 Jenkinsfile。
由于示例 RSVP 应用程序在其容器的端口 5000
上运行,因此修改您的 charts/rsvpapp/values.yaml
文件以匹配此。 在文本编辑器中打开 charts/rsvpapp/values.yaml
:
nano charts/rsvpapp/values.yaml
在此 values.yaml
文件中,将 service:internalPort:
设置为 5000
。 进行此更改后,您的文件应如下所示:
图表/rsvpapp/values.yaml
# Default values for python. # This is a YAML-formatted file. # Declare variables to be passed into your templates. replicaCount: 1 image: repository: draft tag: dev pullPolicy: IfNotPresent service: name: rsvpapp type: ClusterIP externalPort: 80 internalPort: 5000 annotations: fabric8.io/expose: "true" fabric8.io/ingress.annotations: "kubernetes.io/ingress.class: nginx" resources: limits: cpu: 100m memory: 128Mi requests: cpu: 100m memory: 128Mi ingress: enabled: false
保存并退出您的文件。
接下来,更改 charts/preview/requirements.yaml
以适合您的应用程序。 requirements.yaml
是一个 YAML 文件,开发人员可以在其中声明图表依赖关系,以及图表的位置和所需的版本。 由于我们的示例应用程序将 MongoDB 用于数据库目的,因此您需要修改 charts/preview/requirements.yaml
文件以将 MongoDB 列为依赖项。 使用以下命令在文本编辑器中打开文件:
nano charts/preview/requirements.yaml
通过在 alias: cleanup
条目之后添加 mongodb-replicaset
条目来编辑文件,如以下代码块中突出显示的那样:
图表/预览/requirements.yaml
# !! File must end with empty line !! dependencies: - alias: expose name: exposecontroller repository: http://chartmuseum.jenkins-x.io version: 2.3.92 - alias: cleanup name: exposecontroller repository: http://chartmuseum.jenkins-x.io version: 2.3.92 - name: mongodb-replicaset repository: https://kubernetes-charts.storage.googleapis.com/ version: 3.5.5 # !! "alias: preview" must be last entry in dependencies array !! # !! Place custom dependencies above !! - alias: preview name: rsvpapp repository: file://../rsvpapp
在这里,您已将 mongodb-replicaset
图表指定为 preview
图表的依赖项。
接下来,对您的 rsvpapp
图表重复此过程。 创建 charts/rsvpapp/requirements.yaml
文件并在文本编辑器中打开它:
nano charts/rsvpapp/requirements.yaml
打开文件后,添加以下内容,确保在填充的行之前和之后有一行空白:
图表/rsvpapp/requirements.yaml
dependencies: - name: mongodb-replicaset repository: https://kubernetes-charts.storage.googleapis.com/ version: 3.5.5
现在您已将 mongodb-replicaset
图表指定为 rsvpapp
图表的依赖项。
接下来,为了将示例 RSVP 应用程序的前端连接到 MongoDB 后端,请将 MONGODB_HOST
环境变量添加到 charts/rsvpapp/templates/
中的 deployment.yaml
文件中。 在文本编辑器中打开此文件:
nano charts/rsvpapp/templates/deployment.yaml
除了文件顶部的一个空行和文件底部的两个空行之外,将以下突出显示的行添加到文件中。 请注意,YAML 文件需要这些空行才能正常工作:
图表/rsvpapp/templates/deployment.yaml
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: {{ template "fullname" . }} labels: draft: {{ default "draft-app" .Values.draft }} chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}" spec: replicas: {{ .Values.replicaCount }} template: metadata: labels: draft: {{ default "draft-app" .Values.draft }} app: {{ template "fullname" . }} {{- if .Values.podAnnotations }} annotations: {{ toYaml .Values.podAnnotations | indent 8 }} {{- end }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" env: - name: MONGODB_HOST value: "mongodb://{{.Release.Name}}-mongodb-replicaset-0.{{.Release.Name}}-mongodb-replicaset,{{.Release.Name}}-mongodb-replicaset-1.{{.Release.Name}}-mongodb-replicaset,{{.Release.Name}}-mongodb-replicaset-2.{{.Release.Name}}-mongodb-replicaset:27017" imagePullPolicy: {{ .Values.image.pullPolicy }} ports: - containerPort: {{ .Values.service.internalPort }} resources: {{ toYaml .Values.resources | indent 12 }}
通过这些更改,Helm 将能够使用 MongoDB 作为其数据库来部署您的应用程序。
接下来,通过打开应用程序主目录中的文件来检查 Jenkins X 生成的 Jenkinsfile
:
nano Jenkinsfile
这个 Jenkinsfile
定义了每次将应用程序版本提交到 GitHub 存储库时触发的管道。 如果您想自动化您的代码测试,以便在每次触发管道时触发测试,您可以将测试添加到此文档中。
为了演示这一点,添加自定义测试用例,将 Jenkinsfile
中的 stage('Build Release')
替换为以下突出显示的行:
/rsvpapp/Jenkinsfile
. . . stages { stage('CI Build and push snapshot') { when { branch 'PR-*' } environment { PREVIEW_VERSION = "0.0.0-SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER" PREVIEW_NAMESPACE = "$APP_NAME-$BRANCH_NAME".toLowerCase() HELM_RELEASE = "$PREVIEW_NAMESPACE".toLowerCase() } steps { container('python') { sh "pip install -r requirements.txt" sh "python -m pytest tests/test_rsvpapp.py" sh "export VERSION=$PREVIEW_VERSION && skaffold build -f skaffold.yaml" sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:$PREVIEW_VERSION" dir('./charts/preview') { sh "make preview" sh "jx preview --app $APP_NAME --dir ../.." } } } } stage('Build Release') { when { branch 'master' } steps { container('python') { // ensure we're not on a detached head sh "git checkout master" sh "git config --global credential.helper store" sh "jx step git credentials" // so we can retrieve the version in later steps sh "echo \$(jx-release-version) > VERSION" sh "jx step tag --version \$(cat VERSION)" sh "pip install -r requirements.txt" sh "python -m pytest tests/test_rsvpapp.py" sh "export VERSION=`cat VERSION` && skaffold build -f skaffold.yaml" sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:\$(cat VERSION)" } } } . . .
通过添加的行,Jenkins X 管道将安装依赖项并在您提交对应用程序的更改时执行 Python 测试。
现在您已经更改了示例 RSVP 应用程序,使用以下命令将这些更改提交并推送到 GitHub:
git add * git commit -m update git push
当您将这些更改推送到 GitHub 时,您将触发应用程序的新构建。 如果您通过导航到 http://jenkins.jx.your_IP_address.nip.io
并输入“admin”作为您的用户名和密码来打开 Jenkins UI,您将找到有关您的新构建的信息。 如果您从页面左侧的菜单中单击“构建历史”,您应该会看到已提交构建的历史记录。 如果您单击构建旁边的蓝色图标,然后从左侧菜单中选择“控制台输出”,您将找到管道中自动化步骤的控制台输出。 滚动到此输出的末尾,您会发现以下消息:
Output. . . Finished: SUCCESS
这意味着您的应用程序已经通过了您的自定义测试,并且现在已成功部署。
Jenkins X 构建应用发布后,会将应用推广到 staging
环境。 要验证您的应用程序是否正在运行,请使用以下命令列出在 Kubernetes 集群上运行的应用程序:
jx get app
您将收到类似于以下内容的输出:
OutputAPPLICATION STAGING PODS URL rsvpapp 0.0.2 1/1 http://rsvpapp.jx-staging.your_IP_address.nip.io
从这里,您可以看到 Jenkins X 已将您的应用程序部署在您的 jx-staging
环境中,版本为 0.0.2
。 输出还显示了可用于访问应用程序的 URL。 访问此 URL 将显示示例 RSVP 应用程序:
接下来,使用以下命令检查应用程序的活动:
jx get activity -f rsvpapp
您将收到类似于以下内容的输出:
OutputSTEP STARTED AGO DURATION STATUS your_GitHub_username/rsvpappv/master #1 3h42m23s 4m51s Succeeded Version: 0.0.1 Checkout Source 3h41m52s 6s Succeeded CI Build and push snapshot 3h41m46s NotExecuted Build Release 3h41m46s 56s Succeeded Promote to Environments 3h40m50s 3m17s Succeeded Promote: staging 3h40m29s 2m36s Succeeded PullRequest 3h40m29s 1m16s Succeeded PullRequest: https://github.com/your_GitHub_username/environment-horsehelix-staging/pull/1 Merge SHA: dc33d3747abdacd2524e8c22f0b5fbb2ac3f6fc7 Update 3h39m13s 1m20s Succeeded Status: Success at: http://jenkins.jx.your_IP_address.nip.io/job/your_GitHub_username/job/environment-horsehelix-staging/job/master/2/display/redirect Promoted 3h39m13s 1m20s Succeeded Application is at: http://rsvpapp.jx-staging.your_IP_address.nip.io Clean up 3h37m33s 1s Succeeded your_GitHub_username/rsvpappv/master #2 28m37s 5m57s Succeeded Version: 0.0.2 Checkout Source 28m18s 4s Succeeded CI Build and push snapshot 28m14s NotExecuted Build Release 28m14s 56s Succeeded Promote to Environments 27m18s 4m38s Succeeded Promote: staging 26m53s 4m0s Succeeded PullRequest 26m53s 1m4s Succeeded PullRequest: https://github.com/your_GitHub_username/environment-horsehelix-staging/pull/2 Merge SHA: 976bd5ad4172cf9fd79f0c6515f5006553ac6611 Update 25m49s 2m56s Succeeded Status: Success at: http://jenkins.jx.your_IP_address.nip.io/job/your_GitHub_username/job/environment-horsehelix-staging/job/master/3/display/redirect Promoted 25m49s 2m56s Succeeded Application is at: http://rsvpapp.jx-staging.your_IP_address.nip.io Clean up 22m40s 0s Succeeded
在这里,您通过应用带有 -f rsvpapp
的过滤器来获取 RSVP 应用程序的 Jenkins X 活动。
接下来,使用以下命令列出在 jx-staging
命名空间中运行的 pod:
kubectl get pod -n jx-staging
您将收到类似于以下内容的输出:
NAME READY STATUS RESTARTS AGE jx-staging-mongodb-replicaset-0 1/1 Running 0 6m jx-staging-mongodb-replicaset-1 1/1 Running 0 6m jx-staging-mongodb-replicaset-2 1/1 Running 0 5m jx-staging-rsvpapp-c864c4844-4fw5z 1/1 Running 0 6m
此输出显示您的应用程序正在 jx-staging
命名空间中运行,以及后端 MongoDB 数据库的三个 pod,遵循您之前对 YAML 文件所做的更改。
现在您已经通过 Jenkins X 管道运行了一个测试应用程序,您可以尝试将此应用程序推广到生产环境。
第 6 步 — 将您的测试应用程序提升到不同的命名空间
为了完成这个演示,您将通过将示例 RSVP 应用程序提升到您的 jx-production
命名空间来完成 CI/CD 过程。
首先,在以下命令中使用 jx promote
:
jx promote rsvpapp --version=0.0.2 --env=production
这会将与 version=0.0.2
一起运行的 rsvpapp
应用程序提升到生产环境。 在整个构建过程中,Jenkins X 会提示你输入你的 GitHub 账户信息。 用您个人的回答来回答这些提示。
推广成功后,查看应用列表:
jx get app
您将收到类似于以下内容的输出:
OutputAPPLICATION STAGING PODS URL PRODUCTION PODS URL rsvpapp 0.0.2 1/1 http://rsvpapp.jx-staging.your_IP_address.nip.io 0.0.2 1/1 http://rsvpapp.jx-production.your_IP_address.nip.io
有了这个PRODUCTION
信息,就可以确认Jenkins X已经将rsvpapp
提升到生产环境了。 如需进一步验证,请在浏览器中访问生产 URL http://rsvpapp.jx-production.your_IP_address.nip.io
。 您应该看到正在运行的应用程序,现在从“生产”运行:
最后,在 jx-production
命名空间中列出您的 pod。
kubectl get pod -n jx-production
您会发现 rsvpapp
和 MongoDB 后端 pod 正在此命名空间中运行:
NAME READY STATUS RESTARTS AGE jx-production-mongodb-replicaset-0 1/1 Running 0 1m jx-production-mongodb-replicaset-1 1/1 Running 0 1m jx-production-mongodb-replicaset-2 1/1 Running 0 55s jx-production-rsvpapp-54748d68bd-zjgv7 1/1 Running 0 1m
这表明您已成功将 RSVP 示例应用程序提升到生产环境,在 CI/CD 管道末端模拟应用程序的生产就绪部署。
结论
在本教程中,您使用 Helm 管理模拟 Kubernetes 集群上的包,并自定义了 Helm 图表来打包和部署您自己的应用程序。 您还可以在 Kubernetes 集群上设置 Jenkins X 环境,并通过 CI/CD 管道从头到尾运行示例应用程序。
您现在已经拥有了在自己的 Kubernetes 集群上构建 CI/CD 系统时可以使用的这些工具的经验。 如果您想了解有关 Helm 的更多信息,请查看我们的 Helm 简介、Kubernetes 包管理器 和 如何使用 Helm 包管理器在 Kubernetes 集群上安装软件 文章. 要进一步探索 Kubernetes 上的 CI/CD 工具,您可以在本网络研讨会系列的下一个教程中了解 Istio 服务网格。