分享 Say goodbye to Capistrano, say hello to Mina.

sailtsao · 发布于 2013年3月10日 · 最后由 jasl 回复于 2013年3月14日 · 4390 次阅读
96

capistrano大家都用过,不知道大家对他的感觉是啥,我的感觉是太复杂,网上找找教程也只是改改简单配置,还是有很多东西需要手动上服务器去管理
mina相比cap来说,速度快是必须的了,本地生成script然后ssh到服务器去一次执行,而cap则需要ssh登录服务器好几次才行.mina官网都形容是really bloody fast...
其实速度都是最次要考虑的,最主要的用这种gem是为了方便,谁也不想每次部署都要执行一大堆的命令,太烦了.因为我用的是nginx+unicorn,所以之前用cap的时候每次cap deploy之后都要连到服务器上去重启unicorn,很是烦恼,而且第一次部署的时候还要进行nginx配置,unicorn配置.如果这一切都能自动化该多好?
偶然一天在ruby-china上看到@huobazi推荐的unicorn+nginx+mina的github项目,简直是部署神器啊,有了这个项目配合mina,你只需要在服务器上安装好nginx,然后在你项目里面加上此项目的lib文件并改几个配置,恭喜你,所有一切的琐事你都不要操心了,此项目都帮你弄好了,什么nginx添加新网站配置文件,unicorn配置,unicorn重启,nginx重启,rake命令神马的都可以在本地轻松完成,而且速度超快.用unicorn和nginx的你难道不心动么?心动不如行动,快去试试吧,绝对可以让你不再害怕部署的繁琐操作 mina官网 unicorn+nginx+mina项目的Github Page unicorn+nginx的cap版我没有用过,只是搜了一下发现cap也有此类项目,对cap有感情的可以尝试

共收到 16 条回复
122

mint确实快

15

嘿嘿 mina 谁用谁知道!

4904

看了一遍文档

项目没有公开访问的git仓库,怎么做到本地打包,然后上传呢?

打包直接用tar,那么上传呢?有没有类似 push 上传文件的方法

96

@kingwkb 你的意思是你的项目文件的git url? 在deploy里面配置 set :repository, 'your git repo url'

1232

前两天才用过,入手比较简单,也挺快 其实关键是最近capistrano对rails4支持的不好,部署不成,就干脆用mina了,不过可能是因为刚用,有些东西还是自己ssh到服务器那边搞的

1107

unicorn有现成的recipe 没换掉capistrano主要还是因为recipe比较全面了 看例子 mina天生支持multi-stage挺不错的 我对capistrano的deploy.rb做了些手术才达成的

68

这不就是让人爽歪歪的东西吗?

1031

Cap 我还没开始用呢....

4904

#5楼 @sailtsao 我不是这个意思,我的意思是我的项目没有公网可以访问的git,都是内网的,所以呢部署时候需要在本地把代码tar打包,然后上传

322

#7楼 @jasl cap 也可以有 cap production deploy 这样子的用法

不知道 @sailtsao 说的 ssh 几次是什么意思,cap 也可以一次连接执行多个任务,比如 cap update_code link_files restart 这样

1107

@nevill 那个测试过 不够dry 而且不够灵活 我的方法https://github.com/jasl/start_up/blob/master/config/deploy.rb

186

真心不错,还提供了 sudo_setup,可以专门用另外一个有 sudo 权限的用户来执行一些需要管理员权限的配置

322

#12楼 @jasl 可以说一下为什么不够 dry 呢?

看了你的 deploy.rb,我大概明白关键一点是你用了不同的 env 变量来区分 production 和 stage,我下面的例子是 stage / production 都用 'production' 作为 env 变量值。 至于说具体的配置,比如 database.yml 不同,可以在 after deploy:finalize_update 或者 deploy:create_symlink 这个步骤解决。

task :stage do
  set :user, "tester"
  set :target, "stage"
  server "stage.example.com", :app, :web, :db, :primary => true
end

task :production do
  set :user, "deployer"
  set :use_sudo, false
  set :target, "www"
  server "www.example.com", :app, :web, :db, :primary => true
end

set :rails_env, "production"
set :deploy_via, :copy
set :deploy_to, "/deploy/path"
1107

@nevill 因为set各个变量要每个环境写一套,我那个还有些遗留代码没cleanup掉,但实际上完全可以set :user, deploy[:user]一条搞定,另外你说的具体配置不同 那还要增加钩子来解决,感觉太麻烦了,不同环境的特别的任务放到deploy/:env里然后一load就行了,如果你觉得cap production deploy好 其实完全可以做到这样 我扫了一眼multi_stage的实现,太复杂,如果不是为了做成cap的ext,根本不用那么复杂

1107

重写了自己的multi_stage实现,review了下github上的,当初写的时候脑子不清楚

@nevill 我觉得他复杂主要是因为个人的洁癖,我的配置是用yaml统一管理的,所以我应该在deploy.rb里load他,但是deploy/:env里没有这个上下文 要重新加载 我觉得这完全不应该 你的写法也不错 解决了上边的问题,但是如果添加新的env要修改deploy.rb 也不是很好

我新的实现利用eval读取deploy/:env 没有感觉到用task包装有什么好处

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册