跳到主要内容

· 阅读需 7 分钟

在当今快速变化的技术环境中,普通开发者面临的挑战日益增加。无论是在小型初创公司还是在大型企业中,开发人员都被迫面对繁杂的运维任务、复杂的环境配置以及技术的迅速迭代。这些问题不仅消耗了开发者的时间和精力,也限制了他们对业务本身的专注。为了解决这些痛点,Rainbond 应运而生,它为普通开发者提供了一个友好、高效的解决方案。

面对的挑战:开发者的困境

普通开发者往往需要处理多个角色,既要编写代码,又要管理环境配置,甚至涉及到运维工作。这种情况常常导致以下几个问题:

高依赖性

开发者需要依赖运维团队来搭建和维护开发环境,这种依赖关系往往造成沟通上的低效。在项目进度中,开发者常常因为一些小问题而被迫等待运维团队的支持,导致项目拖延。这种情况不仅影响了开发者的士气,还可能导致业务机会的流失。

学习负担

为了能够独立完成开发任务,开发者不得不花费大量时间学习 Linux、容器、K8s 等底层技术。这不仅降低了他们的工作效率,也让他们对核心业务的关注度降低。大量的时间被用来学习运维技能,而不是进行产品创新和用户体验的提升。

成本问题

小型团队常常缺乏足够的资源来雇佣专业的运维工程师。面对复杂的运维需求,团队成员不得不分散精力,投入更多时间在运维工作上,这增加了开发成本和时间风险,甚至影响了团队的核心竞争力。

Rainbond 的价值:赋能开发者

Rainbond 的设计理念是简化开发和运维的过程,让普通开发者能够更专注于业务本身。以下是 Rainbond 如何解决这些问题的几个关键点:

一站式解决方案

Rainbond 将底层技术进行了有效的封装,开发者只需简单的安装步骤,即可快速搭建开发环境。无论是数据库、缓存还是服务部署,Rainbond 提供了清晰的界面和友好的向导,让开发者能够在几分钟内完成配置,显著提高工作效率。

自动化运维

通过 Rainbond,运维工作实现了高度自动化。开发者在进行产品上线和环境配置时,系统会自动处理资源分配、负载均衡、故障恢复等任务。这种自动化不仅减少了人为错误的发生,也大大节省了开发者的时间,使他们能将精力集中在产品的核心功能和用户体验上。

降低学习成本

Rainbond 提供了直观的用户界面和简化的操作流程,使即便是没有运维背景的开发者也能快速上手。通过详细的文档和社区支持,开发者可以在短时间内掌握必要的技能,专注于业务需求,迅速提升工作效率。

支持快速迭代

在产品开发过程中,快速迭代是至关重要的。Rainbond 支持多版本管理和快速部署,开发者可以轻松进行版本切换和功能测试,及时响应市场需求。通过这种灵活性,团队能够更快地推出新功能,提高产品的竞争力。

实践案例:如何用 Rainbond 实现成功

许多团队已经通过 Rainbond 取得了显著的成果。例如,一家初创公司使用 Rainbond,在没有专门的运维工程师的情况下,开发团队的工作效率提升了1倍多,项目上线时间缩短了50%。他们能够更快地响应用户反馈,持续改进产品,而不再被繁琐的运维任务所困扰。

此外,还有一家中型企业在 Rainbond 的帮助下,实现了从传统部署到云原生架构的转型。团队成员表示,使用 Rainbond 后,他们的工作满意度明显提高,团队的创新能力得到了提升。

结语:拥抱自主开发的未来

在一个日益复杂的技术世界中,普通开发者不应再被繁杂的运维任务所束缚。Rainbond 的出现,为他们提供了一个实现自主开发的可能。通过简化流程、自动化管理和降低学习成本,Rainbond 不仅让开发者能够专注于核心业务,还为小型团队节省了成本,提高了效率。

无论你是初学者还是有经验的开发者,现在正是拥抱 Rainbond 的最佳时机。释放你的创造力,专注于构建更好的产品,真正实现产品开发的自主驾驭。选择 Rainbond,让我们一起迎接更加高效、灵活的开发未来!

· 阅读需 9 分钟

近年来,随着云原生技术的快速发展,Kubernetes 已经成为容器编排的标准。然而,尽管 Kubernetes 功能强大,它的复杂性也成为了众多开发者和运维人员的一大挑战。对于那些希望专注于应用开发的团队来说,学习和管理 Kubernetes 可能是一个高昂的学习成本,尤其是在中小企业中,开发者并没有足够的资源和时间去深入了解 Kubernetes 的所有细节。

这就是Rainbond的出现时机。作为一个开源的云原生应用管理平台,Rainbond 通过提供应用级抽象,让用户可以专注于应用的构建、部署和管理,而无需深入理解底层的 Kubernetes 和容器化技术。这种“以应用为中心”的设计理念,使得 Rainbond 成为一款非常友好的平台,适合那些希望享受云原生技术优势,但又不想陷入底层复杂操作的用户。

Kubernetes 的复杂性:开发者的隐忧

在现代的云原生环境中,Kubernetes 被誉为解决容器编排的黄金标准,它的功能包括自动扩展、服务发现、负载均衡、滚动更新等。然而,这些强大的功能背后,也隐藏着一个陡峭的学习曲线。

对于那些并非专职运维的开发者,学习如何创建和管理 Pod、Service、Ingress、ConfigMap、PersistentVolume 等资源,往往会分散开发的注意力。更不用提在多集群环境下的复杂性,或者在大规模应用场景下如何确保高可用性、容错性和扩展性。这些问题都需要专门的运维知识,并不是每个团队都有能力处理。

例如,Kubernetes 的 YAML 配置文件是其应用管理的核心,虽然灵活,但它的语法复杂且冗长,对于不熟悉 Kubernetes 语法的开发者来说,编写和调试这些配置文件不仅费时费力,还容易出错。Kubernetes 核心 API 中有大约50-60种对象(包括不同版本和扩展对象,如 CRD),属性数量因对象而异,通常每个对象拥有5-40个属性不等。

apiVersion: apps/v1
kind: Deployment
metadata:
name: app-deployment
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app-container
image: nginx:latest
ports:
- containerPort: 80
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: app-secret
volumeMounts:
- name: app-storage
mountPath: /usr/share/nginx/html
volumes:
- name: app-storage
persistentVolumeClaim:
claimName: app-pvc
---
apiVersion: v1
kind: Service
metadata:
name: app-service
namespace: default
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
namespace: default
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80

上面的代码展示了 Kubernetes 配置文件的复杂性,对于许多开发者来说,这是一个门槛。

Rainbond:以应用为中心的简化管理

Rainbond 的设计理念从一开始就着眼于解决这些问题。它通过应用级抽象,将 Kubernetes 的复杂性隐藏起来,让用户专注于他们最关心的部分——应用本身。

1. 应用级抽象

应用级抽象是 Rainbond 的核心特性之一。所谓应用级抽象,指的是用户不再需要关注 Kubernetes 中的底层资源(如 Pod、Service、Ingress 等),而是通过一个更高层次的视角来看待应用。在 Rainbond 中,应用被视为一个整体,用户只需关注应用的状态、依赖和版本,而底层的网络配置、存储管理等复杂操作由平台自动处理。

通过这种方式,Rainbond 大大降低了用户的学习成本,特别适合那些没有精通 Kubernetes 的开发者或团队。

2. 以应用为中心

Rainbond 强调“以应用为中心”,这意味着平台的所有功能和设计都是围绕着应用展开的。无论是应用的创建、部署、扩展还是监控,用户看到的都是应用的整体表现,而不是底层的集群或节点细节。

用户可以通过 Rainbond 的图形界面,轻松查看和管理所有应用的状态、日志、依赖关系等信息,所有操作都直观易懂。Rainbond 提供了一个“一键部署”的功能,开发者可以从代码库中直接部署应用,自动生成相应的容器和资源配置,并完成应用的上线工作。

上图展示了 Rainbond 的应用管理界面,用户可以通过直观的界面管理和监控应用的运行状态。

应用级抽象和以应用为中心是技术趋势

云原生应用的发展正逐渐走向“以应用为中心”的技术趋势。在传统的基础设施管理中,开发者和运维人员需要分别关注底层基础设施和应用,这不仅导致了责任的分离,还增加了沟通和协作的成本。而应用级抽象则将基础设施管理与应用管理融合在一起,让开发者和运维团队能够在同一平台上协作,统一管理应用的生命周期。

随着微服务、DevOps 和容器化技术的普及,应用的复杂性日益增加。而通过应用级抽象,平台可以自动处理底层资源和服务的协调工作,开发者可以更专注于应用的业务逻辑,这种趋势已经成为各大云原生平台的共识。

以应用为中心的设计理念,不仅能减少开发人员的运维负担,还能提升应用的开发和部署效率。这种趋势在 Kubernetes 社区也有体现,例如 Open Application Model (OAM) 这样的项目,都是围绕应用级抽象展开的。而 Rainbond 通过进一步简化 Kubernetes 的复杂性,成为了这一趋势的领先者之一。

总结

Rainbond 的出现,为希望享受云原生技术优势但不愿深陷 Kubernetes 复杂性的用户提供了一条捷径。通过应用级抽象和以应用为中心的设计,Rainbond 不仅降低了 Kubernetes 的门槛,还提供了强大的自动化运维和低代码/无代码开发能力。

在未来,随着更多企业和开发团队采用云原生技术,Rainbond 这种简化操作、提升效率的云原生应用管理平台,必将在市场中占据重要地位。Rainbond 让开发者专注于应用,让复杂的技术背景成为过去,从而推动整个行业向着更高效、更智能的方向发展。

· 阅读需 14 分钟

大家可能听说过平台工程,这是一个新术语,它为开发和 DevOps 领域中本已拥挤的角色集合增添了新内容。

在这篇文章中,我们将介绍平台工程、它与 DevOps 的区别以及为什么你可能考虑采用平台工程以及谁需要拥有平台工程的能力。

什么是平台工程?

平台工程就是为软件开发团队设计、搭建和维护工作流程和工具,让团队的工作更加统一,日常任务处理得更快。

很多平台工程师还会维护一个叫做内部开发者平台的软件,这个平台把分散在不同云服务、工具和团队中的信息和知识汇集起来,让所有工程师都能在一个地方找到他们需要的关于应用、服务和基础设施的信息。

这个领域之所以出现,是因为现在软件开发越来越复杂,涉及到的工具和流程越来越多,开发者需要处理的事情也越来越多。

为啥需要平台工程?

平台工程的出现是为了帮助软件开发者应对开发应用的复杂性。虽然DevOps的目标是自动化应用的部署和运行,但实际上只有一些大的团队或能力较强的团队才能做到。

现实中,当一些团队去掉运维人员并实施DevOps时,会出现一些问题。比如,一项研究显示,顶尖的组织能够成功实施谁开发,谁运维的模式,但其他团队尝试这种模式却失败了。

高级开发者常常不得不扮演幕后运维团队的角色,这导致最宝贵的开发资源——也就是成本最高、本应该用来提升开发团队速度和质量的资源——无法专注于他们本职的开发工作,因为他们得花时间处理运维任务。

这就导致运维工作在组织中分散,质量参差不齐,取决于高级开发者能投入多少时间来搭建和维护。

成功的组织和不成功的组织的区别在于,成功的组织有一个专门的团队负责维护内部开发者平台,支持开发团队。这些专门的团队让开发团队能够专注于创建软件功能,而不是管理依赖、流水线和工具。

平台工程的挑战

虽然平台工程为开发团队带来了很多好处,但在实施过程中也会面临一些挑战。

  • 跨团队协作的复杂性:平台工程需要跨越多个团队的边界,涉及开发、运维、安全、质量保证等多个职能部门。如何协调这些团队的需求,并确保平台的变更能够满足所有团队的期望,是一项艰巨的任务。缺乏有效的沟通和协作机制可能导致误解、延误,甚至项目失败。
  • 用户需求的多样性:平台工程师通常需要支持多个团队,这些团队可能有不同的需求和优先级。有时这些需求可能是相互冲突的,或者资源有限,无法同时满足所有需求。这就要求平台工程师具备敏锐的判断力和灵活的优先级管理能力,平衡各方利益。
  • 技术债务的积累:随着时间的推移,平台可能会变得越来越复杂,特别是当引入新的工具和技术时。如果平台工程师没有足够的时间和资源来维护和升级平台,技术债务就会逐渐积累,最终可能导致平台变得难以管理和维护。这不仅会降低平台的效能,还可能影响开发团队的工作效率。
  • 文化和习惯的改变:平台工程的成功依赖于整个组织的文化变革,这意味着团队成员必须接受新的工具、流程和工作方式。改变现有的习惯和思维方式往往是困难的,特别是当团队已经习惯于使用传统的工具和方法时。推动这种变革需要时间、耐心和强有力的领导支持。

平台工程师做什么?

平台工程师负责部署和维护内部开发者平台,他们通常对软件工程实践和软件开发人员的工作方式有深入的理解。此外,他们了解团队中交付什么以及完成这些目标所需的工具和工作流程。他们还有使用各种DevOps工具和实践的经验。

简单来说,平台工程师就像是软件开发团队的后勤支持,他们确保开发者有一个强大、易于使用的工具和环境,以便开发者可以专注于编写高质量的代码,而不必担心其他事情。

平台工程与DevOps的关系是什么?

平台工程与DevOps密切相关。许多平台工程师来自DevOps背景。DevOps是一套帮助企业更快、更有效地交付软件的实践,它强调开发和运维团队之间的协作。

平台工程借鉴了DevOps的许多相同原则,包括自动化、持续交付和持续集成。

平台工程与DevOps的不同之处在于,平台工程是构建工具来帮助工程师和DevOps执行他们的任务。工具创建通常不是DevOps的重点,或者如果工具是创建的,那是临时性的。

谁需要平台工程技能?

如果你的团队正在开发软件,那么你很可能需要平台工程技能来帮助你的软件开发团队加速。集成开发平台越来越普遍,它们被用来帮助世界上一些最具破坏性和适应性的软件开发团队加快工作。

平台工程是所有考虑实施DevOps的组织都要考虑的事情。随着企业努力更快地交付软件,他们需要流程和工程师,这些工程师能够使他们的软件开发团队,而不是阻碍他们。

在做出决策时,要记住DevOps反模式。首先,问问自己是否能够成功执行DevOps。如果不行,那么一个内部开发者平台和平台工程可能是你正确的选择。

基于Rainbond实现平台工程

在理解了平台工程的核心要点之后,接下来简述说一下如何使用 Rainbond 这样的工具来实现平台工程?

