2017-08-09 265 views
3

任何人都知道是否有方法根據環境/工作區是什麼來填充Terraform中的變量?優選一個Terraform環境特定變量

  • 填充VAR命名空間(即,不是外部數據源),
  • 不需要包裝
    • tf(){ terraform --var-file=$(get_tf_env).tfvars
  • 通過改變terraform生效環境/工作區,沒有任何額外的手動步驟(即步驟不是由運行terraform env觸發)?

回答

1

我不知道用Terraform做的本地方法。如果你四處搜索,你會看到很多人將不同的文件夾結構用於TF配置的入口點,每個不同的文件夾可以在tfvars文件中具有不同的值。有一種方法可以幫助你在0.10中引入Terraform Workspaces

我已經實施了一些與您建議使用OctopusDeploy的建議類似的內容。如果您以前沒有使用過,八達通可以很好地管理特定於環境的變量。我有一個默認的tfvars文件和八達通內的相應變量值列表,每個環境。

我有一個基本步驟,遍歷tfvars中的每個變量,然後查找具有相同名稱的Octopus變量,並在找到該變量時將其替換。

我發現這是一個體面的工作方式,因爲它在Terraform tfvars文件(需要什麼值)和八達通中的變量值(實際值是什麼)之間給出了很好的分隔。

E.g.如果我有一個tfvars文件,其中包含

instance_size = "Medium" 

而且在Octopus,Staging和Production中有2個環境。我可以將一個變量添加到名爲「instance_size」的Octopus中,併爲每個環境設置不同的值(例如分別爲「Big」和「Biggest」)。

我寫會發現「instance_size」一corrresponding值,這意味着,當我運行它的分期我會得到步驟模板:

instance_size = "Big" 

和生產

instance_size = "Biggest" 
+0

謝謝費爾明;我特別想避免使用任何形式的包裝;我已經有了文件夾/符號鏈接場設置,但這樣我就可以擁有不同的模塊集(實現相同的接口)來實現操作。在這種情況下,我們的AWS工具已被分解出來,因此可以使用來自Azure或GCE的等效工具來實施。 工作區本質上是以前版本中稱爲環境的0.10版本。如果terraform 0.10.0有一種反映工作區名稱的方法,但是我不認爲它是有用的。 –

+0

我將Octopus步驟作爲部署管道的一部分,因此不要將其看作是包裝本身。不確定我是否通過具有相同接口的不同模塊獲得了您的意思 - 相同的參數要求,但Azure/AWS之間的實現切換? – Fermin

4

Terraform workspaces

工作區是Terraform狀態的命名容器。通過多個工作區,可以使用Terraform配置的單個目錄來管理多個不同的基礎架構資源集。

在0.9版的Terraform版本中,這個概念被稱爲「環境」。根據Terraform本身和使用Terraform的組織內部「環境」這個詞超負荷所造成的混淆的反饋,它被重新命名爲0.10。

引用當前工作空間是用於改變基於所述工作區的行爲是有用的。例如,對於非默認工作區,可能需要調整較小的簇大小。例如:

resource "aws_instance" "example" { 
    count = "${terraform.workspace == "default" ? 5 : 1}" 

    # ... other arguments 
} 
+1

我使用上面描述的工作空間,以及變量映射,這些變量映射允許您根據環境(工作空間)名稱爲各種資源保留不同的變量。然後查看資源就可以這樣完成:「$ {lookup(var.vpc_cidr,terraform.workspace)}」。 這將爲您提供varialbe映射'vpc_cidr'的值與等於工作空間名稱的密鑰,例如ecommerce-dev – Mattec

0

我會建議採取「棧」爲您Terraform項目爲基礎的方法,使您可以配置和管理中的「棧」和每個工作區的遠程狀態(又名環境)。這從風險的角度限制了更改的爆炸半徑,簡化了工作流程,並且還提供了更清潔,更易維護的代碼庫。

什麼讓你一天好?

  • 一個客觀簡單的設計,可以讓你推論平臺及其運動部件。 (aka Stacks)
  • 一個實現,爲您提供了靈活性,同時限制了更改的風險。 (aka限制爆炸半徑)
  • 一種解決方案,可以在今天提供價值,並在持續改進的同時長期提供動力。 (又名模式,工作流程)

這裏是一個很好的做法

  • 管理 「國家」 的快速列表分別爲 「堆棧」 跨越 「工作區」

  • 實施的「棧「爲一致‘’跨越‘工作區配置’

  • 保持它客觀和簡單的用好‘模式’和‘工作流程’。

例Terraform項目使用的是基於堆棧方法

/ 
    /scripts 
    <shell scripts> 
    <terraform wrapper functions> 

    /stacks 
    /application_1 # Provisions Application 1 and its dependencies 
    /application_2 # Provisions Application 2 and its dependencies 
    /application_n # Provisions Application N and its dependencies 
     backend.tf  # Remote State 
     data.tf   # Data Sources 
     stack.tf   # Stack Variables and Defaults 
     aws_resource.tf 
     ... 
     ...  
    /network # Provisions VPC, Subnets, Route Tables, Route53 Zones 
    /security # Provisions Security Groups, Network ACLs, IAM Resources 
    /storage # Provisions Storage Resources like S3, EFS, CDN 

    global.tf  # Global Variables 
    dev.tfvars # Development Environment Variables 
    tst.tfvars # Testing Environment Variables 
    stg.tfvars # Staging Environment Variables 
    prd.tfvars # Production Environment Variables 
    terraform.sh # Wrapper Script for Executing Terraform (Workflow) 

一些更多的想法

隨着你實施的發展這是很簡單的納入未來的需求爲已存在的疊層或作爲新的堆棧,如果它們是共享依賴。

Terraform允許使用遠程國家作爲數據源。爲每個堆棧配置自己的輸出變量使配置和使用導出的資源屬性變得更加簡潔。

設置您的項目,以便您可以在堆棧級別定義變量和合理的默認值,使您可以根據需要在工作區級別覆蓋它們,以滿足Dev,Test,Production等不同環境的需求。同時保持配置的一致性和遠程狀態分別在每個環境下進行管理。

這些都是一些我們已經開發並部署在我們的隊伍,提高我們的經驗與Terraform合作來管理我們的AWS平臺的做法。

乾杯!