摘要：這相當于在原始安裝程序中調整文件。警告我并沒有告訴這件事，因為這可能會嚇到他或任何其他專家。在創建應用商店條目的過程中，還有兩個問題需要解決變量需要設置為確切值，這樣用戶就可以通過它連接到該實例。

Harbor Registry是VMware公司的Docker鏡像管理產品。相較于其他鏡像倉庫，Harbor提供身份管理功能，安全性更高，支持單個主機上的多個registry，這些功能正是很多企業用戶需要的。

在Rancher容器管理平臺之上，VMware Harbor可以被添加為Rancher應用商店（Catalog）中的一個條目。本文將展示如何將Harbor在線安裝程序docker化，然后rancher化，從而在Docker主機的分布式集群上安裝Harbor。

本文作者MASSIMO是VMware云原生應用程序事業部的云架構師。

為了進一步了解Docker容器和它們的生態系統，我在過去幾個月里一直在關注Rancher（開源容器管理平臺）。

我最感興趣的是Rancher的可擴展的應用商店（Catalog）和基礎設施服務： Library為官方應用商店目錄（由Rancher維護和構建），還有一個叫做“社區應用商店”（由Rancher維護，但由Rancher社區建立和支持），此外，用戶還可以添加私有應用商店目錄（你可以添加自己的私有目錄條目并且自己進行維護）。

雖然Rancher支持用戶連接Cloud Registry，但是在社區目錄中只有一個 Registry（Convoy Registry）可以進行部署和管理。這會是添加VMware Harbor為私有目錄項選項的好機會，如下圖所示：

你應該考慮所有你了解到的情況，從字面上說，在當前的形態下，能否把一個想法照搬到生產目的中去。

在我們深入討論這個問題之前，我想要感謝Rancher的Raul Sanchez（耐心地）為我答疑解惑（并幫我修復了一些錯誤的yaml）。如果沒有他的幫助，我想這篇blog會短很多。當然了，因為大家應該都會這樣吧，所以我還要感謝我的妻子和我的狗（雖然我沒有狗）。

首先，我需要先完成一定數量的任務，以完成初始目標。一般來說，一個任務都是依賴于另一個任務的。

如果你想要創建Rancher應用商店條目，就要從應用程序定義文件（使用默認的Cattle調度程序時的標準Docker Compose文件）和Rancher Compose文件上實例化你的應用程序。shell腳本或類似的東西并不能成為Rancher應用商店條目的一部分。

你是不是在研究如何（通過文檔化的“在線安裝程序”）在Docker主機上安裝Harbor? 它與Rancher應用商店模型并不真正兼容。你可以參考下面的步驟：

安裝Harbor時，必須先下載Harbor在線tar.gz安裝程序文件，并在harbor.cfg文件中設置你的配置設置，然后運行”準備”腳本。這個腳本會輸入harbor.cfg文件，然后創建配置文件和環境變量文件。最后，運行Docker Compose文件以傳遞配置文件和環境變量文件作為Docker Compose的卷和指令（要注意一些過程是發生在主安裝腳本下的，并且是在屏幕下發生的）。這才是標準的在線安裝程序。實際上，Docker Compose文件抓取了Docker Hub的Docker鏡像，而且根據配置輸入實例化了Harbor。

最后，將開始的簡單”PoC”項目分成了三個”子項目”:

將Harbor在線安裝程序docker化，這樣“準備”過程就能作為Docker Compose的一部分，并將輸入的參數作為變量傳遞到Docker Compose中去（而不是手動編輯cfg文件，然后執行整個準備circus）。

將已經Docker化Harbor在線安裝程序Rancher化，并且創建一個Rancher私有應用商店以模擬典型的單主機Harbor設置。

作為獎勵：將docker化的Harbor在線安裝程序rancher化，并創建一個Rancher私有應用商店的應用模版，讓我們可以在Docker主機的分布式集群上安裝Harbor。

要注意的是，我需要創建一個docker化的Harbor在線安裝程序來匹配Rancher的目錄模型，而且當你無法采用手動和交互式的方式、只能自動stand up Harbor時，你也可以用這個在線安裝程序（Rancher是這些用戶實例之一）。

在接下來的幾節中，我會詳細介紹為了實施這些子項目我所做的一些工作。

