https://clarence.tw/tags/harbor/ Recent content in Harbor on Clarence｜Backend、AI、DevOps 與 Infrastructure Hugo -- gohugo.io zh-tw Mon, 26 Oct 2026 00:00:00 +0800 https://clarence.tw/posts/self-hosted-gitlab-runner-harbor/ Mon, 26 Oct 2026 00:00:00 +0800 https://clarence.tw/posts/self-hosted-gitlab-runner-harbor/ <p>自 2022 年起，我以 Operator 的角色建置與維護 Self-hosted GitLab、GitLab Runner、Harbor registry 與 CI/CD workflow，把 source code、container image 與 deployment 串在同一條流程上。</p> <p>這篇不是設定教學。<code>.gitlab-ci.yml</code>、Runner 部署與多環境部署的範例整理在 <a href="https://clarence.tw/posts/gitlab-cicd-complete-guide/">GitLab CI/CD 完整配置指南</a>，<code>config.toml</code> 的設定項目與常用變數整理在 <a href="https://clarence.tw/notes/gitlab/runner-config/">GitLab Runner config.toml 設定與常用 CI/CD 變數</a>。這裡想談的是另一面：為什麼要自己養這套系統、各元件怎麼接，以及跑了幾年之後真正花時間的地方。文中提到的問題，都附上我當時寫在 <a href="https://blog.clarence.tw/" target="_blank" rel="noopener">blog.clarence.tw</a> 的紀錄。</p> <h2 id="為什麼考慮自架">為什麼考慮自架</h2> <p>GitLab.com 與各家雲端 registry 都很成熟，自架不是預設答案。會走向自架，通常是下面幾個考量疊在一起：</p> <ul> <li><strong>資料與程式碼放在哪裡</strong>：有些團隊需要原始碼、image 與 build log 留在自己能控制的環境。</li> <li><strong>網路環境</strong>：deployment target 在地端或內部網路時，Runner 與 registry 放在同一側，build 與 pull image 的路徑比較短，也比較好控管對外連線。</li> <li><strong>Runner 資源</strong>：需要特定硬體、作業系統或較大的 build 資源時，自己的 Runner 比較好安排。</li> <li><strong>整合需求</strong>：要和既有的帳號系統、監控與備份流程接在一起。</li> </ul> <p>代價也很清楚：升級、備份、憑證、金鑰、磁碟空間與故障排除都變成自己的事。決定自架之前，要先確定有人願意長期承擔這些工作。</p> <h2 id="整體流向">整體流向</h2> <p>整條流程可以用一句話描述：程式碼進 GitLab，Runner 依照 pipeline build 與測試，產出的 container image 推到 Harbor，部署環境再從 Harbor 拉 image。</p>