土豆不好吃

我是如何优雅的开发、部署并管理多个Telegram Bot的?

文章目录[显示]
这篇文章在 2020年12月25日15:06:21 更新了哦~

并不优雅

大家都知道,最近我一直痴迷于开发各种并无卵用的Telegram Bot。那么这一过程,就包含了开发、部署和管理这三个过程,本文就简单的说下这段时间的经验之谈吧

开发 Telegram Bot

神说:要有这个bot,于是就有了这个bot

开发bot,最重要的一点就是进行技术选型。“技术选型”看起来很玄乎,其实就是为了实现这个bot,我们要选用什么语言,使用什么库等等。

当然一切都要从需求出发,从我的角度而言,首选语言是Go——因为静态类型,静态编译之后很适合放到Docker Image里,并且只要凭借想象力编程就基本没问题了;如果Go无法达到我的预期,那就只好选Python了;如果连Python也做不好,那这个bot就可以丢掉了。

当然,在最终选定时,需要根据需求进行一些基础的调研,拿TeleTweet为例,基础阶段它的需求有这些:

对于Go/Python与其生态的对比

Go:

Python:

那么对于TeleTweet而言,选择Python就是更明智的选择;对于NCMBot,由于需要使用Client API,因此选用Python+Telethon也是比较优雅的选择;对于Archiver,没有太多特殊的地方,用Go就可以了。

部署Telegram Bot

开发完成之后,bot是总要部署到某台服务器上的。由于我自己有很多bot,因此根据情况不同我把他们划分成了两类:

Legacy Bot

一些历史遗留下来的bot,基本没有继续的开发计划,处于即将被Archive的状态,有些甚至连说明都没有,完全是拿来自用?所以就丢着呗!

Modern Bot

最近一段时间开发的bot,有持续的维护计划,运行稳定,表现良好。

对于第一类bot,我选择让它们留在一台新加坡的机器上,原来是怎么跑的就怎么跑,一点都不动;

对于第二类bot,我把它们全部放到了一台日本的机器上。

对于第二类bot,如何运行它们又成为了一个问题。

好吧,现在这些bot,只要还能说话的,我都给丢到一台英国的大鸡鸡上了。

systemd service

使用Python开发的bot,那么就是老生常谈的virtualenv+systemd,实际操作下来有些繁琐,尤其是配置systemd总是有一些蜜汁情况,比如说环境变量啦,比如说用户啦;使用Go开发的bot,那么也就不外乎是clone下来源代码,然后go build . ,然后继续配置systemd。这样的话当bot一旦多起来,甚至以后要换服务器,那么就会更麻烦,所有上述操作都要全部重新再来一遍,非常痛苦?

docker + docker-compose

那么如果用docker去分发部署是不是就很方便了?毕竟第二类bot都是有Dockerfile的。

没错的,就是这样——使用Dockerfile构建出docker image,直接docker run就可以了。

更进一步,我可以把这堆bot都丢到docker-compose中,一个docker-compose up -d就可以了。

当然,构建docker image时,是有很多技巧的,这个就以后再说了。

管理、维护bot

使用Makefile

开发工作总是要不断迭代的,那么如果添加了新功能,,我该如何更新服务器上bot呢?

有些bot,我创建了一个Makefile,里面是这么写的:

default:
    @echo "Updating codes..."
    git pull
    @echo "Restarting service..."
    systemctl daemon-reload
    systemctl restart TeleTweet
    @echo "You're good to go."
    systemctl status TeleTweet

很简单,很黄很暴力是不是,只要ssh到服务上,跳到对应的目录,一个make然后就可以关窗放狗咬人走人了。

对于使用Go的bot,也不过是go build . 之类的,比如DailyGakki是这样写的:

default:
    git pull
    @echo "Installing dependencies..."
    @go get -u github.com/go-bindata/go-bindata/...
    @echo "Build static files..."
    make asset
    @echo "Build current platform executable..."
    go build -o DailyGakki .

asset:
    @~/go/bin/go-bindata -o assets.go images/...

反正也是本机使用,没必要用CGO_ENABLED=0以及额外配置ldflags

如果想要查看Bot的运行状态呢?那么只能systemctl status daily-gakki这样啦!

使用docker+docker-compose

如果使用docker的话,那么一切问题就简单了。push完代码之后,等待docker hub build成功之后,ssh到服务器上:

docker pull xxx
docker restart container_name

使用docker-compose也就不过pull了之后

docker-compose up -d service_name

查看状态?

docker-compose ps

或者

docker stats

总结

由此可见,在整个bot瞎搞的过程中,使用docker来进行分发部署管理还是非常方便的。当数量多起来,要比传统的systemd、supervisor之类的方便得多。

当然docker也有缺点,比如磁盘空间比较宝贵的盆友们,有些时候docker image就可能没那么理想,毕竟有些image只能包含rootfs。提到这点,如果是Python开发的bot,做一个通用的image,包含了这些bot所有需要使用的library也不是不可以的。

另外一个难点,docker容易新手劝退,比如说volumes有时比较有趣,一个不小心就很容易写错,然后就gg啦😂

不过,如果能够用Go开发,那么docker image甚至可以使用multi-stage build的手段。像下面这样:

一眼就能看出来哪些是用Go写的了吧!非常exciting。

更进一步,我甚至准备了一个Repository,专门用来存放这些bot的docker-compose.yml

哪怕哪天换机器了,我也只需要把这个目录拷贝走,然后一个docker-compose up -d就可以继续装死了。


好的,以上就是我要说的全部内容,有关于我究竟开发了哪些bot,可以看这篇文章《有趣的 Telegram Bot》


文章版权归原作者所有丨本站默认采用CC-BY-NC-SA 4.0协议进行授权|
转载必须包含本声明,并以超链接形式注明原作者和本文原始地址:
https://dmesg.app/dev-deploy-bot.html
退出移动版