遠程連接本地容器和其他容器上的Docker容器

Question

對於我們的開發調試簡單性和部署問題，我們計劃對我們擁有的服務進行容器化。例如。

我有服務，如A，B,C和D。其中A是我的開發代碼（經常更改），B，C和D是依賴服務。

目前B，C和D計劃遠程部署，因爲他們僅僅是依賴（泊塢容器） 我會想辦法調試/部署，使

• 我的服務A可在本地和它可以很容易地與遠程多克爾服務B，C，連接D

• 或者A可能以某種方式DEP借用到遠程集羣並且可以進行測試。

我認爲要推進註冊表，但每個開發人員推出自己的快照都無法與其他圖像共同關聯。

注：

• 我不想羣之類的話，但要保持它的簡單。

• 羣集通過Docker Machine進行管理。它可以被替換嗎？

• 這些服務由Docker Compose編織而成。

有關我如何駕駛的建議？另外首選的方法是通過Docker。

Answer 1

分享我的這個體驗的簡化版本。要考慮是否在遠程泊塢窗發動機運轉依賴（B，C和D）甚至是值得冒這個險，必須執行以下中的一個（通常）是真實的：

• 資源由不同的服務使用量不適合在單個開發人員計算機上運行。
• 初始化依賴服務的數據過於麻煩，因爲其大小或其他因素使其在本地運行時太繁瑣。
• 通過根據服務使用的數據引發隱私擔憂

什麼你可能使用遠程方式失去的是一個有點嚇人。

• 開發人員無法輕鬆控制正在運行的依賴服務的版本。如果這些服務是自定義的，這一點尤其重要，以便在問題被發現或修復時降級或升級版本。
• 在轉換到更新版本的第三方服務時，它也可能是一個問題，因爲並非所有的開發人員都可能在支持它的分支上工作。
• 此外，如果您不需要快速跳回舊版本的分支機構/版本來修復或發佈問題，然後將其集成/測試到當前分支，那麼當您最需要它時可能會非常沮喪（時間是問題！）

還有很多要添加到這些列表的其他要點，但這些對我們來說很重要。

我們結束了一個混合的方法。

開發人員將在本地爲大多數任務運行一切。我們削減了爲當地發展提供服務所需的數據，以便他們可以在幾分鐘內在當地啓動。使開發環境完全「脫機」是一個巨大的優勢。如果一箇中央系統發生故障，您的開發人員將迅速減少到在停機期間漫遊大樓的一羣殭屍。他們還有能力在火車上打開他們的筆記本電腦，並在需要時調試一些奇怪的問題，然後做出承諾，並讓CI系統咀嚼測試，以及在他們繼續個人生活的同時進行測試。

另外，我們啓動了一些運行依賴服務的docker引擎的虛擬機。這些（主要）live和dev名稱前綴（以及其他如果需要）幷包含來自現場環境的快照。如果需要，開發人員可以使用單獨的組合設置。當開發人員試圖確定由不良數據導致的問題或使用較大數據集嚴重縮小的代碼時，這可能很實用。

從未改變的是A將始終運行在開發人員計算機上。如果某人出於某種原因有其他需求，我們會啓動一個新的VM，其中包括碼頭引擎，一些數據快照和相關服務。這是一個完全自動化的流程，所以這需要一個完善的高效管道。如果我選擇開始個人設置，則主機名可以使用我的用戶名作爲前綴。

我想說的是，如果開發人員可以在本地運行所有東西，那麼可以將自己從大量工作中拯救出來並做到這一點。在幾分鐘內找到聰明的方式讓所有依賴的服務順利運行。

數據相關性和隱私問題

，因爲太多的忽略了這一部分，我將在這裏注入了這一點爲好。

既然GDPR和Privacy Shield最可能在2018年給隱私問題帶來更大的壓力（至少在你存儲有關歐盟公民的數據時），你的公司將不得不認真對待或者可能面臨鉅額罰款和/或客戶拋棄你。這增加了一些工作。

• 本地服務的所有圖像包含生成的數據或不能用於識別個體的實時數據的變換子集。
• 遠程dev和live主機還包含轉換後的數據以隱藏標識，但簡化了一些以大大加快此過程。
• 只有一小部分開發人員可以訪問實時系統，並且這些也是唯一允許使用實時數據運行自己的虛擬機的虛擬機（他們獲得該主機的唯一客戶機證書）。

開發人員每天都會隨便攜筆記本電腦出行，甚至將其帶回家。包含任何形式的個人信息的數據最終都不會在開發人員筆記本電腦上出現。

Answer 2

我同意格林美的回答，但只是爲了增加一些顏色，我想我會描述一下我們去年使用的系統的效果。基本上，我們儘量在開發機器上儘可能接近我們的產品環境。我們直接在實例上運行一些服務（mongo，haproxy，etcd），而其他一切都在Docker中運行。所以在開發機器上，除了Vagrant之外，我們也是這樣做的。實際上，我們所有的AWS環境基本上都與產品環境類似，只是加/減縮放/冗餘。所有一次性「牛」，可以輕鬆重建。

我們有自己的古怪的小碼頭編制系統，內部構建（pre-k8，pre-swarm），基本上採用了「應該運行的東西」的聲明性清單，並將其粘貼到etcd中。然後，在每個系統的docker上運行的代理程序（對於vagrant而言，只有一個）會檢查映像和配置簽名以查看實際運行的內容，以及是否缺少任何內容。 （如果有任何事情是不應該的，殺死它）。對於網絡路由，通過etcd的confd模板有一些令人恐懼但令人驚訝的haproxy操作，我不想再次觸摸:-)，它將請求路由到正確的碼頭後端，支持藍綠色部署。

對於開發工作，其全部完全相同。儘管如此，對於快速開發循環而言，您不需要隨時重建集裝箱，這很煩人。因此，在集羣清單中，我們有一個神奇的小標誌，您可以指定將一個服務標記爲「在主機上」。這通過相同的etcd/confd/haproxy的東西，但後端是你的開發系統！這裏最大的好處是你可以通過在prod中運行的完全相同的haproxy設置，將https路由到你的服務中。

這是一個有點老派，但我們愛 haproxy。 :-)

因此，基本上，努力盡可能地接近您本地系統上完全隔離的產品環境。哦，並努力刺激不成爲寵物。