Chocolatey 的 Go 安裝變成政策

我把 Chocolatey 的 Go 套件頁拆成一套可重複的內部安裝流程。

我用 Chocolatey 一陣子了，Go 的套件頁一直讓我有點煩。不是因為壞掉，而是它什麼都想塞：套件清單、社群公告、直播宣傳、部署說明，全擠在同一頁。我要的明明只是「怎麼把 Go 1.26.4 裝到受管機器上，而且不要每台都去碰公網」，結果得先穿過一堆噪音。很多套件目錄都這樣，告訴你有什麼，卻不告訴你在真實環境裡到底該怎麼用。

後來我仔細讀了 Chocolatey 社群套件頁的 Go Programming Language 1.26.4，還有頁面裡那套部署指引，整個脈絡才清楚起來。這頁不是在講「安裝 Go」而已，它是在教你怎麼看待軟體交付：社群套件拿來找東西，內部 repo 拿來保穩定，真的在意控制權就做 internalization，腳本只是最後一步。這比「choco install 然後祈禱」有用太多。

所以我會用我自己比較想看到的方式拆它：每一塊到底在講什麼、哪些可以跳過、哪些一定要留、最後怎麼變成一條乾淨的 Go 內部安裝流程。我也會在最後給你一段可以直接複製的模板，拿去改成你自己的套件流程就行。

先講來源。這次把我拉進來的是 Chocolatey 社群套件庫的 Go 頁面，以及頁面裡附的部署指引。原始頁面在 community.chocolatey.org/packages/golang，另外我也參考了 organizational deployment guidance、package creation docs，還有 Chocolatey CLI。我沒有亂編瀏覽數或星數，因為來源沒給，我就不裝懂。

這頁其實是兩個產品硬塞成一個

Welcome to the Chocolatey Community Package Repository! The packages found in this section of the site are provided, maintained, and moderated by the community.

白話翻譯就是：這頁一邊是 Go 的套件資訊，一邊是 Chocolatey 在對你講它的信任模型。這個差別很重要。你如果把它當成一般下載頁，就會漏掉藏在裡面的操作警告：社群套件很好用，但它不是你內部可控的交付來源。

我以前就踩過這種坑。很多 package manager 都把 public feed 做得像「夠用就好」，直到你真的要 reproducibility、auditability、或 freeze window，才發現 public feed 會讓整條安裝鏈開始抖。Chocolatey 這頁算是講得很直白：可以用社群 repo，但不要把它誤認成保證交付的管道。

實操寫法很簡單：把社群套件頁當成 discovery 和驗證，不要當成最後的 production source。你要評估 Go 1.26.4，就先看 metadata、安裝行為、社群審核訊號。你要發到整個機群，就先把它放進自己的 repo 或 internalization 流程，再說完成。

我會把這個心法寫成一句話：頁面看起來像下載鈕，其實是附了下載鈕的警告標籤。

審核才是重點，不是 listing 本身

頁面把 moderation 講得很明：安全性、一致性、品質檢查、安裝測試、VirusTotal 掃描、人工 review，最後才 sign-off。這些才是我在意的。package manager 很愛假裝 metadata 就夠了，其實不夠。真正重要的是，有沒有人真的看過安裝行為，再把它放進 feed。

Chocolatey 這套審核流程，至少在操作上是認真的。我不是說它能保證每個套件都沒問題，當然不能。但它至少告訴我，這不是隨便丟一包 binary 上去就算數。它有 review path，這已經比很多只靠下載量和感覺判斷信任的生態好多了。

但這裡有個很重要的坑：moderated 不等於適合你的環境。套件過審了，還是可能跟你的 proxy、allowlist、offline 部署策略衝突。所以我從來不會停在「它有審核」。我會繼續問：它安裝時到底抓什麼？從哪裡抓？

實操上我會照這個順序看：

• 先確認是不是 moderated。
• 再看 install script 會不會去 vendor 網站抓檔。
• 最後確認能不能 internalize 後維持同樣的安裝結果。

如果第三步做不到，我就把它當候選，不把它當答案。

Chocolatey 其實是在叫你別再信公網做 production

