Summary
- DORY诞生的背景和初衷是什么，DORY是什么
什么是DORY
背景
三代基础设施的特点
- 第一代基础设施: 裸金属，以物理服务器、小型机为代表，应用直接部署在物理服务器上，每台服务器独立安装操作系统，独立安装配置应用运行环境，应用独立部署与维护。
- 第二代基础设施: 虚拟化，以vmware、openstack为代表，应用部署在虚拟服务器中，物理服务器被虚拟化成多台虚拟服务器，虚拟服务器可以统一安装操作系统，但是必须独立安装配置应用运行环境，应用独立部署与维护。
- 第三代基础设施: 容器化(云原生)，以docker、kubernetes为代表，应用部署在容器中，容器中包含应用的所有运行环境，可统一部署，统一运维。
裸金属 虚拟化 部署与运维特点 |
容器化 部署与运维特点 |
|---|---|
| 独立安装 操作系统或者应用运行环境需要独立安装 |
统一打包 把应用运行环境统一打包到容器镜像中 |
| 独立部署 需要独立开发脚本或者手工方式把应用部署到各个主机上 |
统一部署 编写应用部署配置文件，统一部署到容器云环境中 |
| 独立维护 每台主机、每个环境、每个应用需要独立维护保障 |
统一维护 统一维护容器云环境即可，统一维护保障 |
| 应用迁移难 应用要迁移到其他主机，必须独立安装、独立调试 |
应用迁移易 容器包含了应用运行环境，容器云可以把应用调度在任何容器云节点上运行 |
| 水平扩展难 应用水平扩容需要独立安装主机安装环境，水平缩容又要重新回收主机环境释放资源 |
水平扩展易 容器云上调整一个参数，即可实现应用的水平扩缩容，内置支持自动水平扩缩容 |
| 高可用实施难 应用高可用方案需要独立实施高可用和负载均衡方案 |
内置高可用 容器云内置高可用方案，无需各个应用独立实施 |
| 需抢通抢修 主机故障和环境出故障需要单独抢通抢修 |
故障迁移 容器出故障直接丢弃容器，并直接迁移到其他节点即可 |
| 研发与运维分工界面不清 应用部署由运维人员实施，部署过程存在很高的沟通成本，出现故障不容易分清是研发问题还是部署问题 |
研发与运维分工界面清晰 应用的容器镜像由应用开发者统一打包，统一部署，运维人员统一维护容器云，故障定位容易，分工界面清晰 |
为什么容器云普及难
- 既然第三代容器化(云原生)基础设施有这么多优势，为什么还没有在很多领域普及？
- 因为云原生技术实在是 难
- 技能要求高: kubernetes虽然功能强大，但是架构复杂，编写各类应用部署资源的定义文件直接劝退很多开发运维人员，而且经常出现编写不规范的问题。
- 沟通成本高: 由于在kubernetes上部署应用需要很多技能，一般应用开发者很难掌握并自行部署应用，因此会把应用部署交给kubernetes的运维人员负责，因此引入很高的沟通成本，应用开发者要调整一个小参数都必须找运维人员调整。
- 工具整合难: 很多开发团队为了让应用跑到云原生环境，引入了
DevOps持续交付工具链，让应用源代码通过持续交付流水线直接发布到云原生环境，但是这些工具使用难度高，整合难度高，在很多实施案例中都发挥不出预期的作用和价值。
DORY诞生的初衷
DORY诞生的初衷
- 能否让应用开发者通过几项简单的、所见即所得的配置，就可以自动配置好自己的持续交付流水线？
- 能否让应用开发者无需学习kubernetes的架构，无需编写复杂的应用部署配置文件，就可以自己发布应用到云原生环境？
- 能否让那些不懂devops、不懂kubernetes的应用开发者自己就可以把应用从源代码
编译➡打包➡发布到云原生环境？
DORY是什么
- Dory-Engine是一个简单得吓人的应用上云引擎。
- 应用开发者只需要通过几项简单的、所见即所得的配置，就可以自动配置好自己的持续交付流水线。
- 应用开发者无需学习kubernetes的架构，无需编写复杂的应用部署配置文件，就可以自己发布应用到kubernetes云原生环境。
- 让那些不懂devops、不懂kubernetes的应用开发者自己就可以把应用从源代码
编译➡打包➡发布到kubernetes云原生环境。
- DORY 名字的来由：DORY = DevOps Orechstration YML，是一种DevOps编排定义语言DSL的简称，通过这种极简的DSL编排定义语言，应用开发者可以快速定义自己的应用上云流程。
介绍视频