21

मैं अपने प्ले ऐप को परीक्षण, स्थानीय और उत्पादन (उत्पादन हेरोकू) वातावरण के लिए विभिन्न डेटाबेस का उपयोग करना चाहता हूं।Play 2.0 में प्रति वातावरण के विभिन्न डेटाबेस कैसे सेट अप करें?

application.conf में मेरे पास है:

db.default.driver=org.postgresql.Driver 

%dev.db.default.url="jdbc:postgresql://localhost/foobar" 
%test.db.default.url="jdbc:postgresql://localhost/foobar-test" 
%prod.db.default.url=${DATABASE_URL} 

यह काम करने के लिए प्रतीत नहीं होता। जब मैं play test या play run, चलाने सभी डीबी उपयोग के साथ विफल रहता है:

Configuration error [Missing configuration [db.default.url]] (Configuration.scala:258) 

मैं इस बारे में कुछ प्रश्न हैं:

  • सामान्य तौर पर, मैं एक छोटे से कैसे डेटाबेस कॉन्फ़िगर किया गया है के बारे में उलझन में हूँ प्ले में: ऐसा लगता है कि सादा db, db.[DBNAME] और db. [DBNAME].url और विभिन्न ट्यूटोरियल के बीच अलग-अलग विकल्प बनाते हैं। कुछ अभिव्यक्तियां जो प्रतीत होती हैं उन्हें काम करना चाहिए (उदा। db.default.url = "jdbc:..." एक त्रुटि के साथ विफल हो गई है जहां एक स्ट्रिंग प्रदान की गई थी जहां ऑब्जेक्ट की अपेक्षा की गई थी)।

  • मैंने देखा है अन्य लोगों का सुझाव है कि मैं अलग prod.conf, dev.conf और test.conf फ़ाइलों कि प्रत्येक शामिल application.conf बनाने और उसके बाद डीबी विशिष्ट विन्यास होते हैं। लेकिन उस स्थिति में, मैं प्ले कंसोल से test चलाते समय डेटाबेस का उपयोग करने के लिए कैसे निर्दिष्ट करूं?

  • %env सिंटैक्स प्ले 2 में काम करना चाहिए?

  • उपयोग करने के लिए play test के लिए वातावरण निर्दिष्ट करने का सही तरीका क्या है?

उत्तर

20

प्ले 2 में अलग-अलग कॉन्फ़िगरेशन वातावरण नहीं हैं। इसके बजाय आप conf/application.conf फ़ाइल में कॉन्फ़िगरेशन पैरामीटर को सेट या ओवरराइड करते हैं। एक तरह से यह करने के लिए play कमांड लाइन पर है, जैसे:

play -Ddb.default.driver=org.postgresql.Driver -Ddb.default.url=$DATABASE_URL ~run 

तुम भी बता सकते हैं एक अलग कॉन्फ़िग फ़ाइल का उपयोग करने के खेलते हैं:

play -Dconfig.file=conf/prod.conf ~run 

Heroku के लिए एक उदाहरण Procfile लिए, देखें:
प्ले डॉक्स में https://github.com/jamesward/play2bars/blob/scala-anorm/Procfile

अधिक विवरण:
http://www.playframework.org/documentation/2.0/Configuration

+1

हम्म, यह समझ में आता है - तो उन ' % prod' युक्तियाँ प्ले 1.x के लिए थीं? उदाहरणों के लिए धन्यवाद। मैं वास्तव में इस बिंदु पर dev/prod विन्यास मुद्दा काम किया है। मेरा शेष प्रश्न अभी भी है: परीक्षण सूट चलाते समय मैं एक अलग वातावरण का उपयोग करने के लिए Play को कैसे कॉन्फ़िगर कर सकता हूं? – Bill

+2

हां, '% prod' सामान केवल 1.x चलाएं। जब आप परीक्षण चलाते हैं तो आपको वही काम करने में सक्षम होना चाहिए: 'play -Dsetting = foo ~ test' –

+5

यह सच है, लेकिन यह बहुत त्रुटि-प्रवण प्रतीत होता है: यदि मैं समझदारी से कॉन्फ़िगरेशन फ़ाइल नाम छोड़ देता हूं, तो मेरा (संभावित रूप से विनाशकारी) टेस्ट सूट मेरे देव डेटाबेस के खिलाफ चलाएगा। ऐसा करने का कोई और तरीका नहीं है? प्ले 1 से% प्रोड दृष्टिकोण पर्याप्त से अधिक प्रतीत होता है, यह सुनिश्चित नहीं है कि यह अब क्यों उपलब्ध नहीं है। – Bill

2

