指南：從單節(jié)點快速啟動到生產(chǎn)級集群部署)
文檔【免費下載鏈接】docsDocumentation for Docker Official Images in docker-library項目地址https://gitcode.com/gh_mirrors/docs/docs點擊查看免費下載本文以 Docker Official Images 倉庫中的 couchbase/content.md 為骨架系統(tǒng)講解如何用couchbase官方 Docker 鏡像快速搭建單節(jié)點集群、完成初始化與 N1QL 查詢驗證、通過 SDK 接入應(yīng)用并給出生產(chǎn)環(huán)境下的資源規(guī)劃、持久化、ulimit、網(wǎng)絡(luò)配置以及多節(jié)點集群部署拓撲等最佳實踐。讀完本文你將具備從一條 docker run 起一個實例到規(guī)劃一套可支撐生產(chǎn)的多節(jié)點 Couchbase 集群的完整實操能力。一、Couchbase Server 與官方 Docker 鏡像概覽Couchbase Server 是一款構(gòu)建于 NoSQL 技術(shù)之上的分布式文檔數(shù)據(jù)庫官方鏡像說明文檔 couchbase/content.md 將其核心能力概括為三點內(nèi)存優(yōu)先架構(gòu)memory-first architecture以內(nèi)存為第一優(yōu)先級的存儲與索引設(shè)計支撐亞毫秒級延遲與 99.999% 可用性原文表述配合端到端數(shù)據(jù)壓縮顯著降低網(wǎng)絡(luò)、內(nèi)存與存儲成本。全面的 SQL 兼容查詢語言 N1QL支持 ANSI join讓從傳統(tǒng) RDBMS 遷移到 Couchbase 變得平滑。多云與跨數(shù)據(jù)中心能力內(nèi)置 active-active 跨數(shù)據(jù)中心復(fù)制XDCR并提供 Kubernetes 等云集成降低運維負擔。在倉庫元數(shù)據(jù)層面couchbase/metadata.json 將該鏡像歸類于databases-and-storage數(shù)據(jù)庫與存儲類別couchbase/README-short.txt 用一句話概括其定位Couchbase Server 是一個具有分布式架構(gòu)的 NoSQL 文檔數(shù)據(jù)庫。值得一提的是本倉庫的文檔組織方式是源碼驅(qū)動生成真正的維護者書寫 couchbase/content.md再由倉庫根目錄的 update.sh 腳本結(jié)合 .template-helpers/template.md 等模板把標簽列表、架構(gòu)列表、Logo、許可信息等元數(shù)據(jù)自動拼裝成對外展示的 couchbase/README.md。因此本文以content.md為權(quán)威主體展開讀者也可以對照兩份文件查看渲染前后的差異。二、快速啟動用 Docker 跑起單節(jié)點 Couchbase Server 集群2.1 第一步運行容器并規(guī)劃端口映射在宿主機執(zhí)行以下命令即可啟動一個單節(jié)點的 Couchbase Server 容器$ docker run -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase命令要點說明參數(shù)含義-d以守護進程方式在后臺運行--name db給容器命名為db后續(xù)docker exec與docker stop均以此引用-p 8091-8097:8091-8097映射 Web Console 與管理/查詢等 HTTP 服務(wù)端口組其中8091 是 Web Console 的訪問端口-p 9123:9123映射分析Analytics等附加服務(wù)端口-p 11207:11207映射加密數(shù)據(jù)服務(wù)端口-p 11210:11210映射數(shù)據(jù)面memcached 協(xié)議/數(shù)據(jù)訪問端口-p 11280:11280映射代理數(shù)據(jù)服務(wù)端口-p 18091-18097:18091-18097映射與 8091-8097 對應(yīng)的 TLS 加密端口組需要特別說明的是原文檔明確提示Couchbase Server 究竟需要暴露哪些端口取決于具體使用場景上面這一組端口覆蓋了多數(shù)典型場景但并非所有場景的最小集。在真正規(guī)劃生產(chǎn)網(wǎng)絡(luò)時應(yīng)依據(jù) Couchbase Server 官方端口清單文檔install-ports逐項核對這里不再贅述外部鏈接。2.2 第二步通過 Web Console 完成初始化容器啟動后在宿主機瀏覽器訪問http://localhost:8091即可打開Web Console進入 Couchbase Server 的 Setup 向?qū)А０聪驅(qū)崾局鸩讲僮鞑⒔邮苣J值即可完成集群初始化操作時注意兩點內(nèi)存預(yù)算向?qū)е袝鬄?Data、Index、Query、Search、Analytics 等不同服務(wù)分配內(nèi)存。容器內(nèi)的可用內(nèi)存有限通常需要主動調(diào)低各服務(wù)的 RAM 分配使其落在容器資源邊界之內(nèi)否則初始化可能失敗或運行時 OOM。示例數(shù)據(jù)建議在向?qū)е袉⒂胋eer-samplebucket它會自動加載啤酒釀造相關(guān)的示例文檔后續(xù)的 N1QL 查詢演示正是基于這個 bucket 展開的。提示關(guān)于 Couchbase Server 的更詳細生產(chǎn)配置官方提供了 Deployment Guidelines部署指南文檔涵蓋內(nèi)存、磁盤、網(wǎng)絡(luò)等多維度的生產(chǎn)初始化建議可作為深入閱讀的下一站。2.3 驗證容器狀態(tài)初始化完成后可以通過容器命令驗證集群健康狀態(tài)。例如$ docker exec -it db couchbase-cli server-info -c localhost:8091 -u Administrator -p passwordcouchbase-cli是鏡像內(nèi)自帶的命令行管理工具也可以直接在 Web Console 的 UI 首頁觀察節(jié)點狀態(tài)。三、用 N1QL 查詢示例數(shù)據(jù)N1QL 是 Couchbase Server 基于 SQL 的查詢語言語法風格貼近 SQL但面向 JSON 文檔模型。針對beer-samplebucket可以執(zhí)行如下查詢找出指定酒廠mishawaka_brewing釀造的所有啤酒名稱SELECT name FROM beer-sample WHERE brewery_idmishawaka_brewing;注意bucket 名在 N1QL 中需要用反引號包裹以避免與關(guān)鍵字沖突。3.1 方式一Web Console 的 Query 工作臺在 Web Console 頂部切換到Query選項卡在查詢窗口中粘貼上面的語句并執(zhí)行即可看到返回的 JSON 結(jié)果列表。這是最直觀的交互式查詢方式適合臨時探索數(shù)據(jù)。3.2 方式二cbq 命令行工具在容器內(nèi)通過docker exec進入cbqCouchbase 交互式查詢 Shell使用初始化向?qū)r設(shè)置的憑據(jù)認證$ docker exec -it db cbq --user Administrator cbq SELECT name FROM beer-sample WHERE brewery_id mishawaka_brewing;在cbq提示符下輸入查詢語句并回車即可執(zhí)行。該方式適合在腳本化、自動化場景中復(fù)用也是 CI/CD 中做數(shù)據(jù)校驗的常用手段。更豐富的 N1QL 示例可參考 Couchbase Server 官方運行你的第一個 N1QL 查詢教程try-a-query。四、通過應(yīng)用 SDK 連接集群Couchbase Server 官方 SDK 覆蓋多種主流語言C、Go、Java、.NET、Node.js、PHP、Python。在宿主機上運行你的應(yīng)用將 bootstrap 連接串指向容器的 HTTP 端口即可http://localhost:8091/pools該端點返回集群的 pool 信息節(jié)點列表、bucket 列表等SDK 據(jù)此完成拓撲發(fā)現(xiàn)與連接管理。連接時使用與向?qū)б恢碌腁dministrator用戶名與密碼并在代碼中指定要訪問的 bucket如beer-sample。以 Java SDK 為例典型的連接方式為Cluster cluster Cluster.connect(localhost, Administrator, password); Bucket bucket cluster.bucket(beer-sample);其余語言的接入模式完全一致構(gòu)建連接串 → 認證 → 獲取 bucket 句柄 → 執(zhí)行 KV 或 N1QL 操作。更完整的端到端示例含 CRUD 與查詢可參考 Couchbase Server 官方提供的 Sample Application示例應(yīng)用指南。五、容器需求與生產(chǎn)部署最佳實踐5.1 基礎(chǔ)鏡像與資源需求官方 Couchbase Server 鏡像基于最新受支持的 Ubuntu 版本構(gòu)建。容器的內(nèi)存、CPU、磁盤最低需求應(yīng)參照 Couchbase Server 官方的System Resource Requirements系統(tǒng)資源需求文檔分別按開發(fā)development、測試test與生產(chǎn)production環(huán)境取不同檔位這里同樣只做指引、不展開外部鏈接。5.2 避免單點故障Couchbase Server 的高可用依賴集群 副本機制多個獨立節(jié)點組成集群并在節(jié)點間復(fù)制數(shù)據(jù)任何一個節(jié)點失效都不會導(dǎo)致數(shù)據(jù)不可訪問。但在容器化環(huán)境中有一個容易被忽略的陷阱如果多個 Couchbase 節(jié)點跑在同一臺物理機器上等于把單點故障又請了回來——這臺物理機一旦宕機其上的所有容器會同時不可用所有副本一起丟失。因此在能夠控制虛擬機/物理機放置位置的環(huán)境中官方建議確保每個 Couchbase Server 節(jié)點運行在不同的物理硬件上。5.3 容器規(guī)格CPU 建議容器的確會在 Couchbase Server 與底層 OS 之間引入一層輕量開銷。為保證穩(wěn)定性與性能可預(yù)測性開發(fā)環(huán)境至少為容器獨占 2 個 CPU 核心生產(chǎn)環(huán)境建議為容器獨占 4 個核心而不是與其他容器共享核心。核心思想是避免 over-commit資源超賣一旦多個容器互相爭搶 CPU會出現(xiàn)性能不可預(yù)測甚至穩(wěn)定性問題。5.4 持久化把 /opt/couchbase/var 映射到宿主機目錄默認情況下Couchbase Server 容器會把所有持久化數(shù)據(jù)與節(jié)點專屬數(shù)據(jù)寫入容器內(nèi)的/opt/couchbase/var目錄。官方強烈建議用-v選項將該目錄映射到宿主機文件系統(tǒng)$ docker run -d --name db \ -v ~/couchbase:/opt/couchbase/var \ -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 \ -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 \ couchbase這樣做有雙重收益持久性Persistence數(shù)據(jù)存放在宿主機上刪除容器后用同一數(shù)據(jù)目錄重新創(chuàng)建容器數(shù)據(jù)不會丟失甚至可以直接升級到更新版本/更高 release 的鏡像數(shù)據(jù)依舊完好。性能Performance標準 Docker 環(huán)境使用 union 文件系統(tǒng)疊加層若把/opt/couchbase/var留在容器內(nèi)部會引入一定的寫入性能損耗映射為宿主機卷可規(guī)避該損耗。SELinux 環(huán)境下的額外步驟如果你的宿主機啟用了 SELinux把宿主機目錄掛載進容器需要額外一步。假設(shè)要掛載宿主機的~/couchbase目錄需要在首次運行容器之前在該宿主機上執(zhí)行一次$ mkdir ~/couchbase chcon -Rt svirt_sandbox_file_t ~/couchbasechcon為目錄打上svirt_sandbox_file_t上下文標簽容器才被允許讀寫該掛載點。5.5 生產(chǎn)環(huán)境提升 ulimitCouchbase Server 在高負載下對進程資源限額有明確預(yù)期ulimit -n 200000 # nofile: 最大打開文件數(shù) ulimit -l unlimited # memlock: 最大鎖定內(nèi)存地址空間在輕量測試與開發(fā)場景下可以省略這些設(shè)置系統(tǒng)仍可正常工作但在重負載生產(chǎn)環(huán)境下必須設(shè)置否則可能出現(xiàn)打開文件數(shù)耗盡或內(nèi)存無法鎖定導(dǎo)致的穩(wěn)定性問題。由于 Docker 不支持直接傳unlimited作為 ulimit 值官方給出的做法是在docker run時追加--ulimit標志用一個大數(shù)值近似代替$ docker run -d \ --ulimit nofile40960:40960 \ --ulimit core100000000:100000000 \ --ulimit memlock100000000:100000000 \ --name db \ -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 \ -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 \ couchbase參數(shù)解讀標志語義說明--ulimit nofile40960:40960軟/硬限制均為 40960 個打開文件對應(yīng)主機側(cè)ulimit -n的容器化表達--ulimit core100000000:100000000核心轉(zhuǎn)儲文件大小上限100000000 按官方說明對應(yīng)約 100 GB--ulimit memlock100000000:100000000鎖定內(nèi)存上限同上約 100 GB替代unlimited需要注意兩點--ulimit標志自 Docker 1.6 起才受支持舊版本 Docker 無法使用示例把 core 與 memlock 都設(shè)為 100 GB 只是對unlimited的近似。如果你的宿主機內(nèi)存超過 100 GB應(yīng)把該數(shù)值調(diào)大以匹配系統(tǒng)可用內(nèi)存否則會人為限制 Couchbase 使用更多鎖定內(nèi)存。5.6 網(wǎng)絡(luò)配置與端口Couchbase Server 在多個端口上通信管理、查詢、數(shù)據(jù)、復(fù)制、TLS 等端口組并且一般不支持把集群節(jié)點放在任何 NAT 之后。基于這兩點Docker 默認的橋接網(wǎng)絡(luò)bridge/NAT 模式對 Couchbase Server 部署并不理想NAT 會破壞節(jié)點間的直接尋址影響集群心跳、復(fù)制與 XDCR端口轉(zhuǎn)發(fā)鏈路會引入額外開銷與不可預(yù)測性。因此官方建議生產(chǎn)部署使用--nethost宿主機網(wǎng)絡(luò)模式讓容器直接使用宿主機網(wǎng)絡(luò)棧避免性能與可靠性問題。代價是端口不再隔離、需要自行規(guī)劃宿主機端口占用這正符合 Couchbase 集群多端口直連 無 NAT的通信模型。六、多節(jié)點 Couchbase Server 集群的兩種部署拓撲當需要部署多節(jié)點集群時社區(qū)與官方實踐中存在兩種主流拓撲。6.1 拓撲一所有 Couchbase 容器放在同一臺物理機上這種模型常用于以最小規(guī)模模擬生產(chǎn)部署的開發(fā)/測試環(huán)境其架構(gòu)如下┌──────────────────────────────────────────────────────────┐ │ Host OS (Linux) │ │ │ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ │ │ Container OS │ │ Container OS │ │ Container OS │ │ │ │ (Ubuntu) │ │ (Ubuntu) │ │ (Ubuntu) │ │ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │ │ │ Couchbase │ │ │ │ Couchbase │ │ │ │ Couchbase │ │ │ │ │ │ Server │ │ │ │ Server │ │ │ │ Server │ │ │ │ │ └───────────┘ │ │ └───────────┘ │ │ └───────────┘ │ │ │ └───────────────┘ └───────────────┘ └───────────────┘ │ └──────────────────────────────────────────────────────────┘優(yōu)點資源集中、部署簡單適合開發(fā)與測試。限制必須清醒認識所有容器競爭同一臺物理機的資源集群依托復(fù)制機制提供的節(jié)點失效保護被整體削弱——當這臺物理機故障時所有容器同時不可用所有副本一并丟失。這些限制對測試系統(tǒng)或許可以接受但不推薦用于生產(chǎn)應(yīng)用。6.2 拓撲二每個 Couchbase 容器獨占一臺物理機這是生產(chǎn)環(huán)境的標準部署模型也是Couchbase Server 5.5 及以上版本官方支持的生產(chǎn)拓撲┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐ │ Host OS (Linux) │ │ Host OS (Linux) │ │ Host OS (Linux) │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ │ Container OS │ │ │ │ Container OS │ │ │ │ Container OS │ │ │ │ (Ubuntu) │ │ │ │ (Ubuntu) │ │ │ │ (Ubuntu) │ │ │ │ ┌───────────┐ │ │ │ │ ┌───────────┐ │ │ │ │ ┌───────────┐ │ │ │ │ │ Couchbase │ │ │ │ │ │ Couchbase │ │ │ │ │ │ Couchbase │ │ │ │ │ │ Server │ │ │ │ │ │ Server │ │ │ │ │ │ Server │ │ │ │ │ └───────────┘ │ │ │ │ └───────────┘ │ │ │ │ └───────────┘ │ │ │ └─────────────────┘ │ │ └─────────────────┘ │ │ └─────────────────┘ │ └───────────────────────┘ └───────────────────────┘ └───────────────────────┘優(yōu)勢各節(jié)點互不踩踏不爭搶資源性能可預(yù)測性更好單臺物理機故障只會損失一個節(jié)點其余副本仍可服務(wù)真正兌現(xiàn)復(fù)制機制的高可用價值。該模型與第 5.2 節(jié)不同物理硬件的建議完全一致。官方在 Couchbase Server 的 Docker 部署文檔中分別給出了這兩種拓撲的詳細搭建步驟getting-started-docker章節(jié)可作為后續(xù)操作參考。七、延伸Couchbase Cloud 托管服務(wù)除自托管 Docker 部署外官方還提供Couchbase Cloud——一個面向關(guān)鍵任務(wù)應(yīng)用的、全托管的 NoSQL數(shù)據(jù)庫即服務(wù)DBaaS。其交付模式是在用戶自己的 AWS VPC 內(nèi)部署 Couchbase Cloud并由官方負責負載管理用戶獲得的是價格/性能比與運維透明度的提升。它適合不想自建集群基礎(chǔ)設(shè)施、希望聚焦業(yè)務(wù)研發(fā)的團隊作為延伸選項與原文檔中在任意云、任意規(guī)模下部署的定位相呼應(yīng)。八、版本與許可說明Couchbase Server 分兩個版本詳見倉庫中的 couchbase/license.mdEnterprise Edition企業(yè)版可用于開發(fā)與測試的免費許可生產(chǎn)部署需要付費訂閱。Community Edition社區(qū)版可免費部署面向最多 5 個節(jié)點的部門級集群注意社區(qū)版不允許使用 XDCR——該功能已改為企業(yè)版獨占特性。此外Docker 鏡像內(nèi)除 Couchbase Server 外還可能包含來自基礎(chǔ)發(fā)行版的其它軟件Bash 等及其直接/間接依賴這些軟件可能遵循其它許可。使用任何預(yù)構(gòu)建鏡像前使用者有責任確認其中所有軟件的許可合規(guī)性。九、相關(guān)資源與倉庫文件索引如果你想繼續(xù)深入本倉庫內(nèi)與本文直接相關(guān)的文件包括couchbase/content.md —— 本文的權(quán)威來源文檔鏡像描述正文couchbase/README.md —— 由content.md渲染生成的最終對外 README含全部受支持標簽與架構(gòu)列表couchbase/license.md —— Enterprise / Community 雙版本許可說明couchbase/metadata.json —— 鏡像分類元數(shù)據(jù)databases-and-storagecouchbase/github-repo 與 couchbase/maintainer.md —— 維護方與鏡像源碼倉庫指引update.sh —— 將各content.md與模板合并生成README.md的自動化腳本腳本對每個含content.md的目錄執(zhí)行標簽、架構(gòu)、Logo、許可等字段替換.template-helpers/template.md —— README 的統(tǒng)一模板定義了Quick reference / Supported tags / 許可等章節(jié)骨架。掌握本文的端口規(guī)劃、初始化向?qū)?、N1QL 驗證、SDK 接入、持久化與 ulimit 配置、以及兩種集群拓撲的取舍你就能在容器環(huán)境中從零到一地構(gòu)建一套可開發(fā)、可測試、可上線的 Couchbase Server 部署方案。贊分享文檔【免費下載鏈接】docsDocumentation for Docker Official Images in docker-library項目地址https://gitcode.com/gh_mirrors/docs/docs點擊查看免費下載相關(guān)推薦Bonita Docker 官方鏡像實戰(zhàn)指南快速部署、PostgreSQL 集成與生產(chǎn)級配置Bonita Docker 官方鏡像實戰(zhàn)指南快速部署、PostgreSQL 集成與生產(chǎn)級配置 本篇指南以 Docker Official Images 倉庫中文檔RisingWave Kubernetes部署終極指南從單節(jié)點到生產(chǎn)集群實戰(zhàn)RisingWave Kubernetes部署終極指南從單節(jié)點到生產(chǎn)集群實戰(zhàn) RisingWave是一個開源的分布式流處理數(shù)據(jù)庫專為實時數(shù)據(jù)分析和流式計算而數(shù)據(jù)庫流處理后端數(shù)據(jù)工程gaianet-node Docker 部署實戰(zhàn)從快速啟動到鏡像構(gòu)建與節(jié)點 ID 管理gaianet node Docker 部署實戰(zhàn)從快速啟動到鏡像構(gòu)建與節(jié)點 ID 管理 本文以 gaianet node 倉庫的 docker/README.AI 應(yīng)用大模型CLIRAG上一篇ezdxf 完整上手指南Python 讀寫 DXF 文件并渲染出圖的快速入門下一篇Ryzen處理器調(diào)不明白SMUDebugTool幫你把電壓和SMU狀態(tài)都攤開看創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Couchbase Server 官方 Docker 鏡像實戰(zhàn)指南：從單節(jié)點快速啟動到生產(chǎn)級集群部署
文檔【免費下載鏈接】docsDocumentation for Docker Official Images in docker-library項目地址https://gitcode.com/gh_mirrors/docs/docs點擊查看免費下載本文以 Docker Official Images 倉庫中的 couchbase/content.md 為骨架系統(tǒng)講解如何用couchbase官方 Docker 鏡像快速搭建單節(jié)點集群、完成初始化與 N1QL 查詢驗證、通過 SDK 接入應(yīng)用并給出生產(chǎn)環(huán)境下的資源規(guī)劃、持久化、ulimit、網(wǎng)絡(luò)配置以及多節(jié)點集群部署拓撲等最佳實踐。讀完本文你將具備從一條 docker run 起一個實例到規(guī)劃一套可支撐生產(chǎn)的多節(jié)點 Couchbase 集群的完整實操能力。一、Couchbase Server 與官方 Docker 鏡像概覽Couchbase Server 是一款構(gòu)建于 NoSQL 技術(shù)之上的分布式文檔數(shù)據(jù)庫官方鏡像說明文檔 couchbase/content.md 將其核心能力概括為三點內(nèi)存優(yōu)先架構(gòu)memory-first architecture以內(nèi)存為第一優(yōu)先級的存儲與索引設(shè)計支撐亞毫秒級延遲與 99.999% 可用性原文表述配合端到端數(shù)據(jù)壓縮顯著降低網(wǎng)絡(luò)、內(nèi)存與存儲成本。全面的 SQL 兼容查詢語言 N1QL支持 ANSI join讓從傳統(tǒng) RDBMS 遷移到 Couchbase 變得平滑。多云與跨數(shù)據(jù)中心能力內(nèi)置 active-active 跨數(shù)據(jù)中心復(fù)制XDCR并提供 Kubernetes 等云集成降低運維負擔。在倉庫元數(shù)據(jù)層面couchbase/metadata.json 將該鏡像歸類于databases-and-storage數(shù)據(jù)庫與存儲類別couchbase/README-short.txt 用一句話概括其定位Couchbase Server 是一個具有分布式架構(gòu)的 NoSQL 文檔數(shù)據(jù)庫。值得一提的是本倉庫的文檔組織方式是源碼驅(qū)動生成真正的維護者書寫 couchbase/content.md再由倉庫根目錄的 update.sh 腳本結(jié)合 .template-helpers/template.md 等模板把標簽列表、架構(gòu)列表、Logo、許可信息等元數(shù)據(jù)自動拼裝成對外展示的 couchbase/README.md。因此本文以content.md為權(quán)威主體展開讀者也可以對照兩份文件查看渲染前后的差異。二、快速啟動用 Docker 跑起單節(jié)點 Couchbase Server 集群2.1 第一步運行容器并規(guī)劃端口映射在宿主機執(zhí)行以下命令即可啟動一個單節(jié)點的 Couchbase Server 容器$ docker run -d --name db -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 couchbase命令要點說明參數(shù)含義-d以守護進程方式在后臺運行--name db給容器命名為db后續(xù)docker exec與docker stop均以此引用-p 8091-8097:8091-8097映射 Web Console 與管理/查詢等 HTTP 服務(wù)端口組其中8091 是 Web Console 的訪問端口-p 9123:9123映射分析Analytics等附加服務(wù)端口-p 11207:11207映射加密數(shù)據(jù)服務(wù)端口-p 11210:11210映射數(shù)據(jù)面memcached 協(xié)議/數(shù)據(jù)訪問端口-p 11280:11280映射代理數(shù)據(jù)服務(wù)端口-p 18091-18097:18091-18097映射與 8091-8097 對應(yīng)的 TLS 加密端口組需要特別說明的是原文檔明確提示Couchbase Server 究竟需要暴露哪些端口取決于具體使用場景上面這一組端口覆蓋了多數(shù)典型場景但并非所有場景的最小集。在真正規(guī)劃生產(chǎn)網(wǎng)絡(luò)時應(yīng)依據(jù) Couchbase Server 官方端口清單文檔install-ports逐項核對這里不再贅述外部鏈接。2.2 第二步通過 Web Console 完成初始化容器啟動后在宿主機瀏覽器訪問http://localhost:8091即可打開Web Console進入 Couchbase Server 的 Setup 向?qū)А０聪驅(qū)崾局鸩讲僮鞑⒔邮苣J值即可完成集群初始化操作時注意兩點內(nèi)存預(yù)算向?qū)е袝鬄?Data、Index、Query、Search、Analytics 等不同服務(wù)分配內(nèi)存。容器內(nèi)的可用內(nèi)存有限通常需要主動調(diào)低各服務(wù)的 RAM 分配使其落在容器資源邊界之內(nèi)否則初始化可能失敗或運行時 OOM。示例數(shù)據(jù)建議在向?qū)е袉⒂胋eer-samplebucket它會自動加載啤酒釀造相關(guān)的示例文檔后續(xù)的 N1QL 查詢演示正是基于這個 bucket 展開的。提示關(guān)于 Couchbase Server 的更詳細生產(chǎn)配置官方提供了 Deployment Guidelines部署指南文檔涵蓋內(nèi)存、磁盤、網(wǎng)絡(luò)等多維度的生產(chǎn)初始化建議可作為深入閱讀的下一站。2.3 驗證容器狀態(tài)初始化完成后可以通過容器命令驗證集群健康狀態(tài)。例如$ docker exec -it db couchbase-cli server-info -c localhost:8091 -u Administrator -p passwordcouchbase-cli是鏡像內(nèi)自帶的命令行管理工具也可以直接在 Web Console 的 UI 首頁觀察節(jié)點狀態(tài)。三、用 N1QL 查詢示例數(shù)據(jù)N1QL 是 Couchbase Server 基于 SQL 的查詢語言語法風格貼近 SQL但面向 JSON 文檔模型。針對beer-samplebucket可以執(zhí)行如下查詢找出指定酒廠mishawaka_brewing釀造的所有啤酒名稱SELECT name FROM beer-sample WHERE brewery_idmishawaka_brewing;注意bucket 名在 N1QL 中需要用反引號包裹以避免與關(guān)鍵字沖突。3.1 方式一Web Console 的 Query 工作臺在 Web Console 頂部切換到Query選項卡在查詢窗口中粘貼上面的語句并執(zhí)行即可看到返回的 JSON 結(jié)果列表。這是最直觀的交互式查詢方式適合臨時探索數(shù)據(jù)。3.2 方式二cbq 命令行工具在容器內(nèi)通過docker exec進入cbqCouchbase 交互式查詢 Shell使用初始化向?qū)r設(shè)置的憑據(jù)認證$ docker exec -it db cbq --user Administrator cbq SELECT name FROM beer-sample WHERE brewery_id mishawaka_brewing;在cbq提示符下輸入查詢語句并回車即可執(zhí)行。該方式適合在腳本化、自動化場景中復(fù)用也是 CI/CD 中做數(shù)據(jù)校驗的常用手段。更豐富的 N1QL 示例可參考 Couchbase Server 官方運行你的第一個 N1QL 查詢教程try-a-query。四、通過應(yīng)用 SDK 連接集群Couchbase Server 官方 SDK 覆蓋多種主流語言C、Go、Java、.NET、Node.js、PHP、Python。在宿主機上運行你的應(yīng)用將 bootstrap 連接串指向容器的 HTTP 端口即可http://localhost:8091/pools該端點返回集群的 pool 信息節(jié)點列表、bucket 列表等SDK 據(jù)此完成拓撲發(fā)現(xiàn)與連接管理。連接時使用與向?qū)б恢碌腁dministrator用戶名與密碼并在代碼中指定要訪問的 bucket如beer-sample。以 Java SDK 為例典型的連接方式為Cluster cluster Cluster.connect(localhost, Administrator, password); Bucket bucket cluster.bucket(beer-sample);其余語言的接入模式完全一致構(gòu)建連接串 → 認證 → 獲取 bucket 句柄 → 執(zhí)行 KV 或 N1QL 操作。更完整的端到端示例含 CRUD 與查詢可參考 Couchbase Server 官方提供的 Sample Application示例應(yīng)用指南。五、容器需求與生產(chǎn)部署最佳實踐5.1 基礎(chǔ)鏡像與資源需求官方 Couchbase Server 鏡像基于最新受支持的 Ubuntu 版本構(gòu)建。容器的內(nèi)存、CPU、磁盤最低需求應(yīng)參照 Couchbase Server 官方的System Resource Requirements系統(tǒng)資源需求文檔分別按開發(fā)development、測試test與生產(chǎn)production環(huán)境取不同檔位這里同樣只做指引、不展開外部鏈接。5.2 避免單點故障Couchbase Server 的高可用依賴集群 副本機制多個獨立節(jié)點組成集群并在節(jié)點間復(fù)制數(shù)據(jù)任何一個節(jié)點失效都不會導(dǎo)致數(shù)據(jù)不可訪問。但在容器化環(huán)境中有一個容易被忽略的陷阱如果多個 Couchbase 節(jié)點跑在同一臺物理機器上等于把單點故障又請了回來——這臺物理機一旦宕機其上的所有容器會同時不可用所有副本一起丟失。因此在能夠控制虛擬機/物理機放置位置的環(huán)境中官方建議確保每個 Couchbase Server 節(jié)點運行在不同的物理硬件上。5.3 容器規(guī)格CPU 建議容器的確會在 Couchbase Server 與底層 OS 之間引入一層輕量開銷。為保證穩(wěn)定性與性能可預(yù)測性開發(fā)環(huán)境至少為容器獨占 2 個 CPU 核心生產(chǎn)環(huán)境建議為容器獨占 4 個核心而不是與其他容器共享核心。核心思想是避免 over-commit資源超賣一旦多個容器互相爭搶 CPU會出現(xiàn)性能不可預(yù)測甚至穩(wěn)定性問題。5.4 持久化把 /opt/couchbase/var 映射到宿主機目錄默認情況下Couchbase Server 容器會把所有持久化數(shù)據(jù)與節(jié)點專屬數(shù)據(jù)寫入容器內(nèi)的/opt/couchbase/var目錄。官方強烈建議用-v選項將該目錄映射到宿主機文件系統(tǒng)$ docker run -d --name db \ -v ~/couchbase:/opt/couchbase/var \ -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 \ -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 \ couchbase這樣做有雙重收益持久性Persistence數(shù)據(jù)存放在宿主機上刪除容器后用同一數(shù)據(jù)目錄重新創(chuàng)建容器數(shù)據(jù)不會丟失甚至可以直接升級到更新版本/更高 release 的鏡像數(shù)據(jù)依舊完好。性能Performance標準 Docker 環(huán)境使用 union 文件系統(tǒng)疊加層若把/opt/couchbase/var留在容器內(nèi)部會引入一定的寫入性能損耗映射為宿主機卷可規(guī)避該損耗。SELinux 環(huán)境下的額外步驟如果你的宿主機啟用了 SELinux把宿主機目錄掛載進容器需要額外一步。假設(shè)要掛載宿主機的~/couchbase目錄需要在首次運行容器之前在該宿主機上執(zhí)行一次$ mkdir ~/couchbase chcon -Rt svirt_sandbox_file_t ~/couchbasechcon為目錄打上svirt_sandbox_file_t上下文標簽容器才被允許讀寫該掛載點。5.5 生產(chǎn)環(huán)境提升 ulimitCouchbase Server 在高負載下對進程資源限額有明確預(yù)期ulimit -n 200000 # nofile: 最大打開文件數(shù) ulimit -l unlimited # memlock: 最大鎖定內(nèi)存地址空間在輕量測試與開發(fā)場景下可以省略這些設(shè)置系統(tǒng)仍可正常工作但在重負載生產(chǎn)環(huán)境下必須設(shè)置否則可能出現(xiàn)打開文件數(shù)耗盡或內(nèi)存無法鎖定導(dǎo)致的穩(wěn)定性問題。由于 Docker 不支持直接傳unlimited作為 ulimit 值官方給出的做法是在docker run時追加--ulimit標志用一個大數(shù)值近似代替$ docker run -d \ --ulimit nofile40960:40960 \ --ulimit core100000000:100000000 \ --ulimit memlock100000000:100000000 \ --name db \ -p 8091-8097:8091-8097 -p 9123:9123 -p 11207:11207 \ -p 11210:11210 -p 11280:11280 -p 18091-18097:18091-18097 \ couchbase參數(shù)解讀標志語義說明--ulimit nofile40960:40960軟/硬限制均為 40960 個打開文件對應(yīng)主機側(cè)ulimit -n的容器化表達--ulimit core100000000:100000000核心轉(zhuǎn)儲文件大小上限100000000 按官方說明對應(yīng)約 100 GB--ulimit memlock100000000:100000000鎖定內(nèi)存上限同上約 100 GB替代unlimited需要注意兩點--ulimit標志自 Docker 1.6 起才受支持舊版本 Docker 無法使用示例把 core 與 memlock 都設(shè)為 100 GB 只是對unlimited的近似。如果你的宿主機內(nèi)存超過 100 GB應(yīng)把該數(shù)值調(diào)大以匹配系統(tǒng)可用內(nèi)存否則會人為限制 Couchbase 使用更多鎖定內(nèi)存。5.6 網(wǎng)絡(luò)配置與端口Couchbase Server 在多個端口上通信管理、查詢、數(shù)據(jù)、復(fù)制、TLS 等端口組并且一般不支持把集群節(jié)點放在任何 NAT 之后。基于這兩點Docker 默認的橋接網(wǎng)絡(luò)bridge/NAT 模式對 Couchbase Server 部署并不理想NAT 會破壞節(jié)點間的直接尋址影響集群心跳、復(fù)制與 XDCR端口轉(zhuǎn)發(fā)鏈路會引入額外開銷與不可預(yù)測性。因此官方建議生產(chǎn)部署使用--nethost宿主機網(wǎng)絡(luò)模式讓容器直接使用宿主機網(wǎng)絡(luò)棧避免性能與可靠性問題。代價是端口不再隔離、需要自行規(guī)劃宿主機端口占用這正符合 Couchbase 集群多端口直連 無 NAT的通信模型。六、多節(jié)點 Couchbase Server 集群的兩種部署拓撲當需要部署多節(jié)點集群時社區(qū)與官方實踐中存在兩種主流拓撲。6.1 拓撲一所有 Couchbase 容器放在同一臺物理機上這種模型常用于以最小規(guī)模模擬生產(chǎn)部署的開發(fā)/測試環(huán)境其架構(gòu)如下┌──────────────────────────────────────────────────────────┐ │ Host OS (Linux) │ │ │ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ │ │ Container OS │ │ Container OS │ │ Container OS │ │ │ │ (Ubuntu) │ │ (Ubuntu) │ │ (Ubuntu) │ │ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ │ │ │ Couchbase │ │ │ │ Couchbase │ │ │ │ Couchbase │ │ │ │ │ │ Server │ │ │ │ Server │ │ │ │ Server │ │ │ │ │ └───────────┘ │ │ └───────────┘ │ │ └───────────┘ │ │ │ └───────────────┘ └───────────────┘ └───────────────┘ │ └──────────────────────────────────────────────────────────┘優(yōu)點資源集中、部署簡單適合開發(fā)與測試。限制必須清醒認識所有容器競爭同一臺物理機的資源集群依托復(fù)制機制提供的節(jié)點失效保護被整體削弱——當這臺物理機故障時所有容器同時不可用所有副本一并丟失。這些限制對測試系統(tǒng)或許可以接受但不推薦用于生產(chǎn)應(yīng)用。6.2 拓撲二每個 Couchbase 容器獨占一臺物理機這是生產(chǎn)環(huán)境的標準部署模型也是Couchbase Server 5.5 及以上版本官方支持的生產(chǎn)拓撲┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────┐ │ Host OS (Linux) │ │ Host OS (Linux) │ │ Host OS (Linux) │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ │ Container OS │ │ │ │ Container OS │ │ │ │ Container OS │ │ │ │ (Ubuntu) │ │ │ │ (Ubuntu) │ │ │ │ (Ubuntu) │ │ │ │ ┌───────────┐ │ │ │ │ ┌───────────┐ │ │ │ │ ┌───────────┐ │ │ │ │ │ Couchbase │ │ │ │ │ │ Couchbase │ │ │ │ │ │ Couchbase │ │ │ │ │ │ Server │ │ │ │ │ │ Server │ │ │ │ │ │ Server │ │ │ │ │ └───────────┘ │ │ │ │ └───────────┘ │ │ │ │ └───────────┘ │ │ │ └─────────────────┘ │ │ └─────────────────┘ │ │ └─────────────────┘ │ └───────────────────────┘ └───────────────────────┘ └───────────────────────┘優(yōu)勢各節(jié)點互不踩踏不爭搶資源性能可預(yù)測性更好單臺物理機故障只會損失一個節(jié)點其余副本仍可服務(wù)真正兌現(xiàn)復(fù)制機制的高可用價值。該模型與第 5.2 節(jié)不同物理硬件的建議完全一致。官方在 Couchbase Server 的 Docker 部署文檔中分別給出了這兩種拓撲的詳細搭建步驟getting-started-docker章節(jié)可作為后續(xù)操作參考。七、延伸Couchbase Cloud 托管服務(wù)除自托管 Docker 部署外官方還提供Couchbase Cloud——一個面向關(guān)鍵任務(wù)應(yīng)用的、全托管的 NoSQL數(shù)據(jù)庫即服務(wù)DBaaS。其交付模式是在用戶自己的 AWS VPC 內(nèi)部署 Couchbase Cloud并由官方負責負載管理用戶獲得的是價格/性能比與運維透明度的提升。它適合不想自建集群基礎(chǔ)設(shè)施、希望聚焦業(yè)務(wù)研發(fā)的團隊作為延伸選項與原文檔中在任意云、任意規(guī)模下部署的定位相呼應(yīng)。八、版本與許可說明Couchbase Server 分兩個版本詳見倉庫中的 couchbase/license.mdEnterprise Edition企業(yè)版可用于開發(fā)與測試的免費許可生產(chǎn)部署需要付費訂閱。Community Edition社區(qū)版可免費部署面向最多 5 個節(jié)點的部門級集群注意社區(qū)版不允許使用 XDCR——該功能已改為企業(yè)版獨占特性。此外Docker 鏡像內(nèi)除 Couchbase Server 外還可能包含來自基礎(chǔ)發(fā)行版的其它軟件Bash 等及其直接/間接依賴這些軟件可能遵循其它許可。使用任何預(yù)構(gòu)建鏡像前使用者有責任確認其中所有軟件的許可合規(guī)性。九、相關(guān)資源與倉庫文件索引如果你想繼續(xù)深入本倉庫內(nèi)與本文直接相關(guān)的文件包括couchbase/content.md —— 本文的權(quán)威來源文檔鏡像描述正文couchbase/README.md —— 由content.md渲染生成的最終對外 README含全部受支持標簽與架構(gòu)列表couchbase/license.md —— Enterprise / Community 雙版本許可說明couchbase/metadata.json —— 鏡像分類元數(shù)據(jù)databases-and-storagecouchbase/github-repo 與 couchbase/maintainer.md —— 維護方與鏡像源碼倉庫指引update.sh —— 將各content.md與模板合并生成README.md的自動化腳本腳本對每個含content.md的目錄執(zhí)行標簽、架構(gòu)、Logo、許可等字段替換.template-helpers/template.md —— README 的統(tǒng)一模板定義了Quick reference / Supported tags / 許可等章節(jié)骨架。掌握本文的端口規(guī)劃、初始化向?qū)?、N1QL 驗證、SDK 接入、持久化與 ulimit 配置、以及兩種集群拓撲的取舍你就能在容器環(huán)境中從零到一地構(gòu)建一套可開發(fā)、可測試、可上線的 Couchbase Server 部署方案。贊分享文檔【免費下載鏈接】docsDocumentation for Docker Official Images in docker-library項目地址https://gitcode.com/gh_mirrors/docs/docs點擊查看免費下載相關(guān)推薦Bonita Docker 官方鏡像實戰(zhàn)指南快速部署、PostgreSQL 集成與生產(chǎn)級配置Bonita Docker 官方鏡像實戰(zhàn)指南快速部署、PostgreSQL 集成與生產(chǎn)級配置 本篇指南以 Docker Official Images 倉庫中文檔RisingWave Kubernetes部署終極指南從單節(jié)點到生產(chǎn)集群實戰(zhàn)RisingWave Kubernetes部署終極指南從單節(jié)點到生產(chǎn)集群實戰(zhàn) RisingWave是一個開源的分布式流處理數(shù)據(jù)庫專為實時數(shù)據(jù)分析和流式計算而數(shù)據(jù)庫流處理后端數(shù)據(jù)工程gaianet-node Docker 部署實戰(zhàn)從快速啟動到鏡像構(gòu)建與節(jié)點 ID 管理gaianet node Docker 部署實戰(zhàn)從快速啟動到鏡像構(gòu)建與節(jié)點 ID 管理 本文以 gaianet node 倉庫的 docker/README.AI 應(yīng)用大模型CLIRAG上一篇ezdxf 完整上手指南Python 讀寫 DXF 文件并渲染出圖的快速入門下一篇Ryzen處理器調(diào)不明白SMUDebugTool幫你把電壓和SMU狀態(tài)都攤開看創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考