探討一下，docker/compose 中關於 link 的設計怎麼樣？

01-27

compose中，對於link的處理是這樣的（以 A -&> B 為例）——

A的hosts中寫入B的地址，便於地址訪問

在A中設定B的環境變數，為了避免名字衝突，添加前綴 B_ENV_

根據 B 容器對應鏡像的 EXPOSE 指令，在A中添加一組 ADDR、PORT 環境變數

在A中添加一個環境變數指明B的容器全名稱，類似這樣： /&_A_run_1/B

但是試用時速雲的時候發現不兼容compose的做法，溝通後的回答是這樣的——

```
我們的確實跟docker
compose不一樣，不過一個服務的非介面信息，另外一個服務也需要拿到，不知道這個應用場景是什麼？這種環境變數應該是那個服務獨享吧。在
Kubernetes裡面沒有docker 的 --link
的概念，兩個關係緊密的容器可以放到一個Pod裡面，通過localhost和共享存儲進行通信。

```
這樣就變成了 docker compose 和 k8s 的設計取捨問題，哪個設計更合理呢？

compose 是面向開發者自己的小環境的，允許方便的組合幾個 container 做一些 ad-hoc 的事情。不管是從作法（指明容器名字，添加環境變數）還是設計的基礎（知道要運行幾個 container，每個 container 都是一對一的存在）都是完全 non-scalable 的。

何況「修改 A 的 hosts 文件」這種事情，一看就知道是專門為了「懶得設置一個服務發現機制」而不得已為之的 hack。

kubernetes 是面向 PaaS 環境的，解決的是如何可靠、可管理的維護大量的 container，所以設計目的和思路是完全不同的：）而去 Pod 解決的問題更接近於「我這幾個 container 其實應該是一個 container 但我不想重新打包了你幫我搞定好了」。

還是動態配置／服務發現協議是王道啊。etcd 也好，mDNS 也好，允許 container / app 公布自己提供的服務、尋找自己需要的服務並進行自動／手動連接。這不一定要依賴託管平台的環境，把類似 docker-compose 的配置信息，用 centrally managed puppet 自動部署到每個 container 里去（代替 docker-compose）都可以最低限度的做到。

link的設計太low。

1. A-&>B，好，把A的host寫入B，那如果A掛了呢？好。又啟動了一個新的A容器。。。B如何感知到新的A的hostname並且更新自己的hosts文件？

2. 上述只是單向依賴，多重多向依賴的時候，link處理我看看？大規模集群的時候互相依賴link處理我看看？要被煩死了吧。