Rainbond 是一个以应用为中心、不用学习 Kubernetes 的云原生应用管理平台,Rainbond 提供了一系列的功能来支持平台工程的实践。以下是 Rainbond 如何帮助实现平台工程的几个关键点:

  • 简化应用管理:Rainbond 通过其应用中心和应用商店,为开发者提供了一个集中化的管理平台。开发者可以在一个统一的界面中管理他们的应用,从部署到监控,从环境配置到扩展应用的能力。这种集中化管理减少了开发者在不同工具之间切换的需求,从而提升了工作效率。

  • 自动化工作流程:开发者能够轻松地部署他们的应用,从源代码到运行,开发者无需创建、管理 CI/CD 的过程,帮助团队自动化构建、测试和部署流程。通过自动化,开发团队可以专注于编写代码,而平台工程师则可以通过Rainbond配置和维护这些自动化流程,确保整个流程的可靠性和一致性。

  • 统一的环境管理:Rainbond 提供了灵活的环境管理功能,开发者可以轻松创建和管理不同的环境(如开发、测试、生产环境)。这种灵活性使得团队可以快速迭代和测试应用,而不必担心环境之间的不一致性。

  • 简化的Kubernetes集成:Rainbond 抽象了Kubernetes的复杂性,使得开发者可以在不深入了解Kubernetes的情况下,轻松管理云原生应用。平台工程师可以利用Rainbond提供的工具,为开发团队构建一个稳定、高效的开发平台,而开发者则可以专注于应用逻辑的实现。

  • 多云和混合云支持:Rainbond 支持跨多个云平台和混合云环境的部署,这对于需要在不同云服务提供商之间切换或者同时使用多个云服务的企业尤为重要。平台工程师可以通过Rainbond统一管理不同云环境中的资源,降低管理复杂性。
  • 集成开发工具:Rainbond 提供了与多种开发工具和服务的无缝集成,使得开发者可以直接在平台上使用他们熟悉的工具。无论是代码管理、持续集成、还是监控工具,Rainbond 都提供了广泛的支持,进一步简化了开发者的工作流程。
  • 支持微服务架构:Rainbond 针对微服务架构提供了全面的支持,开发者可以轻松管理和扩展他们的微服务应用。平台工程师可以通过Rainbond的微服务治理功能,确保服务间的通信稳定、高效,同时提供故障诊断和自动恢复的能力。
  • ......

通过这些功能,Rainbond 为平台工程的实施提供了一个强大且灵活的工具集。平台工程师可以利用这些工具创建一个集成、高效、安全的内部开发者平台,从而帮助企业加速软件开发的流程。

最后

总而言之,平台工程为企业软件开发注入了新的活力,帮助开发团队在日益复杂的技术环境中保持敏捷和高效。如果你的团队正在寻求更好的开发流程和工具支持,平台工程无疑是值得考虑的解决方案。通过正确的工具和方法,平台工程可以成为推动企业成功的关键因素。

这样一来,无论是开发团队还是企业,都能从平台工程中获得巨大收益,将精力集中在创新和业务增长上,而不是陷入工具和流程的管理困境中。

· 阅读需 10 分钟

在上篇《国产化信创开源云原生平台》文章中,我们介绍了 Rainbond 作为可能是国内首个开源国产化信创平台,在支持国产化和信创方面的能力,并简要介绍了如何在国产化信创环境中在线部署 Kubernetes 和 Rainbond。

然而,对于大多数国产化信创环境,如银行、政府等机构,离线部署的需求更为普遍。值得注意的是,Rainbond 官网文档目前仅提供了在已有 Kubernetes 环境中离线部署 Rainbond 的指南。那么,为什么我们不提供离线部署 Kubernetes 的文档呢?Rainbond 开源社区与其他开源社区不同,Rainbond 始终对每一位开源用户提出的问题负责,并积极帮助解决问题。然而,这无疑会为社区支持团队带来额外的工作负担,特别是在处理本不属于 Rainbond 范畴的问题时。

因此,本篇文章将详细介绍如何在国产化信创环境下部署 Kubernetes 以及 Rainbond,希望能够为用户提供实用的指导,减少在部署过程中的困扰。

准备离线镜像和安装包

在有网的 Arm 环境中准备以下镜像和安装包。

Docker 离线包

下载 Docker 离线安装包和离线安装脚本。

wget https://pkg.rainbond.com/offline/docker/docker-arm-20.10.9.tgz
wget https://get.rainbond.com/install_docker_offline.sh

Kubernetes 离线包

本次部署 K8s 版本为 v1.23.10,采用 Rancher Kubernetes Engine 简称 RKE,是一个经过 CNCF 认证的 Kubernetes 安装程序。

在 Arm 环境中获取以下离线包。

# Kubectl和 Helm 二进制文件
wget https://pkg.goodrain.com/pkg/kubectl/v1.23.10/kubectl-arm -O kubectl
wget https://pkg.goodrain.com/pkg/helm/v3.10.1/helm-arm64 -O helm
# RKE安装二进制文件
wget https://pkg.goodrain.com/pkg/rke/v1.3.15/rke-arm -O rke
#!/bin/bash
# RKE Docker镜像
image_list="registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-coreos-etcd:v3.5.3
registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-kube-dns:1.21.1
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-dnsmasq-nanny:1.21.1
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-sidecar:1.21.1
registry.cn-hangzhou.aliyuncs.com/goodrain/cluster-proportional-autoscaler:1.8.1
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-coredns-coredns:1.10.1
registry.cn-hangzhou.aliyuncs.com/goodrain/cluster-proportional-autoscaler:1.8.1
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-node-cache:1.21.1
registry.cn-hangzhou.aliyuncs.com/goodrain/hyperkube:v1.23.10-rancher1
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-coreos-flannel:v0.15.1
registry.cn-hangzhou.aliyuncs.com/goodrain/flannel-cni:v0.3.0-rancher6
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-pause:3.6
registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-metrics-server:v0.6.1"

for image in ${image_list}; do
docker pull "${image}"
done

docker save -o rke-images.tar ${image_list}

Rainbond 离线包

在有网络的环境下提前准备好 Rainbond 所需的镜像。

#!/bin/bash
VERSION=${VERSION:-'v5.17.3-release'}

image_list="registry.cn-hangzhou.aliyuncs.com/goodrain/kubernetes-dashboard:v2.6.1
registry.cn-hangzhou.aliyuncs.com/goodrain/registry:2.6.2
registry.cn-hangzhou.aliyuncs.com/goodrain/metrics-server:v0.4.1
registry.cn-hangzhou.aliyuncs.com/goodrain/etcd:v3.3.18
registry.cn-hangzhou.aliyuncs.com/goodrain/metrics-scraper:v1.0.4
registry.cn-hangzhou.aliyuncs.com/goodrain/rainbond:${VERSION}-allinone
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-mesh-data-panel:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-webcli:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-eventlog:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-init-probe:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-chaos:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-mq:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rainbond-operator:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-worker:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-node:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-monitor:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-gateway:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-api:${VERSION}
registry.cn-hangzhou.aliyuncs.com/goodrain/rbd-db:8.0.19
registry.cn-hangzhou.aliyuncs.com/goodrain/mysqld-exporter:latest
registry.cn-hangzhou.aliyuncs.com/goodrain/nfs-provisioner:latest"

for image in ${image_list}; do
docker pull "${image}"
done

docker save -o rainbond-"${VERSION}".tar ${image_list}

获取 Rainbond Helm Chart 安装包

git clone --depth=1 https://github.com/goodrain/rainbond-chart

开始部署 Kubernetes

前提要求

在开始安装 K8s 之前请阅读 RKE 安装要求,该文档讲述了 RKE 对操作系统、软件、端口和 SSH 配置的要求,安装前,请检查您的节点是否满足这些要求。

部署 Docker

导入 Docker 离线包到所有节点,执行脚本安装 Docker。

$ ls
docker-arm-20.10.9.tgz install_docker_offline.sh
$ bash ./install_docker_offline.sh

导入 K8s 相关的离线包和 Docker 镜像到所有节点。

配置Docker用户

RKE 要求使用一个免密的用户用于后续的集群安装,该用户需有执行 Docker 的权限。

# 创建用户并加入 root 组
adduser -g root docker && echo "docker:password" | chpasswd
# 生成 ssh 密钥,一直回车全默认即可
ssh-keygen
# 配置免密登录
ssh-copy-id docker@xxxx

使用 Docker 用户登录检查是否有 Docker 执行权限。

$ ssh docker@xxxx
$ docker ps

编辑cluster.yml文件

使用 RKE 安装 K8s 集群需要使用 RKE 生成的配置文件,以下是我的示例,更多请参阅RKE配置文件说明

需要我们修改的只有 nodes 字段,如果导入镜像的镜像仓库地址不变则 yml 也无需修改,如有改动需修改 system_images 字段下所有镜像地址。

nodes:
- address: 192.168.0.138
port: "22"
internal_address: 192.168.0.138
role:
- etcd
- controlplane
- worker
hostname_override: ""
user: docker
docker_socket: ""
ssh_key: ""
ssh_key_path: ~/.ssh/id_rsa
ssh_cert: ""
ssh_cert_path: ""
labels: {}
taints: []
services:
etcd:
image: ""
extra_args: {}
extra_args_array: {}
extra_binds: []
extra_env:
- ETCD_AUTO_COMPACTION_RETENTION=1
win_extra_args: {}
win_extra_args_array: {}
win_extra_binds: []
win_extra_env: []
external_urls: []
ca_cert: ""
cert: ""
key: ""
path: ""
uid: 0
gid: 0
snapshot: null
retention: ""
creation: ""
backup_config: null
kube-api:
image: ""
extra_args: {}
extra_args_array: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_args_array: {}
win_extra_binds: []
win_extra_env: []
service_cluster_ip_range: 10.43.0.0/16
service_node_port_range: ""
pod_security_policy: false
always_pull_images: false
secrets_encryption_config: null
audit_log: null
admission_configuration: null
event_rate_limit: null
kube-controller:
image: ""
extra_args: {}
extra_args_array: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_args_array: {}
win_extra_binds: []
win_extra_env: []
cluster_cidr: 10.42.0.0/16
service_cluster_ip_range: 10.43.0.0/16
scheduler:
image: ""
extra_args: {}
extra_args_array: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_args_array: {}
win_extra_binds: []
win_extra_env: []
kubelet:
image: ""
extra_args: {}
extra_args_array: {}
extra_binds:
- /grlocaldata:/grlocaldata:rw,z
- /cache:/cache:rw,z
extra_env: []
win_extra_args: {}
win_extra_args_array: {}
win_extra_binds: []
win_extra_env: []
cluster_domain: cluster.local
infra_container_image: ""
cluster_dns_server: 10.43.0.10
fail_swap_on: false
generate_serving_certificate: false
kubeproxy:
image: ""
extra_args: {}
extra_args_array: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_args_array: {}
win_extra_binds: []
win_extra_env: []
network:
plugin: flannel # calico
options: {}
mtu: 0
node_selector: {}
update_strategy: null
tolerations: []
authentication:
strategy: x509
sans: []
webhook: null
addons: ""
addons_include: []
system_images:
etcd: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-coreos-etcd:v3.5.3
alpine: registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
nginx_proxy: registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
cert_downloader: registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
kubernetes_services_sidecar: registry.cn-hangzhou.aliyuncs.com/goodrain/rke-tools:v0.1.87
kubedns: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-kube-dns:1.21.1
dnsmasq: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-dnsmasq-nanny:1.21.1
kubedns_sidecar: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-sidecar:1.21.1
kubedns_autoscaler: registry.cn-hangzhou.aliyuncs.com/goodrain/cluster-proportional-autoscaler:1.8.1
coredns: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-coredns-coredns:1.10.1
coredns_autoscaler: registry.cn-hangzhou.aliyuncs.com/goodrain/cluster-proportional-autoscaler:1.8.1
nodelocal: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-k8s-dns-node-cache:1.21.1
kubernetes: registry.cn-hangzhou.aliyuncs.com/goodrain/hyperkube:v1.23.10-rancher1
flannel: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-coreos-flannel:v0.15.1
flannel_cni: registry.cn-hangzhou.aliyuncs.com/goodrain/flannel-cni:v0.3.0-rancher6
calico_node: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-calico-node:v3.22.0
calico_cni: registry.cn-hangzhou.aliyuncs.com/goodrain/calico-cni:v3.22.0-rancher1
calico_controllers: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-calico-kube-controllers:v3.22.0
calico_ctl: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-calico-ctl:v3.22.0
calico_flexvol: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-calico-pod2daemon-flexvol:v3.22.0
canal_node: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-calico-node:v3.22.0
canal_cni: ""
canal_controllers: ""
canal_flannel: ""
canal_flexvol: ""
weave_node: ""
weave_cni: ""
pod_infra_container: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-pause:3.6
ingress: ""
ingress_backend: ""
ingress_webhook: ""
metrics_server: registry.cn-hangzhou.aliyuncs.com/goodrain/mirrored-metrics-server:v0.6.1
windows_pod_infra_container: ""
aci_cni_deploy_container: ""
aci_host_container: ""
aci_opflex_container: ""
aci_mcast_container: ""
aci_ovs_container: ""
aci_controller_container: ""
aci_gbp_server_container: ""
aci_opflex_server_container: ""
ssh_key_path: ""
ssh_cert_path: ""
ssh_agent_auth: false
authorization:
mode: rbac
options: {}
ignore_docker_version: null
enable_cri_dockerd: null
kubernetes_version: ""
private_registries: []
ingress:
provider: none
options: {}
node_selector: {}
extra_args: {}
dns_policy: ""
extra_envs: []
extra_volumes: []
extra_volume_mounts: []
update_strategy: null
http_port: 0
https_port: 0
network_mode: ""
tolerations: []
default_backend: null
default_http_backend_priority_class_name: ""
nginx_ingress_controller_priority_class_name: ""
default_ingress_class: null
cluster_name: ""
cloud_provider:
name: ""
prefix_path: ""
win_prefix_path: ""
addon_job_timeout: 300
bastion_host:
address: ""
port: ""
user: ""
ssh_key: ""
ssh_key_path: ""
ssh_cert: ""
ssh_cert_path: ""
ignore_proxy_env_vars: false
monitoring:
provider: none
options: {}
node_selector: {}
update_strategy: null
replicas: null
tolerations: []
metrics_server_priority_class_name: ""
restore:
restore: false
snapshot_name: ""
rotate_encryption_key: false
dns: null

执行安装

执行以下命令开始安装 K8s。经验证麒麟V10必须 SSH 配置 AllowTcpForwarding yes,不然就会报错,参阅 RKE SSH配置

./rke up

如果安装过程中遇到错误需要清理集群可使用以下脚本进行清理。

curl -sfL https://get.rainbond.com/clean-rke | bash

集群安装成功后需要将 kubeconfig 文件拷贝到默认路径下。

mkdir /root/.kube && cp kube_config_cluster.yml /root/.kube/config

执行以下命令确认安装结果

kubectl get node

开始部署 Rainbond

前提要求

每个节点都需要安装 nfs-utils 包,这里就不详细说明了,网上教程很多,大概就是挂载 DVD 镜像,然后做个本地镜像源,直接 yum install 就可以。

导入镜像包

docker load -i rainbond-v5.17.3-release.tar

安装 Rainbond

复制准备节点 Git 克隆的 Helm Chart。

使用 Helm Chart 安装 Rainbond。

  1. 创建命名空间
kubectl create namespace rbd-system
  1. 编写 Helm values.yml,更多 Chart 参数请参阅 Chart 安装选项
operator:
image:
name: registry.cn-hangzhou.aliyuncs.com/goodrain/rainbond-operator
tag: v5.17.3-release

Cluster:
enableEnvCheck: false
gatewayIngressIPs: 192.168.0.138
nodesForChaos:
- name: 192.168.0.138
nodesForGateway:
- externalIP: 192.168.0.138
internalIP: 192.168.0.138
name: 192.168.0.138
rainbondImageRepository: registry.cn-hangzhou.aliyuncs.com/goodrain
installVersion: v5.17.3-release
Component:
rbd_app_ui:
enable: true
env:
DISABLE_DEFAULT_APP_MARKET: true
  1. 执行 Helm 安装命令
helm install rainbond ./rainbond-chart -n rbd-system -f value.yml

安装进度查询

