在 ECS 上運行 node.js 服務的 Docker 容器能否共享從 EFS 掛載的 node_modules 卷？

Question

在 AWS ECS 下運行的 node.js 服務容器掛載在 EFS 上持久保存的共享 node_modules 卷是一種好習慣嗎？ 如果是這樣，在應用程序啟動之前預填充 EFS 的最佳方法是什么？

我的前端服務運行在 AWS Fargate 實例上啟動的 node.js 應用程序。 這個應用程序使用了許多 node_modules。 每個實例是否需要在自己的容器中安裝整個 node_modules 主體？ 或者他們都可以掛載一個包含 node_modules 的單個副本的共享 EFS 文件系統嗎？

我一直在遷移到 AWS Copilot 進行編排，但是文檔對於如何預填充 EFS 非常模糊。 他們有一次說，“我們建議安裝一個臨時容器並使用它來補充 EFS，但警告：我們不建議將這種方法用於生產。” （ 存儲：AWS Copilot 高級用例）

Answer 1

在 AWS ECS 下運行的 node.js 服務容器掛載在 EFS 上持久保存的共享 node_modules 卷是一種好習慣嗎？

詢問它是否“好”是一個見仁見智的問題。 然而，這通常是 ECS 中的常見做法。 但是，您必須非常清楚您的應用程序將針對 EFS 卷生成的 IOPS。 一旦 EFS 卷用完突發信用，它就會真正減慢並影響應用程序的性能。

我以前從未見過用於存儲node_modules的 EFS 卷。 老實說，這對我來說似乎是個壞主意。 像這樣的依賴應該總是捆綁在你的 Docker 鏡像中。 否則，在升級 EFS 卷中的這些依賴項時會很困難，並且可能需要停機時間來升級。

如果是這樣，在應用程序啟動之前預填充 EFS 的最佳方法是什么？

您必須創建初始 EFS 卷並將其掛載到 EC2 實例或另一個 ECS 容器之類的位置，然后在該 EC2/ECS 實例中運行任何必要的命令將文件復制到卷。

您問題中的引述未出現在您鏈接的頁面上，因此很難確切地說 Copilot 團隊會推薦什么其他方法。

Answer 2

感謝您的提問！ 這指出了我們在發布新功能時打開的文檔中的一些空白。 實際上有一個清單字段image.depends_on可以緩解文檔中關於 prod 使用的問題。

要專門回答有關在服務容器啟動之前對 EFS 卷進行補水的問題，您可以在清單中使用 sidecar 和image.depends_on字段。

例如：

image:
  build: ./Dockerfile
  depends_on:
    bootstrap: success

storage:
  volumes:
    common:
      path: /var/copilot/common
      read_only: true
      efs: true

sidecars:
  bootstrap:
    image: public.ecr.aws/my-image:latest
    essential: false #Allows the sidecar to run and terminate without the ECS task failing 
    mount_points:
      - source_volume: common
        path: /var/copilot/common
        read_only: false

在部署時，您將構建 Sidecar 映像並將其推送到 ECR。 它應該包含您的打包數據或一個腳本，以提取您需要的數據，然后將其移動到容器文件系統中/var/copilot/common的 EFS 卷中。

然后，當您下次運行copilot svc deploy時，會發生以下情況：

1. Copilot 將在您的環境中創建一個 EFS 文件系統。 每個服務將在 EFS 中獲得自己的隔離訪問點，這意味着服務容器都共享數據，但看不到其他服務添加到 EFS 的數據。
2. 您的邊車將運行完成。 這意味着每當部署任務的新副本時，所有當前運行的服務都將看到對 EFS 文件系統的更改，除非您在啟動腳本中專門在 EFS 中創建特定於任務的子文件夾。
3. 一旦 sidecar 成功退出，新的服務容器將在 ECS 上出現並正常運行。 它將有權訪問 EFS 卷，該卷將包含您的啟動數據的最新副本。

希望這可以幫助。