頁面裡的 organizational use 那段，我覺得是整篇最值錢的。它直接說 public repository 的可靠性不能保證，而且套件可能在 runtime 還要連網。這句話很直白，直白到有點刺眼。意思就是：如果你在意控制權，就不要拿 public dependency chain 當 production 基礎。

很多團隊就是在這裡偷懶。開發時從 public feed 裝，沒事；一進 automation 就把同一條命令複製貼上，然後再驚訝為什麼 vendor 掛了、firewall 擋了、DNS 抽風了。這種事我看太多次了，說穿了就是自己沒讀說明。package manager 沒騙你，它只是照規則跑，我們自己把風險想小了。

Chocolatey 在頁面上也把出口寫了：自己 host 套件、cache 社群套件，或直接 internalize。只要你在意稽核、網段隔離、離線安裝，這些就不是備案，是預設路徑。尤其 Go 這種會被裝到很多地方的開發工具，更應該這樣想。

實操寫法：先決定 source of truth 放哪裡，再寫 install script。如果答案是社群 repo，那你就是接受 runtime 依賴公網。如果答案是 internal repo，那腳本就只該指向內部來源。這差別就是 demo 跟 deployment。

• Public repo：適合探索、測試、臨時安裝。
• Proxy repo：適合想先快起來，但能接受第一次還是要碰上游。
• Internalized package：適合你要的是可預期、可重複、少驚喜。

真正值得抄的是 internalization 流程

頁面裡的 Generate Script Builder 才是重點。它會帶你走過 package review、integration method、internal repository URL、environment setup、install script generation。這個順序我很喜歡，因為它逼你先想架構，再寫腳本。先 review，再選整合方式，再決定 repo，最後才產生 script。這才是對的順序。

白話一點，Chocolatey 不是要給你一條神奇的一行指令，它是在逼你做部署決策。你是用一般 shell？個別機器？Ansible？PowerShell DSC？你是接 proxy repo，還是直接 internalized feed？你要不要連 Chocolatey 本體都從內部 repo 裝？這些問題才決定你的 install 流程是不是能長期維護。

我看過太多團隊一開始就衝腳本，然後後面花幾週在補洞。最後那個 script 變成一坨 duct tape。Chocolatey 這套比較好，因為它先把架構攤開。這很無聊，但無聊得很對。

實操寫法：把你的 package onboarding checklist 固定成五步。Go、Node、Python、Git，我都會用同一套。不是為了自動化更快，是為了只把對的依賴路徑自動化一次。

Proxy repo 跟 internalized package，別裝作一樣

Chocolatey 把兩種模式講得很清楚。第一種是 proxy repository，像 Nexus、Artifactory Pro、ProGet 這類工具，會把上游社群 feed 當來源，第一次請求時再快取。第二種是 internalized package，你自己把套件下載下來、存起來、自己管。這個對比很重要，因為它沒有假裝兩者差不多。

白話翻譯就是：你要先決定自己願意保留多少 upstream dependency。Proxy repo 比較快上手，適合你能接受第一次還是要碰上游。Internalization 比較穩，適合你真的在意可重複安裝，尤其像 Go 這種開發工具，常常到處裝、裝完就忘，直到哪天壞掉才想起來。

我用過 proxy repo，也用過 internalized packages。前者在網路狀況穩、團隊又想少一點流程時很方便。後者在鎖網段、重稽核、重可預期性的環境裡更實在。很多人不太想承認，但一旦牽涉 security 和 compliance，第二種通常比較像答案。

實操寫法：如果你在幫 workstation fleet 裝 Go，先問自己能不能接受第一次安裝還要碰上游。如果可以，proxy repo 就夠。如果不行，就把 Go 跟它的依賴 internalize，然後讓 client 只看內部 feed。不要混著玩，半快取半公網最難查。

Chocolatey 也直接點名了我常看到的幾個 repo server：Nexus Repository、JFrog Artifactory、ProGet。這代表它不是玩具流程，而是真的要接到現場環境。

腳本片段不是在秀語法，是在秀紀律

頁面上的 PowerShell、Ansible 之類範例，表面上是在教 syntax，其實不是。它們在教的是紀律。先設 TLS 1.2，先設 error handling，先指向內部 repository URL，必要時再帶 credentials，最後才抓 Chocolatey nupkg 並安裝。這整個順序就是故事本身。