在我寫這篇文章的時候，Harbor 0.5.0已經可以使用OVA或通過安裝程序安裝。安裝程序可以在線（鏡像從Docker Hub動態提取）或離線（鏡像是安裝程序的一部分并會在本地加載）。

我們接下來要關注的是在線安裝程序。

正如我們已經提到的，一旦你下載了在線安裝程序，就要調整在安裝包模板中附帶的harbor.cfg文件的參數以“準備”你的Harbor安裝。

然后將生成的配置集輸入到Docker Compose文件中（通過映射為“卷”的本地目錄和通過“env_file”指令）。

如果不通過“準備”過程，直接將Harbor設置參數傳遞給Docker Compose文件，這樣做是不是會更容易或更好？

進入 Harbor-setupwrapper。

Harbor-setupwrapper是一個包含新docker鏡像的Harbor安裝包，并（或多或少）在docker容器中實現“準備”進程。而Harbor配置參數作為環境變量輸入到容器中。最后，在容器中運行一個腳本，啟動準備例程（這是所有容器本身就包含的），當然這一步也是很重要的。

這個鏡像的Dockerfile和啟動準備例程的腳本都是值得研究的問題。

其實，什么是harbor-setupwrapper.sh和什么是以install.sh為標準的Harbor在線安裝程序，這兩個問題是非常相似的。

我們現在有一個新的Docker Compose文件，這個文件很大程度上是建立在原始Docker Compose文件的基礎上的。此外，這個原始Docker Compose文件是官方在線安裝程序附帶的。現在，你可以通過”組合”這個新的Docker Compose文件傳遞你在harbor.cfg文件中調整過的參數了。

如下圖所示:

一定要注意這只是一個PoC!

我只測試了HARBORHOSTNAME和HARBOR ADMIN_PASSWORD變量。其他變量應該是可以運行的，但我并沒有進行測試

肯定會有特殊情況發生。例如，如果你選擇使用安全連接（https），而我還沒有找到創建證書的方法。這個時候就需要實現harbor-setupwrapper.sh中的附加邏輯（提示：啟用https可能會發生一些奇怪的事情）

采用原始的在線安裝程序就意味著要在單個Docker主機上運行。我會在同樣的模型和相同的前提條件下，實現這個新的安裝機制

由于以上原因，我沒有試過在分布式Swarm集群上部署這個compose文件。另外，雖然說“legacySwarm”已轉換成了“Swarm模式”，但Docker Compose和后者似乎并不兼容，而我又不想花太多的時間在前者上，于是我選擇不在Swarm環境中測試它

也許會有更多的警告，只是我沒有想過（但肯定是可能存在的！）

將wrapper（由harbor-setupwrapper.sh腳本生成）中的配置文件提供給應用程序容器并不難。我已經實現了“volumes_from”指令，所以應用程序容器可以直接從wrapper容器中獲得相關的配置文件。

找出將ENVIRONMENT變量（在wrapper容器上的各種文件）傳遞到應用程序容器上的方法具有一定的難度。而且我無法在compose中運行”env_file”指令，因為指令指向的是運行compose的系統中可見的文件（在我使用時，這些文件在wrapper容器中）。長話短說，我改變了應用程序容器的入口，指向了一個腳本，首先要加載這些環境變量，然后啟動原始腳本或原始入口的命令。如果你愿意的話，你可以檢查harbor-setupwrapper GitHub repo中所有的entrypoint * .sh文件。

如果你打算按照這個方法做，并且用這個新的機制設置Harbor的話，那你就需要克隆harbor-setupwrapper repo和”up”你在harbor-setupwrapper目錄中發現的Docker Compose文件。但是，在啟動它之前，先要導出HARBORHOSTNAM和HARBOR_ADMIN_PASSWORD變量。這相當于在原始安裝程序中調整harbor.cfg文件。如果你忘記導出這些變量，Docker Compose會顯示：

至少要對HARBORHOSTNAME變量進行設置，把HARBORHOSTNAME變量設置為將要安裝它的主機的IP地址或FQDN（否則設置將不起作用，我會在后面解釋原因）。如果你沒有對HARBOR_ADMIN_PASSWORD變量進行設置的話，那你就需要用默認的Harbor密碼(Harbor12345)。

你要做的是:

