2017-03-17 49 views
0

在Pivotal Cloud Foundry中,有一種方法可以讓一個Manifest.yml在不同環境下具有不同的環境變量。例如我們有一個開發/測試/生產環境。在系統中我想要一個環境變量「service = development.pcf.domain.com」,在測試中它應該是「service = test.pcf.domain.com」。如何在一個清單文件中爲不同環境設置Pivotal Cloud Foundry環境變量?

我想維護一個文件並在一個清單中包含所有環境變量,而不必記住每個環境要傳遞哪個清單文件。

換句話說,我不想要有3個文件:

manifest_development.yml 
-env: url=development.pcf.domain.com 
manifest_test.yml 
-env: url=test.pcf.domain.com 
manifest_production.yml 
-env: url=production.pcf.domain.com 

我寧願有1個文件,它定義了所有的環境變量和正確的應該根據應用程序的環境中進行挑選部署:

manifest.yml: 
env-development: 
-url=development.pcf.domain.com 
env-test: 
-url=test.pcf.domain.com 
env-production: 
-url=production.pcf.domain.com 

回答

0

我發現的是一些聰明的傢伙已經有spring_active_profiles設置wirh env特定的設置,所以我只需要創建應用程序系統。屬性和使用彈簧配置文件

0

對「與傳承多體現」一看部分來自https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#multi-manifests,如

--- 
inherit: base-manifest.yml 
... 

如果可能的話最好通過解析VCAP_SERVICES環境變量每個環境的應用程序配置文件避免已經提出通過CF服務/杯,該應用獲得與環境相關的配置應用程序的所有相關服務。

+0

謝謝你會檢查出來。我們的組織剛剛從pcf開始,並向我解釋了他們需要做的一些工作,以便我們能夠註冊我們的服務。當發生這種情況時,我同意將該服務作爲服務參數傳遞。不幸的是還有其他一些情況,我不得不在pcf之外調用尚未轉換的遺留服務。 – George

+0

我可能會誤解一件事。看起來我必須爲每個環境使用不同的應用程序名稱?這似乎是一個壞主意,因爲每一個調用我的微服務的應用程序都必須知道當前環境的服務名稱。 – George

+0

Hi @George 不,您需要在場景中爲每個環境設置提供(cf push -f)不同的應用程序清單文件。 您的應用程序名稱和所有常見設置都可以保存在base-manifest.yml中,這在所有環境中都是常見的,並且可以在每個環境清單中繼承。 我希望有幫助。 –

0

我過去的做法是充分利用管道的靈活性。

我已經使用Jenkins和Concourse。

從技術上講,你只應該部署到開發環境。所有後續部署都應通過管道完成。

我會做的是,有一個通用的清單文件(generic-manifest.yml),其中有佔位符。我會創建一個文件的副本(manifest-local.yml)。而那個只會用於開發環境。

在我的管道中,使用一些shell腳本,我生成了具有正確環境細節(integration,uat,prod等)的manifest.yml。我將不得不維持只有一個文件 - generic-manifest.yml。通常,每次我對它進行更改時,我都會重新創建本地清單文件。

最終,您可以爲您開發環境的管道,在這種情況下,您將不再需要本地清單文件。

我會更進一步說,每次我必須開發一個新的微服務時,我首先會開發一個shell類,它將測試類,然後下一個將爲該微服務開發一個管道。這樣,我再也不用擔心把我的微服務推向雲代工。

你第一次做,它會有一些工作。但是一旦你養成了這種習慣,它就會變得無縫。

試試看。

+0

[Concourse](concourse.ci)是免費的,您可以在幾分鐘內啓動並運行它。 012- Concourse最初可能會引起混淆。但是一旦你掌握了它,你會開始使用它的一切。 我們對任何事情都使用大廳管道。從頭開始構建PCF,升級PCF切片,部署代碼和所有內容。 –