當您從事 IT 工作時，您會開始注意到系統有自己的特色。 他們可以靈活、沉默、古怪、嚴厲。 它們可以吸引或排斥。 不管怎樣，你必須與他們“談判”，在“陷阱”之間周旋，並建立他們的互動鏈。
因此，我們有幸建立了一個雲端平台，為此我們需要「說服」幾個子系統與我們合作。 幸運的是，我們有「API 語言」、直接的雙手和很大的熱情。
這篇文章不會在技術上硬核，但會描述我們在建立雲端時遇到的問題。 我決定以輕鬆的技術幻想的形式來描述我們的道路，講述我們如何尋找系統的通用語言以及從中得到的結果。
歡迎來到貓。
開始的旅程
前段時間，我們團隊的任務是為客戶推出一個雲端平台。 我們擁有管理支援、資源、硬體堆疊以及選擇技術來實現服務的軟體部分的自由。
還有一些要求：
- 該服務需要方便的個人帳戶；
- 該平台必須整合到現有的計費系統中；
- 軟體和硬體：OpenStack + Tungsten Fabric (Open Contrail)，我們的工程師已經學會「烹飪」得很好。
如果 Habra 社群感興趣的話，我們將在下次告訴您團隊是如何組成的、個人帳戶介面是如何開發的以及設計決策是如何制定的。
我們決定使用的工具：
- Python + Flask + Swagger + SQLAlchemy - 完全標準的Python集合；
- Vue.js 前端；
- 我們決定使用 Celery over AMQP 來進行元件和服務之間的互動。
關於選擇 Python 的預期問題，我將進行解釋。 該語言在我們公司找到了自己的定位，並圍繞著它發展了一種雖小但仍然存在的文化。 因此，決定開始在其上建立服務。 而且，這類問題的發展速度往往是決定性的。
那麼，讓我們開始我們的認識吧。
靜音帳單 - 計費
我們認識這個人很久了。 他總是坐在我旁邊，默默地數著什麼。 有時他會將使用者要求轉發給我們、開立客戶發票和託管服務。 一個普通的努力的人。 確實，有困難。 他沉默寡言，時而深思熟慮，時而獨處。
計費是我們嘗試交朋友的第一個系統。 我們遇到的第一個困難就是處理服務的時候。
例如，當建立或刪除任務時，任務將進入內部計費佇列。 這樣就實現了一個與服務非同步工作的系統。 為了處理我們的服務類型，我們需要將我們的任務「放入」這個佇列中。 在這裡我們遇到了一個問題：缺乏文件。
從軟體API的描述來看，這個問題還是有可能解決的，但是我們沒有時間做逆向工程，所以我們把邏輯拿到外面，在RabbitMQ之上組織了一個任務佇列。 對服務的操作由客戶從其個人帳戶發起，變成後端的 Celery“任務”，並在計費和 OpenStack 端執行。 Celery 讓管理任務、組織重複和監控狀態變得非常方便。 您可以閱讀有關“芹菜”的更多信息，例如， .
此外，計費並沒有阻止資金耗盡的項目。 透過與開發人員的溝通，我們發現在計算統計數據時（我們需要準確地實現這種邏輯），存在著複雜的停止規則的相互關係。 但這些模型不太符合我們的現實。 我們也是透過Celery上的任務來實現的，將服務管理邏輯帶到了後端。
上述兩個問題都導致程式碼變得有點臃腫，將來我們將不得不進行重構，以便將處理任務的邏輯移至單獨的服務中。 我們還需要在表中儲存一些有關使用者及其服務的資訊來支援此邏輯。
另一個問題是沉默。
Billy 對某些 API 請求默默地回答「好的」。 例如，當我們在測試期間支付承諾的付款時就是這種情況（稍後會詳細介紹）。 請求已正確執行，我們沒有看到任何錯誤。
我必須在透過使用者介面使用系統時研究日誌。 事實證明，計費本身執行類似的請求，將範圍更改為特定用戶，例如 admin，並將其傳遞到 su 參數中。
總的來說，儘管文件存在缺陷並且 API 存在一些小缺陷，但一切都進展順利。 如果您了解日誌的結構以及要尋找的內容，即使在重負載下也可以讀取日誌。 資料庫的結構很華麗，但很有邏輯性，在某些方面甚至很有吸引力。
所以，總結一下，我們在互動階段遇到的主要問題與具體係統的實作特性有關：
- 以某種方式影響我們的未記錄的「功能」；
- 閉源（計費是用C++編寫的），因此除了「試錯」之外，不可能透過任何方式解決問題1。
幸運的是，該產品具有相當廣泛的 API，我們已將以下子系統整合到我們的個人帳戶中：
- 技術支援模組 - 來自您個人帳戶的請求將被「代理」以透明地為服務客戶計費；
- 財務模組 - 允許您向當前客戶開立發票、核銷並產生付款文件；
- 服務控制模組 - 為此我們必須實作我們自己的處理程序。 系統的可擴展性對我們有利，我們「教」了比利一種新型服務。
雖然有點麻煩，但無論如何，我想比利和我會相處得很好。
漫步鎢田 – 鎢布
鎢場上散佈著數百根電線，透過它們傳遞數千位訊息。 資訊被收集到「資料包」中，進行解析，建構複雜的路線，就像魔術一樣。
這是我們必須與之交朋友的第二個系統的領域 - Tungsten Fabric (TF)，以前稱為 OpenContrail。 它的任務是管理網路設備，為我們使用者提供軟體抽象。 TF - SDN，封裝了與網路設備一起工作的複雜邏輯。 有一篇關於技術本身的好文章，例如， .
該系統透過 Neutron 插件與 OpenStack（下面討論）整合。
OpenStack 服務的互動。
營運部門的人向我們介紹了這個系統。 我們使用系統的 API 來管理我們服務的網路堆疊。 它還沒有給我們帶來任何嚴重的問題或不便（我不能代表 OE 的人說話），但在互動中出現了一些奇怪的情況。
第一個看起來像這樣：透過 SSH 連接時需要向實例控制台輸出大量資料的命令只是「掛斷」連接，而透過 VNC 一切正常。
對於那些不熟悉這個問題的人來說，它看起來很有趣： ls /root 工作正常，而例如 top 完全「凍結」。 幸運的是，我們之前也遇到類似的問題。 這是透過調整從計算節點到路由器的路由上的 MTU 來決定的。 順便說一句，這不是 TF 問題。
下一個問題即將來臨。 在一個「美麗」的時刻，路由的魔力就這樣消失了。 TF 已停止管理設備上的路由。
我們從管理員等級開始使用 Openstack，然後轉移到所需的使用者等級。 SDN 似乎「劫持」了執行操作的用戶範圍。 事實上，連接 TF 和 OpenStack 使用的是同一個管理員帳戶。 在切換到使用者的步驟中，「魔力」消失了。 決定建立一個單獨的帳戶來使用該系統。 這使我們能夠在不破壞集成功能的情況下工作。
矽生命體 - OpenStack
一種形狀怪異的矽膠生物生活在鎢礦區附近。 最重要的是，它看起來就像一個長大的孩子，一揮就能把我們壓扁，但他身上並沒有明顯的攻擊性。 它不會引起恐懼，但它的大小會激發恐懼。 周圍發生的事情的複雜性也是如此。
OpenStack 是我們平台的核心。
OpenStack有幾個子系統，其中我們目前使用最活躍的是Nova、Glance和Cinder。 他們每個人都有自己的 API。 Nova 負責運算資源和實例的創建，Cinder 負責管理磁碟區及其快照，Glance 是管理作業系統範本及其元資訊的映像服務。
每個服務都運行在一個容器中，訊息代理就是「白兔」—RabbitMQ。
這個系統給我們帶來了最意想不到的麻煩。
當我們嘗試將額外的捲連接到伺服器時，第一個問題很快就出現了。 Cinder API 斷然拒絕執行此任務。 更準確地說，如果您相信OpenStack本身，連線已建立，但虛擬伺服器內部沒有磁碟裝置。
我們決定繞道而行，並請求 Nova API 執行相同的操作。 結果是設備連接正確並且可以在伺服器內存取。 看來問題是在區塊儲存不回應 Cinder 時發生的。
使用磁碟時還有另一個困難等著我們。 系統磁碟區無法與伺服器斷開連線。
同樣，OpenStack 本身「發誓」它已經破壞了連接，現在您可以單獨正確地使用磁碟區。 但該 API 斷然不想在磁碟上執行操作。
在這裡我們決定不再特別去戰鬥，而是改變我們對服務邏輯的看法。 如果有實例，則也必須有系統磁碟區。 因此，用戶在不刪除「伺服器」的情況下還無法刪除或停用系統「磁碟」。
OpenStack 是一組相當複雜的系統，有自己的互動邏輯和華麗的 API。 我們得到了相當詳細的文檔的幫助，當然還有反覆試驗（沒有它我們會怎樣）。
測試運行
我們去年XNUMX月進行了一次測試發射。 主要任務是從技術方面和使用者體驗方面在戰鬥模式下測試我們的專案。 有選擇地邀請觀眾並關閉測試。 但是，我們也保留了請求訪問我們網站上的測試的選項。
當然，測試本身也並非沒有有趣的時刻，因為這是我們的冒險才剛開始。
首先，我們在某種程度上錯誤地評估了對該專案的興趣，並且必須在測試期間快速添加計算節點。 這是集群的常見情況，但這裡也存在一些細微差別。 特定版本 TF 的文件指示了測試 vRouter 的工作的特定核心版本。 我們決定啟動具有更新核心的節點。 結果，TF沒有收到來自節點的路由。 我不得不緊急回滾核心。
另一個好奇心與個人帳戶中「更改密碼」按鈕的功能有關。
我們決定使用 JWT 來組織對我們個人帳戶的訪問，以免使用會話。 由於系統多種多樣且分散，我們管理自己的令牌，其中我們「包裝」來自計費的會話和來自 OpenStack 的令牌。 當密碼更改時，令牌當然會“變壞”，因為用戶資料不再有效，需要重新頒發。
我們忽略了這一點，而且根本沒有足夠的資源來快速完成這篇文章。 我們必須在啟動測試之前刪除該功能。
目前，如果密碼已更改，我們會註銷用戶。
儘管有這些細微差別，測試還是進展順利。 幾週內，大約有 300 人前來參觀。 我們能夠透過使用者的眼睛來看待產品，在行動中測試它並收集高品質的回饋。
待續
對我們許多人來說，這是第一個如此規模的項目。 我們學到了許多關於如何團隊合作以及做出架構和設計決策的寶貴經驗。 如何用很少的資源整合複雜的系統並將其投入生產。
當然，無論是在程式碼方面，還是在系統整合的介面方面，都還有一些工作要做。 該計畫還很年輕，但我們充滿雄心，希望將其發展成為可靠、便捷的服務。
我們已經能夠說服系統。 比爾盡責地處理他衣櫃裡的計數、計費和用戶請求。 鎢磁場的「魔力」為我們提供了穩定的通訊。 只有 OpenStack 有時會變得反覆無常，大喊「『WSREP 尚未準備好節點供應用程式使用』」。 但這是一個完全不同的故事......
我們最近推出了這項服務。
您可以在我們的網站上找到所有詳細信息 .
CLO開發團隊
有用的鏈接
OpenStack的
鎢絲布
來源： www.habr.com