注:如果你打算在同一個主機上反復實施Harbor實例，并打算從頭開始的話，那么一定要刪除主機上的/ data目錄（因為它會保存實例狀態，如果新實例找到了這個目錄，那么它將接收之前的實例狀態）。

我們可以通過“compose up”來docker化Harbor安裝程序。現在我們可以把注意力放在第二個子項目了。換句話說就是，創建Rancher應用商店條目的結構。

我覺得這應該是比較容易的。畢竟，我們之前討論過關于重新使用新docker-compose.yml文件的問題。

我了解到比較困難的都是細節的問題，特別是在容器的文章里，為了“修復”一個特定問題而進行的調整通常意味著在其他地方打開一些worms。

我以后會盡可能寫一些你們需要的或是你們想要了解的東西，以便于詳細了解這個安裝包，我把我的經歷分享給你們，是希望可以在其他情況下幫到你們（我會把我的發現記錄下來，不然我恐怕會在2周后忘記）。

首先，在Rancher中，在sidekick中你只能做到“volume_from”。最開始的時候，我是將“io.rancher.sidekicks：harbor-setupwrapper”添加到compose中的每個容器去。然而，我突然發現，這會為每個容器創建一個harbor-setupwrapper以輔助容器，這是一個sidekick。 雖然看起來都已經準備就緒，但我最后發現在一個單一的Harbor部署下運行多個腳本的實例可能會導致各種配置不一致（例如用不可信的密鑰簽名的令牌等）。

我需要改變策略，變成只有一個harbor-setupwrapper容器的實例（在一個過程中將會一致地生成所有的配置文件），我已經在主容器與所有其他應用程序容器中實現了它。實際上，我只是添加了“io.rancher.sidekicks：registry，ui，jobservice，mysql，proxy”作為harbor-setupwrapper容器的標簽。 （警告：我并沒有告訴Raul這件事，因為這可能會嚇到他或任何其他Rancher專家。 但是這成功了，所以請原諒我。）

我們通過開放一個問題來解決另一個問題。sidekick容器的名稱解析并不會真的像你預想的那樣運作，所以我只能找出其它解決方法（如果你感興趣的話，你可以在這里了解問題并且修復它：https://forums.rancher.com/t/...）。

在創建Rancher應用商店條目的過程中，還有兩個問題需要解決:

“harborhostname”變量需要設置為確切值，這樣用戶就可以通過它連接到該Harbor實例。

所有的Harbor容器都只能部署在單個主機上，這個主機可能是許多主機（Cattle）集群中的一個。

我可能會讓Rancher專家再一次感到害怕，為了給主機上的所有容器貼上“harbor-host = true”的標簽，我已經配置Docker Compose文件。

這樣我就能確保所有容器都部署在同一臺主機上（更重要的是，對某一個主機有一定程度的控制權）。 而且，因為我知道我的容器將要到達哪個主機，所以我可以明智地選擇變量“harborhostname”。 它可以是主機IP地址或主機FQDN。

最后，Docker Compose文件將會發布主機上代理容器的端口80和443（顯然在在該主機上這些端口是免費的，不然部署會失效）。也許這不是一個最佳實踐，但可以解決一些基本的或是較為容易的問題。

注意：因為狀態會保存在主機的/ data目錄中，所以如果你是為了測試而啟動和關閉Harbor實例，那你要將狀態保存在多個部署中。這和你運行一個真正的云本地應用程序還是有很大差距的，但它能說明Harbor（0.5.0）是怎么構建的，我只是忠于單個主機上的Rancherization方案的原本的操作模式。

下圖說明了單個主機部署中各個組件間的詳細信息和關系:

下圖是我運行過程中的實際部署：

用于單主機部署的Rancher的Harbor私有應用商店應用模版的當前狀態如下:

它只適用于Cattle調度程序

構建Swarm和K8s的Harbor目錄的版本和Cattle的版本之間應該是沒什么關系的

這個應用模版有上述docker化在線安裝程序的所有限制（例如，它不支持https等）

在Docker主機上推送或拉取鏡像時，要在Docker守護進程上設置“-insecure-registry”標志（因為我們只能通過http訪問啟動Harbor）

有一個主機必須要有docker-compose的“harbor-host = true”標簽，這樣才能夠正常工作和調度容器

具有“harbor-host = true”標簽的主機上必須要有可用的端口80和443

你可以在我的Rancher 應用商店的擴展庫中找到這個子項目的可交付項：https://github.com/mreferre/r...。

