Bitbucket Self-Hosted Runners: クラウドの限界を超え、オンプレミスの牙城をCI/CDへ組み込む極意
クラウドネイティブな開発が標準となった今でも、我々エンジニアはしばしば「物理的な制約」という壁にぶち当たる。社内ネットワーク内にある閉域データベースへの接続、物理デバイスを用いたビルド、あるいは極端な低レイテンシが求められるコンパイル処理。
Bitbucket Pipelinesは素晴らしいが、クラウド上のコンテナには「越えられない境界線」がある。そこで登場するのが「セルフホストランナー（Private Runner）」だ。今回は、単に導入するだけでなく、運用コストを最小化し、開発体験を最大化するための「現場の知見」を叩き込む。
—
1. なぜ「セルフホスト」なのか：境界線を突破するアーキテクチャ
Bitbucketのランナーは、Kubernetesクラスター、あるいはDockerが動くサーバーさえあれば、どんな場所でもCI/CDの実行環境に変貌する。
- 社内リソースへのダイレクトアクセス: VPNやファイアウォールを突き抜けるような危険なポート開放は不要。ランナーが内側からBitbucketへアウトバウンド通信を確立する（Pull型）ため、セキュリティポリシーを遵守しつつ、オンプレ環境をCIの一部に統合できる。
- ハードウェア制約の解消: GPUを積んだワークステーションや、特定のARMアーキテクチャ、あるいは物理的に接続された産業用ロボットの制御コードまで、CIパイプラインの中で「実機テスト」が可能になる。
—
2. 実践：セルフホストランナー構築の鉄則
単にインストールするだけでは、ランナーはただの「不安定なサーバー」になる。以下の構成で、運用を自動化せよ。
神設定：Kubernetes上での自動スケーリング
ランナーを単一サーバーで運用するのは悪手だ。K8s環境にランナーをデプロイし、`runner-helm-chart` を使用してPodとして実行する。これにより、負荷に応じてビルド実行数が増減する「オートスケーリングCI」が完成する。
values.yamlの最適化例
replicaCount: 2 # 最小待機数
resources:
requests:
cpu: “1000m”
memory: “2Gi”
limits:
cpu: “2000m”
memory: “4Gi”
重要な知見: 頻繁なビルド失敗を防ぐため、リソース制限は少し余裕を持つのが鉄則
チーム開発における設定共有化ルール
`bitbucket-pipelines.yml` は肥大化しがちだ。「Include機能を使い倒せ」。共通のビルドロジックやセキュリティスキャンを別ファイルに切り出し、各リポジトリで参照する。これにより、CIの仕様変更を一箇所で管理できる。
bitbucket-pipelines.yml
definitions:
steps:
- step: &build-and-test
name: Build and Test on On-Prem
runs-on: # ラベル指定でセルフホストランナーを名指し
- self.hosted
- linux
script:
- ./scripts/build-in-lan.sh # 社内LAN内でのみ実行可能なビルド
—
3. 生産性を加速させる「隠れたハック」
開発スピードを劇的に高める「ランナーのウォームアップ」
セルフホストランナーの最大の敵は「Dockerイメージのプル時間」だ。
解決策：ランナーを動かしているホストOS側で、頻繁に使うベースイメージを事前に `docker pull` しておく、あるいは専用のローカルレジストリをランナー直近に設置せよ。これでビルド時間は体感で30%以上短縮できる。
絶対入れるべき「神ツール/プラグイン」
- Hadolint: DockerfileのLintツール。ランナー上のビルドでイメージを汚さないため、CIパイプラインの冒頭でDockerfileを静的解析し、バッドプラクティスを排除する。
- Bitbucket CLI (bb): コマンドラインからパイプラインのステータス確認、再試行が可能。Web UIをポチポチする時代は終わった。
- `bb pipeline list` で失敗を検知し、`bb pipeline retry
` で即座に叩く。これがプロのワークフローだ。
—
4. 現場のテックリードへ贈る「運用管理の極意」
1. ランナーは「使い捨て」にする: ランナーの設定にOS依存の深いカスタマイズを入れないこと。構成管理ツール（Ansibleなど）でいつでも再構築可能な状態を維持せよ。
2. ログの外部退避: セルフホストランナーのログは、Bitbucketに送られるものとは別に、CloudWatchやELKスタックへ転送しておくこと。突発的なビルド失敗の原因が「ランナーのOSリソース枯渇」なのか「コードのバグ」なのかを切り分ける唯一の手段だ。
3. セキュリティの階層化: セルフホストランナーの環境変数には、決して本番環境のフルアクセス権限を与えてはならない。`Deployment` 毎に権限を絞った「環境変数グループ」を使い分けろ。
—
結びに代えて
セルフホストランナーの導入は、単なる「インフラの移動」ではない。「クラウドの柔軟性」と「オンプレミスの制約」を、エンジニアがコードの力で調和させる高度なエンジニアリングだ。
この環境を整えれば、あなたのチームは「ビルドが遅い」「環境が違うから動かない」という言い訳から解放される。さあ、今すぐオンプレのサーバーにランナーをインストールし、CI/CDのボトルネックを物理的に粉砕してくれ。
健闘を祈る。