2017年8月10日 JAY CHRISTOPHERSON

創(chuàng)新互聯(lián)于2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元安化做網(wǎng)站,已為上家服務(wù),為安化各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220

以下是Spaceflight Industries 的首席工程師 Jay Christopherson的博客。Spaceflight 正在通過提供一種新的訪問太空的模式來徹底變革航天飛機業(yè)務(wù)。作為一個全面的發(fā)射服務(wù)和任務(wù)管理提供商, 該公司提供了一種簡單且經(jīng)濟高效的產(chǎn)品和服務(wù)套件, 包括最先進的衛(wèi)星基礎(chǔ)設(shè)施、搭乘式發(fā)射產(chǎn)品和能夠讓企業(yè)或政府按時、按預(yù)算實現(xiàn)其任務(wù)目標(biāo)的全球通信網(wǎng)絡(luò)。作為美國西雅圖航空航天產(chǎn)業(yè)的服務(wù)提供商, Spaceflight 通過由全球合作伙伴、地面站和運載火箭供應(yīng)商組成的網(wǎng)絡(luò)提供服務(wù)

在我們確定如何設(shè)計計算基礎(chǔ)結(jié)構(gòu)以支持業(yè)務(wù)應(yīng)用時, 我們面臨兩個主要挑戰(zhàn): 我們應(yīng)該如何處理分布式運行時更改和服務(wù)發(fā)現(xiàn)。我們需要在部署世界各地的遠(yuǎn)程衛(wèi)星通信地面站 (spokes) 時進行分布式更改, 但它們都是通過中心位置 (hub) 來管理的。從中心位置所做的更改需要以自動方式分發(fā)到一個或多個遠(yuǎn)程地面站。至于服務(wù)發(fā)現(xiàn), 我們經(jīng)常構(gòu)建和部署, 我們需要確保在沒有任何手動更新的情況下, 盡快檢測和更新我們基礎(chǔ)結(jié)構(gòu)中的服務(wù)更改。這就是我們關(guān)注HashiCorp Consul的原因。

我們的所有應(yīng)用在部署時都注冊到Consul，所以我們大量使用基于Consul的健康檢查, 標(biāo)簽, 外部服務(wù)注冊和負(fù)載平衡 (對于某些工具, 可以注冊一個 "活動" 組件)功能。此外, DNS 允許我們的各種應(yīng)用和服務(wù)動態(tài)更新并及時發(fā)現(xiàn)其他所需的服務(wù)。對于運行時配置, 我們投資了諸如Consul模板這樣的工具來構(gòu)建可根據(jù)觸發(fā)器更新的動態(tài)配置文件, 例如Consul中的value更改。最后, 對我們部署的服務(wù)的更改通常變得簡單, 就像對源存儲庫文件中保存的參數(shù)進行更改一樣。構(gòu)建在更改時觸發(fā), 更新被推送到Consul?，F(xiàn)在, 我們部署的服務(wù)的更改可以自然而然進行。

我們基于Consul的系統(tǒng)構(gòu)建以及其他的 HashiCorp 產(chǎn)品

在Spaceflight Industries中的任何部署的核心包括四部分:?HashiCorp Consul,?HashiCorp Vault,?HashiCorp Nomad, 和HashiCorp Terraform。專注于Consul, 它是我們所做一切的基本組成部分, 包括關(guān)鍵/價值管理、服務(wù)注冊、動態(tài) DNS 和外部服務(wù)。我們設(shè)計的任何新服務(wù)都是圍繞如何與Consul進行交互和配置而設(shè)計的。它還充當(dāng)我們的 Vault 部署的后備存儲。對于任何生產(chǎn)級服務(wù), 我們都在群集中部署Consul。

我們在一個hub-and-spoke架構(gòu)中設(shè)計了我們的 setup。我們有一個中央 hub, 所有地面站的所有變化都同步到遠(yuǎn)程站點。我們只選擇在中央hub群集中保留本地的一些關(guān)鍵內(nèi)容。以前, 我們使每個遠(yuǎn)程地面站成為hub集群的只讀副本。但是, 我們發(fā)現(xiàn)將某些項目標(biāo)記為本地 (即不同步) 的功能在最新的Consul 版本中可用, 這使我們更容易獲得某些內(nèi)容, 我們更希望采用這種更混合的同步方法。

