現在我正在設置一個基於碼頭工人圖像的部署應用程序。碼頭工人和碼頭工人中的碼頭工人組成塊無端口的一個端口
我用gitlab詞來：
- 測試各種服務
- 構建每個服務
- Dockerize每幅圖像（創建搬運工容器）
- 運行集成測試（啓動搬運工撰寫啓動所有服務在特殊端口上運行集成測試）
- 停止產品圖像並運行新圖像
我爲每個服務都做了這個，但是我遇到了一個問題。
當我開始我的碼頭集裝箱進行集成測試時，它是在gitlab ci任務中設置的。對於每個任務使用基於docker的runner。我也安裝我的主機碼頭套接字，以便能夠在碼頭工人中使用碼頭工人。
所以我的gradle docker鏡像是由gitlab runner啓動的。然後docker將被安裝，所有的圖片將使用docker撰寫。
一個微服務監聽端口10004.在泊塢窗撰寫文件中有一個11004：10004端口映射。
我的集成測試嘗試連接到端口11004.但現在不起作用。
當我連接到運行泊塢窗圖像進行合成，而它試圖通過手動調用
wget ip: port
我剛剛得到的消息連接並等待響應執行集成測試，然後我不能做到這一點。我的測試可以連接成功。我的服務不記錄有關新連接的任何消息。
當我在我的主機外殼內執行這個wget命令然後它工作。
這是一個公共ip，在我的容器中，我也可以使用telnet和wget連接到其他端口。當我嘗試從泊塢窗實例中的泊塢窗連接時，只有一個服務的一個端口被破壞。
當我不使用docker撰寫時，它的工作原理。 Docker撰寫似乎設置了一個特殊的默認網絡，它做了一些奇怪的事情。
設置網絡到主機也工作...
所以有沒有人也做出這樣的體驗使用泊塢窗組成是什麼時候？
同樣的裝置作品在碼頭工人的Mac完美無瑕，但我的服務器上的Debian 8
運行我的解決方案，現在是使用shell亞軍，以避免碼頭工人碼頭工人的問題。它也在那裏工作。
因此碼頭工人與碼頭工人組合的碼頭似乎有一個醜陋的錯誤。
我正在寫作，而我坐在地鐵裏，但我希望描述我的問題也足以談論經驗。我認爲我們不需要一些源代碼來查找錯誤的配置，因爲它在docker和Mac上無需docker即可運行。