# 細分：使用 Docker，ECS 和 Terraform 重建基礎架構 > 原文： [http://highscalability.com/blog/2015/10/19/segment-rebuilding-our-infrastructure-with-docker-ecs-and-te.html](http://highscalability.com/blog/2015/10/19/segment-rebuilding-our-infrastructure-with-docker-ecs-and-te.html)  *這是[段](https://www.linkedin.com/in/calvinfo)的 CTO /聯合創始人 [Calvin French-Owen](https://www.linkedin.com/in/calvinfo) 的來賓[重新發布](https://segment.com/blog/rebuilding-our-infrastructure/)。* 在 Segment 成立之初，我們的基礎設施遭到了相當大的破壞。 我們通過 AWS UI 設置了實例，擁有未使用的 AMI 的墓地，并且通過三種不同的方式實現了配置。 隨著業務開始騰飛，我們擴大了 eng 團隊的規模和體系結構的復雜性。 但是，只有少數知道神秘奧秘的人才能從事生產工作。 我們一直在逐步改進流程，但是我們需要對基礎架構進行更深入的檢查，以保持快速發展。 所以幾個月前，我們坐下來問自己：*“如果今天設計基礎架構設置會是什么樣？”* 在 10 周的過程中，我們完全重新設計了基礎架構。 我們幾乎淘汰了每個實例和舊配置，將服務移至可在 Docker 容器中運行，并切換到使用新的 AWS 賬戶。 我們花了很多時間思考如何制作可審核，簡單易用的生產設置，同時仍具有擴展和增長的靈活性。 這是我們的解決方案。 ## 單獨的 AWS 賬戶 我們沒有使用區域或標簽來分隔不同的暫存和生產實例，而是切換了完全獨立的 AWS 帳戶。 我們需要確保我們的配置腳本不會影響我們當前正在運行的服務，并且使用新帳戶意味著我們一開始就有空白。  `ops`帳戶用作跳轉點和集中登錄。 組織中的每個人都可以擁有一個 IAM 帳戶。 其他環境具有一組 IAM 角色，可以在它們之間進行切換。 這意味著我們的管理員帳戶只有一個登錄點，并且只有一個位置可以限制訪問。 例如，愛麗絲可能可以訪問所有三個環境，但是鮑勃只能訪問開發人員（因為他刪除了生產負載平衡器）。 但是它們都通過`ops`帳戶輸入。 無需復雜的 IAM 設置來限制訪問，我們可以輕松地按環境鎖定用戶并按*角色將其分組。* 通過界面使用每個帳戶就像切換當前活動角色一樣簡單。  不必擔心暫存盒可能不安全或會更改生產數據庫，我們免費獲得*真正隔離*。 無需額外配置。 能夠共享配置代碼的另一個好處是，我們的登臺環境實際上可以反映產品。 配置上的唯一區別是實例的大小和容器的數量。 最后，我們還啟用了各個帳戶的合并結算。 我們使用相同的發票支付每月帳單，并查看按環境劃分的費用的詳細分類。 ## Docker 和 ECS 設置好帳戶后，就可以設計服務的實際運行方式了。 為此，我們轉向了 [Docker](https://docker.com/) 和 [EC2 容器服務（ECS）](https://aws.amazon.com/ecs/)。 截至今天，我們現在在 Docker 容器中運行我們的大多數服務，包括我們的 API 和數據管道。 容器每秒接收數千個請求，每月處理 500 億個事件。 Docker 最大的單一好處是在一定程度上使團隊能夠從頭開始構建服務。 我們不再需要復雜的配置腳本或 AMI，只需將生產集群交給一個映像即可運行。 不再有狀態的實例，我們保證在 staging 和 prod 上運行相同的代碼。 在將我們的服務配置為在容器中運行之后，我們選擇了 ECS 作為調度程序。 總體而言，ECS 負責在生產中實際運行我們的容器。 它負責調度服務，將它們放置在單獨的主機上，并在連接到 ELB 時重新加載零停機時間。 它甚至可以跨可用區進行調度，以提高可用性。 如果某個容器死亡，ECS 將確保將其重新安排在該群集中的新實例上。 切換到 ECS 大大簡化了服務的運行，而無需擔心新貴作業或預配實例。 就像添加一個 [Dockerfile](https://gist.github.com/calvinfo/c9ffb5c28133be525c62) ，設置任務定義并將其與集群關聯一樣簡單。 在我們的設置中，Docker 映像是由 CI 構建的，然后被推送到 Docker Hub。 服務啟動時，它將從 Docker Hub 中拉出映像，然后 ECS 在機器之間調度它。  我們會根據服務集群的關注程度和負載情況對其進行分組（例如，針對 API，CDN，App 等的不同集群）。 具有單獨的群集意味著我們可以獲得更好的可見性，并且可以決定為每個實例使用不同的實例類型（因為 ECS 沒有實例相似性的概念）。 每個服務都有一個特定的任務定義，該任務定義指示要運行哪個版本的容器，要運行多少個實例以及要選擇哪個集群。 在運行期間，服務向 ELB 進行自身注冊，并使用運行狀況檢查來確認容器實際上已準備就緒。 我們在 ELB 上指向本地 Route53 條目，以便服務可以相互通信，并僅通過 DNS 進行引用。  設置很好，因為我們不需要任何服務發現。 本地 DNS 為我們完成所有簿記工作。 ECS 運行所有服務，我們從 ELB 獲得免費的 cloudwatch 指標。 這比在啟動時向中央機構注冊服務要簡單得多。 最好的部分是我們不必自己處理國家沖突。 ## 使用 Terraform 進行模板化 Docker 和 ECS 描述了如何運行我們的每個服務的地方， [Terraform](https://terraform.io/) 是將它們結合在一起的粘合劑。 從高層次上講，它是一組配置腳本，用于創建和更新我們的基礎架構。 您可以將其視為類固醇上的 Cloudformation 版本，但這并不能使您感到驚訝。 除了運行一組用于維護狀態的服務器外，還有一組描述集群的腳本。 配置在本地運行（并在將來通過 CI 運行）并致力于 git，因此我們可以連續記錄生產基礎架構的實際狀況。 這是用于設置堡壘節點的 Terraform 模塊的示例。 它創建了所有安全組，實例和 AMI，因此我們能夠輕松地為將來的環境設置新的跳轉點。 ``` // Use the Ubuntu AMI module "ami" { source = "github.com/terraform-community-modules/tf_aws_ubuntu_ami/ebs" region = "us-west-2" distribution = "trusty" instance_type = "${var.instance_type}" } // Set up a security group to the bastion resource "aws_security_group" "bastion" { name = "bastion" description = "Allows ssh from the world" vpc_id = "${var.vpc_id}" ingress { from_port = 22 to_port = 22 protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } tags { Name = "bastion" } } // Add our instance description resource "aws_instance" "bastion" { ami = "${module.ami.ami_id}" source_dest_check = false instance_type = "${var.instance_type}" subnet_id = "${var.subnet_id}" key_name = "${var.key_name}" security_groups = ["${aws_security_group.bastion.id}"] tags { Name = "bastion-01" Environment = "${var.environment}" } } // Setup our elastic ip resource "aws_eip" "bastion" { instance = "${aws_instance.bastion.id}" vpc = true } ``` 我們在階段和產品中使用相同的模塊來設置我們的個人堡壘。 我們唯一需要切換的是 IAM 密鑰，我們已經準備就緒。 進行更改也很輕松。 Terraform 不會總是拆除整個基礎架構，而會在可能的地方進行更新。 當我們想將 ELB 耗盡超時更改為 60 秒時，只需執行簡單的查找/替換操作即可，然后是`terraform apply`。 而且，兩分鐘后，我們對所有 ELB 進行了完全更改的生產設置。 它具有可復制性，可審核性和自我記錄性。 這里沒有黑匣子。 我們將所有配置都放在了`infrastructure`中央存儲庫中，因此很容易發現如何設置給定的服務。 不過，我們還沒有達到圣杯。 我們希望轉換更多的 Terraform 配置以利用模塊，以便可以合并單個文件并減少共享樣板的數量。 一路上，我們在`.tfstate`周圍發現了一些陷阱，因為 Terraform 始終首先從現有基礎架構中讀取數據，并抱怨狀態是否不同步。 我們最終只是將我們的`.tfstate`提交給了倉庫，并在進行了任何更改之后將其推送了，但是我們正在研究 [Atlas](https://atlas.hashicorp.com/) 或通過 CI 來解決該問題。 ## 移至 Datadog 至此，我們有了基礎架構，配置和隔離。 最后剩下的是度量和監視，以跟蹤生產中正在運行的所有內容。 在我們的新環境中，我們已將所有指標和監視切換到 [Datadog](https://datadog.com/) ，這是出色的。  我們一直對 Datadog 的 UI，API 以及與 AWS 的完全集成感到非常滿意，但是要充分利用該工具，需要進行一些關鍵的設置。 我們要做的第一件事是與 AWS 和 Cloudtrail 集成。 它提供了 10,000 英尺的視圖，可了解我們在每個環境中發生的情況。 由于我們正在與 ECS 集成，因此 Datadog feed 會在每次任務定義更新時進行更新，因此最終會免費獲得部署通知。 驚人地搜索提要很容易，并且可以輕松地追溯到上一次部署或重新安排服務的時間。 接下來，我們確保將 Datadog-agent 作為容器添加到基本 AMI（ [datadog / docker-dd-agent](https://hub.docker.com/r/datadog/docker-dd-agent/) ）。 它不僅從主機（CPU，內存等）收集指標，而且還充當我們 statsd 指標的接收器。 我們的每項服務都會收集有關查詢，延遲和錯誤的自定義指標，以便我們可以在 Datadog 中進行瀏覽并發出警報。 我們的 go 工具包（即將開源）將自動在代碼行中收集 [`pprof`](https://golang.org/pkg/net/http/pprof/) 的輸出并將其發送，因此我們可以監視內存和 goroutine。 更酷的是，代理可以可視化環境中主機之間的實例利用率，因此我們可以對可能存在問題的實例或群集進行高層概述：  此外，我的隊友文斯（Vince）為 Datadog 創建了 [Terraform 提供程序，因此我們可以完全針對*實際生產配置*編寫警報腳本。 我們的警報將被記錄，并與產品中正在運行的警報保持同步。](https://github.com/segmentio/terraform-datadog) ``` resource "datadog_monitor_metric" "app.internal_errors" { name = "App Internal Errors" message = "App Internal Error Alerts" metric = "app.5xx" time_aggr = "avg" time_window = "last_5m" space_aggr = "avg" operator = ">" warning { threshold = 10 notify = "@slack-team-infra" } critical { threshold = 50 notify = "@slack-team-infra @pagerduty" } } ``` 按照慣例，我們指定兩個警報級別：`warning`和`critical`。 `warning`可以讓當前在線的任何人知道某些東西看起來可疑，應在任何潛在問題發生之前就將其觸發。 `critical`警報是為嚴重的系統故障而“半夜醒來”的問題保留的。 更重要的是，一旦我們過渡到 Terraform 模塊并將 Datadog 提供程序添加到我們的服務描述中，那么所有服務最終都會獲得*免費*的警報。 數據將直接由我們的內部工具包和 Cloudwatch 指標提供動力。 ## 讓好時光泊塢窗運行 一旦我們將所有這些組件準備就緒，就可以開始進行轉換了。 我們首先在新的生產環境和舊的生產環境之間建立了 [VPC 對等連接](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html)-允許我們對數據庫進行集群并在兩者之間進行復制。 接下來，我們對新環境中的 ELB 進行了預熱，以確保它們可以處理負載。 亞馬遜不會提供自動調整大小的 ELB，因此我們不得不要求他們提前對其進行調整（或緩慢調整規模）以應對增加的負載。 從那里開始，只需要使用加權的 Route53 路由將流量從舊環境穩定地增加到我們的新環境，并不斷監視一切都看起來不錯。 如今，我們的 API 蓬勃發展，每秒處理數千個請求，并且完全在 Docker 容器內運行。 但是我們還沒有完成。 我們仍在微調我們的服務創建，并減少樣板，以便團隊中的任何人都可以通過適當的監視和警報輕松構建服務。 而且，由于服務不再與實例相關聯，因此我們希望圍繞容器的使用改進工具。 我們還計劃關注這一領域的有前途的技術。 [Convox](https://convox.com/) 團隊正在圍繞 AWS 基礎架構構建出色的工具。 [Kubernetes](http://kubernetes.io/) ，[中層](https://mesosphere.com/)， [Nomad](https://nomadproject.io/) 和 [Fleet](https://github.com/coreos/fleet) 看起來像是不可思議的調度程序，盡管我們喜歡 ECS 的簡單性和集成性。 看到它們如何被淘汰將是令人興奮的，我們將繼續關注它們以了解我們可以采用什么。 在所有這些業務流程變更之后，我們比以往任何時候都更加堅信將基礎架構外包給 AWS。 他們通過將許多核心服務產品化而改變了游戲規則，同時保持了極具競爭力的價格。 它正在創建一種新型的初創公司，可以高效而廉價地生產產品，同時減少維護時間。 而且我們看好將在其生態系統之上構建的工具。 Datadog 鏈接已斷開，它顯示 SSL 錯誤。 正確的網址是 https://www.datadoghq.com/ 我們是一家初創公司，我們正在嘗試從頭開始設置 evyrthing。 感謝您的帖子。