Kubernetes 将自身边界内的事物都抽象为资源。其中的主要部分，是以 Deployment、StatefulSet 为代表的 workload 工作负载控制器，其他各类资源都围绕这些主要的资源工作。这些资源合并起来，可以为 IT 技术工作者展现出一个以 workload 为中心的模型。Kubernetes 中所有的资源，都通过声明式配置文件来编辑描述，一条条的 Yaml 字段定义，给了 IT 技术人员最大的自由度的同时，也对技术人员的能力提出了极高的要求。
用过 GitLab 的同学肯定也对 GitLab CI/CD 不陌生，GitLab CI/CD 是一个内置在 GitLab 中的工具，它可以帮助我们在每次代码推送时运行一系列脚本来构建、测试和验证代码的更改以及部署。
Rainbond 本身默认集成了 CI/CD 的整套流程，用户只需提供源代码，后续构建、运行完全交给 Rainbond 处理，整个过程是由 Rainbond 定义的，无需用户干预。这样有利也有弊，利就是简化用户的操作和无需学习 CI/CD 相关知识；弊是用户无法在 CI/CD 过程中自定义，比如想集成代码检测或运行个脚本，这在 Rainbond 的源码构建流程中是不可自定义的。
本文给大家讲述如何使用 GitLab CI/CD 构建、测试、部署 Spring Boot 应用，将产物运行在 Rainbond 上。
随着微服务体系在生产环境落地，也会伴随着一些问题出现，比如流量过大造成某个微服务应用程序的性能瓶颈、CPU利用率高、或内存泄漏等问题。要找到问题的根本原因，我们通常都会通过日志、进程再结合代码去判断根本原因。对于微服务庞大的业务，这必定会很耗时，而且也很难及时找到关键问题点。
本文将介绍一个 持续性能分析平台 Pyroscope，它能够帮助我们快速找到内存泄漏、CPU利用率高的代码。
对代码进行静态扫描是一种非常常见的代码质量保证手段，这种扫描不仅仅可以检查到代码中的缺陷，应用各种业界最佳实践，也可以检查出安全方面的漏洞，给予项目代码全方位的提升。在各种代码扫描方案之中，SonarQube 最为人熟知，应用最为广泛。各种持续集成方案都有自己的方式融入 SonarQube 进行代码的静态扫描工作。
今天介绍一种基于 SonarScanner 在 Rainbond 源码构建过程中，对 Java Maven 项目进行静态扫描的方法。
随着微服务架构的流行，客户端发起的一次请求可能需要涉及到多个或 N 个服务，致使我们对服务之间的监控和排查变得更加复杂。
举个例子：
某条业务线的某个接口调用服务端时快时慢，这时就需要排查各个服务的日志进行分析，调动各个服务的开发人员联动排查，这种排查费时又费力。对于 ToB 的 业务有时候还拿不到日志，难搞哦！
因此，就需要可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，那就是 APM （Application Performance Monitor）。目前流行的 APM 开源工具有很多，比如：Zipkin，Skywalking，Pinpoint、Jaeger 等等，本文将主要介绍 Jaeger 。
Jaeger 是 Uber 技术团队发布的开源分布式跟踪系统，它用于监控和故障排查基于微服务的分布式系统：
MySQLD Exporter 插件基于标准的 MySQLD Exporter 实现。Rainbond 自带的 Prometheus 监控系统 rbd-monitor 会收集 Exporter 中的数据，并通过监控面板展示出来。用户可以自定义展示哪些关键性能数据的指标，这是监控 Mysql 数据库服务的不二之选。
本文描述通过 Rainbond 云原生应用管理平台 一键部署高可用的 DolphinScheduler 集群，这种方式适合给不太了解 Kubernetes、容器化等复杂技术的用户使用，降低了在 Kubernetes 中部署 DolphinScheduler 的门槛。
Apache DolphinScheduler 是一个分布式易扩展的可视化 DAG 工作流任务调度开源系统。解决数据研发ETL 错综复杂的依赖关系，不能直观监控任务健康状态等问题。DolphinScheduler 以 DAG 流式的方式将 Task 组装起来，可实时监控任务的运行状态，同时支持重试、从指定节点恢复失败、暂停及Kill任务等操作
简单易用：DAG 监控界面，所有流程定义都是可视化，通过拖拽任务定制 DAG，通过 API 方式与第三方系统对接, 一键部署
高可靠性：去中心化的多 Master 和多 Worker, 自身支持 HA 功能, 采用任务队列来避免过载，不会造成机器卡死
丰富的使用场景：支持暂停恢复操作.支持多租户，更好的应对大数据的使用场景. 支持更多的任务类型，如 spark, hive, mr, python, sub_process, shell
高扩展性：支持自定义任务类型，调度器使用分布式调度，调度能力随集群线性增长，Master 和 Worker 支持动态上下线
介绍如何使用 Nocalhost Debug 部署在 Rainbond 上的微服务
之前的文章中我们介绍了如何通过 Nocalhost 快速开发 Rainbond 上的微服务，介绍了基本的开发流程。
本文将续接上文继续介绍，使用 Nocalhost 开发配置文件 实现以下内容：
什么是开发配置？
开发配置是围绕 开发模式 来进行的，例如使用什么镜像来进入 开发模式，是否需要开启持久化来保存开发容器的内容，将哪些文件同步到开发容器中，如何一键调试、一键运行容器内的服务等。 配置了正确且合适的开发配置后，可以在使用 Nocalhost 开发模式 时更加得心应手。
本文介绍如何分享你的插件到 Rainbond 开源应用商店，共享插件扩展能力的同时也可以与 Rainbond 社区一起丰富插件市场。
由于应用运维特征的实现都具有较大的共性，为了将业务容器与其运维能力解耦，Rainbond 基于 SideCar 模式实现了一种组件下的插件机制。Rainbond 插件可以作为组件运维能力的扩展，插件本身就是一个 Sidecar 容器，它可以用于解决以下问题：
插件本身仅包含描述和实现，使其可以被复用。必须绑定到组件时才具有运行时状态。在 V5.7.0-release 版本中，Rainbond 支持用户分享自己的插件到开源应用商店中，其他用户都可使用该插件。
本文介绍在 Rainbond 中使用 Fluentd 插件，收集业务日志，输出到多个不同的服务。
以往有篇文章介绍 EFK（Kibana + ElasticSearch + Filebeat）的插件日志收集。Filebeat 插件用于转发和集中日志数据，并将它们转发到 Elasticsearch 或 Logstash 以进行索引，但 Filebeat 作为 Elastic 的一员，只能在 Elastic 整个体系中使用。
基础不牢，地动山摇。无论是何种体系架构，底层存储的选择都是一个值得探讨的话题。存储承载着业务的数据，其性能直接影响到业务应用的实际表现。也正因为存储和业务的数据关联紧密，其可靠性也必须得到关注，存储的失效一旦导致业务数据丢失，那将会是一场灾难级别的事故。
本文将介绍如何使用 Nocalhost 快速开发 Rainbond 上的微服务应用的开发流程以及实践操作步骤。
Nocalhost 可以直接在 Kubernetes 中开发应用，Rainbond 可以快速部署微服务项目，无需编写Yaml，Nocalhost 结合 Rainbond 加速我们的微服务开发效率。
本文主要表述，基于 Rainbond 安装部署 NeuVector 容器安全平台的步骤，以及配合 Rainbond 实现生产环境中的最佳实践。
Envoy 可以作为 Sevice Mesh 微服务框架中的代理实现方案，Rainbond 内置的微服务框架同样基于 Envoy 实现。本文所描述的熔断实践基于 Rainbond 特有的插件机制实现。
Envoy 可以作为 Sevice Mesh 微服务框架中的代理实现方案，Rainbond 内置的微服务框架同样基于 Envoy 实现。本文所描述的熔断实践基于 Rainbond 特有的插件机制实现。
当前文档描述如何通过云原生应用管理平台 Rainbond 一键安装高可用 Apollo 集群。这种方式适合给不太了解 Kubernetes、容器化等复杂技术的用户使用，降低了在 Kubernetes 中部署 Apollo 的门槛。
在之前的平台中，对于组件之间的网络流向不具备直接的可观测性，用户组件间通信出现问题，只能通过传统命令行工具进行手动排查，而 cilium 的 Hubble 服务可以提供 UI 界面向用户展示实时的流量状态，同时可以将这些指标暴露给 Prometheus 进行聚合整理，让用户可以更直观的对底层网络状态进行观测监控。