Go程式到底需不需要docker？

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

我是Go的粉絲，而且我也對容器感興趣。容器可以使得代碼更容易部署也更容易擴充。 但並不是所有Go程式員都使用容器。 在本文中，我將探討一些真正應該考慮使用Go和容器的原因 - 然後我們來看一些容器根本不會增加任何好處的情況。

首先，我們要確保我們都在相同的起點上。

什麼是容器

對於使用這些容器的人來說，可能有許多不同的定義。對於許多人來說，儘管容器比Docker開源項目或Docker公司要久遠得多，“容器”一詞與Docker是同義字。如果您是容器的新使用者，Docker可能是您的最佳起點，其提供對開發人員友好的命令列支援，但依然還有其他可用的實現：

• Linux容器 - 容器實現，包括LXC和LXD

• 來自CoreOS的rkt-pod-native容器引擎

• runc - 按OCI規範運行容器

• Windows容器 - Windows Server容器和Hyper-V容器

容器是一種虛擬化技術 - 它們允許您隔離應用程式，使其認為自己在單獨物理機器中運行。在這個意義上，容器類似於虛擬機器，除了它使用主機作業系統而不是擁有自己的作業系統以外。

您可以從容器鏡像啟動容器，該容器會捆綁應用程式運行所需的所有內容，包括其所有運行時依賴關係。這些鏡像使分發程式更容易。

容器使你更容易分發代碼

由於依賴關係是容器鏡像的一部分，因此當您在開發機，測試或生產環境中運行它時，您將獲得完全相同的依賴關係。因為資料中心的機器和你的筆記本的環境差異導致的問題將不複存在。

但是Go的一個優勢就是將編譯成一個單獨的二進位可執行檔。您必須在構建時處理依賴關係，而沒有運行時依賴，也不需要管理庫。如果您曾經在Python，JavaScript，Ruby或Java中工作過，您會發現Go的這個特性是其優勢：您可以在Go編譯過程中得到單個可執行檔，它可以在你需要的機器上運行。您不需要確保目標機器具有正確的版本庫或執行環境。

呃，所以，如果你有一個二進位檔案，那麼在容器中打包二進位檔案的要點是什嗎？

答案是可能還有其他的東西你想打包在你的二進位檔案裡。如果您正在構建一個網站，或者您的程式附帶設定檔，則可能會將靜態檔案分開。您可以使用go-bindata或類似的方法將它們構建到可執行檔中。或者您可以使用包含一個包含二進位檔案及其靜態資源的容器鏡像。無論您如何放置該容器鏡像，它都具有程式運行所需的一切。

容器協助你部署代碼

讓我們假設你沒有任何靜態資源，只是一個二進位檔案。您構建該可執行檔，然後將其移動到需要啟動並執行電腦（您只需移動該檔案）。 Go使得交叉編譯變得容易，所以即使要運行代碼的目標機器與您正在構建的代碼不同，也沒什麼大不了的。您需要做的只是在運行go構建時指定目標機器的體繫結構和作業系統。

在許多傳統部署中，您將確切知道哪個（虛擬）機器將運行哪個可執行檔。您可能擁有多個主機（例如為了高可用性），但是現在我們知道為目標機器構建容器是很容易的事情，而將Go二進位檔案部署到機器上並非是高深莫測的事情。

但是現代部署方式是運行一組機器，並使用諸如Kubernetes，ECS或Docker Swarm之類的協調者將容器放置在叢集中的某個位置。

容器對此非常有用，因為鏡像作為協調執行標準“部署單位”。管理員通過給它一個容器鏡像的標識符告訴機器運行什麼代碼？如果機器還沒有該鏡像的副本，它可以從容器登錄中擷取它。

當然也可以運行一個流程來部署沒有打包在容器鏡像中的代碼。但是通過使用容器，您正在利用廣泛使用並語言無關的部署方法，這種方法在行業中越來越多地被使用。即使你的公司今天是一個純粹的Go語言棧，通過使用容器，您將有一個通用的機制來部署不同的程式碼群組件。不管它們可能使用哪種語言，因此避免語言鎖定。