我們對 Consul 的使用在整個過程中為我們提供了重要的經(jīng)驗。我們過去使用腳本填充了 K/V 儲存, 但發(fā)現(xiàn)這實際上不是長期可持續(xù)的。我們真正想要的, 是讓開發(fā)人員在源代碼控制中 check in 一個更改, 并能夠 "自動" 生成/測試/部署, 以便跟蹤所有更改, 而無需對 Consul 或我們的 DevOps 基礎(chǔ)結(jié)構(gòu)有深入了解。使用 Terraform 資源來用 K/V 或外部服務(wù)來填充 Consul 意味著我們可以很容易地實現(xiàn)這個目標(biāo)。在源代碼中進行更改、提交、觸發(fā)構(gòu)建/測試、觸發(fā)Terraform 計劃/部署, 而這一切都在極少的時間內(nèi)在后臺發(fā)生, 并且在初始提交之后無需進行交互。

我們在這里的最佳實踐建議 (這可能是最明顯的), 是構(gòu)建您的系統(tǒng)以便可以輕松地從單個來源跟蹤更改。另外, 設(shè)置您的系統(tǒng), 以便只能從該單一來源進行更改。實施 break-glass procedure, 這將允許某人升級他們的特權(quán), 以便他們可以直接在緊急情況下進行更改。

提高開發(fā)人員工作效率, 減少管理開銷和瓶頸

我們的實施方案有幾個主要好處:

• 我們需要很少的管理開銷來管理全球基礎(chǔ)設(shè)施。
• 沒有一個人 (或組) 需要對系統(tǒng)進行更改-沒有 "如果他被公共汽車撞到" 的情形。任何通過身份驗證的具有源存儲庫訪問權(quán)限的單個開發(fā)人員都可以進行更改, 并能通過系統(tǒng)實現(xiàn)從提交到部署的跟蹤。
• 圍繞 Hashicorp 服務(wù) (特別是 Consul 構(gòu)建我們的體系結(jié)構(gòu)意味著我們的開發(fā)人員在基礎(chǔ)結(jié)構(gòu)的不同功能部分中有通用的配置語言, 有獲得幫助的能力（如果他們需要的話，管是基于community的還是基于合同的), 并且能夠輕松地將生產(chǎn)環(huán)境縮小到單個開發(fā)環(huán)境, 并具有一些參數(shù)變化。

所有這些都減少了我們構(gòu)建系統(tǒng)和推出更改的時間。然后, 我們可以花更多的時間來構(gòu)建我們的產(chǎn)品, 而不是交付基礎(chǔ)設(shè)施。

HashiCorp Consul 是一款可以在任何基礎(chǔ)設(shè)施上連接任何應(yīng)用的產(chǎn)品。Consul 是一個分布式、高度可用和數(shù)據(jù)中心感知的解決方案, 可在動態(tài)分布式基礎(chǔ)架構(gòu)上連接和配置應(yīng)用。Consul 用于服務(wù)發(fā)現(xiàn)、運行時配置和編排, 以及簡化的高級網(wǎng)絡(luò)拓?fù)涔芾?。要了解有關(guān) HashiCorp Consul 的更多信息, 請訪問https://www.hashicorp.com/products/consul/.

【原文】Spaceflight uses HashiCorp Consul for Service Discovery and Runtime Configuration in their Hub-and-Spoke Network Architecture

AUG 10 2017?JAY CHRISTOPHERSON

This is a guest post by Jay Christopherson, principal engineer, DevOps, at Spaceflight Industries. Spaceflight is revolutionizing the business of space flight by delivering a new model for accessing space. A comprehensive launch service and mission management provider, the company provides a straightforward and cost-effective suite of products and services including state-of-the-art satellite infrastructure, rideshare launch offerings, and global communications networks that enable commercial and government entities to achieve their mission goals, on time and on budget. A service offering of Spaceflight Industries in Seattle Washington, Spaceflight provides its services through a global network of partners, ground stations, and launch vehicle providers.