यदि आप कॉन्फ़िगरेशन मान लोड करते हैं, तो आप वास्तव में Play 1.0 कॉन्फ़िगरेशन मान नामकरण विधि का उपयोग कर सकते हैं, यदि आप कॉन्फ़िगरेशन मान लोड करते हैं, तो Play.isTest देखें, और उसके बाद 'test' के साथ लोड की गई प्रॉपर्टी को उपसर्ग करें। यहाँ एक कतरना है:

def configPrefix = if (play.api.Play.isTest) "test." else "" 

def configStr(path: String) = 
    Play.configuration.getString(configPrefix + path) getOrElse 
    die(s"Config value missing: $configPrefix$path") 

new RelDb(
    server = configStr("pgsql.server"), 
    port = configStr("pgsql.port"), 
    database = configStr("pgsql.database"), 
    user = ..., 
    password = ...) 

और संबंधित config टुकड़ा:

pgsql.server="192.168.0.123" 
pgsql.port="5432" 
pgsql.database="prod" 
... 

test.pgsql.server="192.168.0.123" 
test.pgsql.port="5432" 
test.pgsql.database="test" 
... 

अब आप और आपके द्वारा अपना E2E टेस्ट स्वीट चलाने किसी भी प्रणाली गुण स्थापित करने को याद करने की जरूरत नहीं है, अगर आप गलती से नहीं होगा प्रोड डेटाबेस से कनेक्ट करें।

मुझे लगता है कि आप वैकल्पिक रूप से test. मानों को एक अलग फ़ाइल में रख सकते हैं, जिसे आप तब मुख्य कॉन्फ़िगरेशन फ़ाइल के अंत में शामिल करेंगे।

11

कम से कम प्ले 2.1.1 में यह संभवतः पर्यावरण चर के साथ कॉन्फ़िगरेशन मानों को ओवरराइड करना संभव है, यदि वे सेट हैं। (विवरण देखने के लिए: http://www.playframework.com/documentation/2.1.1/ProductionConfiguration)

तो आप अपने conf/application.conf में निम्नलिखित सेट कर सकते हैं:

db.default.url="jdbc:mysql://localhost:3306/my-db-name" 
db.default.url=${?DATABASE_URL_DB} 

डिफ़ॉल्ट प्रति यह जब तक वातावरण चर DATABASE_URL_DB इसके लिए एक मूल्य को परिभाषित करता है JDBC-URL परिभाषित का प्रयोग करेंगे। तो आप कॉन्फ़िगरेशन में और उत्पादन या चरणों के लिए बस अपने विकास डेटाबेस को पर्यावरण चर परिभाषित करते हैं।

लेकिन सावधान रहना, इस प्रतिस्थापन काम नहीं करता है अगर आप उद्धृत तार के अंदर अपने चर संदर्भ डाल:

db.default.url="jdbc:${?DATABASE_URL_DB}" 

इसके बजाय, बस खंड गंदें शब्द बोलना उदाहरण के लिए, प्रतिस्थापित किया जा करने के लिए।

database_host = "localhost" 
database_host = ${?ENV_DATABASE_HOST} 
db.default.url="jdbc:mysql://"${?database_host}":3306/my-db-name" 

इस उदाहरण में, स्थानीय होस्ट डिफ़ॉल्ट रूप से उपयोग किया जाएगा यदि वातावरण चर ENV_DATABASE_HOST सेट नहीं है। (विवरण देखने के लिए: https://www.playframework.com/documentation/2.5.x/ConfigFile#substitutions)

+0

यह एक शानदार सुविधा है! –

0

एक और दृष्टिकोण वैश्विक/GlobalSettings विधि ओवरराइड करने के लिए onLoadConfig और आप कर सकते हैं सामान्य config और नीचे की तरह विशिष्ट वातावरण विन्यास के साथ सेटअप आवेदन विन्यास ...

conf/application.conf --> configurations common for all environment 
conf/dev/application.conf --> configurations for development environment 
conf/test/application.conf --> configurations for testing environment 

conf/prod/application.conf --> configurations for production environment 
वहाँ से है जो है

आप मेरे नमूना कार्यान्वयन के लिए http://bit.ly/1AiZvX5 देख सकते हैं।

उम्मीद है कि इससे मदद मिलती है।

0

विषय से संबंधित नहीं, लेकिन यदि आप 12-कारक-ऐप का पालन करें तो वातावरण के नाम पर अलग विन्यास होने बुरा है:

Another aspect of config management is grouping. Sometimes apps batch config into named groups (often called “environments”) named after specific deploys, such as the development, test, and production environments in Rails. This method does not scale cleanly: as more deploys of the app are created, new environment names are necessary, such as staging or qa. As the project grows further, developers may add their own special environments like joes-staging, resulting in a combinatorial explosion of config which makes managing deploys of the app very brittle

स्रोत: http://12factor.net/config

संबंधित मुद्दे