這是操作分布式應用程序中非常有挑戰性的部分，也是很有趣有用的部分。

雖然Harbor是一個容器化應用程序，但因為某些原因，它并不是應用云本地應用程序操作最佳實踐的理想選擇。它不遵守“十二因子應用（The Twelve-Factor App）”的方法論。

首先，在6個容器都在“眾所周知的”單個主機上運行的前提下，Harbor安裝程序已經建立了。這里有一些例子強調了部分挑戰。我們可能已經提到了其中一些:

Harbor軟件包附帶了一個嵌入式的syslog服務器，Docker守護進程會和這個服務器進行會話/日志。如果你查看了原始的Docker Compose文件，你會發現假定syslog在所有其他容器的同一主機上運行，那么所有應用程序容器都會記錄到0.0.1

您必須輸入（作為設置參數）確切的Harbor主機名，以便于用戶連接注冊表服務器。理想情況下，在云原生的環境中，應用程序應該能夠使用與其關聯的任何給定的IP / FQDN。最后，應該有一個選項來設置（后設置）應用程序將使用的正確的IP / FQDN端點。對于Harbor 0.5.0，你要知道（預先）在啟動設置之前的IP / FQDN是什么（使得一些事在動態，自服務和分布式環境中更加難以操作）。也就是說，如果你的harbor服務以“service123.mycompany.com”這個形式暴露在用戶面前，你就必須在部署時輸入該字符串作為FQDN（甚至可能不知道容器的哪些主機去部署）

Harbor在已知的單個主機上運行是假設的一部分，產品將自己的狀態保存在其部署到的主機的本地目錄上。這是通過容器配置中不同的目錄映射完成的
這個子項目的目標是讓Harbor在一個Cattle集群上運行，而不是在一個已知的主機上運行。

為此，日志圖像在集群的每個節點上需要實例化（要求：每個節點必須具有標簽“harbor-log = true”）。一個更好的解決方案是有一個多帶帶的syslog服務器指向（從而完全擺脫Docker Compose中的日志服務）。

此外，由于我們不知道代理服務器將要到達哪個主機（在這種情況下，我們希望在服務發現方面實現低接觸體驗），我們通過利用Traefik實現了Harbor分布式模型。如果你熟悉Docker的話，就會發現Traefik做的（有點）類似于Docker通過Swarm模式提供的“HTTP Routing Mesh”開箱即用體驗。要注意代理容器端口（80和443）不會暴露在主機上，Traefik是將服務暴露給外界的唯一方法（在這個特定的分布式實現中）。

總體想法是，你的DNS可以解析運行Traefik的IP，然后Traefik會“自動”將你在Harbor設置中輸入的主機名添加到其配置。

存儲管理也是一個有趣的部分。在分布式環境中，你不能讓容器將數據存儲在任何給定時間點都能及時運行的服務器上。

如果容器在另一臺主機上重新啟動（由于失敗或升級），它需要訪問同一組數據。更不用說其他容器（可能在不同的主機上運行）需要訪問同一組數據。

為了解決這個問題，我選擇用Rancher提供的通用NFS服務，它靈活而方便，并且是有用的。因為它允許你預先配置所需的所有卷（在這種情況下，它們通過Harbor目錄條目重新實例化），或者你可以讓Docker Compose在實例化時自動創建（在這種情況下，當Harbor實例關閉時，它們會被刪除）。要注意的是，所有卷都映射到應用程序容器（除了不需要卷的日志和代理容器之外）。這里有很大的優化空間（因為不是所有的卷都需要映射到容器），但我暫時不會考慮這個問題。

因為在Docker Compose中沒有卷目錄映射（所有卷都命名為NFS共享上的卷），所以這會使得所有主機無狀態。

下圖顯示了分布式部署中各個組件間的詳細信息和關系:

此圖片顯示了實際操作中的部署:

Rancher用于分布式部署的Harbor私有應用商店條目的當前狀態如下:

它只適用于Cattle調度程序

構建Swarm和K8s的Harbor應用商店的版本和Cattle的版本之間應該是沒什么關系的

這個應用商店條目有上述docker化在線安裝程序的所有限制（例如，它不支持https等）

在Docker主機上拉/推圖像時，要在Docker守護進程上設置“-insecure-registry”標志（因為我們只能通過http訪問啟動Harbor）