We had two main challenges facing us as we determined how to design the computing infrastructure to support our business applications: how we should handle?distributed runtime changes?and?service discovery. We need distributed changes as we deploy remote satellite communications ground stations (spokes) around the world, but which are all managed from a central location (hub). Changes made from a central location need to be distributed out to one or more remote ground stations in an automated fashion. As for service discovery, we build and deploy quite often and we needed to make sure that changes to services in our infrastructure are detected and updated as quickly as possible without any manual updates. These are the reasons we looked at HashiCorp Consul.

Our applications all register on deployment with Consul and from there, we make heavy use of Consul-based health checks, tags, external services registration, and load balancing (for certain tools that can register an “active” component). Also, DNS allows all of our various applications and services to dynamically update and discover other required services. For runtime configuration we have invested in tools like consul-template to build dynamic configuration files that can update based on triggers, such as a value change in Consul. In the end, a change to our deployed services often becomes as simple as making a change to a parameter held in a file in our source repository; builds are triggered on change, the updates are pushed to Consul. Now, changes to our deployed services “just happen.”

Our Architecture with Consul and other HashiCorp products

The core of any deployment at Spaceflight Industries is composed of four pieces:?HashiCorp Consul,?HashiCorp Vault,?HashiCorp Nomad, and?HashiCorp Terraform. Focusing on Consul, it’s the base component of everything we do which includes key/value management, service registration, dynamic DNS, and external services. Any new service we design is designed around how it is going to interact and be configured with Consul. It also serves as the backing store for our Vault deployment. For any production level services, we deploy Consul in a cluster.

We’ve designed our setup in a hub-and-spoke architecture. We have a central hub where any changes that are common across all ground stations are synchronized out to remote sites. There are a few key things that we choose to keep locally in the hub cluster only. Previously, we made every remote ground station a read-only copy of the hub cluster. However, we have found that the ability to mark some items as local-only (i.e., not sync’d out), available in the more recent versions of Consul, has made certain things easier for us and we prefer a more hybrid approach to synchronization now.

Our implementation of Consul provided us with key learnings throughout the process. We used to populate the K/V store using scripts but found that this really wasn’t sustainable long term. What we really wanted, was to have a developer check in a change to source control, and have that “automagically” build/test/deploy so that all changes are tracked, without requiring special knowledge of Consul or our DevOps infrastructure. Using a Terraform resource to populate Consul with K/V or external services means that we can easily achieve that goal. Make a change in source, commit, trigger a build/test, trigger a Terraform plan/deploy, and it all happens behind the scenes in very little time with zero interaction beyond the initial commit.

Our best practice recommendation here (which is probably obvious to most), is to build your system so that changes can be easily tracked from a single source. Also, set up your system so that changes can only be made from that single source. Implement a break-glass procedure which would allow someone to escalate their privileges such that they can make changes directly in an emergency.

Less management overhead and bottlenecks with increased developer productivity

There have been several key benefits from our implementation:

• We require very little administrative overhead to manage a global infrastructure.
• There’s not one single person (or group) that is required to make changes to the system - no “what if he got hit by a bus” scenario. Any single developer, with proper authenticated access to our source repo, can make a change that they can track through the system from commit to deploy.
• Building our architecture around Hashicorp services (Consul in particular) means that our developers have a common configuration language across different functional pieces of our infrastructure, the ability to receive help if they need it (both community- and contract-based), and the ability to easily scale down a production environment to a single development environment with a few parameter changes.

All of this reduces our time to build systems and roll out changes. We then get to spend more time on building our products rather than the process of delivering our infrastructure.

HashiCorp Consul is a product to connect any application across any infrastructure. Consul is a distributed, highly available, and data center-aware solution to connect and configure applications across dynamic, distributed infrastructure. Consul is used for service discovery, runtime configuration and orchestration, and simplified management of advanced network topologies. To learn more about HashiCorp Consul, visit?https://www.hashicorp.com/products/consul/.