流程定位

Image deployment 的風險集中在「看似同名、實際不同」的產物漂移。latest、mutable tag、重新 build 與跨 registry promotion 都可能讓 staging 測過的 image 不等於 production 跑的 image。嚴謹流程應以 Image Digest 或 immutable tag 作為 artifact 身分。

Build 階段負責封裝 runtime。Multi-stage build、dependency cache、base image pinning 與 build secret 處理會直接影響安全性；CI 應能在乾淨 runner 上重建 image，避免開發機狀態被帶入。

Tag 階段負責支援不同查詢情境。Commit SHA 適合事故追溯，semver 適合 release 溝通，Image Digest 適合 runtime 精準鎖定；production 判讀應以 digest 為準，tag 只作為人類入口。

Scan 階段負責把風險分流。Vulnerability scan、secret scan、license scan 與 SBOM 不應只是報表；流程要定義哪些風險阻擋發布、哪些風險允許例外、例外誰審核、何時重新評估。

Container registry 階段負責保存與推進 image。Registry 要處理權限、retention、immutability、promotion 與垃圾回收；若 production 直接從 feature branch push 的 tag 拉 image，供應鏈邊界就失去治理。

Runtime handoff 階段負責把已驗證 image 交給部署平台。Kubernetes、ECS、Compose 或其他 runtime 都應指向已驗證 digest 或 immutable tag，並把 health、readiness、resource limit 與 rollback 連到同一次 release。

Tag 與 digest 策略

Tag 策略的責任是讓人查得到、機器鎖得住。單一 tag 很難同時滿足可讀性、可追溯與不可變三個需求，因此實務上常搭配多個 tag 與 digest。

Production deployment 應能從 running pod 或 task 反查 image digest，再反查 registry metadata、scan report、workflow run 與 source commit。這條查詢路徑是 incident response 的基本能力。

Scan gate 分流

Scan gate 的責任是讓安全訊號變成可操作路由。掃描工具會產生大量結果，沒有分流規則時，團隊會在兩種壞狀態間搖擺：全部阻擋導致發不出去，全部忽略導致掃描失去信任。

這個分流讓 scan 成為 gate。例外流程要有 owner 與到期日，讓例外維持可追蹤、可重新評估。

常見反模式

反模式的共同問題是讓 image 身分失去穩定錨點。當 image 身分漂移，測試結果、掃描結果與 runtime 狀態會彼此分叉。

下一步路由

• Image 部署總覽：回 Docker / Image 部署 CI/CD。
• Registry 術語：讀 Container Registry。
• 後端 runtime 部署：讀 後端部署 CI/CD。

Private Registry

隔離網路裡需要一個容器映像倉庫，讓內部的 Docker host / Kubernetes 節點能 pull image。

Harbor

Harbor 是 VMware 開源的企業級 registry，功能包含：映像儲存、漏洞掃描（整合 Trivy）、存取控制（RBAC）、映像簽章（Cosign / Notary）、複製策略。適合中大規模的斷網環境。

離線安裝：Harbor 提供 offline installer（.tgz，約 600MB），包含所有需要的容器映像。搬進隔離網路後解壓、跑 install.sh。

1# 外部：下載 offline installer
2wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-offline-installer-v2.11.0.tgz
3
4# 搬運後，在內部解壓安裝
5tar xzf harbor-offline-installer-v2.11.0.tgz
6cd harbor
7cp harbor.yml.tmpl harbor.yml
8# 編輯 harbor.yml：設定 hostname、HTTPS 憑證、admin 密碼
9./install.sh

Docker Registry（官方輕量版）

如果不需要 Harbor 的進階功能（RBAC、掃描），官方的 Docker Registry 是單一容器、設定最簡單：

1# registry image 也要先搬進來
2docker load < registry-2.8.3.tar
3docker run -d -p 5000:5000 --restart=always --name registry \
4  -v /data/registry:/var/lib/registry \
5  registry:2.8.3

內部機器的 Docker daemon 要設定信任這個 registry（如果是 HTTP 而非 HTTPS）：

1{
2  "insecure-registries": ["registry.internal:5000"]
3}

映像搬運

docker save / load

最直接的搬運方式——把映像匯出成 tar 檔、搬運後匯入：

