Azure VM上Jenkins流水线运行Flask应用连接超时问题求助

核心问题定位 #

• 虚拟环境配置失效：Jenkins中每一个sh步骤都会启动独立的shell会话，单步执行的. venv/bin/activate仅在当前会话生效，后续的pip安装、Python运行步骤实际调用的是系统全局Python环境，容易出现依赖缺失、版本不匹配问题。
• 服务启动逻辑错误：直接在sh步骤前台运行Flask进程会持续占用构建会话，Jenkins会一直等待进程退出才会推进构建流程，直接表现就是控制台输出调试器信息后流水线挂起；且Jenkins默认会在构建结束后杀掉所有关联子进程，哪怕前台跑通，构建结束后服务也会被强制终止。
• 服务监听地址限制：Flask开发服务器默认仅绑定127.0.0.1回环地址，只接受VM本机的访问请求，外部流量根本无法到达服务进程，这是出现连接超时的核心原因。
• 缺少进程托管机制：直接通过流水线前台启动的服务没有后台守护逻辑，会话断开、Jenkins重启都会导致服务直接停止。

分步修复操作 #

1. 修正流水线执行逻辑
   将同一阶段需要依赖虚拟环境的命令合并到同一个sh代码块中执行，避免跨步骤会话隔离导致的环境失效；启动Flask时显式指定监听地址为0.0.0.0，关闭debug模式避免调试端口暴露。
2. 改为后台托管运行服务
   不要在Jenkins构建步骤中前台运行服务。测试环境临时验证可使用nohup将进程放到后台运行，日志输出到固定文件方便排查；生产环境建议编写systemd服务配置做进程守护，流水线仅负责代码拉取、依赖安装、服务重启动作，从根源解决进程阻塞、异常退出问题。
3. 逐层验证连通性
   • 服务启动后先在VM本机执行curl http://127.0.0.1:5000，确认服务本身能正常响应
   • 再在VM本机执行curl http://<VM内网IP>:5000，确认服务不是仅绑定回环地址
   • 检查VM本地防火墙（ufw/iptables）是否放通5000端口，再核对Azure入站端口规则是否同时关联到对应VM网卡、所在子网，规则优先级不要高于同端口的拒绝规则，源地址按需配置为公网访问段或指定IP段。

最小可用测试流水线示例 #

pipeline{
  agent any
  stages{
    stage('setup'){
      steps{
        sh """
          sudo apt install python3-venv -y
          python3 -m venv venv
          . venv/bin/activate
          pip3 install -r requirements.txt
        """
      }
    }
    stage('start service'){
      steps{
        sh """
          . venv/bin/activate
          # 清理之前残留的Flask进程，命令执行失败不中断流水线
          pkill -f "python3 hello.py" || true
          # 后台启动服务，绑定所有网卡地址，关闭debug模式，日志输出到固定文件
          nohup python3 hello.py > flask_runtime.log 2>&1 &
        """
      }
    }
  }
}

如果你的hello.py中是通过app.run()硬编码启动参数，需要手动将代码内的host配置改为0.0.0.0，debug参数设为False，确保服务监听所有网卡地址。

生产环境优化建议 #

不要直接使用Flask自带的开发服务器对外提供服务，可搭配gunicorn作为WSGI运行服务，用systemd配置进程守护，前置增加nginx做反向代理和静态资源处理，流水线中仅需执行代码拉取、依赖安装、systemctl restart 你的服务名操作即可，不会出现进程阻塞、会话退出服务停止的问题。

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