1.SpinalHDL(十一) 最后一英里：企业内网Scala环境搭建(nexus私服)
2.Docker源码安装附内网镜像安装演示
3.onnxruntime源码学习-编译与调试 (公网&内网)

SpinalHDL(十一) 最后一英里：企业内网Scala环境搭建(nexus私服)

       在企业内网环境中搭建Scala环境，公司公司尤其是内网内网当开发团队面临网络隔离时，如何顺利部署Scala环境成为了一个挑战。源码本文将介绍在不联网的公司公司情况下部署Scala环境的三种方法，并通过实际操作和团队支持，内网内网成功在内网完成SpinalHDL的源码dnf官服登录器源码部署。同时，公司公司内网部署maven私服还能支持公司内部开发库的内网内网发布与使用，为团队提供便捷的源码内部资源管理。

       方法选择：

       在部署Scala环境时，公司公司有三种主要策略：单跳部署、内网内网两跳部署以及内网部署maven私服。源码单跳部署通过内网设置nexus私服代理连接互联网Maven仓库，公司公司优点是内网内网深海狂飙源码操作相对简单，但存在数据风险。源码两跳部署则在内网设置nexus代理服务器，再通过隔离黄区代理打断内网和外网的直接通路，更符合传统IC公司的信息隔离要求，但复杂度增加。内网部署maven私服为最彻底的方法，支持内部开发库的发布与使用，确保了数据安全。

       部署流程：

       实现SpinalHDL在内网部署的步骤包括：更新build.sbt添加依赖，使用sbt命令编译缓存jar包到私服，更新Classifiers缓存源码和文档jar包。隔离黄区到内网红区的同步可以通过自动化或手动copy解压完成。为了确保部署顺利，linx源码分析需要根据公司IT团队的指导搭建nexus私服，并配置代理，设置合适的group，以确保缓存信息的可见性与安全性。

       内网操作与配置：

       部署完成后，需要对内网进行配置，如在~/.sbt/repositories中指向内网私服，并在IDEA中设置正确的依赖和JDK。使用sbt命令运行编译操作，确保环境配置正确。使用IDEA打开工程，安装Scala插件并配置好依赖，通过右上角的ws协议源码sbt栏刷新按钮检查是否成功导入。

       普通开发者配置：

       普通开发者需要配置~/.sbt/repositories指向内网私服，并在工程的build.sbt中设置正确的依赖。至少在隔离黄区sbt编译时进行缓存下载。

       版本发布：

       对于内部使用的版本发布，可以采用发布到本地、公共路径或maven私服的方式。本地发布适用于个人使用，公共路径发布则需要修改build.sbt并指定版本号，而maven私服发布则需更新本地maven私服的地址与密钥。

       常见问题与解决方案：

       在部署过程中，可能出现SSL安全报错、内网source.jar包找不到等问题。解决SSL安全报错需要在配置中允许不安全协议。姿态unity源码解决source.jar问题，可以尝试取消下载或通过两台机器对比确定问题所在。使用nexus私服的IP地址和端口号搜索包的存在性，以辅助问题排查。