执行完安装命令后,在集群中执行以下命令查看安装状态。

watch kubectl get po -n rbd-system

当名称包含 rbd-app-ui 的 Pod 为 Running 状态时即安装成功。

访问平台

复制如下命令,在集群中执行,可以获取到平台访问地址。如果有多个网关节点,则任意一个地址均可访问到控制台。

kubectl get rainbondcluster rainbondcluster -n rbd-system -o go-template --template='{{range.spec.gatewayIngressIPs}}{{.}}:7070{{printf "\n"}}{{end}}'

离线环境源码构建(可选)

如果你需要在离线环境下进行源码构建,请参阅Rainbond离线源码构建文档进行配置。

最后

通过本文的指导,希望您能顺利完成在鲲鹏ARM和麒麟V10环境下的 Kubernetes 和 Rainbond 的离线部署。在国产化信创环境中,离线部署的需求越来越普遍,我们提供的详细步骤和示例,帮助您减少部署过程中的不确定性和挑战。未来,我们还将继续更新更多相关教程和文档,以更好地服务于国产化信创领域的需求。

· 阅读需 6 分钟

国产化信创是指中国本土信息技术和创新产业的发展和推广。随着各种形势的复杂变化,推动国产化和信创已成为信息产业发展的重要方向。在这一背景下,国内的技术企业和开发者们纷纷投入到开源国产化和自主创新的浪潮中,力图摆脱对国外技术和服务的依赖。从硬件到软件,再到云原生。

众所周知,在各个技术领域都有国产化信创的产品,比如国产CPU、国产操作系统、国产数据库等等都有厂商在做,都有开源的版本。但目前开源的国产化信创云原生平台目前较少。据我了解,目前在国内 Rainbond 是首个支持国产化信创的开源云原生平台。

国产化信创环境支持

目前主流的国产化 CPU 厂商包括飞腾、华为、龙芯、海光、兆芯等,其指令集集中在 X86Arm 以及自主性极高的 LoongArch (MIPS 指令集的后继者) 。

Rainbond 开源版本对国产 CPU 和国产操作系统提供全面支持,确保应用能够在国产硬件和软件环境下稳定运行。这包括对多种国产 CPU 架构的优化和适配,如鲲鹏、飞腾、龙芯等,以及对国产操作系统的兼容性,例如统信、银河麒麟、中标麒麟、龙蜥、欧拉操作系统等。这种支持不仅涵盖了基础的运行环境,还包括了对特定硬件和软件特性的优化,以提高性能和安全性。

信创应用迁移支持

Rainbond 开源版本自动屏蔽架构差异,以最低成本将应用迁移到国产化信创环境之中。仅需要提供源代码,即可在指定架构环境中编译运行。开源应用商店提供不同架构的应用模板,上百种开源软件一键部署。信创应用供应商可以以最小的技术成本和时间成本,即可将不同类型的服务重新编译,并部署到信创环境中去。

国产化信创环境部署实践

Rainbond 的有三种安装方式,这三种安装方式都支持国产化信创环境:

  • 快速安装:这是一个快速体验版本,使用一条命令安装 Rainbond。
  • 基于主机安装:支持通过裸操作系统开始部署 K8s + Rainbond。
  • 基于K8s安装:这种方式需要用户自行部署K8s,再部署 Rainbond。

下面将简述如何使用基于主机安装方式在麒麟V10 + 鲲鹏上部署 Rainbond。我这里是在华为云上开个演示服务器。

安装 Docker

Rainbond 提供了 Arm 版的 Docker 安装脚本,如下:

curl -sfL https://get.rainbond.com/install_docker | bash

安装 Rainbond 控制台

Rainbond 镜像支持多架构,不同的架构自动拉取不同的镜像。使用 Docker 启动 Rainbond 控制台,启动后使用 http://IP:7070进行访问。

docker run -d -p 7070:7070 \
--name=rainbond-allinone --restart=always \
-v ~/.ssh:/root/.ssh \
-v ~/rainbonddata:/app/data \
registry.cn-hangzhou.aliyuncs.com/goodrain/rainbond:v5.17.3-release-allinone

安装 K8s

  1. 登录 Rainbond 后,进入 平台管理 > 集群 -> 添加集群 -> 从主机开始安装 进入图形化安装页面。
  2. 按照页面引导填写信息,如下:

  1. 等待完成安装即可。

安装 Rainbond 集群

在安装完成 K8s 集群后,下一步将进入 Rainbond 集群安装页面,这部分将引导您完成 Rainbond 集群的安装。

根据页面引导填写配置,配置详情可参考 Rainbond 集群安装配置说明

配置信息填写完成后进入 Rainbond 集群安装页面,在该页面可看到安装的进度信息,并且每个组件都可点击查看状态以及事件信息。

等待 Rainbond 所有组件都启动后,会自动跳转到集群对接页面,填写集群 ID,完成对接。

最后

在完成以上步骤后,您已经成功在国产化信创环境中部署了 Rainbond 云原生平台,并且可以开始管理和部署您的信创应用。随着国产化信创的不断推进,Rainbond 作为首个全面支持国产化信创的开源云原生平台,将在未来发挥越来越重要的作用。国产化信创的道路虽充满挑战,但 Rainbond 会致力做好开源、做好国产化信创,我们相信未来国产化信创云原生平台的生态将会更加完善。

· 阅读需 5 分钟

背景

2020年12月08日,CentOS 官方宣布了停止维护 CentOS 项目,并推出了 CentOS Stream 项目,并表示后续都会投入到 CentOS Stream 项目中。更多信息,请参见 CentOS官方公告

  • CentOS 6 已于 2020年11月30日 停止维护,CentOS 8 已于 2021年12月31日 停止维护。
  • CentOS 7 已于 2024年06月30日 停止维护。

影响

CentOS 停止服务主要的影响是以下两个方面:

  • 安全漏洞:无法获取安全补丁来修复高风险的CVE漏洞。
  • 软件功能:不再发布新版本软件包,缺乏新功能、新架构支持;

总的来说停止维护意味着无法获取安全补丁修复高风险的 CVE 漏洞,也无法获取到新版本软件包带来的新功能和架构支持。这直接导致了操作系统出现的任何安全漏洞或其他问题都无法得到官方的处理,同时许多基础软件包也不再更新。

如何应对

面对这种情况,我们不得不考虑迁移到其他长期支持(LTS)的 Linux 发行版,以确保系统的安全和持续更新。可选的迁移目标包括:

  • Ubuntu LTS:提供至少五年的安全更新和维护,适合需要长期稳定支持的企业环境。
  • Debian Stable:同样提供长期安全支持,稳定性良好,适合生产环境。
  • Fedora Server 或 Fedora Workstation:虽然支持周期较短,但提供最新的软件和特性,适合需要最新技术的环境。
  • Rocky Linux:为了填补 CentOS 停止维护留下的空白而创建的,与 Red Hat Enterprise Linux(RHEL)高度兼容,迁移过程相对简单。
  • Anolis OS、openEuler、OpenCloudOS:这些由国内厂商主导并开源的 Linux 发行版,同样与 RHEL 高度兼容,为企业用户提供了很好的本地化支持和服务。

在选择迁移目标时,如果选择迁移到 Ubuntu、Debian 或 Fedora,可能需要使用一些外部工具帮助迁移,因为这些系统与 CentOS 有较大的包管理差异,迁移过程可能涉及较高的风险。

而选择 Rocky Linux、Anolis OS、openEuler 或 OpenCloudOS 则会简化迁移过程,因为这些系统与 CentOS 的高度兼容性降低了迁移难度,让过程更为顺畅。

Centos 7 迁移到 Anolis OS 7

这里以 Centos 7 迁移到 Anolis OS 7 举例。

  1. 下载 Anolis OS 迁移工具 yum 源
wget https://mirrors.openanolis.cn/anolis/migration/anolis-migration.repo -O /etc/yum.repos.d/anolis-migration.repo
  1. 安装迁移工具 centos2anolis
yum -y install centos2anolis

若出现下述的报错,则需要安装epel源,迁移工具需要依赖 epel 源中的 python36-psutil 包

Error: Package: centos2anolis-0.2-20.an7.noarch (migration)
Requires: python36-psutil

$ yum install -y epel-release
  1. 执行迁移命令
# 不加参数默认迁移到 ANCK 内核的 Anolis OS
centos2anolis.py
# 迁移到 RHCK 内核的 Anolis OS
centos2anolis.py --rhck

迁移完成后如下图所示:

  1. 重启并验证 OS 版本

  1. 迁移完成,在 Rainbond 集群管理的节点详情中也可查看到操作系统版本。

迁移到其他 Linux 发行版

自 Centos 系列项目宣布停止维护以后,大部分 Linux 发行版都提供了迁移指南,例如:

以上四种方式都是相当容易、简单的,因为它们都与 Centos 高度兼容。

最后

迁移操作系统是一个比较重要的事情,需要完整的计划和执行。建议在大家实施之前,充分测试所有关键的业务应用以确保兼容性,准备好详细的回滚方案以应对可能出现的问题。祝大家都能完美迁移成功~

· 阅读需 7 分钟

最近一段时间 Docker 镜像一直是 Pull 不下来的状态,感觉除了挂🪜,想直连 Docker Hub 是几乎不可能的。更糟糕的是,很多原本可靠的国内镜像站,例如一些大厂和高校运营的,也陆续关停了,这对我们这些个人开发者和中小企业来说是挺难受的。之前,通过这些镜像站,我们可以快速、方便地获取所需的 Docker 镜像,现在这条路也不行了。感觉这次动作不小,以后想直接访问 Docker Hub 是不可能了。所以我们得想办法搭建自己的私有镜像仓库。

最近网上有很多解决 Docker Hub 镜像拉不下来的文章,我大概总结一下有以下几种办法:

Github Action

利用 Github Action Job 将 Docker Hub 镜像重新打 Tag 推送到阿里云等其他公有云镜像仓库里,这对于需要单个镜像很方便,批量就稍微麻烦一些,如果没🪜Github 访问也是个问题。

CloudFlare Worker

使用 CloudFlare Worker 对 Docker Hub 的访问请求做中转,这种也是最近使用比较多的,因为个人用户的免费计划每天有10万次免费请求,足够个人和中小企业使用了,实在不够可以花 5$ 购买不限制的。Worker 脚本在网上有很多,随便搜索都有示例。

因为 CloudFlare Worker 默认分配的workers.dev结尾的域名国内根本解析不了,所以要把域名托管在 CloudFlare 上才能正常使用,可以购买 .xyz 等其他费用合适的域名专门用来做代理访问。

但 CloudFlare Worker CDN 经常抽风,有时很快有时很慢,可以借助自选优选IP工具帮助获取访问 CloudFlare 延迟最低的IP,将其写入到你的本地 Hosts 文件中。

自建镜像仓库

说到自建首先我想到的就是买个配置比较低国外的服务器,搭建个 Nginx 做代理,分享下我配置成功的 Nginx 配置文件:

server {
listen 443 ssl;
server_name 域名;
ssl_certificate 证书地址;
ssl_certificate_key 密钥地址;

ssl_session_timeout 24h;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

location / {
proxy_pass https://registry-1.docker.io; # Docker Hub 的官方镜像仓库
proxy_set_header Host registry-1.docker.io;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
proxy_intercept_errors on;
recursive_error_pages on;
error_page 301 302 307 = @handle_redirect;
}
location @handle_redirect {
resolver 1.1.1.1;
set $saved_redirect_location '$upstream_http_location';
proxy_pass $saved_redirect_location;
}
}

然后就可以直接用 docker pull 域名/library/nginx:latest 获取镜像了或者配置到 Docker 的daemon.json中。

Nginx 代理的方案你需要能购买到合适的国外服务器,不然网络会很慢。

又或者在国外服务器上搭建 Registry、Nexus、Harbor等镜像仓库,它们具备镜像缓存功能,如果私有镜像仓库中不存在则会去代理服务中获取最新镜像。

建议方案

所以对于个人用户、中小企业来说可以将上述的 CloudFlare Worker + 自建镜像仓库 融合起来,本地搭建 Registry、Nexus、Harbor等镜像仓库,在镜像仓库中配置上自己的 CloudFlare Worker Nginx反代 等代理地址或者当前一些可用的其他代理,当本地不存在则会通过这些代理去获取镜像,代理不可用时本地依然能用。

搭建 Docker Registry

搭建 Docker Registry 可以参考下述命令:

docker run -d --restart=always --name registry \
-p 443:443
-e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \ #代理的镜像仓库URL
-e REGISTRY_HTTP_ADDR=0.0.0.0:443 \ #监听地址
-e REGISTRY_HTTP_HOST=https://xxx.cn \ #访问域名
-e REGISTRY_HTTP_TLS_CERTIFICATE=/opt/cert/cert.pem \ #域名证书
-e REGISTRY_HTTP_TLS_KEY=/opt/cert/cert.key \ #域名证书
-v /opt/cert:/opt/cert \ #挂载本地证书到容器中
-v /data:/var/lib/registry \ #持久化数据目录
registry:2

搭建 Nexus

可选择使用 Docker 命令搭建 Nexus

docker run -d -p 8081:8081 --name nexus sonatype/nexus3

或者使用 Rainbond 应用商店一键安装。

搭建完成后正常登录 Nexus 页面,根据页面引导配置 Docker 相关的存储 Repository 及代理 Repository 即可。

搭建 Harbor

可参考 Harbor文档 搭建或者使用 Rainbond 应用商店一键安装。

可用的镜像代理

最近十来天我尝试了很多镜像加速站,整理了以下镜像站目前是可用状态,但可能随时会遇到不可用、关停、访问比较慢的状态,建议同时配置多个镜像源。

提供商地址
DaoCloudhttps://docker.m.daocloud.io
阿里云https://<your_code>.mirror.aliyuncs.com登录阿里云分配
Docker镜像代理https://dockerproxy.com看运气
百度云https://mirror.baidubce.com
南京大学https://docker.nju.edu.cn
中科院https://mirror.iscas.ac.cn

福利

近期 Rainbond 社区也接受到许多用户反馈 Docker 镜像拉不下来,不能构建、打包了,因此 Rainbond 也搭建了个镜像加速服务,采用 CloudFlare + 国外服务器 Nginx 反代的方案为 Rainbond 社区的用户们提供镜像加速服务。

