如果你的做法是在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/m.aspx?n=bbs/Web_Design/M.1419771243.A.EB1.html ※ 編輯: blue3 (27.105.53.40), 12/28/2014 20:56:22