自建环境下Git提交触发ASP.NET网站自动部署至Linux VPS方案咨询

Hey there! Let's ditch that FTP + CronJob setup—it's definitely clunky and not the most reliable approach. Since you already have TeamCity handling builds whenever code hits Git, we can extend it directly to handle deployment and Docker restarts smoothly, no workarounds needed. Here are a few solid, self-hosted options tailored exactly to your setup:

方案1：TeamCity直接通过SSH执行部署命令（最直接、改动最小） #

This is the simplest upgrade—leverage TeamCity's built-in SSH capabilities to run deployment commands on your VPS immediately after a successful build, cutting out FTP and cron entirely.

步骤： #

• 在你的TeamCity项目中添加一个新的构建步骤，选择「SSH Exec」类型。
• 配置SSH连接信息：填写VPS的IP、用户名，推荐用SSH密钥认证（比密码安全得多）。
• 在「Commands」字段中粘贴部署脚本，根据你的Docker配置调整：

  # 拉取最新构建的镜像（如果TeamCity中已完成镜像构建）
  docker pull your-selfhosted-registry/your-web-app:latest
  
  # 停止并移除旧的staging容器（如果容器不存在则忽略错误）
  docker stop staging-web-app || true
  docker rm staging-web-app || true
  
  # 启动新容器，替换成你的端口、挂载等配置
  docker run -d --name staging-web-app -p 80:80 your-selfhosted-registry/your-web-app:latest
  

  如果你用Docker Compose，脚本可以更简洁：

  cd /path/to/your/staging-compose-files
  docker-compose pull
  docker-compose up -d staging-web-app
  

• 确保VPS上的SSH用户拥有Docker操作权限：执行sudo usermod -aG docker your-ssh-user，然后重新登录生效。

为什么这个方案比FTP+Cron好： #

• 实时部署：构建完成立刻执行部署，不用等Cron定时检测，没有延迟。
• 全程可追溯：TeamCity会记录所有SSH命令的输出，在构建面板就能排查问题。
• 更安全：不需要开放FTP端口（常见攻击入口），SSH密钥认证比FTP凭证可靠得多。

方案2：自建镜像仓库 + Webhook触发部署（适合权限管控严格的场景） #

如果不想让TeamCity直接拥有VPS的SSH权限（为了更严格的权限边界），这个解耦方案很合适：TeamCity将构建好的镜像推送到自建仓库，VPS监听Webhook触发部署。

步骤： #

1. 搭建自建Docker镜像仓库（轻量，用容器运行即可）：

   docker run -d -p 5000:5000 --restart=always --name registry registry:2
   

   可以把仓库部署在VPS或你的其他内网服务器上。

2. 在TeamCity中添加镜像推送步骤：
   构建完成后，给镜像打标签并推送到自建仓库：

   docker tag your-web-app:%build.number% your-registry-ip:5000/your-web-app:latest
   docker push your-registry-ip:5000/your-web-app:latest
   

3. 在VPS上部署Webhook监听服务：
   用开源工具webhook来监听TeamCity的构建完成信号：

   • 安装（Debian/Ubuntu）：sudo apt install webhook
   • 创建hooks.json配置文件，定义部署触发规则：

     [
       {
         "id": "deploy-staging",
         "execute-command": "/opt/deploy-staging.sh",
         "command-working-directory": "/opt",
         "trigger-rule": {
           "match": {
             "type": "value",
             "value": "your-super-secret-token",
             "parameter": "headers.X-Webhook-Token"
           }
         }
       }
     ]
     

   • 编写deploy-staging.sh脚本（记得加执行权限chmod +x）：

     #!/bin/bash
     docker pull your-registry-ip:5000/your-web-app:latest
     docker-compose up -d staging-web-app
     

   • 启动Webhook服务：webhook -hooks hooks.json -port 9000

4. 配置TeamCity发送Webhook通知：
   进入项目的「Notifications」> 添加通知 > 选择「Webhook」。填写VPS的Webhook地址（比如http://your-vps-ip:9000/hooks/deploy-staging），添加自定义头部X-Webhook-Token并填入你的密钥，触发条件选择「构建成功时」。

这个方案的优势： #

• 系统解耦：TeamCity只负责构建和推送镜像，不直接操作VPS，权限划分更清晰。
• 扩展性强：后续要加生产环境等其他部署目标，只需要新增对应的Webhook和脚本即可。

方案3：Ansible + TeamCity（适合复杂部署场景） #

如果你的部署涉及额外操作——比如更新配置文件、执行数据库迁移、同步静态资源——Ansible可以帮你把所有任务编排成可重复、版本可控的剧本。

步骤： #

• 在TeamCity服务器上安装Ansible。
• 编写Ansible剧本（比如deploy-staging.yml），定义所有部署步骤：

  - name: 部署Web应用到Staging环境
    hosts: staging-vps
    tasks:
      - name: 拉取最新Docker镜像
        docker_image:
          name: your-registry-ip:5000/your-web-app:latest
          source: pull
  
      - name: 用Docker Compose重启Staging容器
        community.docker.docker_compose:
          project_src: /path/to/staging-compose
          state: present
          services: staging-web-app
  

• 在TeamCity中添加「命令行」构建步骤，执行剧本：

  ansible-playbook -i your-vps-ip, deploy-staging.yml
  

• 确保TeamCity服务器可以通过SSH密钥访问VPS，且用户拥有必要的操作权限。

复杂场景下的优势： #

• 部署标准化：所有步骤都记录在剧本中，没有手动操作的「黑箱」。
• 维护简单：更新一次剧本，就能把变更应用到所有部署流程中。

最终建议 #

先从方案1入手——它搭建最快，需要的新基础设施最少，能直接替换你原来的FTP+Cron工作流，而且可靠、可追溯。如果后续需要更严格的权限管控，再切换到方案2；如果部署逻辑复杂，方案3是最佳选择。

内容的提问来源于stack exchange，提问作者uxhdvdbkavsnshhhfjj27gdn