每个 Merge Request 自动生成一个在线可访问的预览环境，团队可以直接在浏览器里验收功能，无需本地启动项目。

我们要解决什么问题

前后端全栈项目的 Code Review 有个痛点：光看代码 diff 很难判断功能是否正确。尤其是 UI 变更、API 联调、端到端流程验证，往往需要 Reviewer 本地拉代码、装依赖、启动服务才能验证。这极大地拖慢了 Merge Request 的流转速度。

我们希望做到：创建 MR 的那一刻，就自动生成一个只有这个 MR 代码版本的在线预览环境。Reviewer 打开链接就能看到效果，产品经理也能直接参与验收。

整体架构

GitLab MR ──→ GitLab CI ──→ Mac mini Runner
                                │
                    ┌───────────┼───────────┐
                    │           │           │
              Docker Build  Docker Run  Health Check
                    │           │           │
                    └───────────┼───────────┘
                                │
                     Cloudflare Tunnel API
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                   │
    feature-mr-42.preview.xxx   │   fix-bug-mr-43.preview.xxx
              │                 │                   │
              └─────────────────┼─────────────────┘
                                │
                          用户浏览器访问

核心思路：用一台 Mac mini 作为 GitLab Runner，在上面跑 Docker 容器，再通过 Cloudflare Tunnel 把每个 MR 的容器暴露到公网。

为什么选择这个方案

我们的项目是前后端一体部署（Node.js 服务 + Vite 前端打包到 public/），不是纯静态站点，所以 Vercel Preview 不适用。而每次为 MR 单独开 K8s 资源又太重。Mac mini 方案恰到好处：一台机器就能并行跑十几个预览环境。

逐步实现

1. GitLab CI Pipeline 触发

只在 Merge Request 事件时触发预览部署：

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - when: never

预览环境用 resource_group 来串行化隧道操作（Cloudflare Tunnel 配置是共享资源），但允许不同 MR 并行部署：

deploy_preview_mr:
  resource_group: ai-canvas-preview-tunnel
  interruptible: true
  environment:
    name: review/mr-$CI_MERGE_REQUEST_IID
    url: $DYNAMIC_ENVIRONMENT_URL
    on_stop: stop_preview_mr
    auto_stop_in: 7 days

environment 块是关键——它让 GitLab 在 MR 页面显示一个 "View environment" 按钮，点击直接跳转到预览 URL。auto_stop_in: 7 days 确保过期 MR 不会一直占用资源。

2. 生成唯一的预览域名

每个 MR 需要一个唯一的子域名，格式为 {branch-slug}-mr-{iid}.{domain}：

SOURCE_BRANCH_SLUG="$(
  printf '%s' "${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}" |
    tr '[:upper:]' '[:lower:]' |
    sed -E 's/[^a-z0-9-]+/-/g; s/-+/-/g; s/^-//; s/-$//'
)"