白話一點，這些 script 是 policy 的落地，不只是 installer。TLS 那行是因為老預設不可靠。error action 是因為 silent failure 沒人受得了。repository URL 是因為 package source 也要管。這些都是小事，直到某天凌晨兩點壞掉，你才會知道哪一行有沒有寫。

我以前也寫過看起來很漂亮、實際上很脆的腳本，因為它假設環境太多。Chocolatey 的範例比較像解毒劑，它逼你把假設寫出來，不要藏在某個半年沒人碰的 wrapper function 裡。

實操寫法：抄結構，不抄字面。保留 guardrails、保留明確 repo source、保留 fail-fast。把套件名和版本換成你的目標工具。然後在乾淨機器上測，不要拿你那台已經暖機一週、依賴快取滿滿的 dev box。

Go 只是入口，生命周期才是工作本體

把視角拉遠一點，Go 1.26.4 的頁面其實比較像 lifecycle management 頁面，只是掛著 package 名稱。Go 本身不難裝，難的是它怎麼在你的環境裡持續可用、可信任、版本一致。這就是為什麼頁面一直繞回 repository strategy、internalization、deployment tooling。Chocolatey 很清楚：installer 只是便宜的那一段。

這也是很多 package page 最常漏掉的地方。它們只看 artifact，不看 operating model。Chocolatey 反過來，它假設 artifact 只是起點。真正麻煩的是它怎麼進你的環境、怎麼更新、上游 feed 改了或消失了怎麼辦。

實操寫法：替每個你在意的 package 寫一個很小的 lifecycle policy。像 Go 這種，就決定誰負責版本、多久 refresh 一次、它放哪個內部 repo、哪條 automation path 負責安裝。這件事做一次，下一個套件就會順很多。不做的話，每個套件都會變成一場臨時辯論。

而我喜歡這頁的地方就在這裡。它不會討好你，它只是逼你把那些不性感、但真的能讓安裝不變成民間傳說的事做完。

可抄的模板

# Chocolatey 套件內部化模板：Go 或任何工具都能套用

## 1) 先決定 source of truth
- 社群 repo：只拿來探索與驗證
- Proxy repo：可以接受第一次快取才用
- Internalized package：需要離線或穩定可重複安裝時使用

## 2) 審查套件
- 確認套件是否 moderated
- 檢查安裝時會不會抓外部下載
- 看版本、依賴、vendor URL
- 確認授權與再散布限制

## 3) 選整合方式
- 一般 shell
- 個別機器設定
- Ansible
- PowerShell DSC
- 其他 automation framework

## 4) 設定 repo policy
- 內部 repository URL：https://your-internal-repo.example.com/api/v2/
- 需要才設定 credentials
- client 只能指向內部來源，不要預設碰公網社群 feed

## 5) 先把 Chocolatey 本體放進內部來源
- 從內部 repository 下載 Chocolatey 套件
- 開啟 fail-fast error handling
- 設定 TLS 1.2 或你環境要求的 protocol

## 6) 安裝目標套件
- 套件名稱：golang
- 版本：1.26.4
- source 指向內部 repository
- 先在乾淨機器測過，再推到大範圍

## 7) 驗收
- 確認沒有公網也能安裝
- 確認升級流程一致
- 確認 uninstall / reinstall 都正常
- 確認 log 足夠支援與稽核

## 8) PowerShell 範例
$ErrorActionPreference = 'Stop'
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
$repo = 'https://your-internal-repo.example.com/api/v2/'
choco install golang --version=1.26.4 --source=$repo -y

## 9) 政策註記
此套件只允許從內部 repository 安裝。
社群 repository 只允許用於 review，不允許 production deployment。

這段我刻意寫得很白，因為重點不是炫技，是能不能重複。你把套件名、repo URL、automation 工具換掉，骨架還是要一樣。

如果是 Go，我會直接 pin 版本、先 internalize，再把內部 repository 設成 production 唯一來源。升級流程另外寫，不要讓人之後自己亂猜。

原始來源是 Chocolatey 的 Go 社群套件頁：https://community.chocolatey.org/packages/golang。這篇的拆解、框架和模板是我自己整理的，底層套件說明與範例則來自 Chocolatey Software。