當我說“部署代碼的現代方法”時，您可能會非常正常地認為“無伺服器”架構？無伺服器架構就是在容器內運行某個可執行函數。今天部署到無伺服器看起來有很大不同（跟其他方式比），但我不會驚訝地看待這些術語 - 在某些環境中，您可以用Docker容器鏡像的形式部署無服務函數（不僅僅是它具有全部依賴關係）。

容器限制代碼可以訪問的資源

當您在Linux機器上運行Go（或任何其他）可執行檔時，您將啟動一個進程。如果您在Linux容器中執行代碼，您也將以幾乎完全相同的方式啟動一個進程。該進程實際上認為它運行在單獨的機器上，並且具有所有的資源許可權。

在容器內可以限制程式許可權。虛擬機器在同一硬體上運行多個不同應用程式具有許多相同的優點。例如，容器化進程無法訪問其容器外的檔案或裝置，除非您明確允許它可以訪問，因此它不能影響這些檔案或裝置（由於錯誤等）。它可能會認為可以使用所有CPU來進行CPU密集型的操作，但系統可能會限制其可以使用CPU的能力，以便其他應用程式和服務可以繼續運行。

資源限制是通過使用命名空間和cgroups建立的。這些術語意味著什麼是另一個時代的話題，但是人們告訴我，他們發現我在英國做的這個演講是有協助的。

如果要限制可執行檔並只訪問有限的資源集合，容器會為您提供一個整潔，友好和可重複的方式。

可以用其他方式為可執行檔建立相同的限制，但是使用容器會更容易。例如，傳統的系統管理員已經做了大量的工作，為檔案，裝置和網路連接埠等設定許可權。在容器的世界中，開發人員很容易表達他們的意圖，即代碼應該能夠使用某些連接埠或卷（而不是其他連接埠），並且預設情況下，容器內的所有內容都對於容器是私人的。您需要確保您的Dockerfiles遵循最佳安全做法，而每次Team Dev部署新的應用程式或服務時，都不需要定製操作來擷取使用權限設定。

容器協助你在本地測試其他組件

許多應用程式需要訪問其他組件，如資料庫或排隊服務（或其他無限的）。 當您想在本地運行程式進行測試時，您還需要安裝這些組件。

但是如果不同應用程式需要不同版本的組件怎麼辦？ 或者如果不同項目的配置有所不同？ 例如，如果您是開發人員，您可以輕鬆地使用不同版本（例如Postgres）運行兩個用戶端。 可以在膝上型電腦上運行多個副本，但可能會很痛苦（您必須確保使用正確的版本）。

如果您使用所需服務的docker版本，那麼生活可以簡單得多。 您可以為每個項目設定一個docker-compose檔案，以使用正確配置啟動正確的組件集。

容器能為你做什麼

總之，docker容易：

• 將代碼分發到可以在任何地方啟動並執行程式包中

• 通過一個協調者部署您的軟體

• 限制您（或其他人的）代碼可以在主機上使用的資源

• 在本地運行和測試您的軟體（包括所需的所有服務）

如果您是Go開發人員從事“後端”開發或將代碼部署在雲端的系統軟體，這些都是可能使用容器的原因。 但是如果那些不適用於你，你是否應該使docker部署Go代碼？

什麼時候不該使用容器

Docker有一個口號：“Build, Ship and Run Any App, Anywhere”。Go已經有一些內建的屬性支援這一點。正如我前面提到的，比如交叉編譯和產生單個沒有依賴的可執行檔。除非您使用可執行檔打包其他檔案（或新外掛程式），否則除非“運行”是指“通過編排器進行部署”，容器不能提供便捷。

也許你是一個Go開發人員，並不必擔心將代碼部署到一組機器上。如果你建立一個獨立的案頭或行動裝置 App程式作為下載分發奇，那麼使用容器不會增加任何好處，反而會增加你的工作流程和構建過程的不必要的複雜性。

同樣，如果我正在編寫一個獨立的程式（我只打算在本地運行，也許是一個實驗或示範，或者一個不需要與其他組件互動的小型公用程式），我就不會使用容器。和往常一樣，使用正確的工具作業，如果不會增加價值，就不要使用容器。

有沒有使用容器的其他原因？我很想聽聽你的經曆。