Docker容器之間的通信 - 通用技巧

Question

我正在開始學習docker（和一般的微型服務），並且我已經開始構建一個愚蠢的「hello world」類型的應用程序（1作爲.Net Core控制檯應用程序，另一個作爲ASP.NET Core Web應用程序）。

我的下一個里程碑是讓2個容器與海誓山盟溝通，只是來回發送某種簡單的消息。

通常使用哪些技術來實現容器之間的通信？

我最初的想法是爲容器的傳出和傳入消息設置一個隊列，因此它不需要關心自己發現並直接與另一個容器交談。

這是一種常見策略嗎？還是有更好的碼頭工作方式？

如果隊列是一個不錯的選擇，那麼人們通常與docker一起使用（記住它需要在Windows容器中運行並理想地使用C＃客戶端）？

我已經在碼頭集線器上看到了一個用於rabbitmq窗口的圖像，並且我聽說過很好的東西 - 以前從未使用過它（我永遠無法直接將它安裝在我的Windows機器上，但是使用碼頭工人在幾分鐘內獲得一個工作版本 - 得說我到目前爲止與碼頭工人真的很開心）。我接受建議。

我見過一些人爲他們的容器提供了安靜的apis，但這似乎要複雜得多，因爲您需要知道要與之通信的特定容器，並且接收容器需要以某種方式確認你有權與它溝通（我想你會有一個特殊的授權容器，可能是薄荷糖令牌）。

Answer 1

容器就是在孤立環境中運行的標準守護進程/服務。關於使容器通信沒有特別的規則。

通常，您只需將容器連接到相同的network，它們將充當連接到同一局域網的虛擬服務器，並通過標準網絡連接看到對方。

隊列共享數據的使用不是恕我直言的「容器」，而是微服務良好實踐。總之，您必須區分容器之間的低級網絡連接和服務之間的高級邏輯數據交換。

Answer 2

通常使用哪些技術來實現 容器之間的通信？

Docker有能力創建虛擬網絡。您可以將多個容器添加到同一網絡，並且每個容器可以使用其他容器的名稱直接與其他容器進行通信。容器名稱將充當DNS名稱，並將自動解析同一網絡中的容器。

關於隊列：

隊列或更普遍的短信techologies是一個非常適合微服務。消息傳遞允許異步通信，這對於可伸縮性非常有用。消息傳遞對於請求/響應類型的通信來說並不是非常合適，其中發送者期望來自接收者的直接響應。正如其名，他們是更好的用於發送消息。（想想發送電子郵件，你不會阻止等待回覆）

在另一方面，REST API的是採用同步通信的範疇。它們是公開用於請求/響應通信的API的最流行的方式。

一般來說，REST API比消息傳遞技術更容易實現。消息傳遞通信需要位於通信端點之間的消息傳遞代理（如Rabbitmq）。

總之，如果您的溝通是異步的，請使用rabbitmq。否則，如果您有請求/響應通信參數，則應用程序中會顯示休息apis。

最後，不管您選擇什麼，碼頭網絡都將允許您將所有東西粘合在一起。如果使用rabbitmq，則將其添加到網絡，並將消息發送到rabbitmq（容器名稱）主機。