內(nèi)網(wǎng)做構(gòu)建這件事最容易被低估的就是依賴獲取這一環(huán)。項(xiàng)目一多、語言一雜Maven 拉 jar、YUM 裝 rpm、APT 裝 deb、npm 裝 node 模塊四套東西各自連各自的公網(wǎng)源誰斷了都得停下等。我這邊的研發(fā)環(huán)境就是這么個(gè)情況十幾條流水線混著 Java、Go 打包腳本、CentOS 基礎(chǔ)鏡像和 Ubuntu 構(gòu)建機(jī)新人入職配一次環(huán)境要折騰大半天。后來用Nexus3在內(nèi)網(wǎng)做了一套統(tǒng)一私庫把maven、yum、apt、nodejs四類倉庫全部收口到一臺(tái)機(jī)器上配好之后客戶端只需要改一個(gè)地址就能跑通全流程。這篇就把這套私庫環(huán)境從選型、安裝、建倉、客戶端配置到排錯(cuò)按我實(shí)際落地的順序完整拆一遍參數(shù)和命令都能直接抄也把我踩過的幾個(gè)坑提前說出來。1. 方案先想清楚Nexus3 擺什么位置四類倉庫怎么分工動(dòng)手裝之前先把這臺(tái)機(jī)器到底承擔(dān)什么角色想明白比裝完再返工省事得多。私庫這東西本質(zhì)上是內(nèi)網(wǎng)和外網(wǎng)之間的一個(gè)緩存加中轉(zhuǎn)層它既要把公網(wǎng)的東西拉下來存住又要能收下團(tuán)隊(duì)自己產(chǎn)出的包還要在客戶端眼里只暴露一個(gè)統(tǒng)一的入口地址。Nexus3 恰好把這三種能力做成了三種倉庫類型proxy 負(fù)責(zé)代理外部源并緩存hosted 負(fù)責(zé)托管內(nèi)部產(chǎn)物group 負(fù)責(zé)把前兩者聚合成一個(gè) URL。理解了這一層后面四類倉庫的搭法其實(shí)是同一套邏輯換個(gè)協(xié)議而已。1.1 內(nèi)網(wǎng)直連公網(wǎng)的三個(gè)現(xiàn)實(shí)痛點(diǎn)第一個(gè)痛點(diǎn)是速度和穩(wěn)定性。公網(wǎng)源在國內(nèi)訪問經(jīng)常抖動(dòng)Maven 中央倉庫拉一個(gè)稍大的依賴樹就能拖到十幾分鐘npm 裝一個(gè)前端工程動(dòng)輒幾百個(gè)包一旦中途超時(shí)整個(gè)npm install從頭再來。私庫把包緩存在本地磁盤第二次開始就是千兆內(nèi)網(wǎng)速度差別非常直觀。第二個(gè)痛點(diǎn)是安全和審計(jì)。開發(fā)機(jī)的構(gòu)建腳本如果直接連公網(wǎng)源等于給每臺(tái)機(jī)器都開了對外的下載權(quán)限一旦某個(gè)公網(wǎng)包被投毒內(nèi)網(wǎng)很難察覺也沒法追溯到底是誰在什么時(shí)候引入了哪個(gè)版本。私庫把下載入口收斂成一臺(tái)機(jī)器所有包的進(jìn)出都有記錄還能在 hosted 倉庫里做白名單式的內(nèi)部包發(fā)布。第三個(gè)痛點(diǎn)是離線可用。很多能力受限的機(jī)房、隔離網(wǎng)段、臨時(shí)搭建的測試環(huán)境根本連不上公網(wǎng)這時(shí)候如果沒有一套本地倉庫整個(gè)編譯流程直接卡死。私庫里緩存過的依賴在斷網(wǎng)狀態(tài)下依然能完整安裝這對做交付、做演示、給客戶部署的場景尤其關(guān)鍵。把這三條想清楚你就知道這套東西不是錦上添花而是基礎(chǔ)設(shè)施的一部分。1.2 proxy、hosted、group 三種倉庫的定位差異很多人第一次打開 Nexus3 新建倉庫的界面會(huì)懵類型太多不知道選哪個(gè)。其實(shí)抓住三種角色的分工就清楚了。proxy是代理加緩存你給它一個(gè)遠(yuǎn)端 URL它第一次請求時(shí)去遠(yuǎn)端拉拉到之后存在本地之后同樣的請求直接命中緩存Maven 中央倉庫、npm 官方源、各發(fā)行版的 yum/apt 源都屬于這一類。hosted是托管內(nèi)部產(chǎn)物團(tuán)隊(duì)自己編譯出來的 jar、打好的 rpm、deb 包、私有 npm 模塊都往這里發(fā)。它不連外網(wǎng)只接受上傳和下載是內(nèi)部交付的唯一可信來源。hosted 又分 Release 和 Snapshot 兩種版本策略這個(gè)在 Maven 里尤其重要后面會(huì)細(xì)說。group是聚合入口它自己不存東西只是把若干個(gè) proxy 和 hosted 按順序拼在一起客戶端訪問 group 的地址時(shí)Nexus 依次去成員倉庫里找找到就返回。對客戶端來說永遠(yuǎn)只需要配一個(gè) group 地址既拿到了公網(wǎng)緩存又拿到了內(nèi)部包還省得在配置里寫一堆 URL。我一般給每個(gè)協(xié)議都建一個(gè) group命名統(tǒng)一成xxx-group客戶端配置里只出現(xiàn)這一個(gè)地址。1.3 部署形態(tài)選型Docker 拉起還是裸機(jī) installNexus3 官方提供兩種主流部署方式。Docker 方式最省事拉個(gè)鏡像掛個(gè)數(shù)據(jù)卷就能跑升級就是換個(gè) tag回滾就是換回舊 tag對不熟悉 Java 服務(wù)的人特別友好。裸機(jī)安裝是把官方 tar 包解壓到某個(gè)目錄再用 systemd 托管好處是不依賴容器運(yùn)行時(shí)資源占用略低出問題時(shí)排查鏈路更短。我實(shí)際兩套都跑過。開發(fā)測試環(huán)境用 Docker因?yàn)樾枰l繁重建生產(chǎn)性的私庫用裸機(jī)因?yàn)檫@臺(tái)機(jī)器上還掛著別的服務(wù)不想再引入一層容器網(wǎng)絡(luò)。判斷標(biāo)準(zhǔn)很簡單你的機(jī)器上已經(jīng)有成熟的容器運(yùn)維體系就選 Docker如果是一臺(tái)孤立的虛擬機(jī)、后續(xù)沒人專門維護(hù)容器就裸機(jī)。兩種方式的數(shù)據(jù)目錄都是同一個(gè)結(jié)構(gòu)遷移時(shí)把數(shù)據(jù)目錄拷過去就行所以先選哪個(gè)都不算鎖死。2. 部署前的資源估算與 Nexus3 落地安裝資源這塊不能拍腦袋給少了后面 OOM給多了浪費(fèi)。我按自己的經(jīng)驗(yàn)給一套估算方法然后分別給出 Docker 和裸機(jī)的完整落地步驟。2.1 JVM 堆、磁盤和內(nèi)存的估算過程N(yùn)exus3 是個(gè) Java 應(yīng)用跑在 JVM 里默認(rèn)的最大堆是 2703MB。這個(gè)數(shù)字不是隨便定的官方給的經(jīng)驗(yàn)是堆內(nèi)存至少要能放下你最大單次請求涉及的對象而私庫場景里最大的一塊通常是首次代理一個(gè)大依賴樹或者一個(gè)大鏡像層時(shí)的臨時(shí)緩沖。我的估算方式是基礎(chǔ)堆 2GB 打底然后看你的倉庫規(guī)模。如果只是給幾十個(gè)項(xiàng)目做 Maven 加 npm 代理2GB 到 4GB 足夠。如果還要緩存大量 rpm/deb 并且并發(fā)構(gòu)建機(jī)器超過二十臺(tái)建議給到 6GB 到 8GB物理內(nèi)存留出堆的 1.5 到 2 倍因?yàn)?JVM 除了堆還有直接內(nèi)存、元空間、線程棧和文件緩存。磁盤是另一個(gè)大頭。Nexus3 的數(shù)據(jù)目錄里blob store 會(huì)隨著緩存不斷增長。一個(gè)中等規(guī)模的 Java 團(tuán)隊(duì)一年下來 Maven 緩存吃掉 50GB 到 200GB 很正常如果還代理 npm 和系統(tǒng)包翻倍也不奇怪。我的做法是數(shù)據(jù)目錄單獨(dú)掛一塊盤初始給 500GB配好清理策略并且提前把監(jiān)控做上別等到磁盤寫滿才發(fā)現(xiàn)。提示Nexus3 官方鏡像里 JVM 參數(shù)通過環(huán)境變量INSTALL4J_ADD_VM_PARAMS傳入裸機(jī)安裝則改bin/nexus.vmoptions。改完必須重啟進(jìn)程才生效在線改文件沒用。場景建議堆內(nèi)存建議磁盤說明個(gè)人或小團(tuán)隊(duì)只做 Maven 代理2GB100GB單機(jī)夠用注意清理中型團(tuán)隊(duì)Maven npm4GB500GB并發(fā)十臺(tái)以內(nèi)比較穩(wěn)多語言混合含 yum/apt6GB 到 8GB1TB需要配清理策略和監(jiān)控2.2 Docker 方式十幾分鐘拉起一個(gè)可用的私庫先建好數(shù)據(jù)目錄并授權(quán)。Nexus3 容器內(nèi)以 uid 200 運(yùn)行宿主機(jī)目錄權(quán)限不對會(huì)直接啟動(dòng)失敗這一步很多人會(huì)漏。sudo mkdir -p /data/nexus-data sudo chown -R 200:200 /data/nexus-data sudo chmod -R 775 /data/nexus-data然后用官方鏡像啟動(dòng)。注意把 JVM 參數(shù)和數(shù)據(jù)目錄一起傳進(jìn)去順便把 Java 的 preferences 目錄也指到數(shù)據(jù)卷里避免容器重建后配置丟失。docker run -d \ --name nexus3 \ --restart always \ -p 8081:8081 \ -v /data/nexus-data:/nexus-data \ -e INSTALL4J_ADD_VM_PARAMS-Xms4g -Xmx4g -XX:MaxDirectMemorySize4g -Djava.util.prefs.userRoot/nexus-data/javaprefs \ sonatype/nexus3:3.70.1啟動(dòng)完成后docker logs -f nexus3觀察日志出現(xiàn)Started Sonatype Nexus字樣就說明起來了。第一次啟動(dòng)會(huì)初始化數(shù)據(jù)庫通常要一到三分鐘機(jī)器慢的話更久別急著判定失敗。注意數(shù)據(jù)目錄權(quán)限問題是 Nexus3 啟動(dòng)失敗最常見的原因日志里一般會(huì)提示Permission denied或者直接卡住不輸出。遇到先查目錄屬主再查 SELinux。2.3 裸機(jī)安裝與 systemd 托管裸機(jī)安裝的步驟是先準(zhǔn)備 JDK再解壓 tar 包最后寫成 systemd 服務(wù)。Nexus3 各版本對 JDK 的要求不一樣3.6x 之后的版本普遍要求 JDK 8 或 11動(dòng)手前一定去確認(rèn)對應(yīng)版本的官方要求別隨便裝個(gè)新版 JDK 上去。# 以 JDK 11 為例路徑按你實(shí)際安裝位置調(diào)整 sudo mkdir -p /opt/nexus sudo tar -zxvf nexus-3.70.1-02-unix.tar.gz -C /opt/nexus --strip-components1 sudo useradd -r -s /sbin/nologin nexus sudo chown -R nexus:nexus /opt/nexus改bin/nexus.vmoptions把堆參數(shù)調(diào)成你估算的值-Xms4g -Xmx4g -XX:MaxDirectMemorySize4g -XX:UnlockDiagnosticVMOptions -XX:LogVMOutput -XX:LogFile../sonatype-work/nexus3/log/jvm.log接著寫 systemd 單元讓進(jìn)程跟著系統(tǒng)啟動(dòng)崩潰也能自動(dòng)拉起來[Unit] DescriptionNexus Repository Manager Afternetwork.target [Service] Typeforking LimitNOFILE65536 ExecStart/opt/nexus/bin/nexus start ExecStop/opt/nexus/bin/nexus stop Usernexus Restarton-abort [Install] WantedBymulti-user.target寫完執(zhí)行systemctl daemon-reload再systemctl enable --now nexus。這里有個(gè)容易忽略的點(diǎn)LimitNOFILE要給足私庫并發(fā)高的時(shí)候文件句柄消耗很快默認(rèn) 1024 會(huì)在壓力上來后出現(xiàn)莫名其妙的連接失敗。我給到 65536實(shí)測很穩(wěn)。2.4 首次登錄必須做的三件事新版本 Nexus3 的初始密碼不再固定是admin/admin123而是隨機(jī)生成后寫在一個(gè)文件里Docker 方式在/nexus-data/admin.password裸機(jī)在sonatype-work/nexus3/admin.password。cat /data/nexus-data/admin.password拿到密碼后用admin登錄http://你的IP:8081系統(tǒng)會(huì)引導(dǎo)你改密碼。改完密碼只是第一步另外三件事我建議當(dāng)天就做完第一關(guān)掉匿名訪問或明確配置匿名可讀范圍第二刪掉默認(rèn)的 demo 倉庫避免誤用第三建一個(gè)專用的deploy用戶只給上傳權(quán)限CI 里用這個(gè)賬號不要用 admin。這三件事看著瑣碎但直接決定了后面私庫是不是安全可控。我見過不少環(huán)境圖省事一直用 admin 給所有客戶端發(fā)憑據(jù)一旦泄露就是全庫可寫可刪補(bǔ)救成本極高。3. Maven 私庫搭建hosted、proxy、group 三件套怎么拼Maven 是這套私庫里用得最多的部分也是最容易配錯(cuò)的部分。我的做法是固定建三個(gè)倉庫一個(gè) hosted 收內(nèi)部包一個(gè) proxy 代理中央倉庫一個(gè) group 把兩者聚合客戶端只認(rèn) group。3.1 建倉庫的順序和命名規(guī)范順序上建議先 hosted再 proxy最后 group因?yàn)?group 的成員列表在創(chuàng)建時(shí)就要選前面的沒建好后面選不到。命名我用固定的后綴區(qū)分maven-releases、maven-snapshots、maven-central、maven-public。這樣一看名字就知道類型后期維護(hù)和交接都省心。hosted 倉庫分兩個(gè)是刻意的。Release 版本的包一旦發(fā)布就不應(yīng)該被覆蓋Snapshot 版本可以反復(fù)覆蓋發(fā)布。把兩者分開可以在組策略和清理策略上差異化處理比如給 Snapshot 配定期清理給 Release 配置為不可重復(fù)部署。這個(gè)區(qū)分在做正式交付的時(shí)候非常有用。3.2 proxy 代理中央倉庫的幾個(gè)關(guān)鍵參數(shù)新建 maven2(proxy) 時(shí)遠(yuǎn)端地址填https://repo1.maven.org/maven2/其余參數(shù)大部分可以用默認(rèn)值但有兩個(gè)地方我調(diào)整過。一個(gè)是版本策略proxy 的Version policy保持Mixed即可因?yàn)橹醒雮}庫里既有 release 也有 snapshot。另一個(gè)是緩存過期時(shí)間默認(rèn)的Not Found Cache TTL是 1440 分鐘意思是某個(gè)包如果確定不存在1440 分鐘內(nèi)不再去遠(yuǎn)端查詢。這個(gè)值對內(nèi)網(wǎng)體驗(yàn)影響很大遇到構(gòu)建突然報(bào)找不到某個(gè)剛發(fā)布的版本先想想是不是被這個(gè)緩存擋了臨時(shí)可以把值改小或者手動(dòng)清理緩存。如果你的環(huán)境有穩(wěn)定的國內(nèi)鏡像可用也可以再建一個(gè) proxy 指向它然后在 group 里排到中央倉庫前面命中率更高。但要記住無論后面掛幾個(gè) proxy客戶端配置里永遠(yuǎn)只出現(xiàn) group 地址這是這套設(shè)計(jì)能穩(wěn)定運(yùn)行的前提。3.3 settings.xml 與 pom.xml 可直接抄的配置客戶端側(cè)主要改兩個(gè)文件。全局的settings.xml配鏡像和憑據(jù)項(xiàng)目的pom.xml配發(fā)布地址。先看settings.xml把鏡像指向 group同時(shí)在 servers 里放上傳憑據(jù)settings mirrors mirror idnexus/id namenexus private maven/name urlhttp://192.168.1.100:8081/repository/maven-public//url mirrorOf*/mirrorOf /mirror /mirrors servers server idnexus-releases/id usernamedeploy/username password你的部署密碼/password /server server idnexus-snapshots/id usernamedeploy/username password你的部署密碼/password /server /servers /settings這里mirrorOf用*表示接管所有倉庫請求。有人會(huì)擔(dān)心這樣連不上其他私有源解決辦法是在 group 里把那些源也建成 proxy 成員而不是在客戶端放開多個(gè)鏡像。保持客戶端配置單一后期換地址只需要改一處。pom.xml里加發(fā)布地址distributionManagement repository idnexus-releases/id urlhttp://192.168.1.100:8081/repository/maven-releases//url /repository snapshotRepository idnexus-snapshots/id urlhttp://192.168.1.100:8081/repository/maven-snapshots//url /snapshotRepository /distributionManagement配好之后mvn deploy就能把包推到私庫其他項(xiàng)目通過mvn clean package自動(dòng)從 group 拉取。3.4 快照版本與發(fā)布版本的策略區(qū)別這塊是我踩坑最多的地方。Release 倉庫默認(rèn)策略是Disable redeploy也就是同一個(gè)版本號不允許重復(fù)發(fā)布這是為了保證金版本不可變。如果你調(diào)試時(shí)反復(fù)發(fā)同一個(gè)版本號會(huì)收到 400 錯(cuò)誤報(bào)錯(cuò)信息里會(huì)提到 redeploy。解決辦法是要么升版本號要么臨時(shí)把倉庫策略改成 Allow redeploy但正式環(huán)境千萬別改否則版本就失去可信度了。Snapshot 倉庫則相反允許覆蓋每次發(fā)布自動(dòng)帶時(shí)間戳后綴?？蛻舳死?snapshot 時(shí)會(huì)檢查遠(yuǎn)程的maven-metadata.xml所以如果你本地mvn -U還是拿到舊包很可能是 metadata 緩存沒刷新可以手動(dòng)觸發(fā)一次更新或者等緩存過期。實(shí)操心得給 Snapshot 倉庫單獨(dú)配一條清理策略比如保留最近 30 天或者每個(gè)包最多保留 10 個(gè)快照。不做這件事快照目錄會(huì)以肉眼可見的速度膨脹半年就能吃掉幾百 GB。4. YUM 私庫把 RPM 統(tǒng)一收口Java 團(tuán)隊(duì)之外只要涉及 CentOS、RHEL 一類的系統(tǒng)鏡像構(gòu)建就繞不開 YUM。私庫里做 YUM 的價(jià)值在于內(nèi)網(wǎng)機(jī)器不再需要各自配置一堆外網(wǎng)源所有 rpm 從一處下發(fā)離線環(huán)境也能裝。4.1 yum hosted 與 yum proxy 的建法差異新建時(shí)選yum (proxy)或yum (hosted)。proxy 的遠(yuǎn)端地址填你要代理的發(fā)行版源比如某個(gè)穩(wěn)定鏡像站的centos/7/os/x86_64/路徑hosted 不填遠(yuǎn)端只等著你上傳 rpm。這里有個(gè)版本相關(guān)的細(xì)節(jié)必須提前確認(rèn)Nexus3 對 yum hosted 的支持在較新版本才完善早期版本上傳 rpm 后不會(huì)自動(dòng)生成 repodata客戶端會(huì)直接報(bào)找不到元數(shù)據(jù)。如果你用的是老版本要么升級要么用createrepo在倉庫目錄里手動(dòng)生成后上傳。我建議直接升到較新的 3.x 版本能省掉大量手工維護(hù)元數(shù)據(jù)的工作。4.2 客戶端 repo 文件怎么寫客戶端只改一個(gè).repo文件指向 yum group[nexus-yum] nameNexus YUM Repository baseurlhttp://192.168.1.100:8081/repository/yum-group/ enabled1 gpgcheck0gpgcheck0只是內(nèi)網(wǎng)圖省事的寫法正式環(huán)境應(yīng)該把公鑰下發(fā)到/etc/pki/rpm-gpg/并把gpgcheck打開。改完文件執(zhí)行yum clean all再yum makecache緩存建起來之后再裝包就是內(nèi)網(wǎng)速度。注意改了源之后一定要先yum clean all否則老緩存還在會(huì)繼續(xù)走舊地址讓人誤以為配置沒生效。4.3 批量上傳 RPM 的三種姿勢第一種是界面手動(dòng)上傳適合零散幾個(gè)包缺點(diǎn)是包多了效率極低。第二種是curl PUT 上傳適合腳本化curl -v -u deploy:你的密碼 \ --upload-file ./nginx-1.24.0-1.el7.x86_64.rpm \ http://192.168.1.100:8081/repository/yum-hosted/Packages/n/nginx-1.24.0-1.el7.x86_64.rpm路徑里的Packages/n/只是目錄慣例方便按首字母歸類不影響功能Nexus 會(huì)自動(dòng)識別 rpm 內(nèi)容并更新元數(shù)據(jù)。第三種是從 proxy 緩存里提升到 hosted如果你已經(jīng)通過 proxy 拉過某個(gè)包可以直接在界面上把它移動(dòng)到 hosted 倉庫省一次下載。批量場景我一般寫個(gè)循環(huán)腳本把本地一個(gè)目錄里的 rpm 全部推上去幾百個(gè)包幾分鐘就能跑完。4.4 元數(shù)據(jù)刷新與校驗(yàn)上傳完成后去 hosted 倉庫的 Browse 里看是否出現(xiàn)repodata目錄里面應(yīng)該有repomd.xml和若干primary文件。有就說明元數(shù)據(jù)生成成功?？蛻舳诉@邊如果yum install報(bào)Cannot retrieve repository metadata按三個(gè)方向查網(wǎng)絡(luò)能不能通、baseurl 路徑對不對、group 的成員順序?qū)Σ粚?。group 成員順序這件事容易被忽略。如果你的 hosted 里有一個(gè)包、proxy 里也有同名不同版本的包group 會(huì)按成員列表順序去找先命中誰就用誰。想讓內(nèi)部包優(yōu)先就把 hosted 放到成員列表最前面。5. APT 私庫給 Debian、Ubuntu 做內(nèi)網(wǎng)源APT 這套的邏輯和 YUM 類似但多了簽名密鑰這一環(huán)配置不當(dāng)會(huì)一直卡在apt update報(bào)簽名錯(cuò)誤上所以單獨(dú)拎出來講清楚。5.1 apt hosted 與 apt proxy 的建立創(chuàng)建時(shí)選apt (hosted)或apt (proxy)。hosted 需要填兩個(gè)關(guān)鍵項(xiàng)Distribution比如bionic、focal、jammy這類發(fā)行版代號和Signing Key。簽名密鑰是 APT 體系和 YUM 最大的區(qū)別客戶端默認(rèn)會(huì)校驗(yàn)包和索引的簽名沒有正確的公鑰就會(huì)直接拒絕更新。我的建議是單獨(dú)生成一對專用密鑰導(dǎo)出私鑰粘貼到 Nexus 的 Signing Key 配置里把公鑰保存好下發(fā)給客戶端。用現(xiàn)成的通用密鑰雖然省事但一旦密鑰輪換就是全量客戶端重配不如一開始就規(guī)劃清楚。5.2 sources.list 與公鑰落地客戶端配置寫在/etc/apt/sources.list或/etc/apt/sources.list.d/下的獨(dú)立文件里deb http://192.168.1.100:8081/repository/apt-group/ focal main然后是公鑰。把 Nexus 上導(dǎo)出的公鑰復(fù)制到客戶端后執(zhí)行導(dǎo)入sudo gpg --dearmor -o /usr/share/keyrings/nexus-apt.gpg nexus-public.key再回到 sources 文件里加上簽名引用形如[signed-by/usr/share/keyrings/nexus-apt.gpg]。這樣做的目的是把信任范圍限定到這一個(gè)倉庫不影響系統(tǒng)其他源的校驗(yàn)邏輯比直接把 key 加進(jìn)全局 trusted 列表干凈得多。改完執(zhí)行sudo apt update看到倉庫地址被正常讀取、沒有簽名報(bào)錯(cuò)就說明通了。5.3 上傳 deb 包與 dists 目錄結(jié)構(gòu)deb 包上傳同樣支持 curlcurl -v -u deploy:你的密碼 \ --upload-file ./mytool_1.0.0_amd64.deb \ http://192.168.1.100:8081/repository/apt-hosted/上傳后 Nexus 會(huì)在倉庫里維護(hù)dists/Distribution/和pool/結(jié)構(gòu)apt update讀取的就是dists下的Release和Packages索引。如果你上傳后客戶端報(bào)404八成是 Distribution 名字和 sources 里寫的對不上比如倉庫建的是jammy客戶端寫的卻是focal這種錯(cuò)看起來是網(wǎng)絡(luò)問題其實(shí)是配置不一致。5.4 apt update 報(bào)錯(cuò)的定位方法APT 的報(bào)錯(cuò)信息其實(shí)很直白按關(guān)鍵字對號入座就行?？吹絅O_PUBKEY或者signature verification failed說明公鑰沒導(dǎo)入或者signed-by路徑寫錯(cuò)看到404 Not Found先核對 baseurl、Distribution、組件名三者是否和倉庫配置一致看到Could not resolve或者超時(shí)那是網(wǎng)絡(luò)層的問題先curl一下倉庫地址看能不能通。我遇到過一次特別隱蔽的情況客戶端報(bào)簽名錯(cuò)誤但公鑰明明導(dǎo)入了。最后發(fā)現(xiàn)是密鑰過期時(shí)間設(shè)置得太短半年后就失效了。所以生成密鑰時(shí)有效期至少給幾年并且把輪換計(jì)劃寫進(jìn)運(yùn)維文檔別讓它在你忘記的時(shí)候突然爆掉。6. Node.js 私庫npm 代理加私有包前端工程對私庫的依賴程度可能是四類里最高的因?yàn)閚pm install一次要拉幾百個(gè)包公網(wǎng)速度直接決定構(gòu)建時(shí)長。6.1 npm 三倉庫的建立與 group 順序和 Maven 一樣建三個(gè)npm-hosted放私有包npm-proxy代理官方源遠(yuǎn)端地址https://registry.npmjs.orgnpm-group聚合兩者。group 成員順序建議 hosted 在前這樣私有包名和公網(wǎng)包名沖突時(shí)優(yōu)先命中內(nèi)部版本避免裝錯(cuò)包。有個(gè)細(xì)節(jié)值得強(qiáng)調(diào)Nexus3 的 npm 代理在部分版本上對npm audit和某些元數(shù)據(jù)接口的支持不完整如果團(tuán)隊(duì)重度依賴npm audit可能需要額外配一個(gè)直連場景或者關(guān)掉相關(guān)檢查。這屬于版本特性差異遇到不要硬杠先確認(rèn)你用的 Nexus 版本對 npm 的支持清單。6.2 .npmrc 的工程級配置客戶端配置分兩層。全局的~/.npmrc影響所有項(xiàng)目工程級的.npmrc只影響當(dāng)前項(xiàng)目。我一般把源地址寫進(jìn)工程級配置并提交到代碼庫讓團(tuán)隊(duì)成員克隆下來就能用registryhttp://192.168.1.100:8081/repository/npm-group/ strict-sslfalse如果私庫上了 HTTPS 并用了自簽證書strict-ssl的處理要謹(jǐn)慎穩(wěn)妥做法是把 CA 證書裝到系統(tǒng)信任鏈里而不是一律關(guān)校驗(yàn)。上傳私有包時(shí)還需要認(rèn)證可以用npm login或者直接在.npmrc里配_auth字段。6.3 發(fā)布私有包與 scope 綁定私有包建議統(tǒng)一用 scope比如mycompany/utils并在.npmrc里把 scope 和倉庫綁定mycompany:registryhttp://192.168.1.100:8081/repository/npm-hosted/這樣npm publish時(shí)帶 scope 的包會(huì)自動(dòng)發(fā)到 hosted不帶 scope 的走默認(rèn) registry。綁定 scope 的好處是避免了發(fā)布方向的歧義也方便在 group 里做路由控制。實(shí)操心得發(fā)布前一定在.npmrc里把認(rèn)證信息配好否則npm publish會(huì)返回 401 或 403。CI 環(huán)境里用環(huán)境變量注入憑據(jù)不要把 token 硬編碼進(jìn)倉庫。6.4 緩存、離線與 CI 場景npm 私庫最直接的收益體現(xiàn)在 CI 上。同一條流水線第二次構(gòu)建時(shí)所有依賴都命中內(nèi)網(wǎng)緩存npm ci的時(shí)間能從幾分鐘壓到幾十秒。如果再配合把node_modules或者 npm 緩存目錄做持久化效果更明顯。為了控制磁盤我給 npm proxy 配了緩存清理策略把長期沒人訪問的包定期刪掉。但要注意清理策略刪的是緩存不是內(nèi)部包hosted 倉庫的包不會(huì)受影響。配置時(shí)看清楚作用范圍別把 hosted 也掃進(jìn)去那會(huì)把團(tuán)隊(duì)發(fā)布的私有包誤刪。7. 常見問題速查與排查手法這套環(huán)境跑起來之后日常遇到的問題集中在幾個(gè)固定方向我把它們整理成速查形式遇到直接對號入座。7.1 上傳類錯(cuò)誤怎么讀上傳失敗最常見的三個(gè)狀態(tài)碼401是認(rèn)證沒通過檢查用戶名密碼或者 token403是認(rèn)證過了但沒有寫權(quán)限檢查這個(gè)用戶有沒有對應(yīng)倉庫的nx-repository-view-*-*-add權(quán)限400多見于 Maven 重復(fù)發(fā)布 release 版本或者路徑不符合倉庫約定。有一個(gè)特別容易誤判的情況Maven 上傳時(shí)報(bào) 400 并提到redeploy很多人以為是權(quán)限問題去改用戶其實(shí)是版本策略擋的?？吹竭@個(gè)關(guān)鍵字直接去改策略或者升版本號。7.2 客戶端拉取超時(shí)和 404 的定位順序遇到客戶端拉不到包我固定按這個(gè)順序查第一步確認(rèn)倉庫地址能通用 curl 訪問 group 的根路徑返回 200 說明服務(wù)正常第二步確認(rèn)包在不在直接在界面 Browse 里搜包名看它在哪個(gè)成員倉庫里第三步確認(rèn) group 成員配置有沒有漏加或者順序錯(cuò)了第四步查緩存過期404 被緩存住的情況在老版本里很常見清理一下對應(yīng)倉庫的緩存就好。這個(gè)順序的好處是從大到小逐層收斂不用一上來就翻日志。真到第四步還解決不了再去翻nexus.log里面會(huì)有到遠(yuǎn)端請求的詳細(xì)記錄。7.3 磁盤告警與清理策略磁盤是私庫最現(xiàn)實(shí)的瓶頸。我的做法是每個(gè)倉庫單獨(dú)配清理策略而不是全局一把抓。Maven snapshot 保留最近 30 天npm proxy 只保留最近 90 天被訪問過的包系統(tǒng)包緩存保留版本數(shù)上限。同時(shí)給數(shù)據(jù)目錄做磁盤水位監(jiān)控超過 80% 就告警。需要提醒的是清理策略是定期任務(wù)不是實(shí)時(shí)執(zhí)行配置完要手動(dòng)跑一次或者等調(diào)度周期到才會(huì)生效。別配完就以為空間立刻回來了我見過有人等了半天以為策略沒生效其實(shí)是任務(wù)還沒跑。7.4 備份、遷移和擴(kuò)容備份的黃金法則是備份數(shù)據(jù)目錄而不是備份容器。Nexus3 的所有配置、倉庫內(nèi)容、用戶信息都落在數(shù)據(jù)目錄下的 blob store 和數(shù)據(jù)庫里把整個(gè)目錄 rsync 出來就是完整備份。Docker 環(huán)境把/nexus-data備份走裸機(jī)把sonatype-work/nexus3備份走。遷移時(shí)新機(jī)器裝好同版本 Nexus把數(shù)據(jù)目錄拷過去權(quán)限改成對應(yīng)用戶啟動(dòng)即可。這里有個(gè)大坑目標(biāo)機(jī)器的 Nexus 版本不能低于源機(jī)器否則數(shù)據(jù)結(jié)構(gòu)不兼容會(huì)啟動(dòng)失敗。升級路徑永遠(yuǎn)是先升程序再遷數(shù)據(jù)別反過來。擴(kuò)容主要針對 blob store。Nexus3 支持把 blob store 放到獨(dú)立磁盤甚至共享存儲(chǔ)上數(shù)據(jù)量大了之后可以直接把 blob store 目錄換到更大的盤改配置重啟即可不需要重建倉庫。8. 我在實(shí)際搭建中踩過的坑和積累的小技巧前面講了標(biāo)準(zhǔn)流程這一節(jié)說點(diǎn)文檔里不太會(huì)寫、但實(shí)際會(huì)絆人的細(xì)節(jié)。8.1 權(quán)限別只給能上傳一開始我給 CI 用的deploy用戶只加了上傳權(quán)限結(jié)果發(fā)布 npm 包時(shí)一直 403排查半天才發(fā)現(xiàn) npm 發(fā)布除了寫權(quán)限還需要對倉庫的讀取權(quán)限因?yàn)樗l(fā)布前要先檢查包是否存在。后來給這個(gè)用戶補(bǔ)上了read和browse問題就沒了。所以配權(quán)限時(shí)別只盯著寫讀取和瀏覽通常也得給。8.2 反向代理和上下文路徑的配合把 Nexus 放到反向代理后面時(shí)最容易出問題的是上下文路徑。如果對外暴露的路徑前綴不是根路徑需要在 Nexus 里配置Base URL或者在代理層做路徑重寫否則界面里的資源鏈接會(huì)指向錯(cuò)誤的地址表現(xiàn)為頁面加載一半就失效。最省事的做法是讓 Nexus 的 Base URL 和代理對外地址完全一致不要做多余的路徑變換。8.3 關(guān)于密碼和密鑰的幾條經(jīng)驗(yàn)初始密碼要第一時(shí)間改改完把文件刪掉CI 憑據(jù)走環(huán)境變量注入不要提交到代碼庫APT 的簽名密鑰有效期給足并且記錄輪換計(jì)劃Maven 的部署密碼和登錄密碼不要用同一個(gè)。這些都是小事但每一條出問題都會(huì)變成大事。8.4 一次版本不匹配引發(fā)的連鎖反應(yīng)有一次我在測試機(jī)上升級了 Nexus把數(shù)據(jù)目錄直接拷到舊版本的機(jī)器上想回滾結(jié)果啟動(dòng)直接失敗日志里報(bào)數(shù)據(jù)結(jié)構(gòu)版本不兼容。后來才知道 Nexus 的數(shù)據(jù)庫有 schema 版本號只能向前不能向后。從那以后我給自己定了一條規(guī)矩升級前一定做完整的數(shù)據(jù)目錄快照回滾用快照而不是降級程序。這條比什么優(yōu)化技巧都重要。另一個(gè)小技巧是關(guān)于首次緩存的預(yù)熱。新搭好的私庫第一次給團(tuán)隊(duì)用大家同時(shí)拉依賴會(huì)很慢因?yàn)槎荚诘却砣ミh(yuǎn)端拉。我一般挑幾個(gè)大項(xiàng)目的構(gòu)建先跑一遍把熱門依賴提前緩存進(jìn)私庫等團(tuán)隊(duì)切過來的時(shí)候命中率已經(jīng)很高了體驗(yàn)會(huì)好很多。這個(gè)操作不復(fù)雜但對推廣私庫很有幫助畢竟大家最在意的就是切過去之后是不是真的更快了。最后再補(bǔ)一個(gè)小細(xì)節(jié)關(guān)于客戶端配置的下發(fā)。人一多最麻煩的不是搭私庫而是讓所有人把客戶端配置改對。我的做法是寫一段幾行的初始化腳本Maven 用settings.xml模板覆蓋npm 用工程級.npmrc提交到代碼庫yum 和 apt 的源文件用配置管理工具統(tǒng)一下發(fā)。這樣新人進(jìn)來跑一個(gè)腳本就配好了也不會(huì)有人漏改某一條導(dǎo)致構(gòu)建行為不一致。搭私庫這件事真正的成本從來不在服務(wù)端而在讓整個(gè)團(tuán)隊(duì)用得整齊。