kurtosis本地搭建测试环境

type

status

date

slug

summary

category

icon

password

near 本地测试环境搭建使用了 kurtosis, 用了之后发现太好用了, 打开了新世界大门. kurtosis可以在本地搭建一整套测试环境, 相比部署到测试环境, 本地搭建自由度更高, 360 度想咋玩咋玩. 并且 kurtosis 的环境定义, 可以整体迁移到线上测试环境, 然后到生产环境. 相比目前开发, 打包一个 docker镜像, 在本地测试某个功能, kurtosis 可以创建多套隔离的测试环境, 看起来爽的起飞.

官方文档

我简单的看过 kurtosis 的官方文档后, 简单的总结一下 kurtosis 的设计理念, 以及它这套工具今后的发展方向.

定义

孤立地启动单个服务容器很困难，因为它对服务、卷数据、机密、证书和网络规则等其他资源具有隐式依赖性, 因此, 环境(而非容器)是构建现代软件的基本单元, kurtosis的目标就是构建复杂的分布式系统像构建单服务器应用一样容易.

痛点解决

远古时期服务的部署是将巨大的二进制文件直接部署到裸金属服务器或者虚拟机上, 这种做法对于生产环境或者分阶段部署维护很困难. 随着容器化, 云服务可以提供多套环境: 比如本地开发, ci 测试, 测试环境, 预生产环境, 生产环境等. 问题在于, 能够handle 这么复杂环境的工具已经落后了, DevOps 是 2000 年代随着敏捷提出的,主旨就是让开发直接去负责交付, 而不是像以前把交付品扔给运维. 但是现在需要面对的环境已经十分复杂了, 甚至要雇佣专门的 devops 工程师, 去负责类似Docker, AWS, Terraform, Kubernetes 和关联的的所有服务. 这样已经实际上违背的 devops 的初衷, 把 dev 和 ops 又重新分开了. 面对这种情况, 需要让开发人员重新去 handle 这些环境: 从产品原型, 测试, debug, 部署生产, 监控等等, 在目前环境复杂的情况下, 把 devops 落地, 这个就是 kurtosis 的目标

架构

enclaves:

kurtosis 奉行环境是一等公民, enclave 可以视为是环境的容器(将环境独立运行管理),

services:

每个环境可以有数量不等的分布式应用, 这些应用就是服务

SDKs:

可以通过 golang 和 typescript 提供的 sdk, 或者 cli 操作 engine

kurtosis的操作语言

Starlark是一个最小化的编程语言, 介于配置语言和普通的编程语言之间, 语法是 python 语法的子集, 目前已经应用于 google 和 facebook 的基础设施构建中. 总结来说, 一个图灵完备的语言, 能够解决环境定义可复用的痛点. 通常的环境有local Dev, ephemeral Test in CI, Prod, 这些不同环境的定义都有类似的需求, 比如都需要容易读写, 参数化, 读取数据, 做某些验证, 不同在于 dev 环境不需要版本控制, 需要快速修改, Test 环境需要版本控制, 需要控制某些参数供测试, Prod 生产环境必须要版本控制, 修改必须经过授权,几乎总是声明式的. 然而, 目前的解决方案无法同时解决这几种环境的可复用的需求, 比如 Ansible从顶部看是一种要求幂等和可验证的脚本,更适用于生产用例. Docker Compose适用于开发环境, 但是对于生产环境缺乏幂等性, 没有验证机制, 无法插件化组合. Helm, Terraform 适用于生产用例, 幂等性, 参数化, 适用于分发, 但是 Helm Charts 的 compose 和 decompose很困难

这些都是这几天使用和阅读 kurtosis 的心得, kurtosis 目前还在快速迭代中. 再补充一下 kurtosis 的翻译, 峰度, 描述了概率分布的特定方面.