1# 外部：匯出
2docker pull nginx:1.25-alpine
3docker save nginx:1.25-alpine -o nginx-1.25-alpine.tar
4
5# 搬運後，內部匯入
6docker load < nginx-1.25-alpine.tar
7# 重新 tag 指向內部 registry
8docker tag nginx:1.25-alpine registry.internal:5000/nginx:1.25-alpine
9docker push registry.internal:5000/nginx:1.25-alpine

多個映像可以打包成一個 tar：docker save img1 img2 img3 -o bundle.tar。

skopeo copy

skopeo 是不需要 Docker daemon 的映像操作工具，適合 CI 環境或沒有裝 Docker 的工作站：

1# 外部：從 Docker Hub 複製到本地目錄
2skopeo copy docker://nginx:1.25-alpine dir:/path/to/export/nginx-1.25
3
4# 搬運後，從本地目錄推送到內部 registry
5skopeo copy dir:/path/to/export/nginx-1.25 docker://registry.internal:5000/nginx:1.25-alpine

skopeo 的優勢是不需要 pull 整個映像到本地 Docker（省磁碟空間）、支援 OCI layout、且可以在沒有 root 權限的環境執行。

搬運清單管理

映像搬運容易變成「需要什麼才搬什麼」的臨時操作。建議維護一份搬運清單（manifest），列出所有需要的 base image 和版本：

 1# image-manifest.yaml
 2images:
 3  - name: nginx
 4    tag: 1.25-alpine
 5    source: docker.io/library/nginx
 6  - name: postgres
 7    tag: "16.3"
 8    source: docker.io/library/postgres
 9  - name: node
10    tag: 20-alpine
11    source: docker.io/library/node

搬運腳本讀這份清單自動 pull + save，確保每次搬運的內容一致且可追蹤。

Base Image 更新週期

斷網環境的 base image 不會自動更新——nginx:1.25-alpine 搬進去之後就是那個版本，裡面的 Alpine 套件不會收到安全補丁。需要定期用新版 base image 替換舊的。

更新流程

1. 外部：pull 最新版 base image
2. 外部：用 Trivy 掃描漏洞（見下一節）
3. 搬運：走 content ferry 帶進內部
4. 內部：push 到內部 registry、更新 tag
5. 內部：重新 build 所有依賴這個 base image 的應用映像
6. 內部：部署更新後的應用映像

更新頻率：安全敏感環境月更、一般環境季更。每次更新都要記錄哪些 base image 換了、從哪個版本換到哪個版本。

Helm Chart 離線

如果內部有 Kubernetes 且使用 Helm，chart 也要離線管理：

1# 外部：下載 chart
2helm pull bitnami/postgresql --version 15.5.0
3
4# 搬運後，內部用本地檔案安裝
5helm install pg ./postgresql-15.5.0.tgz -f values.yaml

或架設 ChartMuseum 作為內部 Helm repo：chart 搬進來後 push 到 ChartMuseum，helm repo add 指向它。

離線漏洞掃描

連網環境的 Trivy 會自動下載漏洞資料庫（CVE DB）。斷網環境要先在外部下載 DB、搬進來。

1# 外部：下載 Trivy 漏洞資料庫
2trivy image --download-db-only --cache-dir /path/to/trivy-db/
3
4# 搬運 DB 檔案（~30MB）
5# db.tar.gz 在 /path/to/trivy-db/db/ 裡
6
7# 內部：用離線 DB 掃描
8trivy image --skip-db-update --cache-dir /path/to/trivy-db/ registry.internal:5000/nginx:1.25-alpine

掃描結果的處理方式跟連網環境相同——critical 和 high 的 CVE 要評估是否影響、是否有 base image 更新可修。差別是斷網環境的修復週期更長（要走搬運流程），所以掃描要更頻繁（至少跟 base image 更新同步）。

Harbor 整合 Trivy 後可以在 push 時自動掃描——Trivy DB 的更新同樣需要定期搬運。

時程參考：Private registry 建置（Harbor offline）約需 1 天。映像搬運流程建立約需半天。第一批 base image 搬運 + 掃描約需半天。之後每次更新約 2-4 小時。

跨分類引用

