應用容器化的五個步驟

一般來說，人們想使用你的應用程式這是一件好事。然而，當應用程式在伺服器上執行時，應用程式受歡迎是有代價的。隨著使用者對資源需求的增加，在某些時候，你可能會發現你需要擴充套件你的應用程式。一種選擇是在這種情況下增加更多的伺服器，建立一個像 Nginx 這樣的 負載平衡器，以滿足需求。

但是，這種方法的成本可能很昂貴，因為當需求低的時候，在沒有流量的伺服器上執行你的應用程式的例項並不會節省資源。容器的優點是它是非持久的，在有需求時啟動新例項，而隨著需求的減少逐漸消失。如果這聽起來像是你需要的功能，那麼現在可能是將你的應用程式遷移到容器的時候了。

將應用程式遷移到容器中，很快就會變得迷失方向。雖然容器內的環境可能感覺很熟悉，但許多容器映象是最小化的，而且它們被設計為無狀態的。不過在某種程度上，這也是容器的優勢之一。就像 Python 虛擬環境一樣，它是一塊白板，可以讓你構建(或重建)你的應用程式，而沒有許多其他環境所提供的無形的預設值。

每一次向雲服務的遷移都是獨一無二的，但在將你的應用程式移植到容器之前，你應該注意以下幾個重要原則。

將你的應用程式移植到容器中是一個很好的機會，可以瞭解你的應用程式實際依賴的東西。由於除了最基本的系統元件外，很少有預設安裝的元件，你的應用程式一開始不太可能在容器中執行。

在重構之前，確定你的依賴關係。首先，在你的原始碼中用 grep 查詢 include、import、require、use 或你選擇的語言中用來宣告依賴關係的任何關鍵詞。

$ find ~/Code/myproject -type f \
    -iname ".java" \
    -exec grep import {} \;

不過，僅僅識別你使用的特定語言的庫可能是不夠的。審計依賴關係，這樣你就能知道是否有語言本身執行所需的低階庫，或者特定的模組以預期的功能執行。

容器是無狀態的，當一個容器崩潰或停止執行時，該容器的例項就永遠消失了。如果你要在該容器中儲存資料，這些資料也會消失。如果你的應用程式儲存使用者資料，所有的儲存必須發生在容器之外，在你的應用程式的例項可以訪問的某個位置。

你可以使用對映到容器內某個位置的本地儲存來儲存簡單的應用程式配置檔案。這是一種常見的技術，適用於需要管理員提供簡單配置值的 Web 應用程式，如管理員的電子郵件地址、網站標題等。比如說：

$ podman run \
    --volume /local/data:/storage:Z \
    mycontainer

然而，你可以配置一個資料庫，如 MariaDB 或 PostgreSQL，將大量資料在幾個容器中的共享儲存。對於私人資訊，如密碼，你可以配置一個機密儲存。

對於你需要如何重構你的程式碼，相應地調整儲存位置，這可能意味著改變路徑到新的容器儲存對映，移植到不同的資料庫，甚至是納入容器特定的模組。

容器在構建時通常會從 Git 倉庫中拉取原始碼。一旦你的 Git 倉庫成為你的應用程式的生產就緒程式碼的標準來源，你必須有一個管理 Git 倉庫的計劃。要有一個釋出分支或生產分支，並考慮使用 Git 鉤子 來拒絕意外的未經批准的提交。

容器化應用程式可能沒有傳統的釋出週期。當容器被構建時，它們會被從 Git 中拉取出來。你可以啟動任何數量的構建系統作為容器構建的一部分，但這可能意味著調整你的構建系統，使其比過去更加自動化。你應該重構你的構建過程，使你完全有信心它能在無人值守的情況下工作。

構建映象不一定是複雜的任務。你可以使用 現有的容器映象 作為基礎，用一個簡單的 Docker 檔案對其進行調整。另外，你也可以使用 Buildah 從頭開始構建你自己的映象。

在某種程度上，構建容器的過程與實際重構程式碼一樣，都是開發的一部分。容器的構建是為了獲取、組裝和執行你的應用程式，所以這個過程必須是自動化的、健壯的。建立一個好的映象，你就為你的應用程式建立了一個堅實可靠的基礎。

如果你是容器的新手，不要被術語所嚇倒。容器只是另一種環境。容器化開發的感知約束實際上可以幫助你專注於你的應用程式，並更好地瞭解它是如何執行的、它需要什麼才能可靠地執行，以及當出錯時有哪些潛在的風險。相反，這導致系統管理員在安裝和執行你的應用程式時受到的限制要少得多，因為從本質上講，容器是一個受控的環境。仔細審查你的程式碼，瞭解你的應用程式需要什麼，並相應地重構它。