capistrano deploy_symlink失败

这是我的第一次部署。 我做了一个cap deploy:setup工作正常。

然后,当我尝试执行cap deploy:update我遇到错误消息。 有点像

 rm: cannot remove `/var/www/app_name/current': Is a directory 

这是我的capfile和目录权限。

http://pastie.org/1189919

一般而言,就部署用户和权限而言,最佳做法是什么? 我应该使用root还是创建不同的用户。 如果不同的用户需要具备哪些确切权限?

谢谢

您是否在/var/www/app_name创建了目录,还是由capistrano创建的?

无论如何,你遇到的问题是/var/www/app_name/current不应该是一个目录 – 它应该是/var/www/app_name/releases/当前版本的符号链接。 当capistrano完成在/var/www/app_name/releases/创建新版本文件夹并尝试将符号链接/var/www/app_name/current到它时,会导致失败。

您可以通过重命名/var/www/app_name/current来修复问题(如果出现问题,您可以备份),并从/var/www/app_name/current创建符号链接到/var/www/app_name/current中的最新版本/var/www/app_name/releases/ ,然后执行cap deploy 。 (如果有效,请删除当前的备份)。

就你所做的最佳实践而言, 不要使用root 。 相反,设置一个只具有所需目录权限的用户(或使用现有用户)(没有仔细阅读你的脚本,但可能只是/var/www/app_name

要部署新版本,您应该调用cap deploycap deploy:migrations ,而不是cap deploy:update

我也有过这样的错误。 更新源代码和重新启动服务器这一完全正常的任务似乎总是在简单脚本的各个方面都存在问题。

有时它抱怨github上的哈希值与某个预期值不匹配,有时它不会更新目录,因为它已经存在,但主要是因为它想要创建存在的东西。

有没有办法强迫Capistrano,因此shell命令只是做它? 我至少会欣赏它,问我应该怎么做才能遇到这种类型的错误,而不仅仅是失败和回滚。 特别是当它是一个简单的文件操作。

我最终不得不在服务器上手动删除内容,以便Capistrano脚本能够正常运行而不会失败。 这显然不是前进的方向。