V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Jianzs
V2EX  ›  程序员

大家觉得这种部署方式怎么样?

  •  
  •   Jianzs ·
    pluto-lang · 198 天前 · 2631 次点击
    这是一个创建于 198 天前的主题,其中的信息可能已经有所发展或是发生改变。

    问一下各位 V 友,你们平常会有把应用部署到云上的需求么?都是怎么部署的呢?

    这里想讨论的应用不仅仅是一份应用代码,我们都知道,一个应用可能会依赖很多后端服务,比如 LangChain 应用会用数据库来保存会话历史,用向量数据库存储知识库的 Embedding 。

    然后,我发现将这样的依赖多个服务的综合应用(或者叫多应用?)部署到云上挺麻烦的,目前大致有两种方式:IaC 、手动。但是这两种方式,我分析下来有下面这几个问题。或许这也是 LangSmithModalLaptonAI 之类的 AI Infra 产品出现的原因?

    1. 极易出错:两种方式本质都是手动逐个创建细粒度的服务实例,容易出现配置遗漏、错误等问题,而这些问题在部署过程中很难被发现,只有在应用运行时才会暴露出来。
    2. 需要云背景知识:不管是通过 CDK 代码定义服务实例,还是通过控制台手动创建服务实例,都需要开发者对 AWS 的服务有深入的了解,包括应用直接依赖的 DynamoDB 、S3 等服务,以及间接依赖的 IAM 等服务。
    3. 权限配置繁琐:出于安全的考虑,我们通常以最小权限原则来配置各个资源服务实例的权限,如果由开发者通过 CDK 或者控制台手动管理这些权限,那必定是一个非常繁琐的配置过程,并且在修改业务代码后,也非常容易忘记更新权限配置。
    4. 依赖管理:在将 LangChain 应用发布成 AWS Lambda 函数实例时,我们需要在打包时将应用依赖的 SDK 一并打包进来,而这个过程需要开发者手动管理,一方面容易遗漏依赖库,另一方面如果本地设备的操作系统、CPU 架构与 AWS 平台不一致,那打包过程就会更加麻烦。

    区别于 AI Infra ,我从另一个角度出发来尝试解决这些问题:能不能直接从应用代码中直接推导出应用的基础设施资源需求,然后自动在 AWS 等云平台上创建相应的资源实例,通过这种方式来简化资源创建和应用部署的流程。

    基于这个想法,我做了一个研发工具,叫做 Pluto 。基于 Pluto 实现的 LangChain 应用长下面这个样子,就和普通 Python 应用一样,但是,只需要执行 pluto deploy,Pluto 就能在 AWS 平台上自动创建 API Gateway 、Lambda 资源实例,并且配置好 API Gateway 到 Lambda 的路由、触发器、权限等。

    import os
    
    from pluto_client import Router, HttpRequest, HttpResponse
    from langchain_core.pydantic_v1 import SecretStr
    from langchain_core.prompts import ChatPromptTemplate
    from langchain_core.output_parsers import StrOutputParser
    from langchain_openai import ChatOpenAI
    
    prompt = ChatPromptTemplate.from_template("tell me a short joke about {topic}")
    model = ChatOpenAI(
        model="gpt-3.5-turbo",
        api_key=SecretStr(os.environ["OPENAI_API_KEY"]),
    )
    output_parser = StrOutputParser()
    
    def handler(req: HttpRequest) -> HttpResponse:
        chain = prompt | model | output_parser
        topic = req.query.get("topic", "ice cream")
        joke = chain.invoke({"topic": topic})
        return HttpResponse(status_code=200, body=joke)
    
    router = Router("pluto")
    router.get("/", handler)
    

    你觉得这种方式可以让云更好用么?你会喜欢么?

    最后最后,走过路过的大佬,求个 star🌟 👉 https://github.com/pluto-lang/pluto

    13 条回复    2024-05-17 17:14:03 +08:00
    ShineyWang
        1
    ShineyWang  
       198 天前
    CI CD 没有吗?
    自动发布 一键脚本部署还有什么问题吗?
    guanzhangzhang
        2
    guanzhangzhang  
       198 天前
    你是否需要 CICD 和 terraform
    Jianzs
        3
    Jianzs  
    OP
       198 天前
    @ShineyWang CI/CD 的确很方便,我也非常认可这种方式,后续我也会做 GitOps 实践。

    其实你提到的这些方式,前提是自己原本就有云的背景知识,就会部署,然后把这些经验沉淀成流水线或者脚本,但是这个脚本只针对单独的某个项目。所以,个人认为这种方式没法惠及更多能力没有那么强的开发者。

    我这项目背后其实就是先解析出应用对云的依赖,然后生成一份 IaC 代码,然后自动执行。

    https://pluto-lang.vercel.app/zh-CN/blogs/240515-develop-ai-app-in-new-paradigm 这篇文章比这个帖子更详细一些,大佬可以看看,欢迎交流
    7lQM1uTy635LOmbu
        4
    7lQM1uTy635LOmbu  
       198 天前 via iPhone
    软广,建议移送推广节点
    Jianzs
        5
    Jianzs  
    OP
       198 天前
    @guanzhangzhang 我想把 pluto deploy 做到 CICD 里,让没有 IaC 背景的开发者,也能很简单的用上云。

    理想一点,就是想实现提了很多年的一个概念,云是一台大电脑。想达成的体验就是,开发者只管敲码,执行一条命令,应用就跑到云上了,不用关心云的细节
    ZSeptember
        6
    ZSeptember  
       197 天前
    没太理解和 terraform ,pulumi 的区别是什么。

    是提供一些预制的模板吗
    Mithril
        7
    Mithril  
       197 天前   ❤️ 1
    @Jianzs 前提是云服务厂商不收你钱,或者压根没人扫你服务。
    不然一旦你哪里配置有问题,跑出了大量的费用;或者安全配置没搞好,被人刷爆/拖库。

    那么这个责任是你的,还是开发者的,还是云服务厂商的?

    这就是为什么 AI 医疗喊了那么多年,各种论文研究刷遍各种会议,但最终能落地的还是不多的原因。
    它本质上是个责任问题,而不是技术问题。

    想要改也很简单,自动生成 IaC 配置,但不会部署。或者将两步拆开,强制使用者 review 一遍 IaC 脚本。
    Jianzs
        8
    Jianzs  
    OP
       197 天前
    @Mithril 有道理,感谢大佬!现在是基于 Pulumi 实现,后面打算支持 TF ,到时候导出 TF 代码,让开发者确认
    Jianzs
        9
    Jianzs  
    OP
       197 天前
    @ZSeptember 开发者使用 Terraform 的话,需要维护业务代码、基础设施代码两套代码,有上手成本和维护开销。

    我这里的话,是用户只需要编写业务代码,然后 Pluto 理解业务代码的资源需求,自动生成 IaC 代码,目标是让开发者不关心基础设施。

    业务代码就像平常写的代码一样,这里不是基于模版来实现的,而是通过程序静态分析来实现的
    ZSeptember
        10
    ZSeptember  
       197 天前
    @Jianzs #9 想法确实还可以。但是在公司用起来可能很难。
    1. 根据业务代码,准确性很难保证
    2. 过于动态了
    3. 很难精细化控制到底需要多少资源

    当然最核心的是,现实中,业务部门和运维部门是分开的,很多资源都是要单独申请创建或者修改的,而不是会允许 CICD 里面自动就创建,修改了。
    Jianzs
        11
    Jianzs  
    OP
       197 天前
    @ZSeptember #10 感谢大佬反馈

    对于你最后提到的核心问题,深表赞同,所以这款工具的定位就是面向个人开发者的,对基础设施也有要求,云化需要做的比较好。

    对于大佬前面提到的三个问题,我是这样解决的,可以交流一下:

    1. 对于第一点,Pluto 生成的不是最终的 IaC 代码。比如 API Gateway 这类组件,其实用起来还需要 Route 、Trigger 、Stage 、Integration 之类的组件,我们把这些组件组合在一套 SDK 里,封装出一些方法,生成的代码是这套 SDK 方法的调用。一两句话说不清楚,可以看下这篇文档 https://pluto-lang.vercel.app/zh-CN/documentation/how-pluto-works

    2. 对于第二点,目前的确灵活性不足,我只支持在全局作用域定义这类特殊变量,最近才支持了环境变量,只能说尽可能覆盖更多的编程行为。

    3. 对于第三点,目标是:抽象之下支持完全可扩展性。会在 Router 这类构造器上提供一个 options 参数,通过这种方式对资源进行细粒度的配置。后续也想做插件体系,通过插件的形式对生成的 IaC 代码进行修改。
    ZSeptember
        12
    ZSeptember  
       197 天前
    @Jianzs #11 我觉得想法确实不错,面向个人开发者的话, 不想商业化的话,挺好的。
    我做自己项目的时候也考虑过用一下 terraform ,pulumi ,但是后来发现学习这个的成本还不如手动点点点。
    就是说,很多情况下,个人开发者,,不没有那么多资源,vm ,gateway ,估计都是一次性配置好了。用 lambda 多了,可能需要更多的自动化。
    Jianzs
        13
    Jianzs  
    OP
       197 天前
    @ZSeptember #12 终于有人肯定啦,不考虑商业化

    是这样的,很多个人开发者虚拟机一把梭哈,没有并发的压力,也就不太考虑 Serverless 这一套,所以现在是通过 AWS 的羊毛来吸引用户能上手试试,给点反馈

    大佬下次有需求可以试用一下,劳驾点个 star 呗
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2644 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 04:04 · PVG 12:04 · LAX 20:04 · JFK 23:04
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.