Capistrano3部署Rails5至AWS EC2时资产编译无日志失败排查

遇到这种本地预编译正常但远程部署时资产编译失败、还没有效报错日志的情况确实很棘手，我给你整理几个实用的排查思路，应该能帮你定位问题：

1. 直接查看EC2服务器上的本地日志 #

Capistrano的日志可能没捕获到远程资产编译的详细错误，你可以登录到EC2实例，去项目的日志目录（比如/var/www/your_app/shared/log或者current/log）查看对应环境的日志文件，比如staging.log或者专门的assets_precompile.log，这里面往往会有本地预编译时没触发的错误细节——比如某个asset文件的语法问题、依赖缺失，或者环境变量不足导致的编译失败。

2. 在EC2服务器上手动执行资产编译命令 #

远程环境和本地的差异是这类问题的常见根源，你可以直接在EC2上模拟Capistrano的操作：

• 切换到部署用户（比如su deploy）
• 进入项目的current目录
• 执行命令：RAILS_ENV=staging bundle exec rake assets:precompile

这样能实时看到编译过程的所有输出，不管是报错还是警告，都能直接捕获到。比如远程的Node.js版本和本地不一致、缺少某个系统依赖，或者gem版本差异，都会在这里暴露出来。

3. 单独运行Capistrano的资产编译任务并查看详细输出 #

尝试单独执行资产编译的Capistrano任务，同时开启最详细的日志输出：

bundle exec cap staging deploy:assets:precompile -vvv

-vvv参数会让Capistrano输出所有SSH执行的细节，包括远程命令的标准输出和错误输出，很多时候能找到被默认日志忽略的关键信息。

4. 检查EC2服务器的资源状态 #

资产编译是个耗内存的操作，如果你的EC2实例内存不足，系统可能会直接杀掉编译进程，而且不会留下明显的报错日志。你可以：

• 用free -m查看内存使用情况，看是否有内存耗尽的迹象
• 检查系统日志（Ubuntu看/var/log/syslog，CentOS看/var/log/messages），搜索OOM killer相关的记录，确认是不是内存不足导致进程被终止。如果是这个问题，可以临时添加swap空间，或者升级EC2实例的类型。

5. 对比本地和远程的环境差异 #

本地能成功编译但远程失败，大概率是环境不一致导致的，重点对比这几个方面：

• Gem版本：本地执行bundle show，远程在项目目录执行bundle show，对比资产相关gem（比如sprockets、sass-rails、webpacker）的版本是否一致
• Node.js/Yarn版本：Rails资产编译依赖Node.js，本地node -v、yarn -v和远程对比，版本差异可能导致某些语法或打包工具不兼容
• 环境变量：本地的.env.staging文件里的变量，远程是否都正确加载了？有些资产编译（比如webpack打包）会用到环境变量，缺失的话可能导致编译失败

6. 检查Capistrano的资产编译配置 #

看看deploy.rb或staging.rb里的相关配置：

• 确认set :rails_env, 'staging'是否正确设置，确保编译时用的是staging环境
• 有没有自定义的deploy:assets:precompile任务，覆盖了默认逻辑？比如跳过了某些必要步骤
• 检查asset_env相关的配置，是否正确传递了必要的环境变量给编译进程

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