Contents
前言
之前搭建的umima(参见文章：docker系列 搭建基于umami的网站流量监测系统)版本为1.33.1：
而github官方最新版已经是2.11.3了：
对一个有升级强迫症的人而言，这能忍？？所以开始了升级，不过嘛，折腾了半天，版本没任何变化(后来发现是镜像地址已经失效了)，还发现一段时间后umami忽然收不到数据了(感觉应该是重部部署umami的时候，website-id发生了变化，但是仪表板上又没变)，这就尴尬了。
不过嘛，我想，干脆趁这个机会重新梳理下umami的安装方法吧，毕竟以前搭建umamai的时候，我当时啥也不懂，是完全按照别人的教程一步一步来的，一点都不敢错，现在，经过一段时间的锻炼，我也有了些许提升，再加上现在网上umami的教程感觉都是较长时间之前的，也该来个更新了，所以就有了本文的折腾之旅。
不过还是基于那句老话：”有困难要上，没有困难创造困难也要上”，我这次优先选择了比较崎岖的小路：使用源码方式搭建umami。
搭建umami
使用git用源码方式搭建umami(不推荐，折腾)
前置准备工作
使用PPA安装最新的nodejs：
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt-get install -y nodejs
注1：我写这篇文章的时候，apt install的nodejs最新为18.13，如果直接使用apt安装18.13的版本，后面在安装umami的时候会报错，所以才换成了上面PPA的方式安装：
注2：使用这种方式已经同时安装了npm，不需要使用apt再单独安装了，当然，如果非要使用apt单独安装也不是不行，就是会遇到一堆报错，别问我是怎么知道的。
安装git
apt install git
安装yarn
npm install -g yarn
安装gm2
npm install -g pm2
安装并初始化数据库
使用mariadb(这个慎用，待确认)
github上的说明支持 Postgresql (最小支持版本:v12.14)和MySQL (最小支持版本:v8.0)。以前使用docker-compose方式安装的时候，使用的是Postgresql，不过我一直有点不爽，因为我mariadb用得比较多，也有现成的，既然支持MySQL的话，这次我就优先使用mariadb来做数据库了(事实证明失败了)。
如果没有现成的mariadb数据库，那么依旧推荐使用docker方式部署mariadb(其实这里从强迫症的角度来说也应该用源码方式安装mariadb数据库，不过docker方式部署的数据库从运维上来说的确太方便了，所以这次即便是强迫症病入膏肓的我也只能忍了)：
docker run --name=mariadb -d --restart=always \
-p 3306:3306 \ # 宿主机上映射到容器内部3306的端口，根据自己实际环境设置
-v /docker/mariadb/db:/var/lib/mysql \ # 映射宿主机上需要挂载目到mariadb容器内部的目录
-e MARIADB_ROOT_PASSWORD=yourpassword \# mariadb数据库root密码
mariadb:10.11
注1：使用的时候自行去除#及后面的注释内容
注2：如果更熟悉Postgresql，要用也可以，用哪种都无所谓(后面结果看来，其实有所谓)
初始化数据库的步骤参见文章：奇技淫巧系列 新建空数据库以及给对应用户赋予权限，这里假设我们新建一个名为”umami”的库，并创建用户名及密码均为umami且对umami库有完全权限的账号。
使用Postgresql
docker run格式部署postgresql命令如下：
docker run --name postgres -d --restart=always \
-p 5432:5432 \
-e POSTGRES_USER=umami \
-e POSTGRES_PASSWORD=umami \
-e POSTGRES_DB=umami \
-e PGDATA=/var/lib/postgresql/data/pgdata \
-v /docker/postgres/data:/var/lib/postgresql/data \
postgres:15.4
注：使用postgresql最方便的是，初始化过程使用-e参数就完成了，不过想来mariadb应该也可以吧，以前没太关注过，因为很多库都是后来自己手动初始化的，已经习惯了，以后有空了再研究一下下。
安装umami
选择一个安装目录，我是习惯直接安装在root文件夹中：
cd ~
git clone https://github.com/umami-software/umami.git
cd umami
yarn install
成功：
新建.env文件，填入数据库信息，格式如下：
DATABASE_URL=mysql://umami:umami@localhost:3306/umami #选择mariadb或者mysql
DATABASE_URL=postgresql://umami:umami@localhost:5432/umami #选择postgresql
TRACKER_SCRIPT_NAME=tangwudi #这个很重要，自定义js脚本名字，可以不用加js结尾，我后面解释
注1：localhost:3306表示数据库与umami程序在一台设备上，如果这里数据库在不同的主机上，localhost需要改成所在主机的IP地址。
注2：DATABASE_URL根据自己所选数据库的不同选择不同的数据库链接，二选一哦。
构建umami：
yarn build
注意！！！！如果采用的mysql或者mariadb，我遇到了出现如下报错：
解决方法，打开umami文件夹下的package.json文件(源码方式安装package.json文件就相当于docker-compose安装方式中的docker-compose.yml文件，需要更改默认配置信息比如端口等就在这里修改)：
将上图红框中的第23行内容：
"build-db": "npm-run-all copy-db-files build-db-client",
替换为如下内容：
"build-db": "npm-run-all copy-db-files build-db-client resolve-db",
"resolve-db": "prisma migrate resolve --applied '05_add_visit_id'",
然后重新运行命令
yarn build进行构建就可以了。
构建成功：
更新一下浏览器列表：
npx update-browserslist-db@latest
测试umami能否正常启动：
yarn start
正式使用的话，需要后台启用umami：
pm2 start yarn --name "umami" -- start
开机自动启动pm2以及保存当前运行的umami进程：
pm2 startup
pm2 save
注：使用pm2进程管理器，如果要停止并删除相关进程的，使用如下命令：
pm2 list #查看有哪些pm2进程id
pm2 stop 进程id
pm2 delete 进程id
其实就是用pm2代替了常规service的设置，感觉还蛮好用的。
然后直接使用http://部署机IP:3000的方式进行访问，这里根据选择数据库的不同，有2种结果，至少是我遇到的：
1、mysql或者mariadb
在添加了网站之后，仪表板直接显示错误：
到底是哪里的问题呢：难道是前面在解决yarn build报P3009错误时，其实是参考了使用Vercel构建umami时处理类似问题的办法，这个处理有点水土不服？因为实际上的处理方式影响了数据库的生成，而且我不管是换mysql或者mariadb都是同样的问题，为了验证我这个判断，我才换成postgresql，没想到build的时候没有报错，直接就通过了，而且后面仪表板也没有遇到”出现错误”的报错了。
我又去看了下网上使用源码部署的，升级的时候出现P3005，P3009之类的问题多的是(是由于mysql 5.7的命令和新的8.x的不兼容，需要修改初始化时使用的sql文件中对应的命令)，现在想来，我之前使用的docker-compse方式部署的umami出问题，也是因为不久前手贱尝试了升级操作。。看来升级umami还是要谨慎，特别是使用msql/mariadb的时候，因为涉及到mysql 5.7到新版本8.x的一些命令变动，所以特别容易出问题。
2、postgresql
这种就没问题了：
使用docker方式搭建umami(推荐一般人使用，下次我也用)
创建 docker-compose.yml文件
在对应的目录里创建docker-compose.yml文件，我是在/docker/umami：
mkdir -p /docker/umami/data #data目录是后面postgresql挂载的时候要用，这里提前创建好
cd /docker/umami
vim docker-compose.yml
之前使用的docker-compse方式搭建umami的时候，使用的镜像地址比较旧，貌似已经无法访问了(镜像地址：docker.umami.is/umami-software/umami:postgresql-latest)，这次使用官方最新的，根据github上umami官方提供的yml以及我上篇使用docker-compose搭建umami文章中的yml，我对内容进行了一些修改，以下是目前最新的docker-compose.yml文件内容：
---
version: '3'
services:
umami:
image: ghcr.io/umami-software/umami:postgresql-latest
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://umami:umami@localhost:5432/umami
DATABASE_TYPE: postgresql
APP_SECRET: replace-me-with-a-random-string
TRACKER_SCRIPT_NAME: tangwudi
depends_on:
db:
condition: service_healthy
restart: always
healthcheck:
test: ["CMD-SHELL", "curl http://localhost:3000/api/heartbeat"]
interval: 5s
timeout: 5s
retries: 5
db:
image: postgres:15-alpine
environment:
POSTGRES_DB: umami
POSTGRES_USER: umami
POSTGRES_PASSWORD: umami
volumes:
- ./data:/var/lib/postgresql/data
restart: always
healthcheck:
test: ["CMD-SHELL", "pg_isready -U {POSTGRES_USER} -d{POSTGRES_DB}"]
interval: 5s
timeout: 5s
retries: 5
注：和以前文章中的yml内容相比较，可以看出，已经取消了一个初始化postgresql需要的sql文件(schema.postgresql.sql)，因为已经不需要了，初始化内容已经内置在umami程序中，在github的官方文件夹里其实可以看到postgresql数据库的初始化步骤和内容：
mysql/mariadb类似：
拉取镜像
docker pull ghcr.io/umami-software/umami:postgresql-latest
docker pull postgres:15-alpine
拉起容器
cd /docker/umami
docker-compose up -d
然后和前面使用源码方式部署的步骤一样，直接使用http://部署机IP:3000的方式进行访问。
测试了下，的确是最新版：
注：源码部署的研究我花了2天，虽然主要是因为一开始就选择mariadb作为数据库的原因，但是就算熟练以后不走弯路，部署一次也要十分钟左右，更别说还没考虑不同环境差异可能引发的怪问题，而使用docker-compose的方式搭建，有没有30秒？？所以对于umami而言，一般人搭建还是建议不要折腾源码了。
优化umami配置
详细的初始化配置参见我以前那篇文章，我这里就不重复说了，我只谈几个以前没谈到的优化的关键点。
1、防止被防广告插件拦截
umami默认的js脚本名字是”script.js”或者”umami.js”，这种名字一看就知道是干啥的，非常的不隐蔽。为了防止直接被防广告插件屏蔽，需要伪装一下，换个不容易被发现的马甲，比如，我换成了”tangwudi”～。如果是通过docker-compose的方式安装，那么就需要在”docker-compose.yml”里添加环境变量：
environment:
TRACKER_SCRIPT_NAME: tangwudi
使用源码方式安装，就需要在.env文件里添加
TRACKER_SCRIPT_NAME=tangwudi
注：源码部署方式必须是在运行yarn build之前添加才有用，否则，如果是之后添加，就会出现追踪代码里变成了tangwudi，但是访问起来却找不到网页的错误，还是只有访问”script.js”才有用，逼我又重新构建了一次；同样的，使用docker-compose方式安装，需要是在运行docker compose up -d命令之前。
2、将js脚本(本例中是tangwudi)放在对象存储上
本质上，umami的统计方式是通过浏览器运行一段js脚本，然后将结果传回umami部署的主机上来完成统计工作，所以，理论上脚本放哪里都无所谓，只要浏览器能够读取就行，比如，我可以将js脚本放到cloudflare R2上(如果是国内的服务器，可以放在国内云供应商的COS上，比如腾讯的COS)，并启用了CDN，这个可以尽量减少回源请求，这个是通过修改追踪代码”src”部分实现的：
src="https://r2.tangwudi.com/tangwudi" # 假设r2.tangwudi.com是我r2存储桶的自定义域名
不过，我觉得，如果有cdn，这个直接缓存到cdn上就好了，毕竟就是一段静态内容，也不会频繁的回源，而且，这个选项必须和下一个优化参数”data-host-url”配合使用，感觉又麻烦了很多，因为如果没有”data-host-url”参数，就会直接把src里的地址作为umami接收统计数据服务器地址，少很多折腾。
3、指定实际接收统计数据的服务器地址
data-host-url="https://umamiserver.tangwudi.com" #实际部署umami的服务器访问域名
这个一般是和上一个参数配合使用，看个人选择吧。
4、只限定显示哪个域名的采集信息
data-domains="blog.tangwudi.com"
这个选项其实理论上很有用处，比如我的wordpress，在家里可以直接用内网地址访问，或者在外面直接用tailscale地址访问，我以前没加这个选项的时候，这些地址的访问都会显示在监控页面上，还引发了一次对我的SSRF(服务器端请求伪造)的攻击，就是因为在监控界面上显示了我的wordpress服务器的内网地址192.168.x.x。
注：为啥我说理论上？因为我感觉我被忽悠了，最后生成的分享链接是这样的：
就是在原本的分享链接后加了个”/blog.tangwudi.com”???，关键还可以直接去掉，一样可以访问，去掉后是不是就和原来一样啥地址都看得到了？？
最终我的追踪代码如下图(只用了第一项和第四项优化)：
升级umami
源码部署方式
三步走：
git pull #在umami文件夹下操作
yarn install
yarn build
docker-compose方式
docker compose pull
docker compose up --force-recreate
看起来倒是很简单，不过根据这几天我为了解决使用mariadb库导致的怪问题而逛的英文帖子以及我写这篇文章的导火索，升级umami还是要慎重，特别是版本跨度较大的时候(较小也未必安全就是)，建议优先备份好数据库内容。
总结
至少对于umami而言，源码部署方式的确太折腾了(我后来为了验证是不是环境原因引发的使用mariadb数据库时仪表板的报错问题，还专门搭建了一个全新环境的debian12的lxc，所以现在的umami实际上就是跑在lxc上了，连的docker方式部署的postgresql，懒得再折腾了)，推荐docker-compose方式的部署。
新版的显示比之前好了点，多了一个访问次数的显示：
还多了一个行为类别，不知道是啥，等过了1天看看：
大家可以用后面的链接查看新版umami的实际效果：新版umami演示链接。
无法启动 奇怪了
是以什么方式部署无法启动？报错信息是什么？