是否還有理由將 Consul 與現代（“集成”）Docker Swarm 一起使用？
我過去做過一點 Docker Swarm，它非常簡單——在一個節點上創建一個 Swarm Manager，在另外兩個節點上創建 Swarm Workers，堅持使用一個 Manager。我想了解更多關於 Swarm 的資訊，因此我正在關注 Pluralsight 上 Nigel Poulton 的影片系列“Docker Swarm：本地 Docker 集群”。
然而，這些影片比我兩年前的 Swarm 體驗要復雜得多，可能是因為它們執行在舊（“獨立”）版本的 Swarm 上。我想問一個澄清的問題，看看我現在學習的材料是否過於過時而不值得。（我將在下面描述影片課程的內容，因此無需熟悉即可回答問題）。
這個影片系列，現在已經四歲了，展示瞭如何：
- 安裝一個高可用的Discovery Service（支持Consul、Etcd和ZooKeeper，作者選擇Consul）。它使用progrium/consul映像，截至今天已經五年沒有更新了
- 在 Consul 伺服器上設置三個 Swarm Manager 節點
- 設置三個 Swarm Worker 節點，同時安裝 Consul 客戶端
作者承認這一切都相當複雜，並暗示在拍攝影片時，核心 Docker 將來可能會簡化這些東西。他說（建構您的 Swarm 集群 -> 安裝 HA 發現服務 -> 5:39）：
我什至會放出一個狂野的平底船，在某些時候，Swarm 甚至可能不需要我們做任何這種發現後端手工製作。只是因為這有點痛苦，如果我知道 Docker 的人的一件事，那就是他們全心全意為我們提供這種流暢、輕鬆的 Docker 體驗，而這部分並不是此時此刻。
如果我沒看錯的話，這個功能似乎就是實際發生的事情。從手冊：
您正在查看舊版獨立 Swarm 的文件。這些主題描述了獨立的 Docker Swarm。在 Docker 1.12 及更高版本中，Swarm 模式與 Docker Engine 集成。大多數使用者應該使用集成的 Swarm 模式。
誠然，我之前使用 Swarm 的經驗只使用了一個 Manager，但據我了解，只需使用
docker swarm join-token.那麼對於我的問題：Docker Swarm 的這一特性演變讓我想知道 Consul 是否為管理 Swarm 本身提供了任何價值。我可以做嗎？我是不是該？它是否提供了比集成 raft 共識系統更多的功能？這種學習材料現在有害嗎？
（旁白：我看過這個作者的幾個影片，它們很棒——如果這個已經過時了，那是他無法控制的。如果材料需要重新拍攝，那就是課程/平台需要安排的業主）。
Docker Swarm 有兩種變體。可以使用像 Consul 這樣的外部鍵/值儲存的 Classic/Legacy 版本。這不太可能在未來收到任何更新，並且最近將 repo 重命名為“classicswarm”以幫助減少一些混亂。
集成版本是基於 swarmkit 項目的 Swarm Mode。這不需要任何外部鍵/值儲存，並且當您啟用 Swarm 模式時，嘗試在 docker 引擎中為覆蓋網路配置一個將失敗，因為它使用自己的基於 raft 的解決方案在內部控制鍵/值數據庫。
因此，沒有必要使用 Consul，任何沒有開始的指南都
docker swarm init應該被忽略為過時的。