# DNS 标签最长 63 字符，预留 "-mr-{iid}" 的空间
MAX_SOURCE_BRANCH_SLUG_LENGTH=$((63 - 4 - ${#CI_MERGE_REQUEST_IID}))
if [ "${#SOURCE_BRANCH_SLUG}" -gt "${MAX_SOURCE_BRANCH_SLUG_LENGTH}" ]; then
  SOURCE_BRANCH_SLUG="$(printf '%s' "${SOURCE_BRANCH_SLUG}" | cut -c "1-${MAX_SOURCE_BRANCH_SLUG_LENGTH}" | sed -E 's/-$//')"
fi

PREVIEW_HOST="${SOURCE_BRANCH_SLUG}-mr-${CI_MERGE_REQUEST_IID}.${PREVIEW_DOMAIN_ROOT}"

例如分支 feat/video-export 的 MR #42 会得到域名 feat-video-export-mr-42.preview.example.com。

3. Docker 构建与容器管理

在 Mac mini 上直接构建和运行 Docker 容器：

# 构建时注入 MR 标签，方便后续清理
docker build \
  --label ai-canvas.preview=true \
  --label "ai-canvas.preview.mr=${CI_MERGE_REQUEST_IID}" \
  --label "ai-canvas.preview.sha=${CI_COMMIT_SHORT_SHA}" \
  -t "${PREVIEW_IMAGE}" \
  .

# 运行容器，限制资源
docker run -d \
  --name "${PREVIEW_CONTAINER_NAME}" \
  --restart unless-stopped \
  --network "${PREVIEW_DOCKER_NETWORK}" \
  --memory=1g --memory-swap=1g --cpus=0.5 \
  --label ai-canvas.preview=true \
  --label "ai-canvas.preview.mr=${CI_MERGE_REQUEST_IID}" \
  --env-file "${PREVIEW_RUNTIME_ENV_FILE}" \
  -e "REDIS_KEY_PREFIX=preview:mr-${CI_MERGE_REQUEST_IID}:" \
  -e "BETTER_AUTH_URL=https://${PREVIEW_HOST}" \
  "${PREVIEW_IMAGE}"

注意几个设计细节：

• 资源限制：每个容器最多 1GB 内存、0.5 CPU，防止单个预览拖垮宿主机
• Docker Label：用标签标记 MR 编号和 commit SHA，后续精准清理
• Redis Key Prefix：不同 MR 用不同的 key 前缀，共享 Redis 实例不会互相干扰
• 动态环境变量：BETTER_AUTH_URL、CORS_ALLOWED_ORIGINS 等都根据预览域名动态生成

4. 环境变量安全管理

预览环境需要真实的服务端密钥（数据库、Redis、第三方 API 等）。我们把敏感配置存为 GitLab File Variable，在 CI 中通过脚本校验后写入临时文件：

// scripts/gitlab/normalize-preview-env.mjs
// 校验必要的环境变量是否存在、URL 格式是否正确、枚举值是否合法
const requiredKeys = new Set([
  'DATABASE_URL', 'REDIS_URL', 'BETTER_AUTH_SECRET',
  'TOS_ACCESS_KEY_ID', 'FEISHU_APP_ID', ...
])

const missingKeys = [...requiredKeys].filter(key => !env.has(key))
if (missingKeys.length > 0) {
  fail(`Missing required keys: ${missingKeys.join(', ')}.`)
}

// 输出文件权限设为 0600，仅 owner 可读写
writeFileSync(outputPath, ..., { mode: 0o600 })

这样做的好处是：

• 敏感信息不硬编码在 CI 配置里
• 有完整的校验逻辑，缺配置时提前报错而不是运行时才挂
• 共享数据库和 Redis（开发环境实例），不同 MR 通过 key 前缀隔离

5. Cloudflare Tunnel 动态路由

这是整个方案最精巧的部分。我们在 Mac mini 上跑了一个常驻的 cloudflared 容器，它维护着一条到 Cloudflare 的隧道。然后通过 Cloudflare API 动态修改隧道的 ingress 规则，把不同的子域名路由到不同的预览容器：

// scripts/gitlab/preview-tunnel.mjs
async function up() {
  // 获取当前隧道配置
  const current = await getConfiguration()

  // 添加新规则：preview-host → preview-container:3000
  const previewRule = {
    hostname: context.previewHost,
    service: `http://${context.previewContainerName}:3000`,
    originRequest: {
      connectTimeout: 60,
      disableChunkedEncoding: true,
      httpHostHeader: context.previewHost,
    },
  }

  // 替换同域名的旧规则，保留其他 MR 的规则
  config.ingress = [
    ...rules.filter(rule => rule.hostname !== context.previewHost),
    previewRule,
    catchAll,  // 必须以 catch-all 结尾
  ]

  await putConfiguration(config)
}

down 操作则反过来：移除对应域名的 ingress 规则。这样同一个 Cloudflare Tunnel 可以同时服务多个 MR 预览环境，互不干扰。

6. 双重健康检查

部署完成后有两次健康检查，确保用户访问时服务已经完全就绪：

第一轮：容器内部健康检查（Docker 网络内）

# 从另一个容器通过 Docker 网络访问，不经过公网
for i in $(seq 1 60); do
  if docker run --rm --network "${PREVIEW_DOCKER_NETWORK}" curlimages/curl:latest \
    -fsS -H "Host: ${PREVIEW_HOST}" \
    "http://${PREVIEW_CONTAINER_NAME}:3000/api/health" >/dev/null; then
    break
  fi
  sleep 2
done

第二轮：公网健康检查（通过 Cloudflare Tunnel）

# 通过公网 URL 访问，验证端到端链路
for i in $(seq 1 60); do
  if curl -fsS "https://${PREVIEW_HOST}/api/health" >/dev/null; then
    break
  fi
  sleep 2
done

如果第二轮公网检查失败，会自动回滚隧道配置到上一个容器（如果存在的话），或者清理隧道入口，避免指向一个不可用的容器。

7. 自动清理机制

预览环境有完善的清理策略：

# MR 关闭/合并时手动或自动清理
stop_preview_mr:
  environment:
    name: review/mr-$CI_MERGE_REQUEST_IID
    action: stop
  script:
    - node scripts/gitlab/preview-tunnel.mjs down  # 移除隧道路由
    - docker rm -f $(容器列表)                       # 删除容器
    - docker rmi $(镜像列表)                         # 删除镜像

# 手动清理 7 天前的旧镜像
cleanup_preview_images:
  script:
    - docker image prune -a -f --filter label=ai-canvas.preview=true --filter until=168h

此外，每次部署新 commit 时也会自动清理同一个 MR 的旧容器和旧镜像：

# 删除同一 MR 的旧容器
for cid in $(docker ps -aq --filter "label=ai-canvas.preview.mr=${CI_MERGE_REQUEST_IID}"); do
  sha="$(docker inspect -f '{{ index .Config.Labels "ai-canvas.preview.sha" }}' "${cid}")"
  if [ "${sha}" != "${CI_COMMIT_SHORT_SHA}" ]; then
    docker rm -f "${cid}"
  fi
done

8. 容器数量限制

单机资源有限，需要防止预览容器过多：

PREVIEW_MAX_CONTAINERS="${PREVIEW_MAX_CONTAINERS:-10}"
TOTAL_PREVIEW_CONTAINER_COUNT="$(docker ps -q --filter label=ai-canvas.preview=true | wc -l)"

if [ "${TOTAL_PREVIEW_CONTAINER_COUNT}" -ge "${PREVIEW_MAX_CONTAINERS}" ]; then
  # 如果当前 MR 已有预览容器，允许更新
  # 否则拒绝部署，提示先清理旧环境
fi

9. 数据库 Schema 变更检测

因为多个 MR 共享同一个开发数据库，如果某个 MR 修改了数据库 Schema 但没有提前执行迁移，其他 MR 的预览可能会报错。我们在部署时自动检测：

SCHEMA_CHANGED_FILES="$(
  git diff --name-only "${CI_MERGE_REQUEST_DIFF_BASE_SHA}" "${CI_COMMIT_SHA}" |
    grep -E '^(apps/server/drizzle/|apps/server/src/lib/db/schema/)' || true
)"
if [ -n "${SCHEMA_CHANGED_FILES}" ]; then
  echo 'WARNING: This MR changes database schema files.'
  echo 'Apply the matching migration on the shared test DB before validating preview behavior.'
fi

最终效果

开发者的工作流变成这样：

1. 在分支上开发功能，推送到 GitLab
2. 创建 Merge Request
3. GitLab CI 自动在 Mac mini 上构建并部署预览环境
4. MR 页面出现 "View environment" 按钮，点击即可访问预览
5. Reviewer 和产品经理直接在预览环境上验收
6. MR 合并或关闭后，预览环境自动清理

Merge Request #42
├── 💬 Discussion
├── 📝 Code Changes
└── 🌐 View environment → https://feat-video-export-mr-42.preview.example.com

总结

整个方案的核心开销就是一台 Mac mini 和一个 Cloudflare 免费隧道。对于中小团队来说，这是一个性价比极高的 MR 预览环境方案。

如果你的团队也在做全栈项目、也有 Code Review 验收的痛点，不妨试试这个方案。欢迎交流。

2024

• 写了个 electron 项目，被归档了（更换产品形态）。
• 写了个火急火燎的 web 发了几个版本后无声无息归档了。跟产品对接不顺利，可能是要求有点多。被 hr 约谈了。整得有点怀疑自我，开始会焦虑
• 成了一块砖，那里需要去哪里
• 写了些开源，有些用户有关注🥰
• 白嫖社区赠票去了 HDC
• 去杭州参加了 #AdventureX 只会用 AI 提效的我像个傻子🫠不过认识了很多很棒的人
• 启动了业余项目尝试
• 团队整顿，我的要求不再是特立独行的要求。在年末的小尾巴被邀请任职业务线技术负责人，开始新的挑战（适应中

2025

• 跑多几次步，最近动不动就不舒服，发烧
• 学着管理团队
• 看书，以前不爱看书
• 继续做开源
• 做一些（垃圾）内容输出
• 尝试不同的项目

感谢 @akazwz_ ak 哥 和 酱酱（不玩推的大佬） 陪我玩🥰

还有个丢个 bug 过去会帮我看甚至 debug 的朋友 玄山 🌚

Finny 感谢各位网友😁 新年快乐🎉

前言

经常会有一些服务想要部署在局域网里面的电脑上，但是又需要从公网访问服务。我们通常会有几种选择

1. 购买 VPS。买了 VPS 之后，一般是会给你分配一个 IPv4 地址的，通过这个地址，就可以访问部署在这个 VPS 上的服务了。
2. 使用 Serverless 服务或者是 PaaS 服务
3. 部署在手头上已有的设备上，通过网络穿透的方式把 内网 的服务暴露在 公网 上

本文不会讲解什么是内网/公网

本文会简单记录 (cloudflare tunnel)[https://www.cloudflare.com/products/tunnel/] 的基本使用 (cloudflare tunnel 文档)[https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/]

安装

Uni App 项目搭建之 CLI

博客已经很久没有更新了，下面的命令可能已经不再适用

项目搭建

方式一

通过HBuilderX 可视化界面生成 传送门

方式二

通过 vue-cli 命令行 传送门

使用正式版

vue create -p dcloudio/uni-preset-vue my-project

使用alpha版

vue create -p dcloudio/uni-preset-vue#alpha my-alpha-project

对比

总结

尝试解决缺点

• 上面提到的可视化界面创建的项目无法使用自动化部署

思路：初步设想方案是可以在项目中使用命令启动项目

1. 使用你喜欢的包管理器进行初始化

# 初始化 包管理
yarn init # npm init

2. 在 package.json 中添加一些scripts

{
"scripts": {
     "dev:mp-weixin": "cross-env NODE_ENV=development UNI_PLATFORM=mp-weixin vue-cli-service uni-build --watch",
   }
 }

3. 启动脚本

这里只要你启动成功了，那么说明这个方案是可行的，但是研究了一下，在工具创建的项目它依赖的环境都是工具集成的，所以直接运行应该是找不到依赖，实验没有继续下去，有兴趣的朋友可以尝试一下，但是我认为这个应该是不行的 手动滑稽.jpg

• cli创建的项目无法自动打开模拟器

思路：使用模拟器的命令行工具来解决，这里使用shelljs编写脚本

1. 安装依赖

npm install shell fs

2. 在src下创建shell.js

// shell.js 这是一个js文件，使用shelljs来执行shell
const shell = require('shelljs');
const fs = require('fs');
const BLUE_COLOR = "\033[36m"
const RED_COLOR = "\033[31m"
const GREEN_COLOR = "\033[32m"
const VIOLET_COLOR = "\033[35m"
const line = `# ######################################################################`
const RES = "\033[0m"
const args = require('minimist')(process.argv.slice(2)) // 获取命令行脚本执行参数
const darwinCliPath = "/Applications/wechatwebdevtools.app/Contents/MacOS/cli" // macOS系统开发者工具位置
const winCliPath = "xxxx" # windows系统开发者工具位置
let path = {
  devPath: `${process.cwd()}/dist/dev/mp-weixin`, // 获取开发环境下的打包目录
  prodPath: `${process.cwd()}/dist/build/mp-weixin` // 获取生产环境下的打包目录
}
let cliPath = ''
/**
 * 检测系统平台
 */
function checkPlatform() {
  if (process.platform == "Linux" || process.platform == 'darwin') {
    cliPath = darwinCliPath
  } else {
    cliPath = darwinCliPath
  }
}
/**
* 脚本主方法
*/
function main() {
  lineEcho(GREEN_COLOR)
  shell.echo(`${BLUE_COLOR}#                       Uni-app build Script                       #${RES}`)
  lineEcho(GREEN_COLOR)
  const env = args['env']
  checkPlatform()
  build(env)
}
/**
* 打开模拟器
*/
function openCli() {
  shell.exec(`${cliPath} open`)
}
/**
* 开发项目
*/
function openProject(path) {
  openCli()
  shell.exec(`${cliPath} open --project ${path}`)
}
/**
* 进行构建
*/
function build(env) {
  shell.echo(`${BLUE_COLOR}#                       当前构建环境是${env}                        #${RES}`)
  let realPath = path[`${env}Path`]
  switch (env) {
    case 'dev':
      fs.exists(realPath, function (exists) {
        if (exists) {
          shell.echo(`${VIOLET_COLOR}#                       正在开发构建                       #${RES}`);
          openProject(realPath)
          shell.exec('yarn dev:mp-weixin');
        }
        if (!exists) {
          shell.echo(`${VIOLET_COLOR}#                         初次构建                          #${RES}`);
          shell.exec('yarn dev:mp-weixin-no-watch');
          openProject(realPath)
          shell.exec('yarn dev:mp-weixin');
        }
      })
      break;
    case 'prod':
      shell.echo(`${VIOLET_COLOR}#                     正在发布小程序，请稍后                       #${RES}`);
      shell.exec('yarn build:mp-weixin');
      openProject(realPath)
      break;
    case 'upload':
      lineEcho(GREEN_COLOR)

      shell.echo(`${VIOLET_COLOR}#                     正在发布小程序，请稍后                       #${RES}`);
      lineEcho(GREEN_COLOR)
      shell.echo(`${VIOLET_COLOR}#                            正在打包                               #${RES}`);
      lineEcho(GREEN_COLOR)

      shell.exec('yarn build:mp-weixin');
      shell.echo(`${VIOLET_COLOR}#                         打包完成                               #${RES}`);
      lineEcho(GREEN_COLOR)

      upload();
      break
    default:
      lineEcho(RED_COLOR)
      shell.echo(`${RED_COLOR}#                       脚本启动失败，请手动编译                       #${RES}`);
      break;
  }
}

function lineEcho(color) {
  shell.echo(`${color}${line}${RES}`);
}
/**
* 打包直接上传体验版
*/
function upload() {
  lineEcho(GREEN_COLOR)
  shell.echo(`${VIOLET_COLOR}#                       打包发布体验版微信小程序                       #${RES}`);
  lineEcho(GREEN_COLOR)
  try {
    const versionConfig = JSON.parse(fs.readFileSync('./src/version.json', 'utf8'))
    lineEcho(GREEN_COLOR)
    console.log('小程序的版本是', versionConfig.version);
    console.log('本次更新内容', versionConfig.description);
    console.log('author', versionConfig.author);
    lineEcho(GREEN_COLOR)
    const {
      version,
      description
    } = versionConfig
    let realPath = path[`prodPath`]
    lineEcho(GREEN_COLOR)
    shell.echo(`${GREEN_COLOR}#                       打包完成，上传中                       #${RES}`);
    shell.exec(` ${cliPath} upload --project ${realPath} -v ${version} -d ${description}`)
    shell.echo(`${GREEN_COLOR}#                       上传完成                       #${RES}`);
    lineEcho(GREEN_COLOR)
  } catch (err) {
    console.error(err)
  }
}

main()

3. 在 package.json 中添加scripts

{
      "dev:shell": "node ./src/shell.js --env=dev",
    "build:shell": "node ./src/shell.js --env=prod",
    "prod:upload": "node ./src/shell.js --env=upload",
    "build-upload": "node ./src/shell.js --env=upload",
    "dev:mp-weixin-no-watch": "cross-env NODE_ENV=development UNI_PLATFORM=mp-weixin vue-cli-service uni-build",
}

4. 如果你需要避免看到模拟器，然后直接生产上传体验版，添加/src/version.json

{
  "version": "版本号",
  "author": "我是谁",
  "description": "我做了什么"
}

5. enjoy it！

| script | 作用 |

| ------------ | ------------------------------------------------------------ |

| dev:shell | 进行开发构建并使用微信开发工具打开 |

| build:shell | 进行生产构建并使用微信开发工具打开 |

| build-upload | 进行生产构建直接读取/src/version.json文件注入上传信息，上传体验版 |

两种创建的方式各有优缺点，但也是有方案可以解决的。但是我个人来说更加喜欢使用vue-cli来创建项目，使用shell来辅助（微信开发者工具是不是会抽风卡住不懂，使用脚本进行发版效率显著提高）

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://tinsfox.com/posts/default/n8n-gmail-to-telegram-forwarding

# docker-compose.yml
version: "3.7"

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    # ports:
    #   - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=${SUBDOMAIN}.${DOMAIN_NAME}
      - N8N_PORT=5678
      # - N8N_PROTOCOL=https # 因为我在外部处理了 https， 所以把它的注释了
      - NODE_ENV=production
      - WEBHOOK_URL=https://${SUBDOMAIN}.${DOMAIN_NAME}/
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
    volumes:
      - ./n8n_data:/home/node/.n8n # 把 n8n 的数据挂在到当前的目录下的 n8n_data 中

# 你的域名
DOMAIN_NAME=example.com

# 设置访问 n8n 的域名
SUBDOMAIN=n8n

# 上面的例子设置之后访问 n8n 的域名是 https://n8n.example.com

# 设置时区
GENERIC_TIMEZONE=Asia/Shanghai

# The email address to use for the SSL certificate creation
SSL_EMAIL=user@example.com # 不知道干啥的，应该是申请 SSL 的，但是我不需要，就没有改了

  2. 选择发送消息，这里我选的是 text ，具体要什么的话，可以根据自己的需求，慢慢调试

  4. 然后就可以在左边把要发的数据拖到右边的 Text 去（如果要添加更多的字段的话，应该是  Additional Fields， 这里我也还没有研究🤪）

  5. 保存之后回到整个 Workflow 页面，点击底部的测试，就会开始测试整个 Workflow ，顺利的话，你的 tg 就会收到机器人给你发的消息，到这里就成功啦~
  6. 假的！ 还需要在右上角对这个 Workflow 进行启用

看完了？说点什么呢