Docker源码安装附内网镜像安装演示

       系统版本要求源码包下载

       官网下载地址（download.docker.com/lin...）

       我这里已docker-...tgz该版本做演示

       1.下载源码包文件到本地

       2.通过远程连接工具（xShell、SecureCRT等将源码包文件上载到服务器自定义目录）

       3.解压文件

       4.配置docker为service服务

       5.添加可执行权限

       注：如遇到启动不成功可通过状态查询、/var/log/messages/运行日志或直接使用dockerd命令查看错误信息，如还解决不了建议服务器重启一下在运行docker启动命令

       6.配置镜像加速

       7.检查安装版本内网下载镜像

       注：使用docker pull拉取镜像的时候需要网络，但是项目部署一般都是在内网。内网访问不了外网，所以需要在外网环境下把需要的镜像拉取下来打包，然后拷贝到内网，载入到内网的docker

       1.在外网机器上拉取mysql镜像，可以看到外网的docker已经拉取了镜像。

       2.将镜像打包成tar压缩包

       3.将打包好的mysql镜像包通过远程工具下载到本地

       4.拷贝到内网linux服务器并载入docker

       docker基础命令使用（扩展）下载镜像：(hub.docker.com/search/官网镜像地址)

       docker pull [IMAGE_NAME]:[TAG] #命令格式

       docker pull mysql:8.0 #下载mysql8.0镜像（不指定默认下载最新版本）

       查看当前镜像版本

       docker -v #查看当前安装版本

       docker version #查看版本信息

       docker info #查看系统信息

       docker images #查看当前镜像

       docker search 镜像名 #搜索镜像

       镜像、容器删除

       docker rm 容器ID

       docker rm 容器名字

       docker rmi 镜像ID

       docker rmi 镜像名

       docker rmi -f 镜像ID #强制删除

       创建网络及数据卷

       docker volume create +数据卷名称

       docker volume list #查看当前数据卷信息

       docker network create -d bridge +网络名称

       docker network ls #查看当前网络

       docker inspect containername +id #查看容器的hash值

       启动、关闭容器

       docker stop $(docker ps -a | awk '{ print $1}' | tail -n +2) #关闭所有容器

       docker start $(docker ps -a | awk '{ print $1}' | tail -n +2) #开启所有容器

       杂

       docker inspect 容器ID （使用该命令重点关注容器ip） #查看容器/镜像元数据

       docker exec #在运行的容器中执行命令

       docker exec -it 容器ID /bin/bash #以交互模式开启伪终端

onnxruntime源码学习-编译与调试 (公网&内网)

       在深入学习ONNX Runtime的过程中，我决定从1.版本开始，以对比与理解多卡并行技术。为此，我选择了通过`./tools/ci_build/build.py`脚本进行编译，而不是直接执行`build.sh`，因为后者并不直接提供所需的参数。在`build.py:::parse_arguments()`函数中，我找到了可选择的参数，例如运行硬件（CPU/GPU）、调试模式（Debug/Release）以及是否并行编译。我特别使用了`--skip_submodule_sync`，以避免因与公网不通而手动下载“submodule”，即`./cmake/external`文件夹下的依赖组件。这样可以节省每次编译时检查依赖组件更新的时间，提高编译效率。同时，我使用`which nvcc`命令来确定`cuda_home`和`cudnn_home`的值。

       我的编译环境配置为gcc8.5.0、cuda.7和cmake3..1，其中cmake版本需要不低于3.，gcc版本则至少为7.0，否则编译过程中会出现错误。在编译环境的配置中，可以通过设置PATH和LD_LIBRARY_PATH来指定可执行程序和动态库的路径。对于手动下载“submodule”的不便，可以通过先在公网编译cpu版本，然后在编译开始阶段由构建脚本自动下载所有依赖组件并拷贝至所需目录来简化流程。

       编译顺利完成后，生成的so文件并未自动放入bin目录，这可能是由于在安装步骤后bin目录下才会出现相应的文件。接下来，我进入了调试阶段，使用vscode进行调试，最终成功运行了`build/RelWithDebInfo/onnxruntime_shared_lib_test`可执行文件。

       在深入研究ONNX Runtime的编译流程时，我发现了一个更深入的资源，它涵盖了从`build.sh`到`build.py`再到`CmakeList.txt`的编译过程，以及上述流程中涉及的脚本解析。对这个流程感兴趣的读者可以进行更深入的研究。

       在编译过程中，我遇到了一些问题，如下载cudnn并进行安装，以及解决找不到`stdlib.h`的问题。对于找不到`stdlib.h`，我通过查阅相关文章和理解编译过程中搜索路径的逻辑，最终找到了解决方案。如果忽略这个问题，我选择在另一台机器上重新编译以解决问题。

       在使用vscode调试时，我遇到了崩溃问题，这可能是由于vscode、gdb或Debug模式编译出的可执行文件存在潜在问题。通过逐步排除，我最终确定问题可能出在Debug模式编译的可执行文件上。这一系列的探索和解决过程，不仅加深了我对ONNX Runtime的理解，也提高了我的调试和问题解决能力。