Apollo 分布式配置中心基于 Rainbond 云原生平台的一键部署与多环境管理实战指南【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo导读本文面向不熟悉 Kubernetes、容器化等底层技术的开发者与运维人员讲解如何借助开源云原生应用管理平台 Rainbond以应用模版 图形化界面的方式一键安装高可用 Apollo 配置中心集群并在 Rainbond 拓扑视图中完成环境变量、配置文件挂载与 Service Mesh 出口网络治理插件等日常配置。读完本文你将掌握 Apollo 在 Rainbond 上的完整部署链路、PRO环境的默认初始化方式以及如何通过实例伸缩与追加环境两个高级特性构建统一 Portal 管控的多环境如DEV、PRO配置管理体系同时理解这些操作背后对应的 Apollo 源码实现原理。一、背景为什么用 Rainbond 部署 ApolloRainbond 是一款易于使用的开源云原生应用管理平台。借助 Kubernetes 和容器化技术它将故障自愈、弹性伸缩等自动化运维能力赋能给用户的业务同时内置原生 Service Mesh 微服务框架并与 Spring Cloud、Dubbo 等其他微服务框架有良好的整合体验。Apollo本仓库 apollo是一个适用于微服务配置管理场景的可靠分布式配置中心。二者在用户群体上高度重合大量 Rainbond 用户同时也是 Apollo 用户。对于这类用户而言手动编排 Config Service、Admin Service、Portal 三组件的容器、数据库与网络关系成本较高而 Rainbond 团队将 Apollo 制作成可一键部署的应用模版供开源用户免费下载安装极大降低了 Apollo 集群的部署负担。当前该安装方式支持1.9.2与2.0.1两个版本默认集成一套PRO环境如需其他环境可参见本文高级特性章节。1.1 什么是应用模版应用模版是面向 Rainbond 云原生应用管理平台的安装包。无论业务系统多么复杂应用模版都会将其抽象成为一个应用裹挟着应用内所有组件的镜像、配置信息以及所有组件之间的关联关系一并安装起来。对 Apollo 而言一个应用模版即包含Apollo-portal、Apollo-config、Apollo-admin三个核心组件的镜像各组件间的依赖/连接关系如 Portal 依赖 Config默认环境变量与配置文件挂载项如APOLLO_PORTAL_ENVSpro内置的数据库组件如ApolloPortalDB、ApolloConfigDB。安装时只需选择目标团队、集群与应用Rainbond 便会按照模版描述的依赖顺序自动拉起整套集群。二、前提条件开始安装前请确认满足以下条件前提说明已部署 Rainbond 云原生应用管理平台例如使用快速体验版本可在个人 PC 环境中以启动一个容器的代价运行完整平台可连接到互联网安装过程中需要拉取 Apollo 应用模版及组件镜像内置开源应用商店需要联网访问注意本文描述的是应用商店一键安装路径区别于仓库中另一篇 quick-start.md手动部署与 quick-start-docker.mdDocker 快速开始Rainbond 路径完全基于图形化界面无需编写 YAML。三、快速开始一键安装 Apollo 集群3.1 访问内置的开源应用商店登录 Rainbond 控制台后点击左侧导航栏的应用市场标签页在页面中切换到开源应用商店标签页在搜索框输入关键词apollo即可检索到 Apollo 应用模版。3.2 一键安装与参数说明点击 Apollo 右侧的安装按钮进入安装页面填写信息后点击确定即开始安装页面会自动跳转到拓扑视图。安装表单中主要选择项及其含义如下选择项说明团队名称用户自建的工作空间以命名空间隔离集群名称选择 Apollo 被部署到哪一个 Kubernetes 集群选择应用选择 Apollo 被部署到哪一个应用应用中包含若干有关联的组件应用版本选择 Apollo 的版本目前可选版本为 1.9.2、2.0.1等待几分钟后Apollo 集群即安装完成并运行起来。安装完成后拓扑视图中会出现Apollo-portal-2.0.1、Apollo-config-2.0.1、Apollo-admin-2.0.1三个核心组件以及配套的数据库组件。提示这里的三个组件名对应 Apollo 的三个服务——Portal管理界面、Config Service配置下发与 Admin Service配置管理。在仓库源码中Config Service 与 Admin Service 的默认服务端口分别定义在 configservice.propertiesserver.port8080与 adminservice.propertiesserver.port8090这也是后续配置插件域名时只写域名、不写端口仍能精确访问到对应服务的原因之一。3.3 测试验证 PRO 环境就绪访问组件Apollo-portal-2.0.1提供的默认域名即可登录 Apollo 控制台。登录后在系统信息页面中验证PRO环境已经就绪默认安装即附带PRO环境。3.4 配置环境变量、配置文件与插件在 Rainbond 中可基于图形化界面对 Apollo 集群进行配置主要包括环境变量、配置文件挂载、插件配置三个方面1环境变量在不同组件的页面 →环境配置中可自定义环境变量。例如Apollo-portal-2.0.1默认添加了APOLLO_PORTAL_ENVSpro该变量用于定义当前 Portal 纳管的环境列表。其背后的实现位于 PortalConfig.javaportalSupportedEnvs()读取配置项apollo.portal.envs默认值为FAT, UAT, PRO逐一Env.addEnvironment(envName)注册为 Portal 可管理的环境。Rainbond 模版通过环境变量注入APOLLO_PORTAL_ENVS后Spring 的配置绑定机制会将其映射到该配置项从而控制 Portal 展示与操作的环境集合。2配置文件挂载在不同组件的页面 →环境配置中可以为组件设置配置文件通过挂载覆盖容器内默认配置Apollo-portal-2.0.1挂载/apollo-portal/config/apollo-env.properties用于定义不同环境的meta server 地址Apollo-config-2.0.1挂载/apollo-configservice/config/application-github.properties用于声明当前环境 config 与 admin 的服务地址即服务注册与发现信息。apollo-env.properties的解析逻辑在 DefaultPortalMetaServerProvider.java 中实现Portal 启动时依次从配置文件键以.meta结尾、操作系统环境变量键以_meta结尾、系统属性键以_meta结尾中加载所有环境的 meta 地址低优先级先加入、高优先级覆盖最终构建Env - metaServerAddress映射。该文件中的典型键格式为ENV.metahttp://apollo-config-env:8080。环境名在 Env.java 中会统一转换为大写并将PROD归一为PRO、FWS归一为FAT因此大小写混用的环境名也能被正确识别。而application-github.properties对应仓库中的 apollo-configservice/src/main/resources/application-github.properties 与 apollo-adminservice/src/main/resources/application-github.properties。以 config 组件为例其中通过占位符方式声明数据源并引用服务地址相关配置如spring.datasource.url ${spring_datasource_url}等。需要特别说明的是在 Rainbond 的 Service Mesh 网络模型中组件之间的调用由插件定义域名完成因此该文件中的服务地址通常写成apollo-config-env、apollo-admin-env这类域名形式而非 IP:端口。3插件配置出口网络治理在 Rainbond 中通过为Apollo-portal-2.0.1、Apollo-config-2.0.1安装出口网络治理插件来定义下游调用地址这是一种 Service Mesh 微服务治理的实现方式通过定义下游服务的域名来访问下游服务的指定端口。例如在Apollo-portal-2.0.1的插件中访问Apollo-config-2.0.18080 端口的域名为apollo-config-pro这也是上文配置文件中只定义域名、不需要定义端口的原因——端口映射关系由插件统一管理。从源码角度理解这一设计Apollo 的服务发现默认依赖 Eureka但在 Kubernetes/Rainbond 场景下application-kubernetes.properties 等 profile 会显式关闭 Eureka 与 Spring Cloud Discoveryapollo.eureka.server.enabledfalse、eureka.client.enabledfalse、spring.cloud.discovery.enabledfalse转由平台层的服务发现如 KubernetesDiscoveryService.java通过apollo.config-service.url、apollo.admin-service.url等配置解析下游地址。Rainbond 的出口网络治理插件正是替代了这层服务发现职责将域名解析到目标组件端口。四、高级特性4.1 实例数量伸缩集群化部署Apollo 配置中心所包含的Apollo-portal-2.0.1、Apollo-config-2.0.1、Apollo-admin-2.0.1三个组件均使用 Deployment 控制器部署通过 Rainbond 内置的 Service Mesh 微服务框架实现服务发现与通信。因此这三个组件均可以一键扩展多个实例实现集群化部署与高可用。以Apollo-portal-2.0.1为例进入组件页面点击伸缩修改实例数量点击设置生效。Rainbond 会自动完成新实例的负载均衡与服务发现注册无需修改任何 Apollo 配置。Config Service 与 Admin Service 同样可按此方式扩容以满足高并发配置拉取场景下的吞吐需求。4.2 追加环境如新增 DEV 环境Apollo 配置中心支持对接多套环境并使用统一的 Portal 页面进行管理。基于 Rainbond 一键安装而来的 Apollo 集群默认附带PRO环境。下面演示如何在 Rainbond 场景中追加一套DEV环境。假设在DEV环境中通过apollo-config-dev、apollo-admin-dev分别访问Apollo-config-Dev、Apollo-admin-Dev组件。步骤 1部署一套新的 Apollo 集群并调整拓扑再部署一套 Apollo 集群并去除新集群中的Apollo-portal-2.0.1与ApolloPortalDB组件新环境无需独立 Portal。为便于管理将Apollo-config-2.0.1、Apollo-admin-2.0.1组件改名为Apollo-config-Dev、Apollo-admin-Dev然后添加旧集群Apollo-portal-2.0.1到这两个新组件的依赖。注意该步骤会触发连接信息环境变量冲突的情况请记得为Apollo-config-Dev、Apollo-admin-Dev组件的对内端口重新定义名字例如apollo-config-dev、apollo-admin-dev避免依赖注入时连接信息键名冲突。步骤 2修改 config 组件的服务地址配置文件在环境配置页面修改Apollo-config-Dev的配置文件/apollo-configservice/config/application-github.properties将 config 与 admin 的服务地址修改为预期值即本环境中两个组件的对内访问域名形如apollo-config-dev、apollo-admin-dev。步骤 3配置出口网络治理插件域名分别进入Apollo-config-Dev与Apollo-portal-2.0.1的插件页面为其出口网络治理插件修改配置。Rainbond 内置的微服务框架通过设定的域名Domains定义下游服务的访问地址以Apollo-portal-2.0.1为例需要配置到Apollo-config-Dev、Apollo-admin-Dev的访问域名如apollo-config-dev、apollo-admin-dev配置完成后点击更新配置Apollo-portal-2.0.1即可通过apollo-config-dev这个域名访问到Apollo-config-Dev同理Apollo-config-Dev需要配置到Apollo-admin-Dev的访问域名配置完成后更新配置。步骤 4修改 Portal 配置以纳入 DEV 环境修改Apollo-portal-2.0.1的配置来加入新的DEV环境分两步修改环境变量APOLLO_PORTAL_ENVS的值加入dev环境例如APOLLO_PORTAL_ENVSpro,dev修改配置文件/apollo-portal/config/apollo-env.properties写入dev环境的 meta 地址例如dev.metahttp://apollo-config-dev:8080完成后更新Apollo-portal-2.0.1组件使所有配置生效。最后查看系统信息验证DEV环境加入完成。原理说明环境变量APOLLO_PORTAL_ENVS对应 PortalConfig.java 中的apollo.portal.envs配置决定 Portal 纳管哪些环境而apollo-env.properties中dev.meta键则由 DefaultPortalMetaServerProvider.java 读取键以.meta结尾为DEV环境提供 meta server 地址。二者缺一不可前者让 Portal 展示该环境后者让 Portal 能访问该环境的 config 服务。五、总结通过 Rainbond 应用模版用户可以完全避开 Kubernetes YAML 编写与组件编排在图形化界面中完成 Apollo 高可用集群的部署、配置与扩容部署开源应用商店搜索apollo→ 一键安装默认附带PRO环境配置通过环境变量APOLLO_PORTAL_ENVS、配置文件挂载apollo-env.properties、application-github.properties与出口网络治理插件完成组件间通信定义高可用三个核心组件基于 Deployment Service Mesh 可一键横向扩容多环境通过部署第二套集群去掉 Portal 与 PortalDB、修改 config 服务地址、配置插件域名、更新 Portal 环境变量与 meta 文件四个步骤即可将DEV等新环境纳入统一 Portal 管理。这一部署路径与仓库中的 英文版文档 互为对照也可结合 分布式部署指南 与 部署架构 进一步理解 Apollo 各组件之间的通信模型。对于希望深入了解 Portal 环境解析与 meta 地址加载机制的读者建议直接阅读 DefaultPortalMetaServerProvider.java 与 Env.java 的完整实现。【免费下载链接】apolloApollo is a reliable configuration management system suitable for microservice configuration management scenarios.项目地址: https://gitcode.com/gh_mirrors/apoll/apollo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考