集群上的所有主機必須要有docker-compose的“harbor-host = true”標簽，這樣才能夠正常工作和調度容器

Traefik服務（位于社區目錄中）需要啟動并運行才能從外部訪問Harbor。這已經暴露端口80（要注意Traefik默認值是8080）

NFS服務（位于庫目錄中）需要啟動，運行并正確配置連接到NFS共享。Docker Compose文件已經參數化，其他驅動程序中我只測試了”rancher-nfs”

你可以在我的Rancher私有應用商店目錄中找到這個子項目的可交付項：https://github.com/mreferre/r... 。

在這個項目中，我遇到了一些挑戰。我會介紹其中一些，把這些記錄下來主要是為了將來可以進行參考。

一些小東西有時會有一些大用處。有時它是一個級聯問題（即做A你需要完成B，但做B又需要完成C）。例如，Rancher sidekick要求能夠執行“volume_from”。這基本上打破了完全名稱解析（請參閱單主機部分了解更多信息，了解問題是什么）

容器出現“全綠色”并不代表著你的應用程序會啟動和（正常）運行。有時，容器開始確定并沒有錯誤，但我無法登錄到harbor（由于運行安裝wrapper的多個實例生成的證書不匹配）。有時，我可以登錄，但不能push鏡像。有時，我可以push鏡像，但它們不會在UI中顯示出來（因為sidekicks的名稱解析問題，注冊表容器無法解析ui容器名稱）

在分布式環境中調試容器很困難。有時候，我以為遇到了一個隨機問題，后來才發現是因為特定的容器在錯誤配置的主機上（隨機）調度了。如果找到了問題根源，解決這個問題很容易。但往往，事情難就難在找不到問題根源。

將應用程序包裝為在容器中運行（最重要的是編排部署）時，了解應用程序內部是至關重要的。在分布式場景中我將所有命名卷連接到所有容器的原因之一是因為我不能100％確定哪個容器從哪個卷讀取/寫入。此外，不知道應用程序會使其包裝困難（特別是當某些東西不能正常工作需要調試的時候）。總而言之，容器（和編排）更類似于你如何打包和運行應用程序與你如何管理基礎設施

雖然容器編排是關于自動化和可重復，但它也有點像“手工精靈藝術”。有時候（隨機）代理容器只會顯示nginx歡迎頁面（而不是Harbor用戶界面）。最后我通過重新啟動該容器（部署后）解決了這個問題。我認為這是某個啟動序列的原因。我嘗試用“depends_on”指令，使得代理容器開始“朝向結束”的組成，但這沒有成功。現在似乎是通過利用“external_links”指令（理論上應該不需要AFAIK）。總而言之，正確地協調容器的啟動仍然是工作進程中的一部分（從2014年開始）

管理基礎架構（和服務）以運行容器化的應用程序是很困難的。我運用一些簡單的服務，例如基本的Rancher NFS服務時，遇到了一些問題，我必須解決使用不同級別的軟件，不同的部署機制等等。從一個版本的基礎設施到另一個版本的基礎設施的升級也很關鍵

我遇到的另一個NFS問題是，當堆棧關閉時，卷不能在NFS共享上正確清除。在Rancher UI中，卷似乎已經不存在了，但是直接查看NFS共享，其中一些（一個隨機數）似乎以剩余的目錄的形式留下。我沒有深入研究這是為什么。

正如我所提到的，這只是一個粗略的整合，毫無疑問，它可以更完善一些。這主要是一次很好的學習經歷，未來可以進一步擴展，比如在Rancher Kubernetes內集成，啟用https協議等等。

在分布式系統中完成應用服務的動態配置也是這次實驗的挑戰之一，當然這不是很復雜，但通過這個過程可以讓你更好地了解如何解決這些問題。

從更高的層次看，將一個應用容器化并部署在分布式系統中，它有兩種方式：一是你的基礎服務就以Paas方式構建，所需要的服務資源（如調度、負載均衡、DNS解析等）向Paas申請，你可能需要深度改造你的應用；二是，選用Rancher這樣的平臺，利用它提供的特性，只需要編寫compose編排文件，就可以很輕易的實現需求。實際上Ranche也是更多得幫助你在第二種場景中快速實現你的需求，簡單易用的基礎設施服務助你快速實現應用容器化。