在 2016 年做 DevOps 是一種什麼樣的體驗？

註：在 2016 年學 JavaScript 是一種什麼樣的體驗？ 是模仿 Circle.ci 的這篇文章 It』s The Future 寫的，也就是本文的原文。

嘿，老大讓我來找你聊聊，聽說你很懂 web 應用？

—是吧，我現在做分散式系統比較多。我剛參加了 ContainerCamp 和 Gluecon，下周又要去 Dockercon 了。行業的發展激動人心，讓一切都變得更簡單、更可靠。這就是未來！

酷！我現在想搭建一個簡單的 web 應用，就是用 Rails 做的增刪改查應用，打算部署到 Heroku 上。現在還應該這麼做嗎？

—噢，不。過時啦。Heroku 快掛了，沒人用它了。你現在應該用 Docker。這是未來。

哦，好吧。Docker 是啥？

—Docker 是一種新的容器化方案，和 LXC 很像，但也是一種打包格式、一個分發平台，以及可以非常容易搭建分散式系統的工具。

容器化……等等？什麼是 LXE？

—是 LXC，就像超級版 chroot！

cher-oot 是啥？

—好吧，是這樣的。Docker，或者說容器化，就是未來。它和虛擬化很像，但更快也更便宜。

噢，所以說像 Vagrant。

—不，Vagrant 過氣了。現在所有東西都要容器化，這是未來。

好吧，所以說我不需要知道任何和虛擬化有關的東西？

—不，你還是需要虛擬化，因為容器也不是完全安全。所以，如果你想要在多租戶環境(multi-tenant environmen)中運行什麼，就需要確保用戶無法跳出沙盒。

好吧，我有點搞糊塗了。回顧一下。也就是說有一種類似於虛擬化的東西，它叫容器，而我可以在 Heroku 上用它？

—唔，Heroku 對 docker 有一定的支持，但我已經說了 Heroku 已死。你應該在 CoreOS 上運行容器。

OK，CoreOS 是啥？

—這是個你可以和 Docker 一起使用的宿主操作系統(Host OS)。靠，你甚至都不需要 Docker，你可以用 rkt。

Rocket？（譯註：發音一樣）

-不是，rkt。

對啊，Rocket。

-不是，r-k-t。完全不是一碼事。這是另一種容器化格式，不像 Docker 一樣被捆綁在一起，它要更容易組合。

rkt 好嗎？

—當然好。可組合(Composability)是未來。

好吧，你怎麼用它？

—我不知道。可能也沒人用它吧。

攤手。你剛才提到了 CoreOS？

—是啊，CoreOS 是 Docker 的宿主操作系統。

宿主操作系統是啥？

-宿主操作系統運行所有容器。

運行我的容器？

—對，你得有東西來運行你的容器。比如你配置好一個 EC2 實例，把 CoreOS 放上面，然後運行 Docker 守護進程，再把 Docker 鏡像部署到上面。

這裡面哪個是容器？

—裡面提到的所有東西都是容器。你看，你寫好應用，再寫一個 Dockerfile，在本地構建鏡像，然後推送到 Docker host 上。

啊，就像 Heroku？

-不是 Heroku。我跟你說了，Heroku 已死。你現在可以用 Docker 來運行自己的雲。

什麼？

-嗯，非常簡單。搜一下 #gifee。

Gify？（譯註：發音一樣，這篇文章有意思 2016, the year of GIFEE）

— 『Google』s infrastructure for everyone else』的縮寫，意思是大家都可以用的谷歌基礎設施。你通過容器從中選擇一些工具，就有了和谷歌一樣的基礎設施。

那我可以只用谷歌的東西啊。

—6 個月內你還用不上它。

好吧，沒有人來託管這些東西嗎？我真的不想自己來託管。

—你可以用亞馬遜的 ECS，但你得寫 XML 這種東西。

OpenStack 呢？

-額。

額？

-額。

我真的不想自己託管。

-不是，這很簡單，你只要配置一個 Kubernetes 集群就可以了。

我需要一個集群？

-Kubernetes 集群。它會管理所有服務的部署。

我只有一個服務。

—什麼意思？你有一個應用，對吧，所以你至少會有 8 到 12 個服務。

什麼？不，只是一個應用。服務，什麼東西。只是一個應用。

—不是，看看微服務。微服務就是未來。我們現在都這麼做。把龐大的應用分解成服務，比如說 12 個。每個服務只做一件事。

