在 Proxmox 上執行 Docker，免除網路困擾
Docker 本身很簡單，難的是網路。容器藏在 NAT 後方，嘗試 macvlan 時主機反而無法連線到自己的容器，從路由器取得 IP 本身就成了一項專案。Atlas 以 Atlas Link 解開這個結：每個容器都像真實裝置一樣存在於區域網路中。此外還有精選 Docker 應用程式庫：選擇、一鍵安裝、立即上線。
熟悉的困擾
NAT 的黑暗：容器在執行，卻在網路上看不見。每項服務都要透過連接埠轉送才能連線；衝突只能手動處理。
macvlan 陷阱：一旦想給容器真實 IP，主機就無法連線到自己的容器。論壇上充斥著這個問題。
DHCP 不相容：從路由器取得 IP 並不是 Docker 的原生行為。重新啟動後位址會漂移，也沒有 DNS 名稱；接著就開始猜這項服務到底在哪個 IP 上。
Atlas Link：每個容器都是真實的區域網路裝置
Atlas Link 讓容器成為區域網路中自然的一部分：
來自路由器的真實 DHCP IP
每個容器都以自己的 MAC 位址連上網路；IP 由本地路由器配發，並與其他裝置一樣出現在裝置清單中。
以名稱存取：服務名稱.local
每個容器都透過 mDNS 廣播自己的名稱：jellyfin.local、pihole.local。不必再背 IP。
主機隔離問題已解決
傳統 macvlan 中主機無法連線到自身容器的陷阱，在 Atlas Link 中並不存在；主機能與自己的容器正常通訊。
重新啟動後身分不變
即使容器重新啟動，網路身分也會保留；Atlas 會同步處理位址漂移。
精選 Docker 應用程式庫
不必從頭撰寫 compose：精選的應用程式一鍵安裝，透過 Atlas Link 立即上線：
每個應用程式都經過審閱並固定版本；不會有意外的映像檔變更。
安裝前提供資源摘要：需要多少 RAM、多少磁碟空間、使用哪個網路身分。確認後即安裝。
安裝前會建立還原點；若不滿意，可不留痕跡地回復。
自有的 compose 檔案同樣是一等公民：匯入後連接 Atlas Link，即可享有相同的便利。
VM 還是 LXC？
在 Proxmox 上執行 Docker 的乾淨做法是完整的 VM：擁有自己的核心、完整隔離，也是官方支援的方式。在 LXC 中執行 Docker 雖然可行，但巢狀隔離會變弱。Atlas 從安裝開始就管理 Docker 主機；它會像其他一切一樣出現在地圖上。
常見問題
- 容器真的會從路由器取得 IP 嗎？
- 是的。Atlas Link 讓容器以自己的 MAC 位址連上網路；IP 由本地 DHCP 伺服器配發，並出現在路由器的裝置清單中。也可以在路由器上設定固定配發。
- macvlan 中主機無法連線到容器的問題，在這裡也存在嗎？
- 不存在。Atlas Link 在橋接層解決了這種隔離；主機與容器可以正常互相看見。這是傳統 macvlan 設定中最廣為人知的困擾，而 Atlas Link 正是為此而生。
- 可以用名稱存取服務嗎？
- 可以。每個容器都透過 mDNS 廣播自己的名稱；網路上的裝置可用 jellyfin.local 這類位址連線。不必背 IP，也不必手動建立 DNS 記錄。
- 在 Proxmox 上，Docker 應該放在 VM 還是 LXC 中執行？
- 完整的 VM。擁有自己的核心與完整隔離，這是官方支援的方式；在 LXC 中執行 Docker 會削弱巢狀隔離。Atlas 從安裝開始就管理 Docker 主機 VM。
- 還需要 Portainer 這類工具嗎？
- 由於應用程式庫、生命週期與網路身分都在 Atlas 中，大多數情況下不再需要。若有需要，也可以在旁執行 Portainer；兩者不會衝突。
- 可以使用自有的 compose 檔案嗎？
- 可以。既有的 compose 檔案可以直接匯入；Atlas Link 會加上網路身分與 .local 名稱，執行起來與應用程式庫中的應用程式一樣便利。
相關條目
- 讓容器在網路上擁有自己的位址：得到什麼，付出什麼 容器可以用自己的位址發布，而不必透過連接埠號碼。好處是真的，代價也是真的，而代價通常要等建置完成後才會發現。
- 容器自己變了：latest 標籤實際上承諾了什麼 什麼都沒更新，容器的行為卻不一樣了。這不是故障：latest 不是版本，而是一個指標。真正的問題不在於拿到最新版，而在於能不能回去。
- Docker 在 Proxmox 上該放在哪裡：擺放位置的決定與 compose 陷阱 容器放在哪裡不是品味問題，而是爆炸半徑的問題。compose 檔案看起來像設定，實際上卻是一支要執行的程式。