• → 斷網環境的通用原則：映像搬運走 content ferry 模式
• → 模組五：核心服務上 IaC — 運算：連網環境的容器部署
• → ECS 知識卡：容器編排的基礎概念

本篇涵蓋兩個 registry 的部署與操作：Nexus Repository（多格式套件）和 Harbor（容器映像）。兩者可以獨立運作，也可以搭配使用——Nexus 管套件依賴、Harbor 管容器映像，各自負責不同的 artifact 類型。

Nexus Repository：統一的離線套件 proxy

Nexus Repository OSS（開源版）支援 apt、yum、npm、PyPI、Maven、NuGet、Go modules 等多種格式，用一個實例取代多個獨立的離線 repo mirror。部署在內網後，所有開發機器和 CI runner 把套件 source 指向 Nexus。

部署

Nexus 本身是一個 Java 應用，用 Docker 部署最簡單。映像需要事先從外部搬進來：

1# 外部機器下載映像
2docker pull sonatype/nexus3:latest
3docker save sonatype/nexus3:latest -o nexus3.tar
4
5# 搬運到內網後載入
6docker load -i nexus3.tar
7docker run -d -p 8081:8081 --name nexus \
8  -v nexus-data:/nexus-data \
9  sonatype/nexus3:latest

初始管理員密碼在容器內 /nexus-data/admin.password，首次登入後強制修改。

Hosted repo 模式

連網環境的 Nexus 通常用 proxy repo（代理公開 registry、快取下載過的套件）。斷網環境 proxy 模式無法運作，改用 hosted repo——手動上傳套件到 Nexus，Nexus 作為唯一的分發來源。

