一千萬個為什麽

搜索

在容器中部署/托管基於JavaScript的靜態網站的策略



這在我們的幾個開發團隊中不時出現,我們沒有找到“正確”的方式:

我們使用了很多基於反應的web應用程序,它們可以“編譯”成只有少數html,js和css文件的靜態網站。

但是,這些應用程序的“構建”需要許多變量來啟用/禁用功能標誌,配置後端URL等。 這意味著我們不能“構建”傳統意義上的二進制文件,只需在部署時應用配置文件 - “構建”本身需要設置這些特定於環境的變量,因此我們唯一能夠“構建”正處於部署階段。

現在我們通過將所需的環境變量註入到Docker容器中並沿著行運行start cmd來解決此問題

npm build && nginx run

這有兩個缺點:

  1. 相對於容器的運行時需求,構建過程會占用很多cpu /內存。這意味著我們需要擴展構建過程的容器,而不是運行時需求 - 感覺不對“/ li>
  2. 構建失敗很難“追蹤”。我們可以在Kubernetes中使用健康檢查,但是如果構建需要2分鐘,我們仍然需要等待3分鐘(為了安全起見,另外需要1分鐘),然後才能開始測試容器的健康檢查終結點以查看其是否存活。
  3. 部署可能需要很長時間:如果我們配置Kubernetes進行“串行”部署,它將啟動每個容器並等待2-3分鐘的“initialDelay”時間段,然後再開始下一個容器。這意味著,如果部署縮放到3-4個豆莢,我們很容易查看部署時間為10分鐘。

這一切對我來說都感覺不太理想。我非常有興趣聽到社區如何通過現代JavaScript webapps解決“部署時構建”難題。

我意識到,對於Kubernetes,我們可以使用執行構建的“init-containers”,將artiaces放置在持久存儲中,然後在啟動過程中讓應用容器從持久存儲中簡單地取出,但這仍然更像是“繞過”問題,而不是解決根本問題。

轉載註明原文: 在容器中部署/托管基於JavaScript的靜態網站的策略

一共有 1 個回答:

從我的角度來看,最好的方法是:

  1. 使用Jenkins分離構建過程,該過程將NodeJS項目構建到分發中並將其包裝到Docker鏡像中
  2. 旋轉Docker註冊表,以積累來自Jenkins的Docker鏡像(此註冊表應可從Kubernetes群集訪問)
  3. 將環境變量移至Jenkins秘密,或者使用單獨的工具從外部Git倉庫收集和合並配置(我們使用Spring Cloud Config通過REST API為每個環境中的每個應用程序收集json/yml定義)

使用Jenkins,您可以配置基於通用管道的持續交付系統。可能的流程是:

  1. Developers finish their work in correspondence to GitFlow (latest Pull Request merged into Release branch)
  2. Webhook triggers Jenkins pipeline:
    • Stage 1: collect environment definition
    • Stage 2: build NodeJS app using npm
    • Stage 3: build Nginx Docker image with distribution
    • Stage 4: push Docker image to Docker registry
    • Stage 5: deploy/update service in Kubernetes using standard definitions
  3. Notifications send in regard of results

這個過程可以使用Rancher進行可視化。我可以在聊天中回答你的問題。