关于云原生:开发者不需要成为-K8s-专家

3次阅读

共计 2357 个字符,预计需要花费 6 分钟才能阅读完成。

之前有一篇文章“扯淡的 DevOps,咱们开发者基本不想做运维!”失去了许多开发者的共鸣,每一个开发人员,都心愿可能抛却运维工作,更专一于本人开发的代码,将创意转化为令人惊叹的利用。然而事不尽如人意,到了云原生时代,开发者的运维工作仿佛并没有缩小,而是变成了在 K8s 上的利用部署和治理。

对运维人员来说,只须要保护好底层的 K8s,便能够在弹性、便捷性上失去微小晋升。然而 K8s 对于咱们开发者而言还是太简单了,咱们还须要学习如何打包镜像以及 K8s 相干常识。许多工夫都节约在了利用部署上,咱们真的须要成为 K8s 专家吗?我只是想部署一个利用至于那么简单吗?你是否曾想过,是否有平台或办法,让咱们不用成为 K8s 专家,甚至都不须要懂 K8s 就能部署好你的利用,轻松治理利用?

理论面临的问题

对于咱们开发者而言,总会遇到以下不同的场景,兴许是公司层面的问题、又或是业务层面的问题,兴许当初用传统部署形式很简略,但随着业务增长,又不得不迁徙。而面对这些问题,咱们也要收回本人的声音。

  • 身处小公司,没有专门的运维。须要程序员本人负责写 Dockerfile + YAML + Kustomize 而后部署到 k8s 下面。除了工作量以外,还面临 K8s 本身的复杂性,对于多套业务,Dockerfie、Yaml、CI、CD 脚本占据了绝大部分的工作量。 不写这些行不行?
  • 公司内的微服务越来越简单,在写代码的根底上还得思考各个服务之间的通信、依赖和部署问题,毕竟除了咱们开发者以外,运维人员也不会比你更相熟微服务之间的简单依赖。兴许曾经开始尝试 Helm,然而编写一个残缺的 Chart 包仍然是如此简单,还可能面临格局问题、配置解耦不齐全导致的换个环境无奈部署问题。工夫全写 Yaml 了。 不额定编写 Helm Chart,间接复制利用行不行?
  • 在大型企业外部,正处于在传统利用迁徙到云环境的十字路口。面对多种集群的需要、现有利用的安稳迁徙、甚至一些公共的模块的复用如何做都将成为咱们须要解决的问题。 不要每次都从新开发,把现有的利用或模块积攒下来行不行?

在这些场景下,咱们大量的工夫都耗费在额定的 Dockerfile、Yaml、Helm Chart 这些编写上了。K8s 很好,但仿佛没解决咱们开发者的问题,咱们开发者用 K8s 反而变得更加简单。不说须要额定编写的这些文件或脚本,单单是把握 K8s 的常识就须要消耗大量工夫和精力。
这些问题真的绕不过来吗?我感觉不是。来理解下 Rainbond 这个不须要懂 K8s 的云原生利用治理平台吧。谁说只有成为 K8s 专家后,能力治理好你的利用?

为什么是 Rainbond?

Rainbond 是一个不须要懂 K8s 的利用治理平台。不必在服务器上进行繁琐操作,也不必深刻理解 K8s 的相干常识。Rainbond 遵循“以利用为核心”的设计理念。在这里只有你的业务模块和利用。每一个业务模块都能够从你的代码仓库间接部署并运行,你不是 K8s 专家也能够治理利用的全生命周期。同时利用 Rainbond 的模块化拼装能力,你的业务能够灵便积淀为独立的利用模块,这些模块能够随便组合、有限拼装,最终构建出多样化的利用零碎。

1. 不懂 K8s 部署 K8s 行不行?

行! 对于很多初学者或者开发人员来说,如果公司外部曾经搭建好了可用的 K8s 平台,那么这一步不会是须要放心的问题。然而对于一些独立开发者而言,却很难有这样的环境,而 Rainbond 就提供了这样的解决方案,在 Linux 服务器上,只须要先运行一个 Docker 容器,拜访到 Rainbond 控制台后,再输出服务器的 IP 地址,即可疾速部署一套残缺的 K8s 集群。

如果这还是太简单,那么能够尝试应用 Rainbond 的疾速装置,只须要一个容器和 5 分钟工夫,就能为你启动一个带 K8s 集群的平台,而你在平台上部署的业务也都会部署到这个集群中。

2. 不想或不会写 Dockerfile、Yaml 等文件能不能部署利用?

能! Rainbond 反对自动识别各类开发语言,不管你是应用哪种开发语言,如 Java、Python、Golang、NodeJS、Dockerfile、Php、.NetCore 等,通过简略的向导式流程,无需配置或大量配置,Rainbond 都可能将它们辨认并主动打包为容器镜像,并将你的业务疾速部署到 K8s 集群中进行高效治理。你不再须要编写任何与代码无关的文件。只须要提供你的代码仓库地址即可。

3. 各类业务零碎如何拼装?

在 Rainbond 中,不同的业务程序能够通过简略的连线形式进行疾速编排。如果你须要前端我的项目依赖后端,只需关上编排模式,将它们连接起来,便能迅速建设依赖关系,实现模块化的拼装。这为你的利用架构带来了极大的灵活性,无需简单的配置和操作,即可疾速构建简单的利用零碎。

同时如果你曾经实现了残缺的业务程序,它可能蕴含多个微服务模块,你还能够将其公布到本地的组件库实现模块化的积攒。下次部署时能够间接即点即用,且部署后能够与你其余应用程序再次进行拼装。实现有限拼装组合的能力。

4. 不会 K8s 能不能治理部署好的利用?

没问题! Rainbond 提供了面向利用的全生命周期治理运维,不须要学习 Kubectl 命令,也不须要晓得 K8s 内简单的概念,即可在页面上一键治理利用内各个业务模块的批量启动、敞开、构建、更新、回滚等要害操作,同时还反对利用故障时主动复原,以及利用主动伸缩等性能。同时还反对利用 http 和 tcp 策略的配置,以及相应的证书治理。

如何应用?

在 Linux 终端执行以下命令,5 分钟之后,关上浏览器,输出 http://< 你的 IP>:7070,即可拜访 Rainbond 的 UI 了。

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

接下来追随疾速入门即可疾速部署你的第一个利用。

正文完
 0