以 npm 為例，workflow 是在外部機器打包、搬運、上傳：

 1# 外部機器：打包專案的所有依賴
 2npm pack --pack-destination ./npm-packages/
 3# 或用 npm-offline-packager 批次下載整棵依賴樹
 4npx npm-offline-packager --package ./package.json --output ./npm-packages/
 5
 6# 搬運到內網後上傳到 Nexus
 7for pkg in ./npm-packages/*.tgz; do
 8  curl -u admin:password \
 9    --upload-file "$pkg" \
10    "http://nexus.internal:8081/repository/npm-hosted/"
11done

apt 和 yum 的做法類似：外部機器用 apt-get download 或 yumdownloader 抓 .deb / .rpm 檔案，搬進來後上傳到 Nexus 的 hosted repo。

客戶端設定

開發機器和 CI runner 的套件 source 指向 Nexus：

1# npm
2npm config set registry http://nexus.internal:8081/repository/npm-hosted/
3
4# pip
5pip install --index-url http://nexus.internal:8081/repository/pypi-hosted/simple/ package-name
6
7# apt（在 /etc/apt/sources.list.d/ 加一份）
8deb http://nexus.internal:8081/repository/apt-hosted/ focal main

Harbor：容器映像的 private registry

Harbor 是 CNCF 畢業專案的企業級容器 registry，支援映像簽章、漏洞掃描（Trivy）、存取控制、映像複製。在斷網環境裡它是 Docker Hub 和 ECR 的替代品。

部署

Harbor 用 Docker Compose 部署。安裝包需要從外部下載後搬進來：

 1# 外部機器下載離線安裝包
 2wget https://github.com/goharbor/harbor/releases/download/v2.11.0/harbor-offline-installer-v2.11.0.tgz
 3
 4# 搬運到內網後解壓
 5tar xzf harbor-offline-installer-v2.11.0.tgz
 6cd harbor
 7
 8# 複製並編輯設定
 9cp harbor.yml.tmpl harbor.yml
10# 修改 hostname、storage 路徑、HTTPS 憑證（內部 CA 簽發）
11
12# 安裝
13./install.sh --with-trivy

--with-trivy 啟用內建的漏洞掃描。Trivy 的漏洞資料庫需要離線更新——從外部下載 DB 檔案、搬進來放到指定路徑。

專案與存取控制

Harbor 用「專案」（project）組織映像。每個專案可以設定獨立的存取控制：

• library：公開專案、所有使用者可 pull
• platform：平台團隊專用、限定成員可 push
• vendor：第三方 base image、由 infra 團隊管理更新

robot account 提供 CI/CD 用的非互動式認證（限定 pull / push 權限、可設定到期時間）。

映像搬運 SOP

映像從外部搬進斷網環境是一個需要標準化的操作，涉及格式、大小、多架構支援：

搬運工具比較

skopeo 的操作流程：

1# 外部機器：從 Docker Hub 複製到本地目錄
2skopeo copy docker://nginx:1.25-alpine dir:./images/nginx-1.25-alpine
3
4# 搬運到內網後：從本地目錄推到 Harbor
5skopeo copy dir:./images/nginx-1.25-alpine \
6  docker://harbor.internal/library/nginx:1.25-alpine \
7  --dest-tls-verify=false  # 如果 Harbor 用內部 CA

多架構映像

如果環境同時有 amd64 和 arm64 的機器，搬運時要帶整個 manifest list：

1# 外部：複製所有架構
2skopeo copy --all docker://nginx:1.25-alpine \
3  dir:./images/nginx-1.25-alpine-multiarch
4
5# 內網：推送所有架構
6skopeo copy --all dir:./images/nginx-1.25-alpine-multiarch \
7  docker://harbor.internal/library/nginx:1.25-alpine

--all flag 確保 manifest list 裡的每個架構都被複製，而非只複製本機架構。

套件與映像的更新週期

斷網環境的套件和映像不會自動更新——每一次更新都是一次有意識的搬運操作。更新週期的頻率由安全需求決定：

每次更新的標準流程：

1. 外部機器下載：按清單下載指定版本的套件和映像
2. 安全掃描：在外部（或 staging gateway）跑 Trivy / Snyk 掃描，確認沒有已知的高風險 CVE
3. 審查核准：掃描報告給安全團隊或負責人簽核
4. 搬運：核准的 artifact 寫入唯讀媒體或加密通道搬進內網
5. 上傳到 registry：推到 Nexus 和 Harbor
6. 通知團隊：哪些套件/映像有新版本可用

這個流程的產出是一份更新清單（什麼版本、掃描結果、核准人），存進版控作為稽核紀錄。

Helm chart 離線管理

Kubernetes 環境用 Helm 部署應用。斷網時 Helm chart 需要離線管理：

1# 外部機器：下載 chart
2helm repo add bitnami https://charts.bitnami.com/bitnami
3helm pull bitnami/postgresql --version 15.5.0
4
5# 搬運到內網後有兩個存放選項

選項一：Harbor 內建 chart 支援。Harbor 2.0+ 支援 OCI artifact，Helm chart 可以直接推到 Harbor：

1helm push postgresql-15.5.0.tgz oci://harbor.internal/charts

選項二：ChartMuseum。獨立的 chart repository server：

1# 上傳 chart
2curl --data-binary "@postgresql-15.5.0.tgz" \
3  http://chartmuseum.internal:8080/api/charts

Harbor 的 OCI 方式較簡單（不需要額外維護 ChartMuseum），但需要 Helm 3.8+ 的 OCI 支援。

時程與管理層溝通

管理層需要知道的成本：registry 的維護不是一次性投入，每個更新週期都需要工程師時間執行搬運和掃描。這筆成本在連網環境裡由公開 registry 和自動更新吸收，斷網環境裡由團隊承擔。

跨分類引用

• → 斷網環境的通用原則：content ferry pattern 和安全審查流程
• → 斷網環境的容器與映像管理：映像搬運的更完整討論（本篇聚焦 registry 部署、該篇聚焦映像生命週期）
• → 斷網環境的 IaC：Terraform provider 也需要離線 mirror、可用 Nexus 的 raw hosted repo 存放

概念位置

Container Registry 位在 image build、scan、promotion 與 runtime deploy 之間，連接 CI 產物與環境發布。

可觀察訊號

• 同一 tag 在不同環境對應內容不一致。
• 部署因拉取權限或鏡像不存在失敗。
• 線上 image 缺少來源與掃描紀錄的反查路徑。

接近真實服務的例子

團隊以 immutable digest 推進 staging 與 production，並透過 registry policy 控制 retention、pull 權限與 promotion 路徑。

設計責任

Container Registry 要定義命名策略、權限模型、保留策略與來源追溯，讓 image 發布具備可審計性。