https://clarence.tw/ja/tags/harbor/ Recent content in Harbor on Clarence｜Backend・AI・DevOps・Infrastructure Hugo -- gohugo.io ja Mon, 26 Oct 2026 00:00:00 +0800 https://clarence.tw/ja/posts/self-hosted-gitlab-runner-harbor/ Mon, 26 Oct 2026 00:00:00 +0800 https://clarence.tw/ja/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/ja/posts/gitlab-cicd-complete-guide/">GitLab CI/CD 設定ガイド：Runner、.gitlab-ci.yml、Harbor、デプロイ</a> に、<code>config.toml</code> の設定項目とよく使う変数は <a href="https://clarence.tw/ja/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>：source code、image、build log を自分たちが管理できる環境に置く必要があるチームもあります。</li> <li><strong>ネットワーク環境</strong>：デプロイ先がオンプレミスや内部ネットワークにある場合、Runner と registry を同じ側に置くと build や image pull の経路が短くなり、外向き通信も管理しやすくなります。</li> <li><strong>Runner のリソース</strong>：特定のハードウェア、OS、大きな build リソースが必要な job は、自前の Runner のほうが割り当てやすくなります。</li> <li><strong>既存システムとの連携</strong>：既存のアカウント管理、監視、バックアップの仕組みと接続する必要があります。</li> </ul> <p>代償もはっきりしています。アップグレード、バックアップ、証明書、署名鍵、ディスク容量、障害対応がすべて自分たちの仕事になります。セルフホストを決める前に、その仕事を長期的に引き受ける人がいるかを確認しておくべきです。</p> <h2 id="全体の流れ">全体の流れ</h2> <p>流れはひとことで言えます。コードを GitLab に入れ、Runner が pipeline に従って build とテストを行い、できた container image を Harbor に push し、デプロイ環境が Harbor から image を pull します。</p>