-
默认的dashboard不好用,我们用kubesphere可以打通全部的devops链路;kubesphere集成了很多套件,集群要求较高
kuboard也很不错,集群要求不高
简介
- KubeSphere 是一款面向云原生设计的开源项目,在目前主流容器调度平台 Kubernetes之上构建的分布式多租户容器管理平台提供简单易用的操作界面以及向导式操作方式,在降低用户使用容器调度平台学习成本的同时,极大降低开发、测试、运维的日常工作的复杂度
Kubesphere安装
- 注意版本对应 v2.1
前提条件
安装前提环境
安装helm(master节点执行)
-
Helm是kubernetes的包管理器,包管理器类似于我们在Ubuntu中使用的apt、Centos中使用的yum或者Python中的pip一样,能快速查找、下载和安装软件包。Helm由客户端组件helm和服务端组件Tiller组成,能够将一组k8s资源打包统一管理,是查找、共享和使用为kubernetes构建的软件的最佳方式
-
下载Helm
-
1、配置了科学上网的
#直接执行脚本 curl -L https://git.io/get_helm.sh | bash 复制代码
-
2、下载源码包,解压后将可执行文件
helm
拷贝到/usr/local/bin
目录下即可,这样Helm
客户端就在这台机器上安装完成了下载遇到卡顿,暂停或者重启下载器多试几次
#centos 下载amd64.tar.gz 选择指定版本 #解压后将可执行文件helm拷贝到/usr/local/bin目录下即可,这样Helm客户端就在这台机器上安装完成了 tar -zxvf helm-v2.16.2-linux-amd64.tar.gz #将解压后的helm执行文件放入 /usr/local/bin/ ln -s ln -s /var/touchAirMallVolume/k8s/linux-amd64/helm /usr/local/bin/ helm version 复制代码
现在我们可以使用
Helm
命令查看版本了,会提示无法连接到服务端Tiller
:
-
-
默认开启了
RBAC
访问控制,所以我们需要为Tiller
创建一个ServiceAccount
,让他拥有执行的权限,详细内容可以查看 Helm 文档中的Role-based Access Control; 创建rbac.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 复制代码
应用:
kubectl apply -f helm-rbac.yaml
-
安装
tiller
#查看是否存在旧版 kubectl get deployment -n kube-system #删除旧版 kubectl delete deployment tiller-deploy -n kube-system #把默认的 google 的仓库地址替换成稳定的国内镜像地址,并指定account helm init --service-account=tiller --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.16.2 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts #查看 kubectl get pod -n kube-system -l app=helm #再次查看版本信息 helm version 复制代码
安装设置默认的存储类型
-
集群已有存储类型(StorageClass),执行
kubectl get sc
看下当前是否设置了默认的storageclass
若集群还没有准备存储请参考 安装 OpenEBS 创建 LocalPV 存储类型 ;用作开发测试环境,生产环境请确保集群配置了稳定的持久化存储
- 已有 Kubernetes 集群,并安装了 kubectl 或 Helm
- Pod 可以被调度到集群的 master 节点(可临时取消 master 节点的 Taint)
#查看所有节点的信息 kubectl get node -o wide #查看master是否已有taint kubectl describe node k8s-node1 | grep Taint #临时取消master节点的taint kubectl taint nodes k8s-node1 node-role.kubernetes.io/master:NoSchedule- 复制代码
-
创建命名空间并安装
#安装OpenEBS #创建名称空间 kubectl create ns openebs #安装openEBS kubectl apply -f https://openebs.github.io/charts/openebs-operator-1.5.0.yaml 复制代码
-
验证是否安装成功
查看所有的pod,直到所有pod的status变成running的时候(等待三分钟左右) kubectl get pods --all-namespaces #查看 kubectl get sc --all-namespaces 复制代码
-
如下将
openebs-hostpath
设置为 默认的 StorageClass:kubectl patch storageclass openebs-hostpath -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 复制代码
-
恢复master节点的 taint暂不操作,等kubesphere全部安装完成后,恢复也不迟
踩坑
上面OpenEBS安装完成后,一定不要立马恢复主节点的taint,否则在安装kubesphere的时候,会存在各种pods拉取失败的问题
在 Kubernetes 安装 KubeSphere
-
完整安装对于硬件要求非常高,因此,选择最小化安装
#第一种:网络环境好的 kubectl apply -f https://raw.githubusercontent.com/kubesphere/ks-installer/master/kubesphere-minimal.yaml #第二种:使用已下载好的yaml文件 kubectl apply -f kubesphere-mini.yaml #观察kubesphere pod的创建进度 kubectl get pods --all-namespaces #监控整个安装过程 kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=ks-install -o jsonpath='{.items[0].metadata.name}') -f 复制代码
#观察kubesphere pod的创建进度 kubectl get pods --all-namespaces 直到所有status 都变成running 复制代码
服务器性能越好,安装完成就越快,我这里大概等待了10分钟才完成
-
等待全部变为 running 状态,登录 kubeSphere 的控制台(最小化安装完成)
kubectl get pods --all-namespaces 复制代码
定制化安装(可插拔组件)
硬件要求,再次提高
1、master节点,主要是调度作用,4g内存差不多
2、两个node节点,各分配8g内存
- KubeSphere 在 2.1 版本的 Installer 对各功能组件进行了 解耦,快速安装将默认仅开启最小化安装(Minimal Installation),支持在安装前或安装后 自定义可插拔的功能组件的安装,使最小化安装 更快速轻量且资源占用更少,也方便不同用户 按需选择安装不同的功能组件
可插拔组件列表
-
KubeSphere 有以下六个可插拔功能组件,您可以根据需求,选择开启安装 KubeSphere 的功能组件。我们非常建议您开启这些功能组件来体验 KubeSphere 完整的功能以及端到端的解决方案
- KubeSphere 应用商店
- KubeSphere DevOps 系统:KubeSphere 针对容器与 Kubernetes 的应用场景,基于 Jenkins 提供了一站式 DevOps 系统,包括丰富的 CI/CD 流水线构建与插件管理功能,还提供 Binary-to-Image(B2I)、Source-to-Image(S2I),为流水线、S2I、B2I 提供代码依赖缓存支持,以及代码质量管理与流水线日志等功能;内置的 DevOps 系统将应用的开发和自动发布与容器平台进行了很好的结合,还支持对接第三方的私有镜像仓库和代码仓库形成完善的私有场景下的 CI/CD,提供了端到端的用户体验
- KubeSphere 日志系统:KubeSphere 提供了 强大且易用的日志查询、接收与管理功能,比如多租户日志管理、多级别日志查询 (包括项目、工作负载、容器组、容器以及关键字)、灵活方便的日志收集配置选项等。相较于 Kibana,KubeSphere 日志系统提供了 基于多租户的日志查询,不同的租户只能看到属于自己的日志信息
- KubeSphere Service Mesh(基于 Istio):KubeSphere 基于 Istio 微服务框架提供了可视化的微服务治理功能,无需代码无侵入即可实现 熔断、蓝绿发布、金丝雀发布、流量镜像、流量管控、限流、链路追踪(Tracing)等完善的微服务治理功能,从业务角度为微服务组件提供了服务治理的能力,降低了 Istio 服务网格的学习门槛
- KubeSphere 告警通知系统:KubeSphere 多租户告警系统支持灵活的告警策略和告警规则,支持邮件通知,并具备以下特性:
- 支持基于多租户、多维度的监控指标告警,目前告警策略支持集群管理员对节点级别和租户对工作负载级别等两个层级;
- 灵活的告警策略:可自定义包含多个告警规则的告警策略,并且可以指定通知规则和重复告警的规则;
- 丰富的监控告警指标:提供节点级别和工作负载级别的监控告警指标,包括容器组、CPU、内存、磁盘、网络等多个监控告警指标;
- 灵活的告警规则:可自定义某监控指标的检测周期长度、周期次数、告警等级等;目前支持邮件通知;
- 灵活的重复告警规则:可自定义重复告警周期、最大重复次数并和告警级别挂钩
- Metrics-server(HPA):KubeSphere 支持对 Deployment 设置 弹性伸缩 (HPA) ,支持根据集群的监控指标如 CPU 使用率和内存使用量来设置弹性伸缩,当业务需求增加时,KubeSphere 能够无缝地自动水平增加 Pod 数量,提高应用系统的稳定性
安装后如何开启 Metrics-server 安装
-
1、通过修改 ks-installer 的 configmap 可以选装组件,执行以下命令
kubectl edit cm -n kubesphere-system ks-installer 复制代码
参考如下修改 ConfigMap
··· metrics-server: enabled: True 复制代码
-
2、保存退出,参考 验证可插拔功能组件的安装 ,通过查询 ks-installer 日志或 Pod 状态验证功能组件是否安装成功
#所有pod的安装进度 #很重要 如果有存在createContainer状态 表示安装未完成 kubectl get pods --all-namespaces #日志查看 kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=ks-install -o jsonpath='{.items[0].metadata.name}') -f 复制代码
这一步操作,由于电脑性能原因,持续了15分钟才算基本完成
-
kubesphere的dashboard还可以对集群进行命令行操作
Kubesphere进阶
建立多租户系统
-
本文档面向初次使用 KubeSphere 的集群管理员用户,引导新手用户创建企业空间、创建新的角色和账户,然后邀请新用户进入企业空间后,创建项目和 DevOps 工程,帮助用户熟悉多租户下的用户和角色管理,快速上手 KubeSphere
-
目前,平台的资源一共有三个层级,包括 集群 (Cluster)、 企业空间 (Workspace)、 项目 (Project) 和 DevOps Project (DevOps 工程),层级关系如下图所示,即一个集群中可以创建多个企业空间,而每个企业空间,可以创建多个项目和 DevOps工程,而集群、企业空间、项目和 DevOps工程中,默认有多个不同的内置角色
-
示例逻辑
第一步:创建角色和账号
-
1.1、首先新建一个角色 (user-manager),为该角色授予账号管理和角色管理的权限,然后新建一个账号并给这个账号授予 user-manager 角色
平台角色--创建--user-manager--分配用户管理、角色管理的权限 复制代码
-
1.2、 平台管理 → 账户管理,可以看到当前集群中所有用户的列表,点击 创建 按钮
touch-air-hr --> 角色为 user-manager 复制代码
-
1.3、user-manager 账户登录来创建下表中的四个账号,
ws-manager
将用于创建一个企业空间,并指定其中一个用户名为ws-admin
作为企业空间管理员用户名 集群角色 职责 ws-manager workspaces-manager 创建和管理企业空间 ws-admin cluster-regular 管理企业空间下所有的资源 (本示例用于邀请新成员加入企业空间) project-admin cluster-regular 创建和管理项目、DevOps 工程,邀请新成员加入 project-regular cluster-regular 将被 project-admin 邀请加入项目和 DevOps 工程, 用于创建项目和工程下的工作负载、Pipeline 等资源
第二步:创建企业空间
-
企业空间 (workspace) 是 KubeSphere 实现多租户模式的基础,是用户管理项目、DevOps 工程和企业成员的基本单位
-
2.1、切换为
ws-manager
登录 KubeSphere,ws-manager 有权限查看和管理平台的所有企业空间;点击左上角的平台管理
→企业空间
,可见新安装的环境只有一个系统默认的企业空间 system-workspace,用于运行 KubeSphere 平台相关组件和服务,禁止删除该企业空间;在企业空间列表点击 创建mall-workspace -- 企业成员 -- 邀请成员邀请 ws-admin,并赋予企业空间管理员的角色
-
2.2、企业空间
mall-workspace
创建完成后,切换为ws-admin
登录 KubeSphere,点击左侧「进入企业空间」进入企业空间详情页ws-admin
可以从集群成员中邀请新成员加入当前企业空间,然后创建项目和 DevOps 工程。在左侧菜单栏选择
企业空间管理→
成员管理,点击
邀请成员;这一步需要邀请在 步骤 1.6. 创建的两个用户project-admin
和project-regular
进入企业空间,且分别授予workspace-regular
和workspace-viewer
的角色,此时该企业空间一共有如下三个用户:分别使用
project-admin
和project-regular
登录,观察不同,admin可以创建项目,regular只有浏览权限
第三步:创建项目
-
创建工作负载、服务和 CI/CD 流水线等资源之前,需要预先创建项目和 DevOps 工程
-
3.1、上一步将用户项目管理员
project-admin
邀请进入企业空间后,可切换为project-admin
账号登录 KubeSphere,默认进入 demo-workspace 企业空间下,点击 创建,选择 创建资源型项目在弹窗中的
project-regular
点击"+"
,在项目的内置角色中选择operator
角色。因此,后续在项目中创建和管理资源,都可以由project-regular
用户登录后进行操作3.2、再次使用
project-regular
账户登录,就可以看到它维护的项目
第四步:创建 DevOps 工程
-
4.1、继续使用
project-admin
用户创建 DevOps 工程。点击 工作台,在当前企业空间下,点击 创建,在弹窗中选择 创建一个 DevOps 工程。DevOps 工程的创建者project-admin
将默认为该工程的 Owner,拥有 DevOps 工程的最高权限 -
4.2、. 同上,这一步需要在
demo-devops
工程中邀请用户project-regular
,并设置角色为maintainer
,用于对工程内的 Pipeline、凭证等创建和配置等操作。菜单栏选择 工程管理 → 工程成员,然后点击 邀请成员,为用户project-regular
设置角色为maintainer
;后续在 DevOps 工程中创建 Pipeline 和凭证等资源,都可以由project-regular
用户登录后进行操作 -
4.3、再次使用
project-regular
账户登录,就可以看到它拥有两个项目,一个是微服务商城、另一个是自动化部署的devops
创建WordPress应用
-
WordPress 是使用 PHP 开发的博客平台,用户可以在支持 PHP 和 MySQL 数据库的环境中架设属于自己的网站;本文以创建一个 WordPress 应用 为例,以创建 KubeSphere 应用的形式将 WordPress 的组件(MySQL 和 WordPress)创建后发布至 Kubernetes 中,并在集群外访问 WordPress 服务
一个完整的 WordPress 应用会包括以下 Kubernetes 对象,其中 MySQL 作为后端数据库,Wordpress 本身作为前端提供浏览器访问
PersistentVolume(PV)是集群中由管理员配置的一段网络存储,它是集群中的资源,就像节点是集群资源一样;PV是容量插件,如Volumes,但其生命周期独立于使用PV的任何单个pod
PersistentVolumeClaim(PVC)是由用户进行存储的请求;它类似于pod,Pod消耗节点资源,PVC消耗PV资源
PVC和PV是一一对应的
前提条件
- 已创建了企业空间、项目和普通用户
project-regular
账号(该已账号已被邀请至示例项目),并开启了外网访问,请参考 多租户管理快速入门
创建密钥
- MySQL 的环境变量
MYSQL_ROOT_PASSWORD
即 root 用户的密码属于敏感信息,不适合以明文的方式表现在步骤中,因此以创建密钥的方式来代替该环境变量。创建的密钥将在创建 MySQL 的容器组设置时作为环境变量写入
创建MySQL密钥
-
1、以项目普通用户
project-regular
登录 KubeSphere,在当前项目下左侧菜单栏的 配置中心 选择 密钥,点击 创建 -
2、填写密钥的基本信息,完成后点击 下一步
- 名称:作为 MySQL 容器中环境变量的名称,可自定义,例如
mysql-secret
- 别名:别名可以由任意字符组成,帮助您更好的区分资源,例如
MySQL 密钥
- 描述信息:简单介绍该密钥,如
MySQL 初始密码
- 名称:作为 MySQL 容器中环境变量的名称,可自定义,例如
-
3、密钥设置页,填写如下信息,完成后点击 创建
- 类型:选择
默认
(Opaque) - Data:Data 键值对填写
MYSQL_ROOT_PASSWORD
和123456
- 类型:选择
创建WordPress密钥
- 同上,创建一个 WordPress 密钥,Data 键值对填写
WORDPRESS_DB_PASSWORD
和123456
创建存储卷
-
点击创建,配置可以都是默认的
创建应用
添加MySQL组件
添加WordPress组件
查看应用资源
-
1、在
工作负载
下查看 部署 和 有状态副本集 的状态,当它们都显示为运行中
,说明 WordPress 应用创建成功
外网访问
-
2、访问 WordPress 服务前,查看 wordpress 服务,将外网访问设置为
NodePort
-
3、点击
更多操作
→编辑外网访问
,选择NodePort
,然后该服务将在每个节点打开一个节点端口,通过点击访问
即可在浏览器访问WordPress
-
4、点击
更多操作
→编辑配置文件
,可以看到kubesphere给我们自动生成的yaml文件
创建应用总结
-
至此,您已经熟悉了如何通过创建一个 KubeSphere 应用的方式,通过快速添加多个组件来完成一个应用的构建,最终发布至 Kubernetes;这种创建应用的形式非常适合微服务的构建,只需要将各个组件容器化以后,即可通过这种方式快速创建一个完整的微服务应用并发布 Kubernetes
同时,这种方式还支持用户以 无代码侵入的形式开启应用治理,针对 微服务、流量治理、灰度发布与 Tracing 等应用场景,开启应用治理后会在每个组件中以 SideCar 的方式注入 Istio-proxy 容器来接管流量,后续将以一个 Bookinfo 的示例来说明如何在创建应用中使用应用治理
DevOps
- 项目开发需要考虑的维度
- Dev:怎么开发
- Ops:怎么运维
- 高并发:怎么承担高并发
- 高可用:怎么做到高可用
什么是DevOps
-
微服务:服务自治
-
DevOps:Development 和 Operations 的组合
- DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集
- 突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠
- DevOps希望做到的是软件产品交付过程中IT工具链的打通,使得各个团队减少时间损耗,更加高效的协同工作,专家们总结出了下面这个DevOps能力图,良好的闭环可以大大增加整体的产出
什么是CI&CD
持续集成(Continuous Integration)
- 持续集成是指软件个人研发的部分想软件整体部分交付,频繁的进行集成以便更快的发现其中的错误,持续集成源自于极限编程(XP),是XP最初的12种实践之一
- CI需要具备这些:
- 全面的自动化测试:这是实践持续集成&持续部署的基础,同时,选择合适的自动化测试工具也极其重要
- 灵活的基础设施:容器、虚拟机的存在让开发人员和QA人员不必再大费周折
- 版本控制工具:如Git、CVS、SVN等
- 自动化的构建和软件发布流程的工具:如jenkins
- 反馈机制:如构建/测试的失败,可以快速的反馈到相关负责人,以尽快解决达到一个更稳定的版本
持续交付(Continuous Delivery)
- 持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的【类生成环境】(production-like environments)中;持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上
- 灰度发布
- 持续交付和持续集成的有点非常相似:
- 快速发布:能够应对业务需求,并更快的实现软件价值
- 编码 - 测试 - 上线 - 交付的频繁迭代周期缩短,同时获得迅速反馈
- 高质量的软件发布标准:整个交付过程标准化、可重复、可靠
- 整个交付过程进度可视化:方便团队人员了解项目成熟度
- 更先进的团队协作方式:从需求分析、产品的用户体验到交互设计、开发、测试、运维等角色紧密协作,相比于传统的瀑布式软件团队,更少浪费
持续部署(Continuous Deployment)
-
持续部署是指当交付的代码通过评审之后,自动部署到生成环境中;持续部署是持续交付的最高阶段,这意味着所有通过了一些列的自动化测试的改动都将自动部署到生产环境,它也可被称为 Continuous Release
-
开发人员提交代码,持续集成服务器获取代码,执行单元测试,根据测试结果决定是否部署到预演环境,如果成功部署到预演环境,进行整体验收测试,如果测试通过,自动部署到产品环境,全程自动化高效运转
-
持续部署主要好处是,可以相对独立的部署新的功能,并能快速地收集真实用户的反馈
you build it,you run it
,这是Amazon一年可以完成5000万次部署,平均每个工程师每天部署超过50次的核心秘籍
CI&CD持续交付工具链图
kubesphere流水线
-
Pipeline 是一系列的插件集合,可以通过组合它们来实现持续集成和持续交付的功能。 Pipeline DSL 为我们提供了一个可扩展的工具集,让我们可以将简单到复杂的逻辑通过代码实现
流水线概览
-
下面的流程图简单说明了流水线的完整的工作过程:
流程说明:
- 阶段一. Checkout SCM: 拉取 GitHub 仓库代码
- 阶段二. Unit test: 单元测试,如果测试通过了才继续下面的任务
- 阶段三. SonarQube analysis:sonarQube 代码质量检测
- 阶段四. Build & push snapshot image: 根据行为策略中所选择分支来构建镜像,并将 tag 为
SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER
推送至 Harbor (其中$BUILD_NUMBER
为 pipeline 活动列表的运行序号) - 阶段五. Push latest image: 将 master 分支打上 tag 为 latest,并推送至 DockerHub
- 阶段六. Deploy to dev: 将 master 分支部署到 Dev 环境,此阶段需要审核
- 阶段七. Push with tag: 生成 tag 并 release 到 GitHub,并推送到 DockerHub
- 阶段八. Deploy to production: 将发布的 tag 部署到 Production 环境
创建凭证
注意:
- GitHub 账号或密码带有 "@" 这类特殊字符,需要创建凭证前对其进行 urlencode 编码,可通过一些 第三方网站进行转换,然后再将转换后的结果粘贴到对应的凭证信息中。
- 这里需要创建的是凭证(Credential),不是密钥(Secret)
-
1、本示例代码仓库中的 Jenkinsfile 需要用到 DockerHub、GitHub 和 kubeconfig (kubeconfig 用于访问接入正在运行的 Kubernetes 集群) 等一共 3 个凭证 (credentials) ,参考 创建凭证 依次创建这三个凭证
-
2、然后参考 访问 SonarQube 并创建 Token,创建一个 Java 的 Token 并复制
-
2.1、查看内置安装的 SonarQube
kubectl get svc --all-namespaces 复制代码
可以看到以NodePort的形式暴露了32303,任意节点ip访问32303端口,admin&admin登录
-
-
3、最后在 KubeSphere 中进入
devops-demo
的 DevOps 工程中,与上面步骤类似,在 凭证 下点击 创建,创建一个类型为秘密文本
的凭证,凭证 ID 命名为 sonar-token,密钥为上一步复制的 token 信息,完成后点击 确定
修改jenkinsfile
-
第一步:Fork项目:登录 GitHub,将本示例用到的 GitHub 仓库 devops-java-sample Fork 至您个人的 GitHub
-
第二步:修改 Jenkinsfile:
-
2.1、Fork 至您个人的 GitHub 后,在 根目录 进入 Jenkinsfile-online
-
2.2、在 GitHub UI 点击编辑图标,需要修改如下环境变量 (environment) 的值
第一次使用注意去掉
-o
参数 -
2.3、修改以上的环境变量后,点击 Commit changes,将更新提交到当前的 master 分支
-
2.4、补充:创建完sonarqube的token之后,需要点击
continue
按钮,选择接下来将要分析的代码语言:这里选择Java&Maven
,然后点击finish
-
创建项目
-
CI/CD 流水线会根据示例项目的 yaml 模板文件,最终将示例分别部署到
kubesphere-sample-dev
和kubesphere-sample-prod
这两个项目 (Namespace) 环境中,这两个项目需要预先在控制台依次创建,参考如下步骤创建该项目 -
1、第一步:创建第一个项目:
- 1.1、使用项目管理员
project-admin
账号登录 KubeSphere,在之前创建的企业空间 (demo-workspace) 下,点击 项目 → 创建,创建一个 资源型项目,作为本示例的开发环境,填写该项目的基本信息,完成后点击 下一步。- 名称:固定为
kubesphere-sample-dev
,若需要修改项目名称则需在 yaml 模板文件 中修改 namespace - 别名:可自定义,比如 开发环境
- 描述信息:可简单介绍该项目,方便用户进一步了解
- 名称:固定为
- 1.2、本示例暂无资源请求和限制,因此高级设置中无需修改默认值,点击 创建,项目可创建成功
- 1.1、使用项目管理员
-
2、第二步:邀请成员:第一个项目创建完后,还需要项目管理员
project-admin
邀请当前的项目普通用户project-regular
进入kubesphere-sample-dev
项目,进入「项目设置」→「项目成员」,点击「邀请成员」选择邀请project-regular
并授予operator
角色,若对此有疑问可参考 多租户管理快速入门 - 邀请成员
创建流水线
-
切换
project-regular
身份登录 -
创建完成,可以通过查看 扫描仓库日志,查看失败原因或者拉取进度
运行流水线
-
注意:这里由于github上面的项目一直拉取失败,我将项目导入gitee,并修改了jenkinsfile
-
需要修改的地方
-
1、删除刚刚创建并运行失败的流水线,新建流水线,选择
Git
-
2、新增gitee凭证(同github)修改jenkinsfile,将file中的github-id 替换为 gitee-id,github_accout的值也改为gitee的账户名称
-
-
-
查看运行日志
审核流水线
查看流水线
-
1、点击流水线中
活动
列表下当前正在运行的流水线序列号,页面展现了流水线中每一步骤的运行状态,注意,流水线刚创建时处于初始化阶段,可能仅显示日志窗口,待初始化 (约一分钟) 完成后即可看到流水线。黑色框标注了流水线的步骤名称,示例中流水线共 8 个 stage,分别在 Jenkinsfile-online 中被定义 -
2、当前页面中点击右上方的
查看日志
,查看流水线运行日志。页面展示了每一步的具体日志、运行状态及时间等信息,点击左侧某个具体的阶段可展开查看其具体的日志。日志可下载至本地,如出现错误,下载至本地更便于分析定位问题
验证流水线
-
1、若流水线执行成功,点击该流水线下的
代码质量
,即可看到通过 sonarQube 的代码质量检测结果 -
2、流水线最终 build 的 Docker 镜像也将被成功地 push 到 DockerHub 中,我们在 Jenkinsfile-online 中已经配置过 DockerHub,登录 DockerHub 查看镜像的 push 结果,可以看到 tag 为 snapshot、TAG_NAME(master-1)、latest 的镜像已经被 push 到 DockerHub,并且在 GitHub 中也生成了一个新的 tag 和 release。演示示例页面最终将以 deployment 和 service 分别部署到 KubeSphere 的
kubesphere-sample-dev
和kubesphere-sample-prod
项目环境中 -
3、可通过 KubeSphere 回到项目列表,依次查看之前创建的两个项目中的部署和服务的状态。例如,以下查看
kubesphere-sample-prod
项目下的部署。进入该项目,在左侧的菜单栏点击 工作负载 → 部署,可以看到 ks-sample 已创建成功。正常情况下,部署的状态应该显示 运行
在菜单栏中选择 网络与服务 → 服务 也可以查看对应创建的服务,可以看到该服务的 Virtual IP 为
10.233.42.3
,对外暴露的节点端口 (NodePort) 是30961
-
4、查看推送到您个人的 DockerHub 中的镜像,可以看到
devops-java-sample
就是 APP_NAME 的值,而 tag 也是在 jenkinsfile-online 中定义的 tag -
5、点击
release
,查看 Fork 到您个人 GitHub(Gitee) repo 中的v0.0.1
tag 和 release,它是由 jenkinsfile 中的push with tag
生成的
近期评论