Sysadminka 系統管理員聚會正在車里雅賓斯克舉行，在最後一次聚會上，我報告了我們在 Kubernetes 中的 1C-Bitrix 上運行應用程式的解決方案。
Bitrix、Kubernetes、Ceph－一個偉大的組合？
我將告訴您我們如何從這一切中整合出一個可行的解決方案。
我們走吧！
聚會於 18 月 XNUMX 日在車里雅賓斯克舉行。 您可以在以下位置閱讀有關我們聚會的資訊： 看看 .
如果您想向我們報告或作為聽眾 - 歡迎，請寫信至 [電子郵件保護] 以及 Telegram t.me/vadimisakanov。
我的報告
解決方案“Kubernetes 中的 Bitrix，南橋 1.0 版”
我將以「Kubernetes 傻瓜」的形式討論我們的解決方案，就像聚會上所做的那樣。 但我假設您至少在 Wikipedia 上的文章層級上了解 Bitrix、Docker、Kubernetes、Ceph 這些字。
Kubernetes 中的 Bitrix 有哪些現成的？
整個互聯網上關於Bitrix應用程式在Kubernetes中運行的資訊非常少。
我只找到這些材料：
來自 Qsoft 的 Alexander Serbul、1C-Bitrix 和 Anton Tuzlukov 的報告：
我建議聽一下。
從用戶那裡開發您自己的解決方案 .
發現更多 .
啊……實際上，僅此而已。
我警告您，我們尚未檢查上面連結中解決方案的品質:)
順便說一句，在準備我們的解決方案時，我與 Alexander Serbul 進行了交談，當時他的報告還沒有出現，所以在我的幻燈片中有一個項目“Bitrix 不使用 Kubernetes”。
但是已經有很多現成的 Docker 映像可以在 Docker 中執行 Bitrix：
這足以在 Kubernetes 中為 Bitrix 創建完整的解決方案嗎？
不。 有大量的問題需要解決。
Kubernetes 中 Bitrix 有哪些問題？
首先，Dockerhub 提供的現成映像不適合 Kubernetes
如果我們想要建立一個微服務架構（在 Kubernetes 中我們通常會這樣做），我們需要將 Kubernetes 應用程式分離到容器中，並讓每個容器執行一項小功能（並且做得很好）。 為什麼只有一個？ 簡而言之，越簡單越可靠。
更具體地說，請觀看這篇文章和影片：
Dockerhub 中的 Docker 映像主要是基於一體化原則建構的，因此我們仍然必須製作自己的自行車，甚至從頭開始建立映像。
其次 - 網站程式碼是從管理面板編輯的
我們在網站上建立了一個新部分 - 程式碼已更新（新增了具有新部分名稱的目錄）。
如果您從管理面板變更了元件的屬性，程式碼就會變更。
Kubernetes 「預設」無法處理此問題；容器必須是無狀態的。
原因：叢集中的每個容器（pod）僅處理一部分流量。 如果只更改一個容器（Pod）中的程式碼，那麼不同 Pod 中的程式碼將會不同，網站的工作方式也會不同，並且網站的不同版本將顯示給不同的使用者。 你不能那樣生活。
第三 - 您需要解決部署問題
如果我們有一個整體和一個「經典」伺服器，一切都非常簡單：我們部署一個新的程式碼庫，遷移資料庫，將流量切換到新版本的程式碼。 切換立即發生。
如果我們在 Kubernetes 中有一個站點，切入微服務，有很多帶有程式碼的容器 - 哦。 您需要收集具有新版本程式碼的容器，推出它們而不是舊版本，正確遷移資料庫，並且最好在訪客不注意的情況下完成此操作。 幸運的是，Kubernetes 幫助我們實現了這一點，支援大量不同類型的部署。
第四 - 你需要解決儲存靜態的問題
如果您的網站「只有」10 GB 並且您將其完全部署在容器中，那麼您最終將獲得 10 GB 的容器，並且需要很長時間才能部署。
您需要將網站「最重」的部分儲存在容器之外，問題是如何正確執行此操作
我們的解決方案缺少什麼？
整個Bitrix程式碼沒有劃分為微功能/微服務（以便註冊是分開的，線上商店模組是分開的等）。 我們將整個程式碼庫儲存在每個容器中。
我們也不將資料庫儲存在 Kubernetes 中（我仍然在 Kubernetes 中實作了用於開發環境的資料庫解決方案，但不用於生產環境）。
網站管理員仍然會注意到該網站在 Kubernetes 上運作。 「系統檢查」功能無法正常運作；若要從管理面板編輯網站程式碼，您必須先按一下「我要編輯程式碼」按鈕。
問題已經確定，實現微服務的需求已經確定，目標也很明確——在 Kubernetes 中獲得一個在 Bitrix 上運行應用程式的工作系統，同時保留 Bitrix 的功能和 Kubernetes 的優勢。 讓我們開始實施吧。
架構
有許多帶有 Web 伺服器（工作人員）的“工作”pod。
下一項是 cron 任務（只需要一項）。
一項用於從管理面板編輯網站程式碼的升級（也只需要一項）。
我們解決問題：
- 在哪裡儲存會話？
- 快取存放在哪裡？
- 在哪裡儲存靜態數據，而不是在一堆容器中放置千兆位元組的靜態數據？
- 資料庫將如何運作？
Docker映像
我們首先建立一個 Docker 映像。
理想的選擇是我們擁有一個通用映像，在其基礎上我們獲得工作 Pod、帶有 Crontasks 的 Pod 以及升級 Pod。
.
它包括nginx、apache/php-fpm（建置時可以選擇）、用於傳送郵件的msmtp和cron。
組裝映像時，網站的整個程式碼庫都會複製到 /app 目錄（除了我們將移動到單獨的共用儲存的那些部分）。
微服務、服務
工人 Pod：
- 帶有 nginx 的容器 + apache/php-fpm 容器 + msmtp
- 將msmtp移到單獨的微服務中並沒有成功，Bitrix開始對它無法直接發送郵件感到憤慨
- 每個容器都有一個完整的程式碼庫。
- 禁止更改容器中的程式碼。
克羅恩下：
- 帶有 apache、php、cron 的容器
- 包含完整的程式碼庫
- 禁止更改容器中的程式碼
升級如下：
- nginx 容器 + apache/php-fpm 容器 + msmtp
- 不禁止更改容器中的程式碼
會話存儲
Bitrix快取存儲
另一件重要的事情是：我們將連接到所有內容（從資料庫到郵件）的密碼儲存在 kubernetes 機密中。 我們得到了一個好處：密碼僅對我們授予其秘密存取權限的人可見，而不是對所有有權存取該專案程式碼庫的人可見。
靜態儲存
您可以使用任何東西：ceph、nfs（但我們不建議將 nfs 用於生產）、來自雲端提供者的網路儲存等。
儲存需要在容器中連接到網站的 /upload/ 目錄和其他包含靜態內容的目錄。
數據庫
為簡單起見，我們建議將資料庫移至 Kubernetes 之外。 Kubernetes 中的基礎是一個單獨的複雜任務；它將使方案複雜一個數量級。
會話存儲
我們使用記憶體快取:)
它可以很好地處理會話存儲，是集群式的，並且在 php 中作為 session.save_path “本地”支援。 當我們建立具有大量 Web 伺服器的叢集時，這樣的系統已經在經典的整體架構中進行了多次測試。 對於部署，我們使用 helm。
$ helm install stable/memcached --name sessionphp.ini - 這裡的圖像包含用於在 memcached 中儲存會話的設置
我們使用環境變數透過 memcached 傳遞有關主機的數據 .
這允許您在 dev、stage、test、prod 環境中使用相同的程式碼（其中的 memcached 主機名稱會不同，因此我們需要將會話的唯一主機名稱傳遞到每個環境）。
Bitrix快取存儲
我們需要所有 Pod 都可以寫入和讀取的容錯儲存。
我們也使用memcached。
該方案是Bitrix自己推薦的。
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - 在 Bitrix 中指定快取的儲存位置
我們也使用環境變數。
克龍塔斯基
在 Kubernetes 中運行 Crontasks 有不同的方法。
- 使用用於運行 Crontasks 的 pod 進行單獨部署
- 用於執行 crontasks 的 cronjob（如果這是一個 Web 應用程式 - 使用 wget ，或某個工作單元內的 kubectl exec 等）
- 等。
您可以爭論最正確的一個，但在本例中，我們選擇了「與 Crontasks 的 pod 單獨部署」選項
它是如何完成的：
- 透過 ConfigMap 或透過 config/addcron 檔案新增 cron 任務
- 在一個實例中，我們啟動一個與工作容器相同的容器+允許在其中執行皇冠任務
- 使用相同的程式碼庫，由於統一，容器組裝很簡單
我們得到什麼好處：
- 我們在與開發人員環境（docker）相同的環境中執行 Crontasks
- Crontasks 不需要為 Kubernetes 進行“重寫”，它們以與以前相同的形式和相同的程式碼庫工作
- cron 任務可以由對生產分支具有提交權限的所有團隊成員添加，而不僅僅是管理員
南橋 K8SDeploy 模組和從管理面板編輯程式碼
我們正在談論升級？
如何疏導那裡的交通？
萬歲，我們用 PHP 寫了一個模組:)這是 Bitrix 的一個小型經典模組。 目前尚未公開，但我們計劃開放。
此模組的安裝方式與 Bitrix 中的常規模組類似：
它看起來像這樣：
它允許您設定一個 cookie 來識別網站管理員並允許 Kubernetes 將流量傳送到升級 Pod。
當更改完成後，您需要點擊 git Push，程式碼變更將發送到 git，然後系統將使用新版本的程式碼建立鏡像並在整個叢集中“推出”，替換舊的 pod 。
是的，這有點像拐杖，但同時我們維護微服務架構，並且不會剝奪 Bitrix 使用者最喜歡的從管理面板修正程式碼的機會。 最後，這是一個選項；您可以透過不同的方式解決編輯程式碼的問題。
舵圖
為了在 Kubernetes 上建立應用程序，我們通常使用 Helm 套件管理器。
對於 Kubernetes 中的 Bitrix 解決方案，我們的首席系統管理員 Sergey Bondarev 編寫了一個特殊的 Helm 圖表。
它建構worker、ugrade、cron pod，配置入口、服務，並將變數從 Kubernetes 秘密傳輸到 pod。
我們將程式碼儲存在 Gitlab 中，並且還從 Gitlab 運行 Helm 建置。
簡而言之，它看起來像這樣
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production如果部署期間突然出現問題，Helm 還允許您進行「無縫」回滾。 當您沒有驚慌失措時（因為產品崩潰而透過 ftp 修復程式碼），這很好，但 Kubernetes 會自動執行此操作，並且無需停機。
部署
是的，我們是 Gitlab 和 Gitlab CI 的粉絲，我們使用它:)
當在 Gitlab 中提交到專案儲存庫時，Gitlab 會啟動一個部署新版本環境的管道。
階段：
- build（建置新的 Docker 映像）
- 測試（測試）
- 清理（刪除測試環境）
- 推送（我們將其發送到 Docker 註冊表）
- 部署（我們透過 Helm 將應用程式部署到 Kubernetes）。
萬歲，已經準備好了，讓我們實施吧！
嗯，或者有問題就問吧。
那我們做了什麼
從技術角度來說：
- dockerized Bitrix；
- Bitrix「切」成容器，每個容器執行最少的功能；
- 實現容器的無狀態狀態；
- 解決了 Kubernetes 中更新 Bitrix 的問題；
- 所有 Bitrix 功能都繼續運作（幾乎全部）；
- 我們致力於部署到 Kubernetes 以及版本之間的回溯。
從商業角度來看：
- 容錯；
- Kubernetes 工具（可輕鬆與 Gitlab CI 整合、無縫部署等）；
- 秘密密碼（僅對那些直接有權存取密碼的人可見）；
- 在單一基礎設施中創建額外的環境（用於開發、測試等）很方便。
來源： www.habr.com