NOTES

1.对于使用node_exporter+prometheus+grafana的检测流程，由于我的大部分项目都是被docker容器化了的，包括nginx网络，所以必须要在一个公共的容器网络中联系，这样才能让prometheus接收到数据，必须要在同一网络下！ 2.往往搭建虚拟内网进行对话，是使用tailscale，但是tailscale有一个问题就是，他会强制修改环境中的dns,他会污染dns导致无法正常curl和ping外界网页，所以下载好tailscale后，必须要检查dns,以及修改成原来的dns地址 3.以前不知道有类似于uv这样的开发包管理，以后必须使用uv来建立项目，防止出现容器内缺少需要的库或者是包

首先就是这个更新，需要记住服务器中的挂载位置，记不得了可以看Dockerfile或者docker-compose.yml，想要更新就得修改挂载的目录内容 其次就是这个ci/cd问题，特别在github私人仓库中的actions的指令布置当中，需要彻底的重启整个服务，不然的话由于镜像的版本都是latest，会导致更新内容无法上线，服务依旧保持旧版本 最后就是注释很重要，不然就得重新开始看代码的逻辑，最好有一个readme

对于本次的重构fastapi中遇到的问题如下： 1.由于我使用了github action作为ci/cd的工具人角色，但是我对于workflows的构建存在一些小问题，导致初步的更新镜像源无法成功，所以说写好一个工作流很重要 2.端口占用问题，虽然由于使用了docker,并且独立封装了nginx服务，不会担心端口冲突，但是重要的是flask和fastapi默认的端口不一样，必须要修改Dockerfile和docker-compose.yml的配置信息 3.在重构后端时，必须要清楚旧的框架和新框架之间的区别，再进行细节上的修改，以及前后端的传值区别

netstat -tulpn | grep PORT 可以通过这个看到他的pid或者是ppid 使用kill -9/12 来清除端口的占用

第一次测试，这是用于测试是否可以通过在宿主机上改变内容，实现间接修改容器内容作用的文本 第二次测试，完全在容器内的服务，是否能够修改成功 第三次测试，测试workflows的工作流问题是否得到修复 第四次测试，测试workflows的工作流问题是否得到修复 第五次测试，测试workflows的工作流问题是否得到修复

由于nginx的默认地址会影响到用户项目的打包，所以需要建立软连接 这串命令就是由此而生 这里面的simple_status.html该文件需要改名字，但nginx默认的地址会在html目录下 ln -sf /新路径/文件名 /旧路径/文件名