如果你的做法是在CMS运行在dyno上才进行安装plugin 那当然会消失 实际的细节是 source code->slug->dyno https://devcenter.heroku.com/articles/slug-compiler slug包含你的应用程式档案，和执行你的应用程式所需的环境 像是php, apache等 当heroku要启动一个dyno时，就会用这个slug来安装在某个server上(dyno) 所以你必须要在local把你所需要的plugin和template装好才push上去 这样这些档案才会被包装在slug里面 下次重新启动dyno, 也才会有这些档案 如果你是在运行的时候才装，你的确可以装在上面 但是这些档案并没有被打包压缩在slug里 所以才会造成说sleep後重新启动档案不见的状况 至於所谓sleep的状态，实际上是你的dyno整个被关掉了 下次新的request进来，heroku会用打包好的slug去产生出一个全新的dyno 这边有我之前的分享，请参考第5页 http://www.slideshare.net/YuChengWang/heroku-git-push-run ※ 引述《jimmytzeng (jimmytseng)》之铭言： : 感谢您的回答 : 我後来看了一下heroku dev center的说明 : DYNO确实是当我的code push上去後就会产生DYNO, 而不是我说的当有request进来才会产生 : 而平常DYNO只是处於sleep的状态 : 感谢指正 : 另外我後来详细的去了解的问题 : 发现不仅仅是config无法做储存,甚至连某些CMS在运作时所安装的plugins以及templates : 都是会随着DYNO处於sleep状态後而消失 : 後来自己想到解决的方法 : 只能先在local端先架设一个简易的sever, 进行CMS的configuration以及plugins,templates的安装 : 当一切设定完毕,在push至heroku完成初始化设定 : ※ 引述《blue3 (啦啦啦)》之铭言： : : 你要先了解heroku平台的设计原则 : : 才有办法设计出符合这个平台的应用程式 : : http://12factor.net/ : : 这是heroku创办人提出的12factor : : 如果一个应用程式依照这12个原则去设计 : : 那麽将可以更容易地被scale或是部署在不同的环境 : : 你的问题解决方式很简单，也是heroku建议的方式 : : 就是所有应用程式相关的设定，都应该透过环境变数的方式去设定 : : https://devcenter.heroku.com/articles/config-vars : : 像是资料库，或是add-on的设定 : : 而dyno本身的设计必须是stateless的 : : 也就是不应该有任何的状态资料(session, file等)被储存 : : file应该透过第三方平台去存取 : : session则应写入资料库或是透过像memcached来做分散式快取 : : 这是因为dyno的设计，是建构在硬体可能随时坏掉的前提之上 : : 因此stateless的特性，让dyno不储存任何状态 : : 可以在dyno crash的时候，重新启动一个dyno来服务 : : 另外，修正一下你的说法， : : 并不是一个request进来才会产生一个dyno, : : dyno在你push code到heroku时就会产生了 : : 如果你只有一个dyno, 才会有sleep的效应 : : 也就是你说的，太久没用被卸载来减轻平台本身的负担 : : 当"第一个"request进来，才会再产生一个dyno : : 如果你有两个dyno, 就不会sleep : : 但是两个dyno的状况下，就要让session可以在不同dyno之间同步 : : 你遇到的不是平台的问题 而是它的设计就是如此 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 27.105.53.40 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/Web_Design/M.1419771243.A.EB1.html ※ 编辑: blue3 (27.105.53.40), 12/28/2014 20:56:22