• 比较严格限制的需求下,可以着怎样做:APP内发出的HTTP请求至服务器,服务器返回的是加密后的页面,客户端拿到加密后的页面后,解密,渲染。这个是目前很多APP采用的做法。

  • 没错 我个人感觉 很多的公司用docker的场景都是“为了用docker而用docker”😂 😂 😂 ,为了啥?为了给自己本来业务量不大业务场景也不复杂的应用贴上一些前沿的词汇而已。。。。。真不知道有多少家公司的业务需要上百台服务器来支撑,一半以上的公司的某个产品,可能也就几台服务器就hold住了,但是这些公司的技术leader非要把自己本来稳定运行的环境搬迁到docker上,然后自我感觉良好。(个人拙见)😂

  • 已经解决

    passenger在启动的时候,默认使用bundle的执行环境,bundle在执行的时候会查找gemfile文件,查找顺序为ENV[BUNDLE_GEMFILE], ../Gemfile;

    如果在首次启动passenger的时候,没有加载环境变量BUNDLE_GEMFILE的话,那么gemfile文件的位置就是应用的根目录下的Gemfile文件路径,一旦passenger启动完成,那么bundle使用的gemfile文件的路径就不会再更改了(记录在passenger的进程中)

    所以在使用passenger-config restart命令的时候,在经过几次capistrano的keep_release之后,最初始的那个版本被删除之后,重启会失败,报错(Bundler::GemfileNotFound)

    所以在启动passenger的时候,指定环境变量:BUNDLE_GEMFILE 即可,类似于如下:

    BUNDLE_GEMFILE=/var/www/XXX/current/Gemfile bundle exec passenger start
    

    包括unicorn的启动也是如此 只不过unicorn会在启动脚本里面加上:

    before_exec do |server|
      ENV['BUNDLE_GEMFILE'] = "/var/www/XXX/current/Gemfile"
    
    end
    

    道理是一样的

  • 很赞!我很喜欢这种docker+自己写脚本部署的方式

  • 👍 好的

  • 之前的项目一直是rails3.X的 资源的安放路径是public 现在使用5.2的版本,想遵循一些以前的做法,看来我的这种想法就是错的

  • 是的,我现在直接用< style >标签的写法了,资源的时间戳是我自己打上去的。

  • 我们不用AP来编辑静态资源,我们前端用自己的构建资源的工具以及压缩方法。一般上线前,前端会把他们编译压缩后的静态资源提交,我们直接引用相应的资源即可,没有用到AP的功能,所以也禁用了AP。但是感觉stylesheet_link_tag的写法很方便,所以想使用这个helper方法。尤其是stylesheet_link_tag可以在生成的资源文件后面加上时间戳来防止资源文件的缓存问题。

  • 禁用 Assets Pipeline之后,stylesheet_link_tag 写成相对路径不生效,写成绝对路径就行了,但是不知道在哪里设置stylesheet_link_tag的默认工作dir

  • 是的,我感觉也是,在线上环境下使用gemset来管理ruby gem非常不方便,出了在自己的个人电脑上还行。推荐的文档不错!