在使用 IaC 時，專案的管理是一個滿困難的議題。到底要將全部的 IaC 程式碼放在一起呢？還是將程式碼分開呢？

這個問題在專案還小的時候可能還不是問題，但當專案內管理的資源變多時，就需要考慮是否要將專案切
割成多個專案了。

在 Pulumi 官方的部落格文章中有提到這個問題（連結於參考資料中），建議在專案變大時，可以考慮將原本的專案切分成不同的專案。

而且大部分的狀況可能都是已經有一套 IaC 工具在使用了，Pulumi 是後來導入的工具，這時就會需要去參考到其他工具的 State。

這也是為什麼要在前面的文章特別提到跨專案的資源參考，因為這在 Pulumi 中是很常見的需求。

多專案的例子

下圖提供了一個可能的專案切割方式，可以參考如何將 IaC 分散在不同的 Project 中的作法。

下圖表示多個專案之間的參考依賴關係：

專案的依賴與軟體的套件依賴很像，要儘量避免循環依賴的問題。如果在 IaC 專案之間有循環依賴，那在遇到問題要在新的環境重建時，就會遇到狀況。有循環依賴關係的兩個專案都無法成功的建立，因為都有依賴未滿足。

接著大概列出每個專案可能有的資源，也比較好了解每個專案的功能

• Project - VPC
  • VPC
  • Subnet
  • Gateway
  • RouteTable
• Project - DNS
  • Zone
  • Record
• Project - K8S Cluster
  • EKS
  • NodeGroup
  • Load Balancer (for Ingress controller)
• Project - DB
  • RDS Database
  • RDS Proxy
  • DB subnet group
• Project - Data warehouse
  • Lake formation
  • S3 Bucket
  • Redshift
  • EMR
  • Athena
• Project - App
  • 專案程式碼
  • S3 Bucket
  • k8s resources
  • DNS Record

通常可以將比較有相關聯的資源或是需要一起更新的資源放到同一個 Project 中。

這邊有個設計是希望每個應用程式可以自行管理自己的 K8S 的 YAML 與 DNS 的設定。所以會將 Zone 與 Record 分拆在不同的專案中，並再使用 StackReference 參考 ZoneId。

另外值得注意的是，App 有關的專案。並不是每個 App 都有個專案，放置 Pulumi 的 IaC 程式碼，而是會將 Pulumi 的程式碼放在 App 專案中。這邊的 App 指的就是撰寫的應用程式，例如網頁的 API server。

將 App 的 source code 與 IaC code 放在一起有幾個好處

1. 可以讓開發人員自己管理需要用到的資源。並且借助 Pulumi 的特性，專案使用什麼程式語言，Pulumi 就使用那個程式語言來撰寫。可以減少開發人員的排斥。
2. CI/CD 流程上的簡化，因為程式碼與如何部屬的程式都在一起，可以一個專案直接一條龍的完成 CI/CD 流程，不需要再去通知其他專案做 Deployment。

小結

Pulumi 專案的各種使用建議，滿推薦參考下方 Reference 的官方部落格文章。裡面有提到多專案時的各種設計考量。

Reference

• https://www.pulumi.com/blog/iac-recommended-practices-structuring-pulumi-projects/
• https://www.pulumi.com/blog/iac-recommended-practices-using-stack-references/