似乎過頭了。

—這是保證可靠性的唯一途徑。假如你的驗證服務宕了……

驗證服務？我打算用以前一直在用的 gem。

—很好。用那個 gem，把它單獨做成一個項目，加上 RESTful API，然後再讓其他服務調用這些 API，優雅地處理錯誤等等。最後把它放到容器里，然後持續交付。

好吧，現在我有了十幾個無法管理的服務，接下來呢？

—我不是說了 Kubernetes 嘛，它可以指揮所有這些服務。

指揮？

—對，既然你有了這些服務，而它們又必須可靠，你就得有這些服務的多個備份。Kubernetes 能確保你有足夠的備份，而且分布在伺服器 fleet（艦隊）的多個 host 上，從而可以一直提供服務。

現在我需要一個 fleet 了？

—對，為了保證可靠性。不過 Kubernetes 會幫你管理。Kubernetes 肯定能行，因為它是谷歌出品，而且還是運行在 etcd 上。

etcd 是啥？

—是 RAFT 的一種實現。

RAFT 又是啥？

—就像 Paxos 一樣。

天，這個鏈條啥時候能到頭？我只是想發布一個應用。唉。靠。好吧，深呼吸。天啊。好吧，Paxos 是啥？

—Paxos 就像是上世紀 70 年代沒人懂或理解的那種分散式一致性協議。

很好，謝謝你告訴我這一點。Raft 又是什麼鬼？

—因為沒人懂 Paxos，於是 Diego……

哦，你認識他？

—不認識，他在 CoreOS 工作。不管怎樣，迪亞哥為了寫博士論文打造了 Raft，因為 Paxos 太難了。真是個聰明的傢伙。然後他寫了 etcd 來實現 Raft。Aphyr 總算沒說它是一坨屎。

Aphyr 是啥？

—Aphyr 就是那個寫了「Call Me Maybe」的傢伙，那個分散式系統和 BDSM 的傢伙。

什麼？你剛才說了 BDSM？

—嗯，BDSM。灣區的人都在用分散式系統和 BDSM。

好吧，他寫了「Call Me Maybe」這首歌？

—沒有，他寫了一系列關於為什麼所有資料庫都沒能打破 CAP 的博文。

CAP 是啥？

—CAP 定理，即任何分散式系統只能在一致性(Consitency)，可用性(Availability)和分區容忍性(Partition Tolerance)中三選二。

好吧，所有資料庫都沒能打破 CAP？這代表了什麼？

—這說明它們都很垃圾，比如 Mongo。

我以為 Mongo 可擴展(scale)。

—沒人這麼想過。

好吧，etcd 呢？

—etcd 是一個分散式鍵值倉庫。

噢，像 Redis。

—不，和 Redis 一點都不像。etcd 是分散式的。如果網路分區(network partition)，Redis 會丟失一半的寫入。

好吧，etcd 是一個分散式鍵值倉庫，為什麼這一點很有用？

—Kubernetes 可以用 etcd 來配置一個標準的 5 節點集群作為 message bus。etcd 結合一些 Kubernetes 服務可以提供一個相當健壯的指揮系統。

5 個節點？我只有一個應用。我一共需要多少機器？

—唔，你大概需要 12 個服務，每個服務還要有一些冗餘備份，一些負載均衡器，etcd 集群，資料庫以及 Kubernetes 集群。大概 50 個容器吧。

靠！

—小事一樁！容器非常高效，你可以在大約 8 台機器上部署這些容器！是不是很神奇？

也許吧，有了這些服務，我總能部署我的應用了吧？

—當然，不過存儲仍然是個問題，網路也會花很多功夫，但差不多就這樣啦！

這樣。好吧，我覺得我懂了。

—太好了！

謝謝你解釋這些。

—沒事。

我再說一遍，看我理解了沒有。

—好的！

所以，我需要把一個簡單的增刪改查應用分解成 12 個微服務，每個微服務都要有自己的 API，還可以調用其他微服務的 API，並且能健壯地處理錯誤，接著把微服務放入 Docker 容器，啟動 8 台運行 CoreOS 的 Docker 託管機器，用一個運行 etcd 的小 Kubernetes 集群來「指揮」它們，再解決網路和存儲的問題，然後持續交付每個微服務的多個冗餘備份到 8 台機器上。對吧？

—對！是不是很棒？

我還是滾回去用 Heroku 吧。