✨ 从旧站搬运一批文章
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
---
|
||||
{
|
||||
title: "ChronoCat使用遇到亿点困难 3.28开发小记",
|
||||
description: "作者在Docker中配置ChronoCat QQ框架时遇到困难,包括版本兼容、VNC显示问题及冻号风险。部分API测试成功,基于Satori协议调用方便。后续计划提供JSON格式的API供其他容器使用,示例包含来源、目标和信息内容。环境问题尚未解决。",
|
||||
draft: false,
|
||||
type: "article",
|
||||
created_at: "2024-03-28T09:26:00+08:00",
|
||||
published_at: "2024-03-28T09:34:00+08:00",
|
||||
updated_at: [ "2024-03-28T09:34:00+08:00"],
|
||||
category: 'Uni',
|
||||
tags: [ "QQBot" ],
|
||||
tech_stack: [ "ChronoCat" ],
|
||||
tech_stack_percent: [ 100 ],
|
||||
tech_stack_icon_names: [ "mdi:cat" ],
|
||||
tech_stack_theme_colors: [ "#bc446f" ],
|
||||
}
|
||||
---
|
||||
!!!warning Legacy Article 过时的文章
|
||||
此文章从旧博客迁移而来,编写时技术水平有限,仅供参考
|
||||
!!!
|
||||
|
||||
## ChronoCat 配置小结
|
||||
|
||||
最近一直在弄qq框架 ChronoCat
|
||||
首先这东西一定得弄在Docker里,我没有精力在原系统做一个vnc,然后再装一个QQ,想想就感觉太地狱了。
|
||||
但是Docker好像没有足够新的版本,倒是找到了能用的Compose文件,但是好多Api都搞不通,我怀疑是版本问题。
|
||||
另一方面,有一些消息表明使用早期版本的QQ会导致冻号,虽然我的号还没出问题。
|
||||
问题落在了完成一份新的Dockerfile上。
|
||||
但是我没能成功,目前仍然卡在这一步。根据错误消息,我怀疑是vnc和QQ不对付,vnc可以启动,但是看不到QQ的画面。
|
||||
感觉只要涉及到Linux图形化,最后都会变成一场噩梦。
|
||||
不过也有好消息,从已经成功测试的部分Api来看,调用Api并不困难,基于Satori协议,还是比较方便的。
|
||||
可以假设我将在一段时间后解决上述配环境的问题,现在考虑一下后端框架。
|
||||
首先,我需要提供一批Api,供其他Container使用。
|
||||
以一个报错信息为例子
|
||||
需要以下信息:(来自谁,发送到谁(人/组/多组),信息内容(string))
|
||||
```json
|
||||
{
|
||||
"from": "string?",
|
||||
"to": ["people","groupA","groupB"],
|
||||
"info": "string?"
|
||||
}
|
||||
```
|
||||
还有很多要考虑的事 要下课了
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
{
|
||||
title: "补档 Uni运维小记",
|
||||
description: "作者在Docker中配置ChronoCat QQ框架时遇到困难,包括版本兼容、VNC显示问题及冻号风险。部分API测试成功,基于Satori协议调用方便。后续计划提供JSON格式的API供其他容器使用,示例包含来源、目标和信息内容。环境问题尚未解决。",
|
||||
draft: false,
|
||||
type: "article",
|
||||
created_at: "2024-03-29T10:30:00+08:00",
|
||||
published_at: "2024-03-29T11:18:00+08:00",
|
||||
updated_at: [ "2024-03-29T11:18:00+08:00"],
|
||||
category: 'Uni',
|
||||
tags: [ "运维" ],
|
||||
tech_stack: [ "Docker", "Nginx", "MariaDB", "Azure Devops" ],
|
||||
tech_stack_percent: [ 40,30,20,50 ],
|
||||
tech_stack_icon_names: [ "mdi:docker","simple-icons:nginx", "simple-icons:mariadb", "simple-icons:azuredevops" ],
|
||||
tech_stack_theme_colors: [ "#1c90ed","#109748","#c0765a","#2b99e2" ],
|
||||
}
|
||||
---
|
||||
!!!warning Legacy Article 过时的文章
|
||||
此文章从旧博客迁移而来,编写时技术水平有限,仅供参考
|
||||
!!!
|
||||
|
||||
#运维
|
||||
运维的主要任务有:部署代码,配置和维护服务器上的nginx,Docker和mariaDB服务。~~还有背锅~~
|
||||
运维技术路线:
|
||||
|
||||
##Docker
|
||||
学习[Docker](https://docker-practice.github.io/zh-cn/)会是你的第一课。几乎全部的后端代码都运行在Docker中,Docker提供了服务管理,自动化部署和端口映射功能你需要学习的有关知识有:
|
||||
Image、Container的概念及相关操作
|
||||
从Image构建Container,端口映射相关配置
|
||||
导出Container Log, 进入运行的Container进行检查
|
||||
从 DOCKERFILE 文件构建Container
|
||||
从 DockerCompose 构建Container
|
||||
|
||||
##nginx
|
||||
nginx维护的关键是:看懂学长留下的配置文件。然后在其基础上堆上自己的文件,同时保持nginx不崩
|
||||
目前笔者nginx技术有限。不过多赘述
|
||||
|
||||
##mariaDB
|
||||
mariaDB和Mysql语法略有区别。但大部分都是一致的。作为运维,你需要为后端代码建立所需的数据库。建立数据库,配置用户并不困难。去bing或者谷歌花点时间就能做好。
|
||||
但是关键是,把带有帐号,密码,地址的字符串传递给后端代码。我将在后续提到。
|
||||
|
||||
##Azure
|
||||
你有很大概率在Azure中看到这份指导文件,但你大概率还不会使用Azure进行代码管理和部署配置。
|
||||
这里不会讲Commit PR 或是 Branch相关的概念。如果你不了解,你需要去学习Git相关知识。在很大程度上,Azure和Github类似,只是这里不会从搜索引擎中搜到。接下来,我会假设你了解相关概念。
|
||||
这里主要讲Azure Pipelines的配置
|
||||
在左侧,你能找到Pipelines。你可以右键,在新窗口中打开。这样就可以不退出本指导。
|
||||
你可以看到很多Pipeline在其中。排在前面的可能是IWutApi,或是其他什么东西。它们在进行**自动化部署**的工作。每个Pipeline都在持续监测某个仓库的的某个分支,如果发生改变,它会把代码传到制定的服务器,构建,运行。这样,后端开发者就能在第一时间对最新的代码进行测试,并且把最新的代码上线,供用户使用。
|
||||
这一近乎神奇的操作的关键,是仓库中的一个yml文件,它通常被命名为 ***-pipeline.yml
|
||||
关于yml文件的配置,我的建议是:抄
|
||||
```yml
|
||||
trigger:
|
||||
- main
|
||||
|
||||
resources:
|
||||
- repo: self
|
||||
|
||||
variables:
|
||||
projectName: iwut-api-prod
|
||||
|
||||
stages:
|
||||
- stage: Deploy
|
||||
displayName: 部署到服务器
|
||||
jobs:
|
||||
- deployment: VMDeploy
|
||||
displayName: 部署到Uni服务器
|
||||
environment:
|
||||
name: JP-tencent
|
||||
resourceType: VirtualMachine
|
||||
strategy:
|
||||
runOnce:
|
||||
deploy:
|
||||
steps:
|
||||
- checkout: self
|
||||
fetchDepth: 1
|
||||
displayName: 切换到目标仓库分支
|
||||
- bash: |-
|
||||
docker compose -p $(projectName) -f docker-compose.yml up --build -d
|
||||
env:
|
||||
DeployPort: 5003
|
||||
ConnectionStrings__App: $(ConnectionStrings__App)
|
||||
displayName: 运行 docker compose 命令
|
||||
```
|
||||
这是目前正在运行的一份pipeline文件。我们来简单分析一下,如果要改在其他工程上,需要改什么。
|
||||
trigger:规定正在监测的分支名字是什么
|
||||
projectName:项目名字,改成对应的
|
||||
stages里,第一个可能要改的是environment,你要部署到哪个服务器。在Pipeline-Environments中,可以看到现在可用的服务器。这个大概率会有人告诉你。但以防万一,这里简单叙述目前的情况。
|
||||
如果你要部署的是一个需要Debug,后端还在开发的代码,放在uni-tencent上,并且只部署dev分支。
|
||||
如果你要上线一个供用户使用的新功能,那么JP-tencent是更好的选择,只部署main(或master?)分支
|
||||
下一个要改的是steps中的bash 这是一行从Docker-Compose启动docker container指令,关于Docker Container创建和端口转发,在Docker-Compose文件中。
|
||||
然后是env, DeployPort和ConnectionStrings__App
|
||||
env是环境变量,这里创建了两条环境变量,部署端口和连接字符串。
|
||||
|
||||
这里容我粘贴DockerCompose.yml(也能在仓库找到)文件,插入的讲解一下
|
||||
```yml
|
||||
version: '3.8'
|
||||
|
||||
services:
|
||||
iwut-api: #目标Contaienr 名字
|
||||
image: iwut-api:prod #镜像名字
|
||||
build:
|
||||
context: .
|
||||
dockerfile: IWutApi/Dockerfile #DockerFile文件位置,需要修改
|
||||
args:
|
||||
BuildConfig: Release #发行环境
|
||||
environment:
|
||||
TZ: Asia/Shanghai
|
||||
ASPNETCORE_ENVIRONMENT: Production #发行环境
|
||||
ConnectionStrings__App: ${ConnectionStrings__App:?} #数据库连接串
|
||||
ports:
|
||||
- ${DeployPort}:80 #端口
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
```
|
||||
这个文件中,发行环境可能会改成Debug或Development,这个看后端需求。
|
||||
你可以看到 数据库连接串和端口使用了${something} 的形式,这里就是在读取环境变量。
|
||||
|
||||
回到之前的Pipeline文件,端口没什么说的了,现在聊聊ConnectionStrings_App
|
||||
该环境变量 在构建Pipeline过程中加入,如图。![Screenshot_2024-03-25-15-29-23-111_com.realvnc.viewer.android.jpg][1]
|
||||
右侧添加名字和值,由于该字符串包括密码,所以需要**勾上Keep this value secret**
|
||||
问题出现了,你 ~~,一个刚准备接锅的运维,~~ 怎么知道这个值怎么填,因为过往的Pipeline这里都是****
|
||||
两个办法:
|
||||
如果是新的项目,直接问后端,直接问他怎么填,要个示例。
|
||||
如果是老项目
|
||||
还记得之前Docker要求你学习怎么进入容器内部吗?
|
||||
``` Bash
|
||||
docker exec -it (DockerID) bash
|
||||
echo $ConnectionStrings__App
|
||||
```
|
||||
当然还有第三个办法,反正代码就在这,不如发挥主观能动性,学习后端。
|
||||
祝你好运
|
||||
|
||||
|
||||
[1]: https://typecho.lichx.top/usr/uploads/2024/03/1075500197.jpg
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
{
|
||||
title: "转向Lagrange.Core 解决Sign服务问题",
|
||||
description: "作者放弃ChronoCat转向Lagrange.Core,但在发送消息时遇到阻塞。发现未配置Sign服务器导致登录异常。通过阅读源码,自定义SignProvider并硬编码URL后解决问题,成功实现消息发送。",
|
||||
draft: false,
|
||||
type: "article",
|
||||
created_at: "2024-03-29T09:50:00+08:00",
|
||||
published_at: "2024-03-29T10:19:00+08:00",
|
||||
updated_at: [ "2024-03-29T10:19:00+08:00"],
|
||||
category: 'Uni',
|
||||
tags: [ "QQBot" ],
|
||||
tech_stack: [ "LagrangeCore","C#" ],
|
||||
tech_stack_percent: [ 50, 50 ],
|
||||
tech_stack_icon_names: [ "mynaui:letter-l","mdi:language-csharp" ],
|
||||
tech_stack_theme_colors: [ "#8f71b0","#a179dc" ],
|
||||
}
|
||||
---
|
||||
!!!warning Legacy Article 过时的文章
|
||||
此文章从旧博客迁移而来,编写时技术水平有限,仅供参考
|
||||
!!!
|
||||
|
||||
## 事件记录
|
||||
在群U的劝说下,放弃了ChronoCat,转向了**Lagrange.Core**
|
||||
初步了解后,我发现这东西竟然有Nuget开发包,我直呼还有这好事,直接对着Api文档开写。
|
||||
写到发送单对单信息后,开始测试,发现发不出去,就阻塞了,卡在那了,没报错,没异常。
|
||||
在反复对照,调试了30min后,向Rosemoe求助。
|
||||
他一开始也觉得没问题,突然问我,**你配Sign了吗?**
|
||||
我一下子就不懂了
|
||||
然后他丢给我一个sign的链接 这里就不丢出来了,需要的去telegram找
|
||||
我就愣住了,然后就开始看文档,看ReadMe 我就发现只有一个地方提到了sign的事 Lagrange.OneBot Appsettings.json里面有一个,要求用户填入。
|
||||
然后我就把链接填到Docker Contianer里的Appsettings.json 重启 但是没用
|
||||
更不会了,突然想起来Docker也有log 我决定对比一下我的请求和Docker log 看看有没有什么报错信息。
|
||||
然后我就发现一个奇怪的事,好像我的请求,和log没什么关系?
|
||||
|
||||
而且log里也有用于登录的二维码? ~~这不扫一下~~
|
||||
然后我发现我的电脑qq被顶下去了,我立刻意识到,它成功登录了,而我的Api调用登录是不成功的。
|
||||
这时我才意识到Lagrange.Core 和 Lagrange.OneBot是两个东西,关于Lagrange.Core的sign服务配置,只在ReadMe.md有提到
|
||||
> 暂不提供签名 API,您可能需要在某个地方找到它并在 BotConfig 继承 SignProvider 类的CustomSignProviderBotConfig
|
||||
|
||||
之前ChronoCat使用vnc直接显示qq界面,登了就顶,符合直觉。
|
||||
在调用Lagrange.Core时,如果没有正确配置sign服务器,登录时手机会显示有其他设备登录,但是电脑上不顶号。获取到了BotContext,甚至有uin字段,但是实际是没有登录成功的。
|
||||
这也解释了为什么Online事件没有正常触发。
|
||||
|
||||
#正题 Lagrange.Core sign配置
|
||||
没办法了,只能试着看源代码了
|
||||
在这个过程中,Rosemoe给了我OneBot sign 服务实现的代码,位置是
|
||||
> Lagrange.OneBot.Utility.OneBotSigner
|
||||
|
||||
大致的读了一下代码,关键在于:从AppSettings获取了Sign链接,然后配合其他的变量,发送了一条请求,最后返回了一个byte[]
|
||||
Core下也有类似的代码:
|
||||
> Lagrange.Core.Utility.Sign.LinuxSigner //这里只考虑Linux
|
||||
|
||||
但是该文件中 Url是空的,并且没有函数给它赋值,LinuxSigner继承自SignProvider
|
||||
SignProvider是BotConfig的一个属性 而BotConfig是Create一个Bot时需要的变量。
|
||||
看到这,你可能已经明了了
|
||||
LinuxSigner只有在BotConfig的SignProvider为null时才会被构建,所以需要写一个自己的Signer,然后把里面的url填上。
|
||||
由于LinuxSigner的url是 private const 我不太确定继承能不能使用新的url,我这里直接继承SignProvider为Sign,然后 copy LinuxSigner,修改url,后面可能改成从AppSettings读取。这里先直接硬写了。
|
||||
然后使用新的SignProvider初始化BotConfig,重新测试,没有问题。
|
||||
Reference in New Issue
Block a user