在 Centos7 上部署 ASP.NET 8.0 + YOLOv11 的踩坑实录

本文将详细记录我在CentOS 7上部署ASP.NET 8.0结合YOLOv11目标检测项目过程中遇到的问题及解决方案，旨在为有雷同需求的开发者提供参考。
  1. 配景

随着人工智能技术的迅猛发展，目标检测成为了浩繁应用场景中的焦点技术之一。YOLO（You Only Look Once）系列作为实时目标检测领域的代表，已经发展到了YOLOv11版本。同时，.NET平台也在不断迭代升级，最新版本已发布至.NET 9。然而，实际项目中大概会遇到各种环境限制和兼容性问题，特别是在老旧系统如CentOS 7上举行部署时。本文将详细记录我在CentOS 7上部署ASP.NET 8.0结合YOLOv11目标检测项目过程中遇到的问题及解决方案，旨在为有雷同需求的开发者提供参考。
2. 项目配景

项目标需求非常简单，需要一个目标检测的 Web 服务，实现发送照片到服务器，服务器返回照片中的目标位置信息。这里我们接纳 ASP.NET 8.0 作为 Web 服务的后端框架，YOLOv11 作为目标检测的算法，利用了YoloSharp 库来实现目标检测的功能。
整体开发过程还是非常顺利的，由于接纳了 .NET ，所以可以非常方便的在 Windows 开发后发布各个平台的版本，并可以选择发布独立的不依赖.NET框架的版本。但是在 CentOS 7 上部署时，由于系统环境的限制，导致了一系列问题。下面将详细记录这些问题及解决方案。

固然，最简单省事的部署方式还是容器化，项目也提供了 Docker 镜像包，但是目标机器 Docker 环境存在一些未知问题，加之无法联网，长途支持操作也不畅。固然后面修好了，这里就不再睁开介绍了。
3. 部署过程

请留意，运维操作无小事。建议先在假造机上举行操作，以避免误操作导致不可挽回的后果。同时，在实际执行时，请务必准备好备份，以防操作失误。
首先勘查系统信息：

1. [root@CentOS-7 ai]# uname -a
2. Linux CentOS-7 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
3. [root@CentOS-7 ai]# cat /etc/redhat-release
4. CentOS Linux release 7.9.2009 (Core)

复制代码

3.1 部署测试与初次碰壁

首先，我们按照通例流程，利用.NET 8发布一个针对Linux x64的发布包，然后将其拷贝到CentOS 7服务器上。添加执行权限并运行，结果发现步伐无法正常启动，出现了依赖库报错。

1. [root@CentOS-7 ai]# ./YoloApp
2. ./YoloApp: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./YoloApp)
3. ./YoloApp: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./YoloApp)

复制代码

这是由于 CentOS 7 自带的 GLIBC 版本较低，无法满意.NET 8所需的 GLIBCXX_3.4.21 版本。为相识决这个问题，我们需要升级 GLIBCXX 库。通过下令 strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX 可以查看当前系统的 GLIBCXX 版本。CentOS 7默认GCC 4.8的libstdc++.so.6仅支持到GLIBCXX_3.4.19。

1. [root@CentOS-7 ai]# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
2. GLIBCXX_3.4
3. GLIBCXX_3.4.1
4. GLIBCXX_3.4.2
5. GLIBCXX_3.4.3
6. GLIBCXX_3.4.4
7. GLIBCXX_3.4.5
8. GLIBCXX_3.4.6
9. GLIBCXX_3.4.7
10. GLIBCXX_3.4.8
11. GLIBCXX_3.4.9
12. GLIBCXX_3.4.10
13. GLIBCXX_3.4.11
14. GLIBCXX_3.4.12
15. GLIBCXX_3.4.13
16. GLIBCXX_3.4.14
17. GLIBCXX_3.4.15
18. GLIBCXX_3.4.16
19. GLIBCXX_3.4.17
20. GLIBCXX_3.4.18
21. GLIBCXX_3.4.19
22. GLIBCXX_DEBUG_MESSAGE_LENGTH

复制代码

还好，这个问题比较大众，网上有很多解决方案。相比较而言，重新编译或是升级依赖库都是比较贫苦的，重新编译操作复杂且风险较高，升级依赖后由于源包地点由于已经不被支持无法访问，需要更改软件包地点。相较而言直接下载一个新的 libstdc++.so.6 文件，然后替换系统自带的文件就方便很多了。
这里我找到了一个 GCC 6.0.26 版本的 libstdc++.so.6 文件，下载并解压后，将 libstdc++.so.6.0.26 文件拷贝到 /usr/lib64 目录下，然后删除原有的 libstdc++.so.6 文件，重新建立软链接即可。最后，再次查看 GLIBCXX 版本，确认是否升级成功。

