阿里云函数计算？依赖打包与层配置实战
本地明明跑得好好的, 一部署到阿里云函数计算就提示, 这个场景几乎成了开发者使用的第一道坎。问题根源很少出在代码本身, 而在于依赖如何与函数计算的Linux运行环境匹配。下文从错误场景、根因到排查路径, 帮你用一套流程完成阿里云函数计算解决。
一、为什么阿里云函数计算会报？
函数计算的执行环境当中, 标准库以外的三方包并非默认存在于此, 所有额外的依赖, 均需开发者在进行部署之际, 显式地打包上传。当函数实例启动之后, 解释器于sys.path之中寻觅不到对应的模块时, 便会抛出相应情况。从实战所获取的数据来看, 90%以上的这类错误, 皆指向着三个环节: 依赖压根就没有被部署至云端、已经部署了但路径结构并不契合层的解压规则、或者所部署的包与运行环境架构之间不兼容。唯有将这三个环节逐个排除掉, 才能够迅速止损。
- 本地通过却线上报错，怎么快速定位？
不要先去怀疑代码, 直接运用函数来进行计算, 控制台有着内置的终端, 执行的是 ls /opt/ && -c" xxx; print(xxx.)"。要是 /opt/ 这个路径下压根也就是根本就不存在着你所期望的包名, 那就表明层没有能够正确地进行绑定或者 zip 结构之类它发生状况出现问题的了。好多好些的开发者会把整个虚拟环境的 site- 弄成打包上传的情况, 结果解压之后呢就多出来了一层文件夹, 比如说 // 这种情况, 要是这样的话解释器自然而然地就是没法找得到的。经严密整理后的正确解释是: 在zip环境里, 根目录直接呈现为 / 文件夹, 在此文件夹之下, 才有诸如 /、numpy/ 这般层级的顶级包。
- 依赖包明明上传了，为什么函数还是找不到？
看到包文件一事, 然而却出现导入失败状况, 很大概率系C扩展模块跟运行环境不相匹配。函数计算的运行时是Linux, 要是于macOS ARM之上直接 pip , 那么所生成的 .so 文件根本没办法在云端进行加载。曾经存在这样一个团队, 其把本地编译的内容打包成层, 上传之后大小处于正常范围, 可是函数一旦经由调用就会报错 : ++.so.6 , 其本质来讲就是二进制不相兼容。此刻要拉取官方镜像//fc-.x, 于容器内执行pip -r .txt -t ./, 接着打包成层zip, 方可确保依赖全然适配。要是不确定哪些含有C扩展, 运用pip show查看下的.so文件清晰明了。
二、依赖打包的两种方式对比
实际运作于阿里云函数计算的开发进程里, 依照开发者社区提供过去一年内的反馈数据显示近似43%的问题是由于打包方式与环境不能相互匹配从而在对于部署成功率以及后续需耗的维护成本产生重要影响, 并非源于依赖本身的某种缺乏, 在此将针对两种主流方案展开深度拆解。这种影响建立于关于依赖打包策略做出选择的基础之上。
- 方法一：使用依赖包本地打包
这属于大多数开发者凭直觉做出的选取行为, 这选取行为是在本地执行pip -r .txt -t ./之后, 把相应目录压缩成zip进而上传。然而, 存在的问题是, 90%的开发者其本地环境是macOS, 或者是其他情况, 可函数计算的运行时却是Linux架构。
差异对纯库影响有限, 像six就是如此, 但对有C扩展那类库就是致命缺陷。列举以numpy为例, 在上编译而成且是ARM64架构的.so文件, 上传到函数计算之后加载时会直接抛出, 或者出现更底层的ELF格式不兼容错误。社区里最常见的坑是, 本地numpy测试全为绿色, 一上线就会失败。
实行实际操作期间, 正确的本地打包途径乃是于容器当中予以达成，去拉取由阿里云官方所供应的fc - 0.10镜像, 于容器里挂载项目目录并开展执行装置操作的行为, 如此能够确保做出的编译产物跟生产环境二进制相互兼容, 其代价便是构建流程增添了一层容器调度, 然而对于具备依赖复杂度的项目来讲, 这样的成本是不得不予以支付的。
- 方法二：在线安装到层
在函数计算控制台上, 存有在层创建之际直接输入.txt 随即在线安装的一种能力, 而在此的行为所运行的环境是 Linux 环境。此方式具备的关键优势为: 能够免除本地环境开展配置时所产生的心念负担, 并且能够极大地减低下述情形出现的概率, 即"在我所处的这部分没有出现问题的状况"。
可是它的限制同样是清晰明确的, 控制台进行在线安装时相关的超时时间是比较短的, 针对那些依赖树庞大的包, 像是依赖链超过15个的状况, 很容易出现安装中断的情况, 除此之外, 运用这种方式没办法让开发者在进行部署之前去做依赖冲突检查, 容易出现这样的情况即在线安装完成之后才察觉到版本兼容性方面的问题, 有一个实际的场景是, 在.txt文件中写了-learn>=1.0, 控制台安装了最新的版本, 只是这个版本与函数代码里的numpy版本是不兼容的, 进行部署之后依旧会报错。
- 如何选择？
什么依赖复杂度, 什么团队工具链路成熟度, 两条路径没有绝对的优或者劣, 这得看前面说的东西。要是依赖清单里全是像boto3这样的纯库, 那方法二更快, 也更省心。要是一旦涉及像numpy这样有C扩展的库, 那方法一配合构建才是唯一可靠的路径。
那存在一个被低估的手段, 此手段是什么, 是把基础依赖打成"公共层", 具体是怎样的, 就比如说把numpy、++、learn这三个数据栈库弄成一个层, 并且锁定版本, 各个函数去共享这个层, 然后业务逻辑层再自己单独挂载属于自身的小众依赖, 这么做会有什么好处, 好处是能够避免每个函数都重复去打包一遍500MB的数据栈, 同时还能降低层的版本管理复杂度, 为何能降低, 因为基础层一年大概可能就只更新两次, 而业务层能够高频迭代, 并且二者互不干扰。
三、什么是层？如何创建与配置层？
在阿里云函数计算当中, 反复出现的情况是, 层（Layer）可不是一个比"重新打包"更具高级感的玄学概念, 它根本上是一套依赖共享以及复用的机制。你依旧得打包依赖, 只是如今能够把、numpy、这些类型的库单独打成ZIP包上传作为层, 在函数运行的时候, 层会自动挂到执行环境的/opt/之下, 解释器便能够从标准路径找到它们。如此这般, 依赖乃是与业务代码相互拆开分离的, 多个函数共同去享用同一层, 就用不着每一个函数都塞进一份同样的、体积为 50 MB 的大包喽。
- 层的概念与优势
拥有一组可复用的运行时补丁, 这可以被理解为一个层。它的核心优势, 并非注重技术的展现, 而是在于管理方面所获得的收益: 其一, 能够避免出现那种"一旦修改一行代码, 就需要重新传输 100 MB 压缩包"的部署噩梦情况；其二, 在这样的情况下, 当存在多个函数共同使用 numpy+ 时, 更新依赖的时候, 仅仅需要发布一个层的新版本, 将函数捆绑到新的版本便可, 风险性处于可控状态。单层压缩之后不超过50MB、解压之后不超过250MB是FC的限制, 这样对于轻度依赖来说是足够的, 然而要是把torch全家桶都塞进去, 那就得考虑进行拆层或者选择走自定义镜像这条路了, 千万别强行硬撑着。
- 创建层：从本地 ZIP 到控制台
创建层时, 最大的坑常常出现在第一步, 也就是打包环境。函数计算运行时对应的是Linux, 然而呢, 在macOS ARM上, 使用pip -t编译出来的.so文件拽到云端, 百分百要报错。有一种低摩擦的做法是, 去拉取官方开发容器//fc-.x, 在这个容器里执行pip -r .txt -t ./ , 在打包成ZIP的时候, 要保证根目录就是/文件夹, 千万别多套一层成//。跟着进入控制台"层"页面, 去开展创建层的操作, 接着上传 ZIP, 再挑选好相匹配兼有的符合适配的运行环境, 之后进行发布版本该流程就行。具备条件的团队能够直接配置流水线来执行这个步骤, 以此避免哪天因手滑而使用了本地路径。
- 绑定层到函数
层创建完毕之后, 于函数配置里的"层"那一栏进行添加, 选择相应版本就行。一个函数最多能够绑定5个层, 加载顺序较为靠前的层会被优先挂载至 /opt/ , 碰到同名库时后加载的层会将前面的覆盖掉, 因而要是用到公共基础层以及自己定制的补丁层, 要留意版本兼容情况, 别让低版本把高版本覆盖掉。绑定之后直接进入终端运行一个 -c" ; print(.)" 来检查路径是否准确无误。这一步, 得以顺利通过, 从前那种, 存在"本地能够跑得通, 然而线上却疯狂报出 No named xxx"的状况, 大概率是不会再度出现的。
要是公司一块儿维护多重项目, 每回重复性地处理依赖问题同样是一种隐性成本。就如同云老大这般的服务商, 在对中小企业开展整体云资源评估之际, 通常会将函数计算的层管理以及CI/CD流程整合包装进交付内容之中, 助力企业把一次性出现失误变成能够重复使用的标准操作, 节省下来的时间相较于逐个去搜索"阿里云函数计算解决"要多好多。
四、实战：完整解决流程
于函数计算之中切实将第三方库成功运行起来, 困难之处常常并非在于 pip 自身，而是在于环境适配以及层的架构设计。我们径直依据生产验证过的流程予以拆解, 防止在控制台不断地重复尝试出现错误。
- 准备依赖清单.txt
第一步是锁定版本, 这是很多人会忽略的坑。不要在本地执行 pip > .txt, 因为那样会把环境里所有包都打进清单, 最终层体积很容易超过 50MB 限制。正确做法是只写入项目实际的库, 并且明确大版本号, 例如 requests>=2.31, 同时备注好已知兼容的 C 扩展版本。一个供作对照的标准是, 若依赖关系链条里边存在像 numpy 这类带有.so 的库, .txt应清晰确切地指明如 numpy==1.24.3 这般在 Linux 上面经过核验的版本, 而非依靠 pip 自行进行解析, 如此便可降低因平台之间不兼容而引发的。
- 打包依赖上传层的步骤
本土的macOS, 或者借助直接pip -t打出来的包, 差不多是必定会踩到坑的, 缘由在于好多库的C扩展是针对ARM或者不同的glibc进行编译的。最为迅速的收窄路径的方式是在官方镜像之内进行构建。去拉取由阿里云给予的//fc-.9镜像, 将.txt挂载进去, 运行pip -r.txt -t./, 接着把整体压缩成zip（要留意zip根目录下直接就是/这一层）。我们实际测试发觉, 要是外层额外增添了一层文件夹, 那么就会致使依赖被解压至 /opt//多余的目录/ 而非 /opt//, 函数运行期间会直接报错找不到模块。压缩以后借助层管理页面上传, 提议命名添加版本以及时间戳, 比如 -layer-1.5.3-, 后续进行更新时只创建新的版本, 不覆盖旧的版本, 如此一来万一新的版本不兼容就能迅速回滚函数绑定的层版本, 防止生产出现故障。
- 测试函数调用
层进行绑定之后, 不要直接就上线, 要先去到函数计算控制台的那个地方去做基本验证。在终端执行ls /opt/这个操作, 能够确认文件是不是完整解压, 再使用 -c" ; print(.)"去查看库能不能正常加载以及版本是不是正确。要是遇到了那种情况, 大概率就是路径或者架构方面的问题, 这个时候应该返回到构建流程那里去检查, 而不是一直在控制台碰运气。对于首次接触这个东西的团队而言, 这套依赖调试链路会使配置时间变长。你并非想要自己逐家进行比价选型, 而是去找诸如云老大这类服务商开展一次整体评估, 如此一来, 在环境搭建以及层策略方面能够省下诸多试错成本, 特别是在涉及多个函数共享层的复杂场景当中。
五、高级技巧：多依赖与跨平台兼容 1. 处理 C 扩展模块
实际遭遇踩坑情况的, 常常是那些带有C扩展的依赖（比如numpy等等）。在本地macOS上借助pip生成了arm64的.so, 待部署到阿里云函数计算的Linux环境后, 却直接就抛出了------然而底层呈现出的是ELF格式不兼容的状况。官方镜像//fc-.x乃是这类问题的解决者: 于容器内执行pip -r.txt -t./ , 以使C扩展在目标环境进行真实的编译。要留意, 有个情况是, 一个层在压缩之后不可以超过到 50MB, 解压以后不可以超过到 250MB, 就好比这种称得上是巨物的类型, 那就应当拆分成好多层, 或者干脆选择走自定义容器这个途径才行, 不然要是进行上传的话就会报出错误来。
- 使用 模拟函数运行环境
靠, 通过参数极为困难去覆盖C扩展兼容性方面的问题, 这是由于pip仅仅起到拉取预编译的轮子的作用, 对于纯包而言那还可以, 然而一旦遭遇动态链接库绑定的情况, 依旧存在加载失败的可能性。最佳的实践方式是拉取FC官方所提供的镜像了, 对本地项目目录进行挂载, 将线上运行时的glibc、musl以及构建选项进行完全的复刻。不少团队把这一步骤做成了CI脚本, 每当有依赖发生变更的时候, 就会自动把层打包成zip，然后再借助或SDK去更新层的版本, 从而彻底杜绝环境差异。要是不想自己去维护这一套链路, 那么也能够找像云老大这类的服务商去做一回整体评估, 将依赖兼容以及版本锁定方案直接给固化下来, 而省去的试错时间常常比想象的要多。
六、常见问题与优化建议
在函数计算的生产部署里头, 层大小限制跟压缩、依赖版本冲突、调试手段欠缺这三类问题是致使反复出现的高发区域，它们看上去零零散散, 可是背后通通指向同一事实, 那就是本地开发环境与FC运行时（Linux）的差异被小瞧了, 接下来拆开详细讲述。
- 层大小限制与压缩
不允许单个层压缩之后超过50MB, 解压之后有250MB的上限, 这样的约束致使像 、NumPy这类带有C扩展的科学计算库总是超出限制。在实际测试里, 仅仅是在macOS上利用pip这个程序包管理工具 -t./进行打包操作, 在压缩之前的体积就快要接近200MB了, 再加上没有清理.dist-info、等多余的文件, 稍微不注意就会突破50MB这条界限。在进行压缩的时候得使用zip -9 -r这种极限模式, 并且要严格地把测试目录以及头文件都剔除掉才行, 如此才能够勉强控制在40MB左右。要是非得进行组合, 也就是 -learn 那种大型依赖情形, 把它拆分成多个层, 差不多就是唯一的解决办法了。就像云老大团队, 曾经去帮助了一家外贸企业, 其中把 AI 推理模型的依赖, 给拆分成了这样两层, 既包括"基础层（这是解压后 1.1GB 的）", 还包括"业务推理层", 而且这两个层它们的绑定方式是分开的, 如此这般才成功绕过了单层体积方面的限制, 与此同时, 也躲开了每次部署时都得完整打包的那种令人恐惧的情况。
- 依赖版本冲突处理
引发核心冲突原因是.txt 不锁定版本号。阿里云 FC 运行时拉取依赖, 按默认会获取最新兼容版本, 若子依赖向后不兼容变动出现在你们部署间隙, 会在线上报或本地皆正常。典型踩坑案例是有版本改变模块路径, 促使新版若缺少特定旧版时候加载则面临失败情况。解方清晰无比: .txt 应当锁定于次版本号, 就如同 numpy==1.24.2 那般, 并且借助 pip 去生成完整的依赖图, 以此防止隐式依赖出现漂移状况。针对已然存有冲突的场景, 于镜像容器之中运用 pip --no-cache-dir -r .txt 对构建过程予以重现操作, 一般而言能够迅速确定究竟是哪个包被无意之中进行了升级。
- 代码调试技巧
直接用函数计算的内置Shell做"现场勘探", 这比盲目猜测更高效。部署完成后, 在控制台执行ls /opt/, 如此便能够一键确认层是否挂载到位。接着跑 -c" ; print(.)", 这样就可以立刻看到模块的实际加载路径。不少开发者的第一反应是反复通过日志排查, 然而实际上所提供的交互式终端能把诊断时间从数分钟压缩到几十秒。再者呢, 还存在一个值得予以留意的细节, 那就是, FC的日志在默认状况下仅仅会去捕获标准输出以及标准错误, 然而呢 , 至于处于调用栈深处的那些信息, 通常来讲, 只有借助sys.path打印才能够将其完全呈现出来, 所以说 , 在代码当中临时增添几行路径检查语句, 相较于反复进行重新部署而言, 效率可是要高得多了。