目前速度挺快的(未来不好说

使用方法

1.直接获取 Docker Hub 镜像

docker pull docker.rainbond.cc/library/node:20
docker pull docker.rainbond.cc/rainbond/rainbond:v5.17.2-release-allinone

2.配置镜像加速器

tee /etc/docker/daemon.json <<-'EOF'
{
"registry-mirrors": ["https://docker.rainbond.cc"]
}
EOF
systemctl daemon-reload
systemctl restart docker

· 阅读需 6 分钟

TOPIAM 企业数字身份管控平台, 是一个开源的IDaas/IAM平台、用于管理账号、权限、身份认证、应用访问,帮助整合部署在本地或云端的内部办公系统、业务系统及三方 SaaS 系统的所有身份,实现一个账号打通所有应用的服务。

传统企业 IT 采用烟囱式建设方式,容易带来以下挑战:

  • 应用授权管理混乱,容易发生安全问题,导致数据外泄。
  • 身份认证安全存疑,敏感系统缺乏严格的身份认证机制。
  • 各系统独立建设账号体系、权限体系,账号权限分配等此类管理操作低效、重复、价值低,账户分散管理风险大、不可控。员工需要记多套账号密码。

TOPIAM 企业数字身份管控平台提供一套集中式的账号、权限、认证、审计工具,帮助打通身份数据孤岛,实现“一个账号、一次认证、多点通行”的效果,强化企业安全体系的同时,提升组织管理效率,助力企业数字化升级转型。

使用 Rainbond 部署 TOPIAM

Rainbond 是一个云原生应用管理平台,核心100%开源,Serverless体验,不需要懂K8s也能轻松管理容器化应用,平滑无缝过渡到K8s,是国内首个支持国产化信创、适合私有部署的一体化应用管理平台。

首先安装 Rainbond 或使用以下命令安装 Rainbond

curl -o install.sh https://get.rainbond.com && bash ./install.sh

登录 Rainbond 后,选择从应用市场安装应用,在搜索框中搜索 topiam,点击安装按钮。

点击安装后,等待 TOPIAM 所有组件自动启动,部署后拓扑图如下:

  • 管理端(eiam-console)
  • 门户端(eiam-portal)
  • OpenAPI(eiam-openapi)

点击访问按钮,访问管理端组件的对外服务地址,默认账号密码 admin/topiam.cn。用户端登录需要在管理端中创建账号再登录,更多请参阅TOPIAM文档

TOPIAM能做什么?

提供统一组织信息管理,多维度建立对应关系,实现在一个平台对企业人员、组织架构、应用信息的高效统一管理。

支持钉钉、飞书等身份源集成能力,实现系统和企业 OA 平台数据联动,以用户为管理基点,结合入职、离职、调岗、兼职等人事事件,关联其相关应用权限变化而变化,保证应用访问权限的安全控制。

支持微信、微博、QQ 等社交认证集成,使企业具有快速纳入互联网化认证能力。

支持 OIDC、OAuth2、SAML2、CAS、JWT、表单代填等认证协议及机制,实现单点登录功能。

完善的安全审计,详尽记录每一次用户行为,使每一步操作有据可循,实时记录企业信息安全状况,精准识别企业异常访问和潜在威胁的源头。

防暴力破解机制,在一定次数的失败尝试后,系统会自动锁定账户,有效防止恶意用户使用暴力破解技术尝试多次登录,使得进一步尝试登录变得无效。

完备的密码策略机制,可以设置相应的密码复杂度、相应的锁定解锁策略,还可以设置是否允许与历史密码重复等高级策略。同时,可以通过开启弱密码字典库来检查密码的安全强度。

提供标准 openapi 接口轻松完成机构用户同步,实现企业对于账号生命周期的精细化管理。

最后

TOPIAM 与 Rainbond 以及 Rainbond 上部署的应用还有很多场景可以结合,后续会持续输出相关的系列文章,例如:TOPIAM 对接 Rainbond 用户登录体系、SpringBoot OIDC 对接等系列文章,敬请期待!

· 阅读需 9 分钟

基于主机安装基于Kubernetes安装的 Rainbond 集群(均使用默认参数安装),默认使用的共享文件存储是 NFS ,以 Pod 方式运行在 Kubernetes 中,但这种方式也有一些无法避免的问题,比如:NFS 的 SVC 无法通信时集群无法挂载存储则导致不能使用、服务器关机时卡在 umount 导致不能正常关机等等。

当然还有切换共享文件存储的需求,在第一次安装 Rainbond 时,大多数都使用的默认安装,使用一段时间后想切换到外部的 NFS,或者云上的 NAS等等。

在原生的 Kubernetes 集群中,通过 StorageClass 创建的 PVC 是无法修改存储后端的,需要将 PV、PVC 删除后通过新的 StorageClass 创建新的 PVC,然后再将数据迁移,再重新挂载 PVC。当有很多个 PVC 时,需要多次重复的操作。

而 Rainbond 虽然也是通过 StorageClass 创建的 PVC,但相比原生 Kubernetes 省去了创建 PV、PVC 和重新挂载的步骤,以及重复性的操作。在 Rainbond 中只需要将底层存储类更换,然后迁移 Rainbond 所创建的一整个目录,最后重新在页面中修改挂载即可完成迁移。

本文将讲述如何迁移 Rainbond 默认的 NFS 存储到外部 NFS 存储,大致分为以下几个步骤:

  1. 部署外部 NFS 存储并对接到 K8s 上。
  2. 备份 NFS 存储的数据。
  3. 恢复备份数据并切换 Rainbond 默认存储至外部存储。

注意:

  • 关闭正在运行的应用,避免增量数据导致数据不一致。
  • 组件挂载的存储必须是共享存储,其他存储则需要单独迁移。

部署 NFS 并对接到 K8s 上

外部 NFS 存储可以选择部署 NFS 双机热备或其他方案,这里就不演示了,以单节点 NFS 为例。

在 Centos 上部署 NFS

  1. 安装 nfs-utils
yum install -y nfs-utils
  1. 创建共享目录
mkdir -p /data
  1. 编辑 /etc/exports 文件,添加如下内容:
$ vim /etc/exports

/data *(rw,sync,insecure,no_subtree_check,no_root_squash)
  1. 配置完成后,执行以下命令启动 NFS 服务:
systemctl enable nfs-server
systemctl start nfs-server
  1. 验证 NFS 是否可用
showmount -e 172.20.251.94

在 K8s 中部署 NFS Client

下面将外部的 NFS 存储对接到 Kubernetes 上,在 Kubernetes 中部署 NFS Client Provisioner

  1. 安装 Helm 命令

  2. 添加 Helm Chart 仓库

helm repo add rainbond https://openchart.goodrain.com/goodrain/rainbond
  1. 安装 NFS-Client-Provisioner
helm install nfs-client-provisioner rainbond/nfs-client-provisioner \
--set nfs.server=172.20.251.94 \
--set nfs.path=/data \
--version 1.2.8
  1. 验证 NFS Client 是否可用,创建 PVC 验证。
$ vim test-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-claim
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 1Gi
storageClassName: nfs-client

$ kubectl apply -f test-pvc.yaml

查询 PVC 状态为 Bound 则正常。

备份默认 NFS 的数据

查看 rbd-system 下所有的 PVC。

kubectl get pvc -n rbd-system

PVC名称解释
data测试存储是否正常默认创建的PVC(无用)
data-nfs-provisioner-0NFS Pod所使用的PVC,默认路径在宿主机的/opt/rainbond/data/nfs下。
data-rbd-monitor-0存储监控数据。(可不要)
rbd-api存储 api request 请求日志。(可不要)
rbd-chaos-cache存储构建组件的缓存(可不要)
rbd-cpt-grdata存储平台上所有组件挂载共享存储数据,以及组件的日志。(必须)
rbd-db-rbd-db-0存储 MySQL 数据,默认是存在本地的,没存储在 NFS 中。
rbd-etcd-rbd-etcd-0存储 Etcd 数据,默认是存在本地的,没存储在 NFS 中。
rbd-hub存储镜像数据(必须)

以上数据中对于我们要迁移的重要数据有 rbd-cpt-grdatarbd-hub,根据 VOLUME 名称在默认的存储目录 /opt/rainbond/data/nfs 下查找,例如 pvc-9ec619e3-1e20-4d7a-b744-aa04088fb6c3

使用 rsync 同步工具,将数据同步到新的 NFS 存储服务器上,根据以下命令开始同步,根据实际情况修改命令。

rsync -avP /opt/rainbond/data/nfs/pvc-9ec619e3-1e20-4d7a-b744-aa04088fb6c3 root@172.20.251.94:/data
rsync -avP /opt/rainbond/data/nfs/pvc-d0bf09ca-5543-4050-bd08-b02ebb593b4e root@172.20.251.94:/data

注意:数据同步完成后切记要校验数据的完整性。

切换 Rainbond 存储

更改 Rainbond 默认存储

  1. 修改 rainbondcluster CRD资源,添加 storageClassName
$ kubectl edit rainbondcluster -n rbd-system

spec:
rainbondVolumeSpecRWX:
storageClassName: nfs-client #由 NFS-Client-Provisioner 创建的 sc
  1. 修改 rainbondvolumes CRD资源,修改 storageClassNamenfs-client
$ kubectl edit rainbondvolumes -n rbd-system

spec:
storageClassName: nfs-client
  1. 删除 Rainbond 基于默认 NFS 创建的 StorageClass rainbondsssc rainbondslsc
kubectl delete sc rainbondsssc rainbondslsc
  1. 删除 rbd-system 命名空间下旧的 PVC。这时候会删除不掉,因为还有 POD 在使用该 PVC,先 ctrl c 结束。
kubectl delete pvc data data-rbd-monitor-0 rbd-api rbd-chaos-cache rbd-cpt-grdata rbd-hub -n rbd-system
  1. 删除 Rainbond 组件的控制器让 rainbond-operator 控制 PVC 重新创建。
kubectl delete deploy rbd-api -n rbd-system
kubectl delete ds rbd-chaos -n rbd-system
kubectl delete sts rbd-monitor -n rbd-system
kubectl delete deploy rbd-worker -n rbd-system
kubectl delete deploy rbd-hub -n rbd-system
kubectl delete deploy rbd-resource-proxy -n rbd-system
kubectl delete sts rbd-eventlog -n rbd-system
kubectl delete ds rbd-node -n rbd-system
kubectl delete pod -l release=rainbond-operator -n rbd-system

等待所有 POD 重新创建,创建完成后 Rainbond 平台可正常访问,正常工作。

恢复数据

下面将前面备份的数据恢复到新创建的 PVC 中。

此时 rbd-cpt-grdatarbd-hub 新创建的目录下的数据都是自动创建,先将其删除。

rm -rf /data/rbd-system-rbd-cpt-grdata-pvc-44167209-1006-4de5-9801-afcce996449c/*
rm -rf /data/rbd-system-rbd-hub-pvc-c326b89f-7c0e-4990-a8e2-31472799ccc8/*

再将备份的 rbd-cpt-grdatarbd-hub 数据分别同步到新的目录中,例如以下命令。

rsync -avP /data/pvc-9ec619e3-1e20-4d7a-b744-aa04088fb6c3/* /data/rbd-system-rbd-cpt-grdata-pvc-44167209-1006-4de5-9801-afcce996449c
rsync -avP /data/pvc-d0bf09ca-5543-4050-bd08-b02ebb593b4e /data/rbd-system-rbd-hub-pvc-c326b89f-7c0e-4990-a8e2-31472799ccc8

注意:数据同步完成后切记要校验数据的完整性。

重新 Rainbond 部分组件的 POD 生效。

kubectl delete pod -l name=rbd-api -n rbd-system
kubectl delete pod -l name=rbd-chaos -n rbd-system
kubectl delete pod -l name=rbd-monitor -n rbd-system
kubectl delete pod -l name=rbd-worker -n rbd-system
kubectl delete pod -l name=rbd-hub -n rbd-system
kubectl delete pod -l name=rbd-resource-proxy -n rbd-system
kubectl delete pod -l name=rbd-eventlog -n rbd-system
kubectl delete pod -l name=rbd-node -n rbd-system

更改 Rainbond 上的组件存储

替换底层存储后,此时 Rainbond 上组件的存储还未修改,此时需要进入 Rainbond 的组件中将当前存储删除重新添加。

挂载路径、存储类型保持不变,删除当前的配置添加新的同样配置即可。

至此存储切换完成,后续请验证应用的数据是否都完整。

删除默认 NFS 存储资源(可选)

修改 CRD 资源,将 nfs-provisioner replicas 设置为 0

$ kubectl edit rbdcomponent nfs-provisioner -n rbd-system

spec:
replicas: 0

删除 nfs-provisioner 控制器

kubectl delete sts nfs-provisioner -n rbd-system

删除 nfs-provisioner 的 PV、PVC

kubectl delete pvc data-nfs-provisioner-0 -n rbd-system
kubectl delete pv nfs-provisioner

删除宿主机上的 NFS 数据存储目录

rm -rf /opt/rainbond/data/nfs

· 阅读需 14 分钟

Rainbond v5.14.2 版本,又称信创版本。从这个版本开始,开源用户也可以利用 Rainbond 管理符合信创要求的硬件计算资源。在这个版本中,产品团队将此前只在企业版产品中存在的信创相关功能拆分出来,融入到了开源产品路线之中。本文围绕如何在信创环境中将应用迁移上云这一主题,结合 Rainbond 信创版本的能力,给出可行的落地方案。

向信创环境迁移应用的必要性

信创产业即信息技术应用创新产业,是我国数字化转型的重要组成部分,也是关键基础设施的重要支撑。其核心在于通过行业应用拉动构建国产化信息技术软硬件底层架构体系和全周期生态体系,解决核心技术关键环节卡脖子的问题,为中国发展奠定坚实的数字基础。

对一般的软件供应商而言,在面向党政军企售卖软件时,符合国产化信创要求已经逐渐成为无法绕过的硬性标准。即使是已经交付完成的软件,在后期的建设计划中,处于信创转型时期的党政军企也会提出向国产化信创环境中迁移的硬性要求。需求的背后总是隐藏着商机,掌握国产化信创背景下的应用迁移能力,将软件产品转化为信创应用是当下所有 ToB/ToG 信创应用供应商必须掌握的能力。Rainbond 信创版本在这样的场景中可以发挥极大的作用。

信创硬件生态

信创应用必须运行在国产化硬件和操作系统之上。国产化硬件生态中最重要的是 CPU 芯片,CPU 芯片的架构直接影响信创应用是否可以在国产化硬件上运行。目前主流的国产化 CPU 厂商包括飞腾、华为、龙芯、海光、兆芯等,其指令集集中在 X86Arm 以及自主性极高的 LoongArch (MIPS 指令集的后继者) 之中。而指令集的不同,直接影响到信创应用是否需要重新编译来进行适配。

不难看出,国产化 CPU 芯片的生态有这么几个特点:

  • LoongArch自主程度最强,但是其生态受限严重,短时间内无法很好的面向市场推广。
  • 海光、兆芯手持生态最为繁茂的 X86 指令集授权,然而自主化程度最弱。X86 过于成熟稳定,前人大厦已成,很难在此基础上做出创新。
  • 华为、飞腾拥有 Arm 指令集授权,自主化程度适中,而且 Arm 生态正处于蓬勃发展中,可以和 X86 生态掰一掰手腕。

市场的反馈非常理性,在当前国内的 CPU 芯片市场中,飞腾在党政领域PC市占率领先,海光与鲲鹏占据运营商服务器主要份额。回到信创应用供应商的视角,如何打好 Arm 这张牌,将会是闯入国产化信创赛道的关键点。Rainbond 信创版本通过一云多芯能力,方便的纳管包括 Arm 在内的多架构集群。

“一云多芯”统管Arm & x86集群

顾名思义,一云多芯的异构集群,指的是在同一个集群中的计算节点中,其 CPU 芯片架构不唯一。

一般情况下,CPU 芯片的架构都是基于 Intel 公司推出的 X86 指令集,作为后起之秀的 AMD 也推出完全兼容 X86amd64 指令集,二者可以视为等同。而在国产化信创场景中,很多国产 CPU 架构都是基于 Arm 指令集开发,常见的鲲鹏920、飞腾芯片等都属于该架构类型。为了能够融入国产化信创 IT 生态,Rainbond 自信创版本开始,全面兼容了 Arm 架构。

国产化信创绝非一朝一夕之事,大量在传统 X86 架构下开发的应用都需要很长时间的调整甚至重构才能完全在国产化芯片上运行,一云多芯主打同时能够运行多种架构应用的能力,在国产化替代的过渡阶段中将发挥重大作用。

Rainbond 信创版本可以在同个集群中统一管理和调度多种不同 CPU 架构计算节点,同时也可以借助多集群管理能力纳管多个单架构集群。超高的灵活性,可以让决策者自行决定异构计算资源的部署策略。

除 Arm 架构之外,Rainbond 信创版本也兼容主流国产化软硬件,全面支持信创场景,并且获得了国内各大 CPU 厂商、操作系统厂商的认证。一体化管理信创应用的开发、运维、交付全流程,极大降低国产化信创场景下的应用管理成本。

信创应用迁移难点

对于信创应用供应商而言,从头开发一套信创应用并不是难事。我国信创生态已经日趋完整,无论是操作系统、开发工具还是数据库,都不存在空白区域,它们为全新信创应用的开发提供了全面的支持。真正的难点在于如何将已经运行在传统服务器中的遗留业务系统迁移到国产化信创环境中去。从传统的 X86 跨越到 Arm 架构基本意味着业务系统中所有服务组件的重新编译,甚至重构。在保障业务连续性的前提下,完成传统应用向信创应用的转化是我们无法回避的课题。

首先,让我们按照服务的开发语言、运行方式做个分类:

解释型语言

以 Python、PHP、Shell 为代表的解释型语言,也称脚本语言,是完全与 CPU 架构无关的。我们只需要提供能在信创环境中可用的语言解释器,即可在不改动一行代码的前提下将这种服务运行起来。

字节码型的编译文件

这种类型以 Java 语言编译出的 Jar、War 包为代表。Jar 、War 包是非常常见的软件交付物。由于其打包的是与 CPU 架构无关的字节码,最终运行由跨平台的 JVM 虚拟机负责,故而我们只需要提供能在信创环境中可用的 JDK 、JRE工具,即可在不改动一行代码的前提下将这种服务运行起来。

编译型语言

这里的描述是不严格的,因为字节码型的编译文件也产自编译型语言。在这里,我们特指的是以 C、C++、Golang 为代表的编译型语言,它们在编译时与 CPU 架构强相关,编译出的二进制产物只能在指定的 CPU 架构下运行。这一特性也意味着迁移过程必须经过重新编译,才可以在信创环境中运行起来。

遗留业务系统向国产化信创环境迁移绝非易事,需要甲方与供应商的密切合作。然而由于遗留业务系统的特性,导致供应商能够提供的支持是不一样的。支持力度的不同,直接影响迁移的效果。

提供支持

当甲方决意对某个遗留业务系统进行信创迁移时,恰好供应商承诺的支持期限还没有到期,供应商可以对业务系统的迁移提供全面的支持时,问题会简单很多。即使是面对编译型语言,只要能够提供源代码进行重新编译,则可以完成信创迁移,只是耗时费力罢了。

不提供支持

当甲方决意对某个遗留业务系统进行信创迁移时,恰好供应商承诺的支持期限已经到期,甚至已经无法联系到供应商时,事情就难办许多。甲方对遗留业务系统的了解不会太深,只能找到软件交付物进行分析,重新基于信创环境搭建编译、运行环境。然而对有些经年日久的业务系统而言,很难找到当年的源代码,如果这个服务恰好是编译型语言编译出的二进制文件,基本意味着信创迁移走入了死路。此时,甲方不得不考虑重新招标另一家供应商来重构这个系统,新的替代系统落地绝非一朝一夕之事,期间不能因为这一个服务阻碍国产化信创的整体落地进程。

Rainbond "信创" 版本的核心功能是支持传统应用在信创环境中的云迁移。它紧密关注用户所使用的不同语言类型,并自动化完成信创迁移的工作。一旦所有组件成功部署,通过内置的 ServiceMesh 微服务架构,可以实现跨架构的微服务编排,将服务组件连接起来形成完整的业务系统。

传统应用迁移上云

Rainbond 信创版本自动屏蔽架构差异,以最低成本将应用迁移到国产化信创环境之中。仅需要提供源代码,即可在指定架构环境中编译运行。开源应用商店提供不同架构的应用模板,上百种开源软件一键部署。信创应用供应商可以以最小的技术成本和时间成本,即可将不同类型的服务重新编译,并部署到信创环境中去。

异构微服务编排能力

Rainbond 信创版本凭借一云多芯管理能力, 可以在同个集群中统一调度管理不同 CPU 架构的计算节点。应用中的服务组件也可以按照要求部署到指定的架构中去。但是只有不同架构的微服务组件之间可以相互编排、相互通信,那么它们才能够成为一个有机的整体,形成完整的业务系统。同时也满足信创应用从传统的 X86Arm 国产化迁移的过渡期的特殊要求。

借助于 Service Mesh 亦或是 Kubernetes Service 的能力,Rainbond 天生支持跨架构微服务之间的编排与通信。使用方法与 Rainbond 一直以来的拖拉拽拼积木式的微服务编排方法无异。

· 阅读需 10 分钟

PostgreSQL 是一种流行的开源关系型数据库管理系统。它提供了标准的SQL语言接口用于操作数据库。

repmgr 是一个用于 PostgreSQL 数据库复制管理的开源工具。它提供了自动化的复制管理,包括:

  • 故障检测和自动故障切换:repmgr 可以检测到主服务器故障并自动切换到备用服务器。
  • 自动故障恢复:repmgr 可以检测到从服务器故障并自动将其重新加入到复制拓扑中。
  • 多个备用服务器:repmgr 支持多个备用服务器,可以在主服务器故障时自动切换到最合适的备用服务器。
  • 灵活的复制拓扑:repmgr 支持各种复制拓扑,包括单主服务器和多主服务器。
  • 管理和监控:repmgr 提供了用于管理和监控PostgreSQL复制的各种工具和命令。

可以说 repmgr 是一个扩展模块,简化了 PostgreSQL 复制的管理和维护,提高系统的可靠性和可用性。它是一个非常有用的工具,特别是对于需要高可用性的生产环境。同时 repmgr 也是由 Postgresql 社区开发以及维护的。

Pgpool 是一个高性能的连接池和负载均衡器,用于 PostgreSQL 数据库。Pgpool 可以作为中间层,位于客户端和 PostgreSQL 服务器之间,来管理连接请求并分配给不同的 PostgreSQL 服务器进行处理,以提高整体的系统性能和可用性。Pgpool 的一些主要功能包括:

  • 连接池:Pgpool在应用程序和数据库之间建立一个连接池,使得多个应用程序可以共享一组数据库连接,避免了重复的连接和断开。
  • 负载均衡:Pgpool可以将客户端请求均衡地分配到多个PostgreSQL服务器上,以实现负载均衡和更好的性能。
  • 高可用性:Pgpool可以检测到PostgreSQL服务器的故障,并自动将客户端请求重新路由到其他可用服务器,从而提高系统的可用性和稳定性。
  • 并行查询:Pgpool可以将大型查询分成几个子查询,然后将这些子查询并行发送到多个PostgreSQL服务器上执行,以提高查询性能。

本文将介绍在 Rainbond 上使用 Postgresql-repmgr + Pgpool 实现 Postgresql 高可用集群的部署和管理。

架构

当使用 Postgresql HA 集群时,应用只需连接 pgpool 即可。

  • 通过 pgpool 实现读写分离,写入操作由 Master 执行,读取操作由 Slave 执行。
  • 由 repmgr 实现流复制,Master 数据自动复制到 Slave。
  • 当 Master 遇故障下线时,由 repmgr 自定选择 Slave 为 Master,并继续执行写入操作。
  • 当某个节点遇故障下线时,由 pgpool 自动断开故障节点的连接,并切换到可用的节点上。

部署 Rainbond

安装 Rainbond,可通过一条命令快速安装 Rainbond,或选择 基于主机安装基于 Kubernetes 安装 Rainbond。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

通过 Rainbond 开源应用商店部署 PostgreSQL 集群

Postgresql HA 集群已发布到 Rainbond 开源应用商店,可一键部署 Postgresql HA 集群。

登陆 Rainbond 控制台,进入 平台管理 -> 应用市场 -> 开源应用商店 中搜索 postgresql-ha 并安装。

安装完成后的拓扑图如下。

配置 Pgpool 组件

  1. 获取 PostgreSQL-repmgr 连接地址,进入 PostgreSQL-repmgr 组件的 Web 终端内。
env | grep REPMGR_PARTNER_NODES

  1. 将上述的内容复制出并修改成以下格式,然后进入 Pgpool 组件内,修改PGPOOL_BACKEND_NODES 环境变量,并更新组件。
0:pg-grde8ebc-0.pg-grde8ebc.dev.svc.cluster.local:5432,1:pg-grde8ebc-1.pg-grde8ebc.dev.svc.cluster.local:5432,2:pg-grde8ebc-2.pg-grde8ebc.dev.svc.cluster.local:5432

  1. 验证集群,进入 Pgpool 组件的 Web 终端中。
# 连接 postgresql
PGPASSWORD=$PGPOOL_POSTGRES_PASSWORD psql -U $PGPOOL_POSTGRES_USERNAME -h localhost

# 查询集群节点
show pool_nodes;

status 字段均为 UP 即可。

从零开始部署 PostgreSQL 集群

从零开始在 Rainbond 上部署 Postgresql HA 集群也是非常简单的,大致分为以下几个步骤:

  • 基于镜像部署 PostgreSQL-repmgr 组件,并修改组件配置。
  • 基于镜像部署 pgpool 组件,并修改组件配置。
  • 建立组件之间的依赖关系。

镜像均采用 bitnami 制作的 postgresql-repmgrpgpool,因 bitnami 制作的镜像将很多配置文件都抽离成了环境变量,配置比较方便。

部署 PostgreSQL-repmgr 组件

1. 创建组件

进入团队内 -> 新建组件 -> 基于镜像创建组件,应用、组件、英文名称等自定义即可,镜像填写 bitnami/postgresql-repmgr:14.7.0

2. 修改组件类型

进入组件内 -> 其他设置,将组件部署类型修改为 有状态服务

3. 添加环境变量

进入组件内 -> 环境变量,新增以下环境变量:

# 默认初始化的数据库
POSTGRESQL_DATABASE=initialize

# 创建普通用户和密码
POSTGRESQL_USERNAME=admin
POSTGRESQL_PASSWORD=admin@123

# 管理员 postgres 密码
POSTGRESQL_POSTGRES_PASSWORD=postgres@123

# repmgr 用户密码
REPMGR_PASSWORD=repmgrpass

# 初始化主节点的 HOST。Rainbond 控制台自动渲染 SERVICE_NAME 变量,获取当前 Statefulset 的控制器名称。
REPMGR_PRIMARY_HOST=${SERVICE_NAME}-0.${SERVICE_NAME}.${NAMESPACE}.svc.cluster.local

# 集群中的所有节点,以逗号分隔
REPMGR_PARTNER_NODES=${SERVICE_NAME}-0.${SERVICE_NAME}.${NAMESPACE}.svc.cluster.local,${SERVICE_NAME}-1.${SERVICE_NAME}.${NAMESPACE}.svc.cluster.local,${SERVICE_NAME}-2.${SERVICE_NAME}.${NAMESPACE}.svc.cluster.local

进入组件内 -> 其他设置,添加 Kubernetes 属性,选择 env,添加以下内容:

# repmgr 节点名称
- name: REPMGR_NODE_NAME
value: "$(POD_NAME)"
# repmgr 节点网络名称
- name: REPMGR_NODE_NETWORK_NAME
value: "$(POD_NAME).$(SERVICE_NAME).$(NAMESPACE).svc.cluster.local"

### "$(POD_NAME)" 用于定义 env 之间的相互依赖

4. 添加组件存储

进入组件内 -> 存储,添加新的存储,存储路径为 /bitnami/postgresql,其他自定义即可。

5. 启动组件

在组件视图内构建组件等待构建完成并启动。

6. 修改组件实例数量

进入组件内 -> 伸缩,将组件实例数量设置为 3,等待所有实例启动即可。

部署 pgpool 组件

1. 创建组件

进入团队内 -> 新建组件 -> 基于镜像创建组件,应用、组件、英文名称等自定义即可,镜像填写 bitnami/pgpool:4.4.2

2. 添加环境变量

进入组件内 -> 环境变量,新增以下环境变量:

# pgpool admin 用户与密码
PGPOOL_ADMIN_USERNAME=admin
PGPOOL_ADMIN_PASSWORD=admin@123

# postgres 用户与密码
PGPOOL_POSTGRES_USERNAME=postgres
PGPOOL_POSTGRES_PASSWORD=postgres@123

# 用于执行流检查的用户和密码
PGPOOL_SR_CHECK_USER=admin
PGPOOL_SR_CHECK_PASSWORD=admin@123

# postgresql 后端节点。节点列表获取进入到 PostgreSQL-repmgr 组件的 Web 终端内,使用 env | grep REPMGR_PARTNER_NODES 命令获取,然后修改为以下格式
PGPOOL_BACKEND_NODES=0:postgresql-ha-repmgr-0.postgresql-ha-repmgr.dev.svc.cluster.local:5432,1:postgresql-ha-repmgr-1.postgresql-ha-repmgr.dev.svc.cluster.local:5432,2:postgresql-ha-repmgr-2.postgresql-ha-repmgr.dev.svc.cluster.local:5432

3. 添加依赖

在应用视图,将 pgpool 组件依赖至 PostgreSQL-repmgr 组件。

4. 启动组件

在 pgpool 组件视图内构建组件等待构建完成并启动。

5. 验证集群

进入 Pgpool 组件的 Web 终端中,输入以下命令验证集群:

# 连接 postgresql
PGPASSWORD=$PGPOOL_POSTGRES_PASSWORD psql -U $PGPOOL_POSTGRES_USERNAME -h localhost

# 查询集群节点
show pool_nodes;

status 字段均为 UP 即可。

最后

外部连接

如想使用本地工具连接到 postgresql,可在 pgpool 组件的端口内打开对外服务端口,通过该端口连接到 postgresql,默认用户密码为 postgres/postgres@123

验证高可用集群

为了保障高可用集群,Kubernetes 集群至少有 3 个节点,且底层存储使用分布式存储,如没有分布式存储,需将 Postgresql 存储切换为本地存储也可保障高可用集群的数据。可通过以下方式进行高可用集群验证:

  • 通过 Pgpool 连接后,创建数据库并写入数据,再进入 PostgreSQL-repmgr 组件的 Web 终端内查询每个实例是否都有数据。
  • 挂掉主节点,验证是否主节点自动切换并可正常连接并写入。

· 阅读需 21 分钟

Kubernetes Gateway API 是 Kubernetes 1.18 版本引入的一种新的 API 规范,是 Kubernetes 官方正在开发的新的 API,Ingress 是 Kubernetes 已有的 API。Gateway API 会成为 Ingress 的下一代替代方案。Gateway API 提供更丰富的功能,支持 TCP、UDP、TLS 等,不仅仅是 HTTP。Ingress 主要面向 HTTP 流量。 Gateway API 具有更强的扩展性,通过 CRD 可以轻易新增特定的 Gateway 类型,比如 AWS Gateway 等。Ingress 的扩展相对较难。Gateway API 支持更细粒度的流量路由规则,可以精确到服务级别。Ingress 的最小路由单元是路径。

Gateway API 的意义和价值:

  • 作为 Kubernetes 官方项目,Gateway API 能够更好地与 Kubernetes 本身集成,有更强的可靠性和稳定性。

  • 支持更丰富的流量协议,适用于服务网格等更复杂的场景,不仅限于 HTTP。可以作为 Kubernetes 的流量入口 API 进行统一。

  • 具有更好的扩展性,通过 CRD 可以轻松地支持各种 Gateway 的自定义类型,更灵活。

  • 可以实现细粒度的流量控制,精确到服务级别的路由,提供更强大的流量管理能力。

综上,Gateway API 作为新一代的 Kubernetes 入口 API,有更广泛的应用场景、更强大的功能、以及更好的可靠性和扩展性。对于生产级的 Kubernetes 环境,Gateway API 是一个更好的选择。本篇文章将深入解读 Kubernetes Gateway API 的概念、特性和用法,帮助读者深入理解并实际应用 Kubernetes Gateway API,发挥其在 Kubernetes 网络流量管理中的优势。

发展现状

版本现状

Gateway API 目前还处于开发阶段,尚未发布正式版本。其版本发展现状如下:

  • v1beta1: 当前的主要迭代版本,Gateway API 进入了beta 版本,这意味着我们可以在生产中使用 Gateway API 能力了,目前 beta 版本仅支持 HTTP 协议, TCP 协议、UDP 协议、gRPC 协议、TLS 协议均为 alpha 版本。

  • v1.0: 首个正式GA版本,API稳定,可以用于生产环境。但功能还会持续完善。

可用场景

下面简单整理了一下 HTTPRoute 的一些可用场景:

  • 多版本部署:如果您的应用程序有多个版本,您可以使用 HTTPRoute 来将流量路由到不同的版本,以便测试和逐步升级。例如,您可以将一部分流量路由到新版本进行测试,同时保持旧版本的运行。

  • A/B 测试:HTTPRoute 可以通过权重分配来实现 A/B 测试。您可以将流量路由到不同的后端服务,并为每个服务指定一个权重,以便测试不同版本的功能和性能。

  • 动态路由:HTTPRoute 支持基于路径、请求头、请求参数和请求体等条件的动态路由。这使得您可以根据请求的不同属性将流量路由到不同的后端服务,以满足不同的需求。

  • 重定向:HTTPRoute 支持重定向,您可以将某些请求重定向到另一个 URL 上,例如将旧的 URL 重定向到新的 URL。

周边生态

目前,尽管 Gateway API 还处于开发阶段,但已经有部分项目表示支持或计划支持Gateway API。主要包括:

  • Istio 是最流行的服务网格项目之一,Istio 1.9 版本计划引入实验性的 Gateway API 支持。用户可以通过 Gateway 和 HTTPRoute 资源来配置 Istio 的 Envoy 代理。

  • Linkerd 是另一个流行的服务网格项目,Linkerd 2.10 版本添加了 Gateway API 支持。用户可以使用 Gateway API 资源来配置 Linkerd 的代理。

  • Contour 是一个Kubernetes Ingress Controller,Contour 1.14.0 版本添加 Gateway API 支持,可以使用 Gateway 和 HTTPRoute 来配置 Contour。

  • Flagger 是一款 Kubernetes 的蓝绿部署和 A/B 测试工具,Flagger 0.25版本添加了对Gateway API的支持,可以使用Gateway和HTTPRoute构建Flagger的流量路由。

  • HAProxy Ingress Controller支持Gateway API,可以使用Gateway和HTTPRoute构建HAProxy的配置。

  • Traefik是著名的开源边缘路由器,Traefik 2.5版本开始支持Gateway API并逐步淘汰Ingress支持。

除此之外,Apisix、Envoy gateway、Higress等开源项目也支持或打算支持Gateway API,各大云服务商都在积极跟进Gateway API进展,预计未来会在相应的服务中提供Gateway API支持。可以看出,尽管Gateway API还不算成熟和稳定,但由于其强大的功能和作为Kubernetes官方项目的影响力,已经获得大量项目的支持和兼容。服务网格、API网关以及各大云服务商都将是Gateway API的重点生态。

未来规划

  • 完善功能和稳定性:继续完善 Gateway API 的功能和稳定性,以确保其能够应对不同场景的需求。

  • 管理规模:针对大规模 Kubernetes 集群的需求,优化 Gateway API 的性能和扩展性,使其能够管理更多的网关和路由规则。

  • 增强安全性:加强 Gateway API 的安全性,包括在传输过程中的加密、身份验证等方面,以确保网络流量的安全性。

  • 完善文档和社区支持:完善 Gateway API 的文档和社区支持,以帮助用户更好地使用和了解该项目。

Gateway API 规范解读

基础概念

Kubernetes Gateway API 定义了三种基本资源类型:GatewayClass、Gateway、Route 。

  • Gatewayclass: 一组共享通用配置和行为的 Gateway 集合,与 IngressClass、StorageClass 类似,需要知道 Gateway API 并不会创建真正的网关,真正的网关是由一些支持 Gateway API 的社区(基础设备提供商)所提供的 Controller 所创建,如 Envoy 、Istio、Nginx。GatewayClass, Gatewayclass 的作用就是绑定一个 Controller 定义一种网关类型。
  • Gateway: 可以说成 GatewayClass 的具体实现,声明后由 GatewayClass 的基础设备提供商提供一个具体存在的 Pod,充当了进入 Kubernetes 集群的流量的入口,负责流量接入以及往后转发,同时还可以起到一个初步过滤的效果。
  • Route: 真实的路由,定义了特定协议的规则,用于将请求从 Gateway 映射到 Kubernetes 服务。目前只有 HTTPRoute 进入了v1beta 版本,是比较稳定的版本,后续 TCPRoute、UDPRoute、GRPCRoute、TLSRoute 等也会陆续进入 beta 版本达到生产可用,这里将只对 HTTPRoute 进行介绍。

关于他们三者之间的关系,官方文档也给了一幅非常清晰的结构图,如下图所示,在我看来,图片主要强调了面向角色的特点,官方想表达意思是 GatewayClass 由基础设施供应商提供,Gateway 资源由集群工程师创建,基本环境搭建完成后,开发者便可以轻松创建 HTTPRoute 将自己的业务代理出来。

工作原理

结构图

GatewayClass

通过部署 GatewayClass 绑定下游实现提供的 Controller,为集群提供一种网关能力,这里可以看作是一种注册声明吧,将你的下游实现注册到集群中供 Gateway 绑定使用。Controller 可以看作监听 Gateway 资源的 Operator。

spec:
controllerName: gateway.envoyproxy.io/gatewayclass-controller #绑定的 Controller 名称

Gateway

Gateway 资源是一个中间层,需要定义所要监听的端口、协议、TLS 配置等信息,可以将网络流量的管理和控制集中到一个中心化的位置,提高集群的可用性和安全性。配置完成后,由 GatewayClass 绑定的 Controller 为我们提供一个具体存在 Pod 作为流量入口,需要注意的是,各家实现在此处还是略有不同,比如说 Envoy 当你创建 Gateway 资源后,Envoy Controller 会创建一个 Deployment 资源为你提供入口流量 Pod ,然而 Nginx 则是自己本身就是流量入口 Pod 不会创建新的。

spec:
gatewayClassName: envoy #绑定的 GatewayClass 名称。
listeners: # 定义了一些监听项,供 Route 进行绑定
- allowedRoutes: #定义流量转发范围
namespaces:
from: All #允许 Gateway 往所有的 Namespace 的 Pod 转发流量。
name: http #监听项名称。
port: 8088 #监听项所占用的端口
hostname: www.gateway.*.com #定义一个域名,一般为泛域名、匹配来自该域名的流量。
protocol: HTTP #定义协议,HTTP或者HTTPS
- allowedRoutes:
namespaces:
from: All
name: https
port: 8443
protocol: HTTPS
tls: #为 HTTPS 配置加密协议
mode: Terminate #加密协议类型,Terminate 或 Passthrough
certificateRefs:
- kind: Secret
name: cafe-secret
namespace: default

协议类型:

  • Terminate:将加密的流量解密并将明文流量转发到后端服务。这种模式需要在网关处配置证书和密钥,以便对客户端和服务器之间的流量进行加密和解密,确保数据安全性。
  • Passthrough:将加密的流量原样转发到后端服务。这种模式不需要在网关处配置证书和密钥,因为 TLS 连接只在后端服务处终止。这种模式适用于需要将 TLS 流量直接传递到后端服务的场景,如需要对后端服务进行更细粒度的访问控制或流量监控的情况。

HTTPRoute

HTTPRoute 便跟你的业务密切相关了,在这里定义详细的规则,将流量代理到对应的业务服务上。

#HTTPRoute A
spec:
parentRefs: #绑定 Gateway 监听项
- name: gateway #Gateway 资源名称
namespace: envoy #Gateway所在命名空间
sectionName: http #监听项名称
hostnames: #为路由配置域名
- "www.gateway.example.com" #可配置泛域名,可配置多个
rules: #配置详细的路由规则,可配置多个,下面有对各种规则类型的详细解析
- matches: #匹配条件
- path: #路径匹配
type: PathPrefix #路径类型:Exact 完全匹配/PathPrefix 前缀匹配/RegularExpression 正则匹配
value: /gateway
filters: #高级设置
- type: requestHeaderModifier #加工请求头
requestHeaderModifier: #支持 set 覆盖/add 添加/remove 删除
set:
- name: service
value: goodrain
- type: RequestRedirect #请求重定向
requestRedirect:
scheme: https # 重定向所使用的协议,http/https
hostname: www.baidu.com #重定向的域名
port: 8443 #重定向所使用的端口
statusCode: 301 #重定向状态码:301 永久的重定向/302 临时重定向
-----------------
#HTTPRoute B
spec:
parentRefs:
- name: gateway
namespace: envoy
sectionName: https
hostnames:
- "www.gateway.example.com"
rules:
- matches:
- headers: #请求头匹配
- name: service
value: goodrain
backendRefs: #后端路由
- name: goodrain-v1 # service 名称
port: 80 #service 端口
weight: 80 #权重
- name: goodrain-v2
port: 80
weight: 20

规则类型:

  • matches: 由一个或多个匹配条件组成,这些匹配条件可以基于HTTP请求的各种属性(如请求方法、路径、头部、查询参数等)进行匹配,从而确定哪些请求应该被路由到该规则对应的后端服务。
  • filters: 对传入请求进行更细粒度的控制,例如修改请求的头部、转发请求到其他服务、将请求重定向到不同的URL等。它们由一组规则组成,每个规则都包含一个或多个过滤器。这些过滤器可以在请求被路由到后端服务之前或之后进行处理,以实现各种不同的功能。
  • backendRefs: 用来指定后端服务的引用,它包含一个后端服务的列表,每个服务由名称和端口号组成,可以使用不同的负载均衡算法,将请求路由到后端服务的其中一个实例中,实现负载均衡。

深入了解以后,我们可以看出来 HTTPRoute 的用法非常的灵活,可以通过将不同的规则组合搭配,来创建一条适合我们业务的路由,就拿上面的 yaml 为例,整体流量走向如下图所示,当 http 协议的请求流量进入后,按照规则匹配,流量会向下转发到 HTTPRoute A 的路由上,HTTPRoute A 按照规则顺序,先对请求进行加工处理添加请求头,之后将请求重定向到 HTTPRoute B上,再由 HTTPRoute 将流量按照权重比例路由到对应的后端服务。

需要注意的是,规则集有优先级,当同时存在多个规则(rule)的时候,流量会从上往下进行匹配,只要有匹配上流量会直接代理到其对应的后端或重定向到对应的路由。

Gateway API 快速上手

整理一下部署思路,如果在业务中使用 Gateway API 我们都需要做什么。

  • Kubernetes Gateway API 基础 CRD。安装网关 API CRD地址
  • Gateway API 下游实现,即基础设备供应商。(包含 GatewayClass 资源)下游实现地址
  • 创建 Gateway ,定义基础的路由方式供 HTTPRoute 选择。根据上面的字段解释自行编写。
  • 创建 HTTPRoute 设置规则绑定自己的业务。根据上面的字段解释自行编写。

下面以 Envoy 提供的 demo 为例,串一下整体流程

安装Gateway API CRD 和 Envoy Controller

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v0.3.0/install.yaml

查看安装效果

# 查看安装的 CRD 资源
kubectl get crd |grep networking.k8s.io

# 查看安装的 envoy controller
kubectl get pod -n envoy-gateway-system

安装 Gateway、HTTPRoute 及示例应用

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v0.3.0/quickstart.yaml

内部 GatewayClass 资源

资源的 controllerName 属性字段配置绑定了 envoy 的 controller

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: eg
spec:
controllerName: gateway.envoyproxy.io/gatewayclass-controller

内部 Gateway 资源

资源的 gatewayClassName 属性字段配置绑定了 gatewayclass 资源名称 eg,同时提供了一个 对内监听端口为 80,协议类型为 http 的监听项。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: eg
spec:
gatewayClassName: eg
listeners:
- name: http
protocol: HTTP
port: 80

内部的 HTTPRoute 资源

资源的 parentRefs 属性字段配置绑定了 gateway 资源名称 eg。域名为 www.example.com ,代理的后端服务类型选择了 service,名称为 backend ,服务端口为 3000。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: backend
spec:
parentRefs:
- name: eg
hostnames:
- "www.example.com"
rules:
- backendRefs:
- group: ""
kind: Service
name: backend
port: 3000
weight: 1
matches:
- path:
type: PathPrefix
value: /

查看安装效果

# 查看安装的 gatewayclass 资源
kubectl get gatewayclass

# 查看安装的 gateway 资源
kubectl get gateway

# 查看安装的 httproute 资源
kubectl get httproute

#查看由 Controller 提供的流量入口 Pod。
kubectl get pod -n envoy-gateway-system

#查看路由解析地址,其中 nodeport 类型的 svc 便是你的解析地址。
kubectl get svc -n envoy-gateway-system|grep LoadBalancer

#访问
curl --resolve www.example.com:31830:xx.xxx.xx.xxx --header "Host: www.example.com" http://www.example.com:31830/get

Gateway API 生产指南

Gateway API使用到生产需要考虑易用性、可管理性和稳定性因素:

  • 易用性:Gateway API扩展了很多配置内容,如果直接写yaml上手难度较大,而且容易出错,所以需要有一个基于UI的管理工具。
  • 可管理性:Gateway API支持分角色管理和使用,跟平台工程的思路一致,但要用到生产需要有一个分权限和角色的平台。
  • 稳定性:Gateway API当前的实现中,Envoy 和 Nginx可以用到生产环境。

基于以上因素,在生产环境需要Gateway API的管理工具,当前相对成熟的工具可以选择Rainbond,它运行Kubernetes基础上,它也是平台工程的设计思路,提供web界面管理Kubernetes的资源,包括Gateway API,对使用者不需要写Yaml文件,能区分管理员角色和普通开发者角色,管理员可以通过管理界面安装兼容的Gateway API的实现,比如Envoy和Nginx,安装好的网关,普通开发者只需要配置业务的路由就可以使用,不用关心是哪一种实现。

具体落地过程:

在Kubernetes上安装Rainbond

参考安装文档: 基于 Kubernetes 安装 Rainbond

管理员安装Gateway API的网关实现

通过Rainbond提供的应用市场,搜索 GatewayAPI会出来三个应用,先安装GatewayAPI-Base,再安装GatewayAPI-Envoy或Gateway-Nginx,当然也可以两个都装。

管理员配置 Gateway API的资源

平台管理 / 扩展 / 能力 点击对应资源的编辑,配置Gateway 和 GatewayClass资源。

开发者配置业务路由

开发者在自己开发的应用中配置网关,如果同时安装多个网关实现,可以先选择网关类型,然后通过界面配置 HTTPRoute 字段。

补充说明:

  • Rainbond当前版本只支持HTTPRoute,其他类型的Route暂时不支持;

  • 从Rainbond应用市场只能安装 Envoy和Nginx两种网关实现,要支持更多网关实现需要Rainbond先支持或自己制作插件;

  • 资料参考:Rainbond 的 Gateway API 插件制作实践

· 阅读需 16 分钟

内容概要:文章探讨了混合云场景中的难点、要点,以及Rainbond平台在跨云平台的混合云管理方面的解决方案。包括通过通过统一控制台对多集群中的容器进行编排和管理,实现了对混合云中应用的一致性管理。文章还介绍了Rainbond平台在混合云环境下的应用模板交付、跨云团队管理等功能,帮助用户简化跨云平台的应用交付和运维操作。

混合云的应用场景

随着云原生技术的逐渐成熟,混合云成为了企业在云原生领域中的热门话题之一。混合云的场景特点是企业应用和数据在多个云环境中进行部署和运行,包括私有云和公有云,以及不同的云服务提供商。这样的场景带来了许多挑战和机遇。

混合云的价值点主要在于:

  • 灵活性和可扩展性:混合云能够让企业在不同云环境中选择最适合的部署方案,使得应用和服务的部署更加灵活和可扩展。

  • 高可用性和容灾能力:混合云能够通过在多个云环境中部署应用和数据,提高系统的可用性和容灾能力,从而减少系统停机时间和数据损失。

  • 降低成本:混合云能够让企业根据应用和数据的需求,在不同的云环境中选择最优惠的价格和性能比例,从而降低总体成本。

混合云管理要点

混合云场景相较于单一的私有云或公用云场景而言复杂很多,建设混合云的难点往往来自于不同供应商提供的云平台之间有很多差异,很难做到统一的管理体验。而且,多个供应商提供的云平台之间不互通,跨云进行数据同步时,需要考虑一致性与安全性。

  • 跨云平台标准化:不同的云平台之间存在着各种差异,使得跨云平台的操作和管理变得复杂。标准化能够让不同平台之间的操作和管理更加一致,减少管理难度。

  • 数据一致性:不同云平台之间的数据交换和同步需要确保数据一致性,以避免数据冲突和丢失。

  • 安全性:在混合云场景下,不同云平台之间的数据和应用需要得到适当的安全保护,以保障数据的机密性和完整性。

  • 用户管理:在混合云场景下,不同的云平台之间的用户体系并不相通。统一的混合云管理平台能够利用一套用户体系纳管多个集群中的计算资源,极大的降低了管理成本。

混合云场景功能需求

在混合云场景中,以下跨云功能通常具有很强的需求:

  1. 一致性操作体验:以一致性的管理体验,抹平用户使用不同云资源的操作差异。使得用户可以通过一套操作,完成应用从发布到上线到多个云环境的核心过程。一致性操作体验可以极大的弱化用户在面对多个不同云环境的不适感,使底层计算资源对用户透明。

  2. 用户管理:通过在统一控制台层面抽象用户体系,完成一套用户管理所有集群的效果。可以极大的降低企业管理成本。

  3. 跨云迁移和部署:随着企业在多个云平台上部署应用程序,跨云迁移和部署变得非常重要。能够将应用程序从一个云平台迁移到另一个云平台,无缝部署并在多云环境中进行管理,将大大提高企业的灵活性和敏捷性。

  4. 多云容灾:由于云服务提供商可能会遇到可用性问题,因此在混合云场景中,多云容灾变得非常重要。通过在多个云平台上部署应用程序,企业可以在一个云平台遇到问题时,快速切换到另一个云平台上运行,以保持业务的连续性。

  5. 跨云数据管理:在混合云场景中,跨云数据管理也是一个重要的需求。能够在多个云平台上进行数据备份和恢复,以及在不同云平台之间共享数据,将为企业提供更强的灵活性和可扩展性。

基于Rainbond 的混合云建设

Rainbond云原生应用管理平台在设计之初就考虑了如何适应混合云管理场景。在产品设计中,Rainbond可以从逻辑上划分为控制台和集群端组件两大部分,其中控制台的多云管理模块可以使其对接并管理多个集群。而集群端组件可以部署在各类 Kubernetes 集群之中,通过与 Kube-apiserver 的通信来管理 Kubernetes 集群之中的各类资源。Rainbond 集群端组件可以部署到各类 Kubernetes 集群之中,包括标准 Kubernetes 集群、 K3s 集群,也可以部署到阿里云ACK托管服务、腾讯云 TKE 服务等托管集群之中。并能够适配公有云服务商所提供的多种云服务,比如通过CSI为业务Pod分配阿里云硬盘存储。

Rainbond控制台则提供了多集群管理的唯一入口,用户不需要过多学习,就可以掌握面向不同云环境发布应用的操作步骤。而这些操作步骤是统一且易用的,不受低层不同云环境的掣肘。

团队工作空间隔离

Rainbond云原生应用管理平台在控制台层建设用户体系,这意味着用户体系与低层云环境无关,Rainbond 通过自身RBAC权限体系来决定用户可以访问哪些云环境所对应的工作空间中的资源。Rainbond 通过团队这一抽象概念来划分用户的工作空间。团队与低层云环境的对应关系可以是共享的,也可以是独享的。用户一旦加入指定的团队,即可使用团队所开通的集群。

  • 共享模式:即一个团队在多个不同的集群中开通,团队一旦在多个集群中开通,就会在其中同时创建同名的命名空间。在这个团队中的用户,自然可以在不同的集群中部署自己的业务系统。不同集群的操作入口由控制台提供,非常容易理解。
  • 独享模式:独享模式更好理解,即在指定的集群中开通命名空间与之对应,用户仅可以使用这个集群中的计算资源。

基于团队这一工作空间的抽象,用户可以在其中完成应用的发布与管理操作。Rainbond 提供更多能力丰富其管理能力,包括操作审计、资源限额、权限管理等能力。

多云容灾

混合云多云容灾是在混合云场景中,为了确保应用的高可用性和容灾能力而采取的一种策略。在混合云环境中,由于应用可能部署在不同的云平台上,因此需要确保即使某一云平台出现故障或不可用,应用仍能够在其他云平台上继续运行。这就需要实现混合云多云容灾,使得应用可以在不同云平台之间实现无缝切换,确保应用的高可用性和容灾能力。

Rainbond 的多云管理机制为多云容灾打造了坚实的低层框架,纵使 Rainbond 在自身高可用能力上投入甚多,但我们依然不能假定集群级别的宕机崩溃不会发生。生产环境中常借助云服务商提供的其他能力一起建设健壮的多云容灾场景。额外要引用的能力包括:

  • 智能化的网络入口切换能力:Rainbond 依靠 CDN 和智能 DNS 的协作,完成网络入口智能切换的能力。在平时,外部流量可以根据地域自动切换到就近的网关进行访问。在集群级别的宕机发生时,则将有故障的集群入口下线。
  • 数据同步能力:无论用户访问到哪一个集群中的服务,都会得到同样的反馈,保障这个效果的前提是多个集群中的业务数据实时同步。Rainbond 不提供数据同步能力,这一部分我们需要依靠公有云供应商提供的数据同步服务来保障。阿里云提供的 DTS 服务是其中的代表。
  • 专线网络能力:多个集群之间的数据同步往往不会轻易从公共网络中穿梭。从安全性和可靠性的角度出发,我们更倾向于使用专线网络进行多个集群之间的通信,尤其是在数据跨云同步场景里。

从整体架构上考虑多云容灾是我们的首要任务。但面对数据灾难,我们能做的不仅仅是防患未然,如何进行灾难后的恢复也是非常重要的一环。Rainbond云原生管理平台提供两个层次的备份恢复能力,首先是为Rainbond平台本身进行备份,确保平台自身可以恢复;其次是针对应用的备份能力,能够将包括持久化数据在内的应用进行整体备份。机房可以被战争、火灾或者自然灾祸摧毁,但只要运维人员手里拥有备份数据,整个Rainbond混合云平台及运行其上的应用就可以被重建。

跨云应用部署

在混合云场景中,业务应用是一等公民,应用如何能够在不同的云环境中自由部署实际上是对混合云管理场景最基础的要求。在这个方面,Rainbond云原生应用管理平台以应用模板的交付流程来打通应用跨云部署的屏障。

应用交付一直是 Rainbond 致力解决的痛点问题。现代微服务动辄会将业务系统拆分成为几十个相互关联的微服务,利用传统方式将其部署到 Kubernetes 容器云环境中,不免要为数十份复杂的 Yaml 文件和容器镜像头痛不已。加之不同的云供应商所提供的云环境也不相同,更加灾难化了应用交付的体验。

前文中已经说到,Rainbond云原生应用管理平台已经在混合云场景下抹平了不同云环境的使用体验。在应用跨云交付场景中也是如此,复杂的微服务系统在 Rainbond 中被抽象成为了一个可以统一管理、统一交付的应用。通过将应用发布成为应用模板,即可在不同的集群之间完成一键安装和升级。极大的降低了软件交付成本。

写在最后

混合云管理场景是眼下云计算领域最炙手可热的话题,利用 Rainbond 云原生应用管理平台打造的混合云可以解决大多数难点与痛点。面向未来展望,Rainbond 会在混合云管理领域继续发力,围绕更复杂的场景,纳管更多种不同的云资源。比如通过与 Kubedge 的集成,将混合云解决方案扩展到边缘计算场景。

· 阅读需 3 分钟

DataCap是用于数据转换、集成和可视化的集成软件,支持多种数据源、文件类型、大数据相关数据库、关系数据库、NoSQL数据库等。通过该 DataCap 可以实现对多个数据源的管理,对数据源下的数据进行各种操作转换,制作数据图表,监控数据源等功能。

在 Rainbond 上部署 DataCap

前提

安装 Rainbond,可通过一条命令快速安装 Rainbond。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

对接 Rainbond 开源应用商店并部署 DataCap

DataCap 已发布到 Rainbond 开源应用商店,可通过 Rainbond 开源应用商店一键部署 DataCap。

进入 Rainbond 控制台的 平台管理 -> 应用市场 -> 开源应用商店 中搜索 DataCap 并安装。

安装完成后,可通过 Rainbond 提供的默认域名访问 DataCap,默认用户密码 admin/12345678

DataCap 快速入门

添加数据源

进入到 管理 -> 数据源 添加 Mysql 数据源

配置 中配置 MySQL 访问地址,这里可以配置 DataCap 使用的 MySQL,访问地址可在 MySQL 组件 -> 端口 中获取访问地址,MySQL 默认用户密码 root/root

SQL 编辑器

进入到 查询 中选择数据源,就可以在编辑器中编写SQL进行数据源的查询等相关操作。

SQL 绘表

通过 SQL 查询出数据后,可以进行数据绘表。

SQL 片段

片段可以将当前的 SQL 语句保存,方便后续引用。可在 管理 -> 片段 中查询片段列表。

监控进程

管理 -> 进程 中可看到当前数据库的进程。

最后

DataCap 还有更多好用的功能,比如 执行历史、函数、SQL模板,还集成了 ChatGPT 用于 SQL 优化,不过我的 ChatGPT Key 过期了,就不多描述了,有兴趣的小伙伴可以安装体验下。

· 阅读需 6 分钟

Jpom 是一个简而轻的低侵入式在线构建、自动部署、日常运维、项目运维监控软件。提供了:

  • 节点管理:集群节点,统一管理多节点的项目,实现快速一键分发项目文件
  • 项目管理:创建、启动、停止、实时查看项目控制台日志,管理项目文件
  • SSH 终端:在浏览器中执行 SSH 终端,方便进行日常运维,记录执行命令记录
  • 在线构建:在线拉取 GIT、SVN 仓库快速构建项目包,不用运维人员手动上传项目包
  • 在线脚本:在线管理脚本、定时执行脚本、webhook 钩子执行、执行日志等
  • Docker管理:在线管理镜像、容器、SWARM 集群。界面化管理 DOCKER
  • 用户管理:多用户管理,实现不同用户不同权限,用户操作、管理日志完善记录
  • 项目监控:实时监控项目当前状态、如果异常自动触发邮件、钉钉报警通知
  • NGINX 配置、SSL 证书:在线快速方便的修改 NGINX 配置文件,SSL 证书统一管理

Rainbond 与 Jpom 结合

Rainbond 与 Jpom 结合可以实现云原生项目和本地项目的统一管理,例如:

  • 使用 Rainbond 部署和管理 Jpom
  • 可通过 Jpom 构建可容器化的云原生项目并部署在 Rainbond 上管理和运维
  • 通过 Jpom 管理一些无法容器化的传统项目以及部署
  • 通过 Jpom 管理 Rainbond 集群的服务器,可作为堡垒机使用
  • 使用 Jpom 管理脚本、执行脚本和定时脚本等。

部署 Jpom

前提

安装 Rainbond,可通过一条命令快速安装 Rainbond。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

对接开源应用商店并部署 Jpom

Jpom 已发布到 Rainbond 开源应用商店,可通过 Rainbond 开源应用商店一键部署 Jpom。

进入 Rainbond 控制台的 平台管理 -> 应用市场 -> 开源应用商店 中搜索 Jpom 并安装。

安装完成后,可通过 Rainbond 提供的默认域名访问 Jpom并登陆进行用户注册。

Jpom 快速入门

本地构建 + SSH 发布 Java Jar 项目

简述使用 Jpom 构建 Java 项目然后通过 SSH 发布到服务器上并运行。

1.添加 SSH 节点

进到 系统管理 -> 资产管理 -> SSH管理 添加 SSH 节点,如下图。

添加 SSH 节点后,点击 关联,配置文件目录,发布的项目将在这个目录下操作。

2.添加 Git 仓库信息

进入 功能管理 -> 在线构建 -> 仓库信息 新增仓库,Git 仓库地址:https://gitee.com/rainbond/java-maven-demo

3.添加构建任务

进入 功能管理 -> 在线构建 -> 构建列表 添加构建:

  • 名称:自定义

  • 源仓库:选择上一步创建的仓库信息

  • 分支:master

  • 方式:本地构建

  • 构建命令:

    mvn clean package
  • 产物目录:target/java-maven-demo-0.0.1.jar

  • 发布操作:选择 SSH

  • 发布的SSH:选择第一步配置的 SSH 节点

  • 发布目录:选择配置的目录 /home/zqjava 目录是项目运行目录

  • 发布前命令:一般用于停止就的进程。

Tag="java-maven-demo"

pid=$(ps -ef | grep -v 'grep' | egrep $Tag| awk '{printf $2 " "}')
if [ "$pid" != "" ]; then
echo -n "boot ( pid $pid) is running"
echo
echo -n $"Shutting down boot: "
pid=$(ps -ef | grep -v 'grep' | egrep $Tag| awk '{printf $2 " "}')
if [ "$pid" != "" ]; then
echo "kill boot process"
# kill "$pid"
kill -9 "$pid"
fi
else
echo "boot is stopped"
fi
  • 发布后命令:一般用于启动项目。
nohup java -Dappliction=java-maven-demo -jar /home/zq/java/java-maven-demo-0.0.1.jar > /dev/null 2>&1 &

其他都默认即可,保存并构建。

等待构建完成后,就可以在服务器上看到进程,并且也能访问。

最后

Jpom 还有很多优秀的功能和场景,比如:节点管理、脚本管理、文件管理、监控管理 以及一些实践场景等等,有兴趣的小伙伴可以自行探索。

· 阅读需 4 分钟

zyplayer-doc 是一款适合企业和个人使用的WIKI知识库管理工具,提供在线化的知识库管理功能,专为私有化部署而设计,最大程度上保证企业或个人的数据安全,可以完全以内网的方式来部署使用它。

当然也可以将其作为企业产品的说明文档来使用,支持一键将整个空间的内容开放到互联网,并提供有不同风格的开放文档页样式可供选择,省去您为了产品的说明文档而去定制开发一个系统的成本。

本文将介绍通过 Rainbond 部署在线知识库系统 zyplayer-doc 的两种方式,使用 Rainbond 开源应用商店一键部署和通过源代码部署。

部署 zyplayer-doc

安装 Rainbond

Rainbond 是一个云原生应用管理平台,使用简单,不需要懂容器、Kubernetes和底层复杂技术,支持管理多个Kubernetes集群,和管理企业应用全生命周期。主要功能包括应用开发环境、应用市场、微服务架构、应用交付、应用运维、应用级多云管理等。

可通过一条命令快速安装 Rainbond。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

通过应用商店部署 zyplayer-doc

zyplayer-doc 已经发布到 Rainbond 开源应用商店,用户可通过开源应用商店一键安装 zyplayer-doc

在 Rainbond 的 平台管理 -> 应用市场 -> 开源应用商店 中搜索 zyplayer-doc 并安装。

部署完成后拓扑图如下。

可通过 Rainbond 默认提供的域名访问 zyplayer-doc,访问需要加后缀 /zyplayer-doc/,如:http://xxx.cn/zyplayer-doc/,默认用户密码 zyplayer/123456

通过源码部署 zyplayer-doc

zyplayer-doc 是由 Java 编写的 SpringBoot 项目,Rainbond 对于 Java 项目可以通过识别项目的 pom.xml 文件来进行模块的打包以及构建和部署,实现一键式体验。

部署 MySQL

zyplayer-doc 需要使用 MySQL 服务,可以通过 Rainbond 开源应用商店快速部署 MySQL。

在 Rainbond 的 平台管理 -> 应用市场 -> 开源应用商店 中搜索 mysql 并安装,可选择安装 5.78.0 版本。

源码部署 zyplayer-doc

修改 zyplayer-doc-manage/src/main/resources/application.yml配置文件,连接信息可在 MySQL 组件中的依赖信息查看。

zyplayer:
doc:
manage:
datasource:
driverClassName: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&autoReconnect=true&useSSL=false
username: ${MYSQL_USER}
password: ${MYSQL_PASSWORD}

进入到团队/应用内,选择通过源码创建组件。

然后 Rainbond 会检测出来为多模块项目,选择 zyplayer-doc-manage 并进行构建,其他模块都是依赖项,是不可运行的。

编排服务

在应用内 -> 切换到编排模式,将 zyplayer 组件依赖至 MySQL 组件,这样 MySQL 组件会将自身的环境变量注入到 zyplayer 中,zyplayer 组件就可以通过配置文件中的环境变量连接到 MySQL 数据库。

然后更新 zyplayer 组件即可。

最后通过 Rainbond 默认提供的域名访问 zyplayer-doc,访问需要加后缀 /zyplayer-doc/,如:http://xxx.cn/zyplayer-doc/,默认用户密码 zyplayer/123456

· 阅读需 5 分钟

建木 是一个面向 DevOps 领域的极易扩展的开源无代码(图形化)/低代码(GitOps)工具,可以帮助用户轻松编排各种DevOps流程并分发到不同平台执行。

建木的图形化编排提供了多个节点,节点可以定义该步骤要执行的操作,用户可通过多个节点自由组合流水线。Rainbond 社区参与了建木节点的开发并贡献了 Rainbond组件创建与持续部署 节点。用户可使用该节点在 Rainbond 中自动创建组件和持续部署组件。

建木应用的部署则可以通过 Rainbond 开源应用商店一键安装,使建木应用的部署更简单,同时也可以作为应用插件扩展 Rainbond 构建体系。

下图是最终要实现的效果,也是建木的图形化流水线配置,本文将以下图的流程为例进行介绍:

  1. 克隆项目源代码
  2. 使用 Maven 构建项目
  3. 构建 Docker 镜像
  4. 在 Rainbond 上自动创建组件并部署

部署 Rainbond 与建木

Rainbond 部署

Rainbond 是一个云原生应用管理平台,使用简单,不需要懂容器、Kubernetes和底层复杂技术,支持管理多个Kubernetes集群,和管理企业应用全生命周期。

可参阅 基于主机安装Rainbond 文档进行安装。

建木部署

通过 Rainbond 开源应用商店一键安装建木应用,在 平台管理 -> 应用市场 -> 开源应用商店 中搜索 建木,进行安装。

安装完成后,建木应用拓扑图如下,可通过 Rainbond 默认提供的域名访问建木 UI,默认用户密码 admin/123456

同时也可以在 平台管理 -> 扩展 -> 插件 中看到建木应用插件的定义。

建木使用

将通过一个 Java SpringBoot Demo 项目进行演示,项目地址:https://gitee.com/zhangbigqi/java-maven-demo

配置图形化流水线

访问建木UI,进入图形项目。

1.添加 git clone 节点并配置 git 地址。

2.添加 maven构建 节点并配置 workspace,其他都默认。

3.搜索 rainbond,添加 构建docker镜像-rainbond 节点,并配置。

  • 配置 docker 用户和密码,用于推送镜像。需要在建木 首页 -> 密钥管理 中添加。
  • 配置镜像名称。
  • 指定 registry 地址,用于推送镜像。
  • 配置执行构建命令的目录,选择 git clone目录

4.搜索 rainbond,添加 rainbond组件创建与部署 节点,并配置。

运行图形化流水线

保存流水线配置并触发流水线执行,等待流水线执行完毕。

流水线执行完毕后,进入 Rainbond 的测试应用内,可看到组件成功创建。然后进入组件内添加 5000 端口并打开对外服务进行访问,验证服务是否正常。

最后

当然还有更高级的玩法,建木支持定义 Workflow,Workflow 支持节点并行、串行等等,但只能通过代码项目编辑 DSL 定义 Workflow。

· 阅读需 9 分钟

Curve 是网易主导自研的现代化存储系统, 目前支持文件存储(CurveFS)和块存储(CurveBS)。

CurveBS 的核心应用场景主要包括:

  • 虚拟机/容器的性能型、混合型、容量型云盘或持久化卷,以及物理机的远程存储盘
  • 高性能存算分离架构:基于RDMA+SPDK的高性能低时延架构,支撑MySQL、kafka等各类数据库、中间件的存算分离部署架构,提升实例交付效率和资源利用率

CurveFS 的核心应用场景主要包括:

  • AI训练(含机器学习等)场景下的高性价比存储
  • 大数据场景下的冷热数据自动化分层存储
  • 公有云上高性价比的共享文件存储:可用于AI、大数据、文件共享等业务场景
  • 混合云存储:热数据存储在本地IDC,冷数据存储在公有云

使用 CurveAdm 部署 CurveFS

CurveAdm 是 Curve 团队为提高系统易用性而设计的工具,其主要用于快速部署和运维 CurveBS/CurveFS 集群。主要特性:

  • 快速部署 CurveBS/CurveFS 集群
  • 容器化服务
  • 运维 CurveBS/CurveFS 集群
  • 同时管理多个集群
  • 一键升级
  • 错误精确定位

安装 CurveAdm

bash -c "$(curl -fsSL https://curveadm.nos-eastchina1.126.net/script/install.sh)"

主机列表

主机模块用来统一管理用户主机,以减少用户在各配置文件中重复填写主机 SSH 连接相关配置。我们需导入部署集群和客户端所需的机器列表,以便在之后的各类配置文件中填写部署服务的主机名。

这里采用一台服务器,做单节点集群。

配置免密登陆

生成密钥并配置服务器免密登陆

# 一直回车即可
ssh-keygen

# 使用 ssh-copy-id 配置
ssh-copy-id root@172.31.98.243

# 验证免密
ssh root@172.31.98.243

# 无需输入密码登陆成功即可

导入主机列表

准备主机列表文件 hosts.yaml

$ vim hosts.yaml

global:
user: root # ssh 免密登陆用户名
ssh_port: 22 # ssh 端口
private_key_file: /root/.ssh/id_rsa # 密钥路径

hosts:
- host: curve
hostname: 172.31.98.243

导入主机列表

$ curveadm hosts commit hosts.yaml

查看主机列表

$ curveadm hosts ls

准备集群拓扑文件

CurveFS 支持单机部署和高可用部署,这里我们采用单机部署验证。

创建 topology.yaml 文件,只需修改 target: curve,其他都默认即可。

$ vim topology.yaml

kind: curvefs
global:
report_usage: true
data_dir: ${home}/curvefs/data/${service_role}${service_host_sequence}
log_dir: ${home}/curvefs/logs/${service_role}${service_host_sequence}
container_image: opencurvedocker/curvefs:v2.4
variable:
home: /tmp
target: curve

etcd_services:
config:
listen.ip: ${service_host}
listen.port: 2380${service_host_sequence} # 23800,23801,23802
listen.client_port: 2379${service_host_sequence} # 23790,23791,23792
deploy:
- host: ${target}
- host: ${target}
- host: ${target}

mds_services:
config:
listen.ip: ${service_host}
listen.port: 670${service_host_sequence} # 6700,6701,6702
listen.dummy_port: 770${service_host_sequence} # 7700,7701,7702
deploy:
- host: ${target}
- host: ${target}
- host: ${target}

metaserver_services:
config:
listen.ip: ${service_host}
listen.port: 680${service_host_sequence} # 6800,6801,6802
listen.external_port: 780${service_host_sequence} # 7800,7801,7802
global.enable_external_server: true
metaserver.loglevel: 0
braft.raft_sync: false
deploy:
- host: ${target}
- host: ${target}
- host: ${target}
config:
metaserver.loglevel: 0

部署集群

添加 my-cluster 集群,并指定集群拓扑文件

curveadm cluster add my-cluster -f topology.yaml

切换 my-cluster 集群为当前管理集群

curveadm cluster checkout my-cluster

开始部署集群

$ curveadm deploy
......
Cluster 'my-cluster' successfully deployed ^_^.

终端出现 Cluster 'my-cluster' successfully deployed ^_^. 即部署成功。

查看集群运行情况

$ curveadm status
Get Service Status: [OK]

cluster name : my-cluster
cluster kind : curvefs
cluster mds addr : 192.168.3.81:6700,192.168.3.81:6701,192.168.3.81:6702
cluster mds leader: 192.168.3.81:6702 / 7f5b7443c563

Id Role Host Replicas Container Id Status
-- ---- ---- -------- ------------ ------
6ae9ac1ae448 etcd curve 1/1 d3ecb4e81318 Up 17 minutes
c45e2f0b9266 etcd curve 1/1 8ce9befa54b8 Up 17 minutes
6c6bde442a04 etcd curve 1/1 cbf093c6605f Up 17 minutes
9516d8f5d9ae mds curve 1/1 f338ec63c493 Up 17 minutes
fe2bf5d8a072 mds curve 1/1 b423c3351256 Up 17 minutes
7f5b7443c563 mds curve 1/1 7ad99cee6b61 Up 17 minutes
e6fe68d23220 metaserver curve 1/1 d4a8662d4ed2 Up 17 minutes
b2b4dbabd7bf metaserver curve 1/1 65d7475e0bc4 Up 17 minutes
426ac76e28f9 metaserver curve 1/1 f413efeeb5c9 Up 17 minutes

部署 Rainbond

Rainbond 是一个云原生应用管理平台,使用简单,不需要懂容器、Kubernetes和底层复杂技术,支持管理多个Kubernetes集群,和管理企业应用全生命周期。

可以通过一条命令快速安装 Rainbond 单机版。

curl -o install.sh https://get.rainbond.com && bash ./install.sh

执行完上述脚本后,耐心等待 3-5 分钟,可以看到如下日志输出,表示 Rainbond 已启动完成。

INFO: Rainbond started successfully, Please pass http://$EIP:7070 Access Rainbond

部署 MinIO

由于目前 CurveFS 只支持 S3 作为后端存储,CurveBS 后端即将支持。 所以我们需要部署一个 MinIO 对象存储。

通过 Rainbond 开源应用商店一键部署单机版 MinIO 或者集群版 MinIO。进入到 Rainbond 的 平台管理 -> 应用市场,在开源应用商店中搜索 minio 进行一键安装。

部署完成后,通过 Rainbond 提供的域名访问 MinIO 控制台,默认用户密码 minio/minio123456。然后需要创建一个 Bucket 供 CurveFS 使用。

部署 CurveFS-CSI

  • 前提:Rainbond 版本要在 v5.13+

通过 Rainbond 开源应用商店一键部署,进入到 Rainbond 的 平台管理 -> 应用市场,在开源应用商店中搜索 curve-csi 进行一键安装。

由于 CurveFS-CSI 没有 Rainbond 应用模型类的组件,都属于 k8s 资源类型,可在 应用视图内 -> k8s资源 下看到。

安装完成后,需要修改 curvefs-csi-cluster-role-bindingcurvefs-csi-role-binding 的 namespace 为当前团队的 namespace,如当前团队 namespace 为 dev,如下:

# curvefs-csi-role-binding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: curvefs-csi-role-binding
......
subjects:
- kind: ServiceAccount
name: curvefs-csi-service-account
namespace: dev # changed

# curvefs-csi-cluster-role-binding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: curvefs-csi-cluster-role-binding
......
subjects:
- kind: ServiceAccount
name: curvefs-csi-service-account
namespace: dev # changed

创建 storageclass 资源,同样在 应用视图内 -> k8s资源 -> 添加

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: curvefs-sc
provisioner: csi.curvefs.com
allowVolumeExpansion: false
reclaimPolicy: Delete
parameters:
mdsAddr: "172.31.98.243:6700,172.31.98.243:6701,172.31.98.243:6702"
fsType: "s3"
s3Endpoint: "http://9000.grda6567.1frt0lmq.b836cf.grapps.cn"
s3AccessKey: "minio"
s3SecretKey: "minio123456"
s3Bucket: "curve"
  • mdsAddr:通过 curveadm status 命令获取。

    $ curveadm status
    ......
    cluster mds addr : 172.31.98.243:6700,172.31.98.243:6701,172.31.98.243:6702
  • s3Endpoint:填写 MinIO 组件的 9000 端口对外服务域名。

  • s3AccessKey:MinIO 访问 Key,填 root 用户或生成 AccessKey。

  • s3SecretKey:MinIO 密钥 Key,填 root 密码或生成 SecretKey。

  • s3Bucket:MinIO 桶名称。

在 Rainbond 上使用 CurveFS

通过镜像创建一个 Nginx 组件,在 组件 -> 其他设置 修改组件部署类型为 有状态服务。在 Rainbond 上只有 有状态服务 可以使用自定义存储,无状态服务使用默认的共享存储。

进入到 组件 -> 存储 添加存储,选择类型为 curvefs-sc,保存并重启组件。

等待组件启动完成后,进入组件的 Web 终端内,测试写入数据。

然后进入到 MinIO 桶内查看,数据已写入。

未来规划

Rainbond 社区未来会使用 Curve 云原生存储作为 Rainbond 底层的共享存储,为用户提供更好、更简单的云原生应用管理平台和云原生存储,共同推进开源社区生态以及给用户提供一体化的解决方案。