1. wget http://www.vuln.cn/wp-content/uploads/2019/08/libstdc.so_.6.0.26.zip
2. unzip libstdc.so_.6.0.26.zip
3. cp libstdc++.so.6.0.26 /usr/lib64
4. cd /usr/lib64
5. rm libstdc++.so.6
6. ln -s libstdc++.so.6.0.26 libstdc++.so.6
7. strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

复制代码

3.2 新的拦路虎：ICU缺失错误

在解决了 GLIBCXX 问题后，我们再次运行步伐，发现又出现了新的错误。

1. [root@CentOS-7 ai]# ./YoloApp
2. Process terminated. Couldn't find a valid ICU package installed on the system. Please install libicu (or icu-libs) using your package manager and try again. Alternatively you can set the configuration flag System.Globalization.Invariant to tase see https://aka.ms/dotnet-missing-libicu for more information.
3.    at System.Environment.FailFast(System.String)
4.    at System.Globalization.GlobalizationMode+Settings..cctor()
5.    ...

复制代码

这是由于.NET Core在Linux上利用了ICU库来处置处罚国际化问题，而CentOS 7默认是没有安装ICU库的。解决这个问题也比较简单，只需要安装 libicu 库即可。

1. yum install libicu

复制代码

对于离线环境，可以直接下载 libicu 的安装包，然后上传到服务器上举行安装。安装包的话，可以安装后在 yum 的 cache 目录查找或是直接利用工具 yumdownloader 下载都是可以的。
3.3 终极Boss：GLIBC_2.27的降维打击

在解决了 ICU 问题后，我们再次运行步伐，此时终于看到了启动日志，但是在实际运行测试中，焦点功能却无法正常工作。

1. [root@CentOS-7 ai]# ./YoloApp
2. Connection id "0HNAB1PQ9LV69", Request id "0HNAB1PQ9LV69:00000001": An unhandled exception was thrown by the application.
3.        System.TypeInitializationException: The type initializer for 'Microsoft.ML.OnnxRuntime.NativeMethods' threw an exception.
4.         ---> System.DllNotFoundException: Unable to load shared library 'onnxruntime' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DE
5.        /root/ai/onnxruntime.so: cannot open shared object file: No such file or directory
6.        /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /root/ai/libonnxruntime.so)
7.        libonnxruntime.so: cannot open shared object file: No such file or directory
8.        /root/ai/onnxruntime: cannot open shared object file: No such file or directory
9.        /root/ai/libonnxruntime: cannot open shared object file: No such file or directory

复制代码

好嘛，这下是绕不开了，OnnxRuntime 解决不了，前面做的一切都白费了。这个问题是由于 CentOS 7 自带的 GLIBC 版本过低，无法满意 OnnxRuntime 所需的 GLIBC_2.27 版本。
网上大多建议升级系统的 GLIBC 版本，但这种操作风险较大，容易导致系统不稳定。我最初在假造机中实行了这种方法，履历了不少波折。编译 GLIBC 需要先升级 gcc 和 make。我最初编译了 gcc 11 版本，并将 make 从 3 升级到 4。然而，由于 gcc 版本过高，需要匹配的 glibc 版本，所以我又降级到 gcc 8 版本。最终在编译 glibc 完成后，make install 过程中出现了未知问题。只好利用前面的方法，直接替换了新的 so 文件，导致 ls、cd 等下令无法利用，系统基本瘫痪。总之，升级 glibc 风险较大，真心不建议实行。
既然解决不了问题，那就解决造成这个问题的根源。onnxruntime.so 出现的问题，编译就太贫苦了，可以实行“时光回溯”大法，直接在 Nuget 找 Microsoft.ML.OnnxRuntime 的旧版本，能不能行，就看直接的测试效果了，经过几个版本的测试，夹逼法则和大版本到小版本依次测试，最终找到了最后一个可以或许正常运行的版本 1.16.3。下载 package 包后利用 7-zip 解压，将 runtimes 目录下的 onnxruntime.so 文件直接拷贝替换，再次运行步伐，终于成功运行了。
固然，这个方法并不是最优解，只是在无法升级系统的情况下，可以或许解决问题的一种方法。用 patchelf工具逼迫修改so依赖库版本也是一种解决方案，有兴趣的可以实行。
4. 最后

老旧系统带来的“技术债”是无法避免的，这一番折腾，一天又过去了。查找资料，试错，等待编译，都是在不断的消耗时间。
尽管在老旧的CentOS 7环境下部署最新的ASP.NET 8.0结合YOLOv11目标检测项目面临诸多挑战，但通过合理的依赖管理和接纳符合的技术本领，问题依然可以迎刃而解。希望本文的分享能为在雷同环境中举行项目部署的开发者提供有价值的参考与帮助。希望这篇文章不会被直接用到（旧的不去新的不来，少些折腾吧），而是作为一个解题思路的参考，帮助大家少走一些弯路。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。