近年来， 互联网极速发展，为了跟进业务快速增长的发展步伐，新的技术如雨后春笋般不断的涌现，一眼望去，漫天星光，群星争艳。以容器为核心的云原生技术成长迅速，其中 Kubernetes 作为新的基础设施，容器编排事实上的标准， 无疑是最耀眼的那颗星。
然而，Kubernetes 虽然很好的解决了大规模应用部署，资源管理及调度的问题，但是其对业务交付并不友好，Kubernetes 自身的部署也比较复杂，在不断涌现的围绕 Kubernetes 生态的应用中， 始终缺少了可以将业务、中间件、集群整合起来一体化交付的应用。
在当下，由阿里云智能云原生应用平台团队发起， 政采云、谐云科技合作共建的 sealer 开源项目补充了 Kubernetes 在一体化交付领域的短板，sealer 以非常优雅的设计方案考虑了集群 + 分布式应用的整体交付。而政采云作为政府采购行业的代表，已成功的利用 sealer 完成了大型分布式应用的整体私有化交付，交付的实践充分证明了：sealer 具备灵活，强大的一体化交付能力。
政采云的私有化交付客户为政企场景，需交付业务规模较大：300+ 业务组件， 20+ 中间件，交付目标的基础设施不同构且不可控，网络限制严格，一些敏感的场景甚至是完全隔离的网络，在这种背景下，业务交付的最大痛点就是部署依赖的处理以及交付一致性的问题。虽然业务统一基于 Kubernetes 进行交付实现了运行环境的一致，但是如何解决部署过程中所依赖的所有镜像、 各种包的统一处理以及交付系统自身的一致性等一系列问题，亟需解决。
如上图所示政采云本地化交付的流程中， 主要分为：用户需求确认-> 提出资源需求给用户 -> 获得用户所提供的资源清单 -> 根据资源清单生成准备配置 -> 准备部署脚本及依赖 -> 实际交付六个步骤。前置准备和实际交付时， 需要消耗大量的人力和时间来准备和进行部署。
云原生时代，docker 的出现解决了单个应用的环境一致性和打包问题，业务的交付不再像传统的交付那样花费大量的时间在部署环境依赖上。而后 Kubernetes 等容器编排系统的出现解决了对底层资源进行统一的调度，对应用运行时进行统一的编排的问题，然而一个复杂的业务， 其交付的本身就是一个工程浩大的问题，以政采云的场景为例：各种 helm chart、RBAC， istio gateway，cni，中间件等各种资源对象的部署和配置，再加上 300 余业务组件的交付，每一次私有化交付带来的都是大量人力和时间成本的消耗。
政采云正处于业务高速发展的时期， 私有化部署项目的需求不断新增，高成本的交付方式越来越难以支撑实际的需要，如何降低交付成本，并保障交付的一致性是运维团队最迫切的需要解决的问题。
在早期， 政采云使用 ansible 来进行业务的交付，ansible 方案实现了一定程度的自动化并降低了交付成本但是存在如下几个问题：
1、ansible 只解决部署过程问题，需要单独准备部署所需的依赖，依赖的准备和可用性验证产生了额外的成本，且政采云的本地化场景基本都会严格限制外部网络。直接从外网获取依赖的方式也不可行。
2、使用 ansible 应对差异化的需求会非常累， 政采云的私有化交付场景中，各个用户的需求不一， 业务的依赖不一，每一次的交付重新编辑 ansible playbook 都要花费不少的时间进行调试。
3、涉及到复杂的控制逻辑时，ansible 的声明语言比较乏力。
4、部署交付之前需要先准备 ansible 的运行环境。无法做到交付的0依赖。
ansible 更多的是在做一些粘合的事情，更适合逻辑比较简单的运维工作。随着本地化项目不断新增， ansible 交付的弊端开始显现，每个本地化项目都需要大量的时间投入，政采云运维团队开始探索和思考交付体系的优化方向。我们调研了很多的技术方案，但是已有的 Kubernetes 的交付工具都专注于集群本身的交付而不考虑业务层交付。虽然可以基于集群部署工具进行封装，但是这种方案和使用 ansible 进行集群部署后再去部署上层业务并没有本质的区别。
比较幸运的是，我们发现了 sealer 项目, sealer 是一套分布式应用打包交付的解决方案，通过把分布式应用及其依赖一起打包以解决复杂应用的交付问题。其设计理念非常优雅，可以以容器镜像的生态来管理整个集群的打包交付。