Harness Open Source完全ガイド：SCM・CI/CD・Gitspaces・レジストリをOSSセルフホストで完結させる方法

はじめに ― なぜ今「オールインワンDevOps セルフホスト」が注目されるのか

ねえねえ、キミ！！「今のDevOpsツール構成、なんかゴチャゴチャしてきたな……」って、思ったことナイ！？😭 僕さ、最初ハマったんだヨ……というか、今もハマりかけてるんだケド（笑）。

ちょっとだけ聞いてヨ。僕のチームの話なんだケドサ。

ツール乱立疲れとセルフホストDevOps統合の潮流

ウチのチームがどんな感じだったかって言うとサ——GitHubでコード管理して、JenkinsでCI回して、Harborでコンテナレジストリ管理して、SonarQubeでコード品質チェックして……って、もうツールのログインだけで10分かかるみたいな状態だったんだヨネ。

パスワードマネージャーの中のエントリが20個超えたとき、さすがにオレも「ｺﾚマジでヤバくナイ！？」って思いましたヨ！！🦝

GitHub使うだけでもさ、Actionsのランナー管理して、Packagesでレジストリ管理して、Codespaces使いたいなら課金して……ってなると、スタートアップや中規模チームには正直キツいヨネ。運用コストって、お金だけじゃなくて「頭の中のコスト」も馬鹿にならないワケで。

「ツール統合したいけど、GitLabに全部乗せるのも怖いし、コスト高いし……」って悩んでるチームのエンジニア、キミだけじゃないヨ！！

そんな悩みを一発で解決できる可能性を秘めたOSSが、今日紹介する Harness Open Source なんですネ。

Harness Open Sourceとは何か ― 30秒サマリー

Harness Open Sourceっていうのはサ、一言で言うと「SCM・CI/CD・Gitspaces・アーティファクトレジストリを、たった1つのOSSで全部賄える」セルフホスト型のDevOpsプラットフォームなんですヨ😆。

SCM：GitHubみたいにリポジトリ管理できる
CI/CD：パイプライン定義してビルド・デプロイ自動化できる
Gitspaces：GitHub Codespacesみたいなクラウド開発環境が使える
アーティファクトレジストリ：DockerイメージやHelmチャートを中央管理できる

しかもだヨ！！Apacheライセンス2.0なので商用利用も完全フリー！！そして——なんと単一のDockerイメージで、30秒以内に起動できちゃうんですヨ😆

ちなみにサ、最近オフィスの近くに激ウマのカツカレー屋さん見つけちゃってネ、週3で通ってるんですヨ。関係ないケド！！😋

じゃあサ、まずはこのプラットフォームがどこから来たのか、歴史から見ていきましょかネ♪

歴史的背景 ― Drone CIからHarness Open Sourceへの進化

Drone.ioの誕生とコンテナネイティブCI/CDの革新（2012年）

キミ、「Drone CI」って知ってるかナ！？😆 知ってたらセンスあるヨ！！

2012年、Brad Rydzewski氏が作ったOSSのCI基盤がDrone.ioなんですヨ。ちょうどDockerがまだ生まれたてで、「コンテナでCIパイプライン回すぞ！！」みたいな思想を持ったシステムで、当時はかなり革新的だったワケ。

僕さ、Droneを初めて触ったとき「ｺﾚマジでｵｽｽﾒ！！」ってSlackで叫んだんだヨネ😆 ファミコンのカセット吹いてた頃からのクセで、ツールへの愛着が激しくてサ（笑）📟

その後Droneはどんどん成長して——

DockerHub累計1億ダウンロード
5万人のアクティブユーザー
250名超のコントリビューター

という超デカいOSSプロジェクトになったワケですヨ！！🎉 コンテナネイティブなCI/CDの先駆け的存在として、多くのエンジニアに愛された歴史があるんですネ。

Harness社による買収と「OSSコミットメント」（2020年）

で、2020年8月にサ、エンタープライズDevOpsの会社 Harness がDrone.ioを買収したんですヨ。

……って聞くと、「え、OSSが企業に買収されたら終わりじゃないの！？」って思うよネ。わかる、わかるヨその気持ち。僕も最初そう思いましたヨ……。

でもさ！！HarnessはちゃんとOSSコミュニティへの配慮をしてて、「Droneは常にOSSであり続ける」という公式コミットメントを宣言したんですヨ！！✨ しかも旧Droneのコードは drone ブランチで独立してメンテナンスされてて、既存のDroneユーザーはシームレスに使い続けられる設計になってるんだネ。

企業に買収されてもOSSとしての魂を守り続ける——コレ、なかなかできることじゃないヨネ💡

GitnessからHarness Open Sourceへ ― リブランドと機能拡張

その後「Gitness」という名前でリブランドして、さらに進化して現在の Harness Open Source になりましたヨ😆

旧Droneの思想——「各ステップをDockerコンテナで独立実行する」「YAMLでシンプルにパイプラインを定義する」——を継承しつつ、SCM・Gitspaces・アーティファクトレジストリという機能を統合したわけですヨ！！

しかもDrone互換のパイプライン構文が維持されてるので、「Droneからの移行コストが少なくて済む」という強みがあるんだネ♪ Droneユーザーのみんな、移行、そんなに怖くないヨ！！😆

Harness Open Sourceアーキテクチャ概要 ― Go + TypeScriptのシングルバイナリ設計

キミ、センスあるネ！！ここまで読んでるってことはかなりの技術愛だヨ😆 じゃあもう少し踏み込んでいきましょかネ♪

バックエンド：Goによる軽量・高速なセルフホスト向けシングルバイナリ

Harness Open Sourceのバックエンドは Go 1.20以上 で書かれてて、コードベースの 59.1% がGoなんですヨ。

Goって、コンパイル後にシングルバイナリになるじゃないですか。コレが本当に強くてサ——

起動が爆速：サーバー起動まで数秒
低リソース動作：小さいVMやコンテナ環境でも快適
依存関係の地獄がない：「あのライブラリのバージョンが……」みたいな悲劇とサヨナラ

しかもCI/CDパイプラインの実行エンジンは Docker APIと自動ネゴシエーション する設計になってて、各ステップをDockerコンテナとして実行するワケですヨ。コレはDroneから受け継いだ設計思想で、「ステップがコンテナで隔離されてるから、ビルド環境が汚染されない」っていう安心感があるんですネ💡

フロントエンド：TypeScript + ReactによるSPA

フロントエンドはサ、TypeScript + SCSS で書かれてて、コードベースの 39.5% を占めてるんですヨ。ReactベースのSPA（シングルページアプリケーション）として提供されてるから、操作感がサクサクしてるんですネ。

僕、最初にWebUIを開いたとき「え、OSSでこのクオリティ？！」って声出ちゃいましたヨ😆

データ永続化レイヤーの選択肢 ― SQLiteからPostgreSQLまで

データの保存先はサ、用途に応じて選べるようになってるんですヨ！！

用途	DBの選択肢
開発・小規模環境	SQLite（設定ゼロで動く！！）
本番環境	PostgreSQL または MySQL
アーティファクト保存	S3互換ストレージ（MinIO等）

SQLiteで始めてサクッと試して、チームが大きくなったらPostgreSQLに移行する——そういう段階的なスケールアップが設計思想として組み込まれてるワケ。コレ、地味だけどすごく重要なポイントですヨ！！✨

Harness Open Source主要4機能の詳細解説 ― セルフホストDevOpsを完結させる柱

さあ、ここからが本番ですヨ！！😆 Harness Open Sourceの4つの柱を一個ずつ見ていきましょかネ♪

① SCM（ソースコード管理） ― セルフホストGitリポジトリでプライバシーを守る

要するに、自分のサーバーでGitHubみたいなことができちゃうワケですヨ。プライベートなGitリポジトリをセルフホストして、PRレビューもマージリクエストのフローも全部自分のインフラで完結させられる！！

で、僕が一番「コレは！！」ってなったのが Gitleaks統合 なんですヨ😆

ねえ、正直に言うヨ。僕さ、昔やらかしちゃいましたヨ……😭 APIキーをうっかりコミットしちゃって、GitHubに上がって、5分後にAWSから「不審なアクセスがあります」ってメールが来て……冷や汗どころじゃなかったヨ（笑）www

Gitleaksっていうのはシークレット検出のOSSでサ、Harness Open Sourceにはコレが統合されてるんですヨ！！パスワードやAPIキーをコミットしようとすると、プッシュ時に自動でブロックしてくれる！！

プッシュ拒否されたときのログイメージ、百聞は一見にしかずですネ——キミ、コレ見てみてヨ！！

# Gitleaksが検出するとこんな感じでエラーが出るよ
# (実際のharness側のログイメージ)
# error: secret detected: AWS_ACCESS_KEY_ID
# hint: push rejected to protect secrets

コレが組み込まれてるだけで、チームのセキュリティ事故がグッと減りますヨ！！💡 僕みたいな失敗、キミにはしてほしくないからサ😅

② CI/CDパイプライン ― Harness Open Sourceのコンテナネイティブな自動化基盤

コレがまあ、Droneの遺伝子を一番強く受け継いでる部分ですヨネ🎵

YAMLでパイプラインを定義するワケなんだケドサ、構文がDroneと互換性を意識して作られてるから、Droneユーザーなら「あ、これ読めるじゃん」ってなるはず！！

実際に動かして「あ、これだよこれ！！」って膝打ったパイプラインYAMLがコチラですヨ——

kind: pipeline
type: docker
name: default

steps:
  - name: test
    image: golang:1.21
    commands:
      - go test ./...

  - name: build
    image: golang:1.21
    commands:
      - go build -o app .
    when:
      branch:
        - main

  - name: docker-build
    image: plugins/docker
    settings:
      repo: my-registry/my-app
      tags:
        - latest
        - ${DRONE_COMMIT_SHA}
    depends_on:
      - build

  - name: notify
    image: plugins/slack
    settings:
      webhook:
        from_secret: SLACK_WEBHOOK
    when:
      status:
        - success
        - failure

このYAML一発でサ——

条件付きロジック（when で分岐）
依存関係の制御（depends_on で順番管理）
並列実行（depends_on がないステップは並列になる）
シークレットの安全な参照（from_secret でマスクされる）

全部できちゃうんですヨ！！しかも各ステップがDockerコンテナの中で独立して動くから、ステップAのビルド環境がステップBに影響することがない！！コレ、地味だけど超重要なんですヨネ💡

動いた時サ、思わず「やったー！！」って声出ちゃいましたヨ😆

マトリクス戦略も使えるから、複数のGoバージョンで並列テストみたいなことも一発ですヨ！！キミ、マルチバージョンテストって憧れるヨネ——試してみてヨ✨

kind: pipeline
type: docker
name: matrix-test

steps:
  - name: test
    image: golang:${GO_VERSION}
    commands:
      - go test ./...

matrix:
  GO_VERSION:
    - "1.20"
    - "1.21"
    - "1.22"

GO_VERSIONの数だけパイプラインが並列実行されちゃうんですネ🎵 ｺﾚマジでｵｽｽﾒ！！

③ Gitspaces ― Harness Open Sourceのセルフホスト型クラウド開発環境

キミ、GitHubのCodespaces使ったことある！？コレ、似たようなことをセルフホストでできちゃう機能ですヨ！！😆

Gitspacesはサ、devcontainer.json でチームの開発環境を定義しておくと、メンバー全員が同じ環境でコード書けるようになる機能なんですヨ。

この設定ファイル一個でチームの全員が同じ環境に揃う——コレだけでも導入する価値があると思いましたヨ！！

{
  "name": "Go Dev Environment",
  "image": "mcr.microsoft.com/devcontainers/go:1.21",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {},
    "ghcr.io/devcontainers/features/kubectl-helm-minikube:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "golang.go",
        "ms-kubernetes-tools.vscode-kubernetes-tools"
      ]
    }
  },
  "postCreateCommand": "go mod download",
  "forwardPorts": [8080, 9090]
}

コレをリポジトリに置いとくだけでサ——

VS Codeブラウザ版からアクセスできる（ポート3000）
VS Codeデスクトップ版からSSH接続もできる（ポート3022）
ローカル環境ゼロ：「僕のMacでは動くんだけどな……」が永遠にサヨナラ！！

チームに新しいメンバーが入ったときサ、「環境構築に3日かかります」みたいな話ってあるじゃないですか😭 僕も経験あるヨ……READMEどおりにやっても動かなくて、先輩に怒られながら丸2日溶かしたことが……懐かしいような、忘れたいような（笑）

Gitspacesがあれば、そういう悲劇がなくなるワケですヨ！！💡 コレは地味に組織の生産性を爆上げする機能だと思いますヨ、マジで！！🔥

④ アーティファクトレジストリ ― DockerイメージとHelmチャートのセルフホスト中央管理

最後の柱、地味に見えてここが一番「実は重要」なんですヨ！！✨ DockerイメージとHelmチャートを、Harness Open Source自身の中で管理できる組み込みレジストリ機能！！

Harborを使ったことある人なら「あ、そういうやつ」ってイメージできるかもネ。データ構造がすごくよく設計されてて——

アーティファクト（例：my-app）
  └── バージョン（タグ）：v1.0.0, v1.1.0, latest
        └── ダイジェスト：sha256:abc123... （不変！！）

この3階層モデルがポイントでサ、latest タグって実は「どのイメージを指してるか変わる可能性がある」じゃないですか。でも SHA-256ダイジェスト は絶対に変わらない！！コレで「あれ、同じタグなのに昨日と違う動きするんだけど……」みたいな謎の事故を防げるワケですヨ💡

アーティファクトストレージのバックエンドは MinIOなどのS3互換ストレージ に逃がせるので、データが膨大になってきたときもスケールアウトできますヨ！！

Harness Open Sourceセルフホストセットアップ手順 ― Docker単体からDocker Composeまで

さあ！！実際に動かしてみましょヨ！！🔥 ここからが実践編ですヨ、キミ！！

前提条件と必要なソフトウェア

まずチェックリストですヨ♪

Docker Engine がインストールされてること
最小リソース：2コアCPU・4GBメモリ・10GBディスク（開発用の目安）
開放するポート：
- 3000：Web UI・APIアクセス用
- 3022：Gitspaces SSH接続用
- 9000：MinIO APIアクセス用（本番構成時）
- 9001：MinIOコンソール用（本番構成時）

コレだけ準備できたら、もう動かせますヨ！！

最速起動 ― 開発環境向けSQLite構成

試してみたくて指が震えてきたキミに送るコマンドがコレですヨ！！😆

docker run -d \
  --name harness \
  -p 3000:3000 \
  -p 3022:3022 \
  -v /path/to/data:/data \
  harness/harness

マジでコレだけですヨ！！ターミナルにコピペして30秒待てば、もう動いてるんですヨ😆

起動後の確認はこんな感じ：

# コンテナの起動確認
docker logs harness

# Web UIにアクセス
open http://localhost:3000

# Swagger APIドキュメントにアクセス
open http://localhost:3000/swagger

# アーティファクトレジストリのSwagger
open http://localhost:3000/registry/swagger

本番環境向けセルフホスト ― PostgreSQL + MinIO + Harness Open Source Docker Compose構成

さあキミ！！ここからが本番中の本番ですヨ！！😆 開発環境でサクッと動かして「ええやん！！」ってなった次のステップ——PostgreSQLでデータを安全に永続化して、MinIOでアーティファクトをS3互換ストレージに逃がす、「セルフホストDevOps」の本命構成ですネ！！

長年の試行錯誤の末にたどり着いた僕的ベスト構成、コレが完全体ですヨ——保存しておくといいヨ！！

version: "3.8"

services:
  harness:
    image: harness/harness:latest
    container_name: harness
    restart: unless-stopped
    ports:
      - "3000:3000"
      - "3022:3022"
    environment:
      - GITNESS_DATABASE_DRIVER=postgres
      - GITNESS_DATABASE_DATASOURCE=host=postgres port=5432 user=harness password=harness_secret dbname=harness sslmode=disable
      - GITNESS_BLOB_STORAGE_TYPE=s3
      - GITNESS_BLOB_STORAGE_S3_BUCKET=harness-artifacts
      - GITNESS_BLOB_STORAGE_S3_ENDPOINT=http://minio:9000
      - GITNESS_BLOB_STORAGE_S3_REGION=us-east-1
      - GITNESS_BLOB_STORAGE_S3_PATH_STYLE=true
      - GITNESS_BLOB_STORAGE_S3_ACCESS_KEY=minioadmin
      - GITNESS_BLOB_STORAGE_S3_SECRET_KEY=minioadmin_secret
      - GITNESS_URL_BASE=http://localhost:3000
      - GITNESS_GITSPACE_ENABLE=true
    volumes:
      - harness_data:/data
    depends_on:
      postgres:
        condition: service_healthy
      minio:
        condition: service_healthy

  postgres:
    image: postgres:15-alpine
    container_name: harness_postgres
    restart: unless-stopped
    environment:
      - POSTGRES_USER=harness
      - POSTGRES_PASSWORD=harness_secret
      - POSTGRES_DB=harness
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U harness -d harness"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

  minio:
    image: minio/minio:latest
    container_name: harness_minio
    restart: unless-stopped
    command: server /data --console-address ":9001"
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      - MINIO_ROOT_USER=minioadmin
      - MINIO_ROOT_PASSWORD=minioadmin_secret
    volumes:
      - minio_data:/data
    healthcheck:
      test: ["CMD", "mc", "ready", "local"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s

  minio-init:
    image: minio/mc:latest
    container_name: harness_minio_init
    depends_on:
      minio:
        condition: service_healthy
    entrypoint: >
      /bin/sh -c "
      mc alias set local http://minio:9000 minioadmin minioadmin_secret;
      mc mb --ignore-existing local/harness-artifacts;
      mc anonymous set none local/harness-artifacts;
      echo 'MinIO bucket initialized successfully';
      "
    restart: "no"

volumes:
  harness_data:
  postgres_data:
  minio_data:

ポイントを解説しますヨ！！😆

depends_on + condition: service_healthy：ヘルスチェックが通過してから次のサービスが起動するので、「Harnessが起動したのにPostgreSQLがまだ準備中……」みたいな起動順序の事故を防げますヨ！！
minio-init サービス：MinIOが起動した直後に harness-artifacts バケットを自動作成してくれる使い捨てコンテナですネ。restart: "no" にしてるから、初期化後は自動的に終了しますヨ。
GITNESS_BLOB_STORAGE_S3_PATH_STYLE=true：MinIOはPath Style Accessingが必要なので、コレを true にしておかないと繋がらないんですヨ！！うっかり忘れがちなので注意ですネ💡

初期設定ウィザードとHarness Open Source動作確認

Docker Composeで起動したら、いよいよ初期設定ですヨ！！😆

① 起動確認

# 全サービスの起動確認
docker compose up -d

# ログ確認（エラーが出てないかチェック！）
docker compose logs -f harness

# 全サービスのステータス確認
docker compose ps

② 管理者アカウント作成

ブラウザで http://localhost:3000 にアクセスすると、初回起動時にアカウント作成ウィザードが出てきますヨ。管理者のユーザー名・メールアドレス・パスワードを設定すれば、ダッシュボードに入れるようになりますネ！！

③ MinIOとAPIの動作確認

# MinIOコンソールでバケットが作成されてるか確認
# ブラウザで http://localhost:9001 にアクセス
# ユーザー名: minioadmin / パスワード: minioadmin_secret

# APIが正常に動いてるか確認
curl http://localhost:3000/api/v1/system/config

ダッシュボードからリポジトリを新規作成して、前述のパイプラインYAMLをコミットして——実際にCIが走るのを見た瞬間、「やったー！！これで全部揃ったヨ！！」って叫びましたヨ！！😆

セルフホスト Harness Open Source運用のベストプラクティス

ここからは「せっかく建てたのに壊れた……」を防ぐための話ですヨ。地味だけど超重要なセクションですネ💡

バックアップ戦略 ― PostgreSQL定期ダンプ + MinIOバケットレプリケーション

データを守るのは運用者の最重要ミッションですヨ！！定番中の定番だケドサ、侮れないんだネ——

#!/bin/bash
# pg_dump定期実行スクリプト（cronで毎日実行推奨）
BACKUP_DIR="/backup/postgres"
DATE=$(date +%Y%m%d_%H%M%S)
FILENAME="${BACKUP_DIR}/harness_${DATE}.sql.gz"

mkdir -p "${BACKUP_DIR}"

docker exec harness_postgres pg_dump \
  -U harness \
  -d harness \
  --no-password \
  | gzip > "${FILENAME}"

# 7日以上前のバックアップを削除
find "${BACKUP_DIR}" -name "*.sql.gz" -mtime +7 -delete

echo "Backup completed: ${FILENAME}"

MinIOのバケットレプリケーションはサ、MinIOコンソールの「Replication」設定から別のMinIOインスタンスやS3バケットに自動レプリケーションを設定できますヨ。本番環境では必ず設定しておくことをおすすめしますネ！！

セキュリティ強化 ― HTTPS化でセルフホストを安全に運用する

本番環境でHTTPのまま運用するのはNGですヨ！！リバースプロキシ経由でHTTPS化しましょカ。nginxを使う場合はコレですネ——

server {
    listen 443 ssl http2;
    server_name harness.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/harness.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/harness.yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /api/v1/repos/ {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_read_timeout 300;
        client_max_body_size 500m;
    }
}

GITNESS_URL_BASE を https://harness.yourdomain.com に変更するのを忘れずに！！コレを忘れると、WebhookやCloneURLがHTTPのままになっちゃうんですヨ……僕はやらかしちゃいましたヨ……😭 30分悩んだ末に気づいたときの虚脱感よ（笑）。

Gitleaksの検出ルールはデフォルトでもかなり強力なんですケドサ、.gitleaks.toml をリポジトリのルートに置くことでカスタムルールも追加できますヨ。チームが使ってる独自トークンのパターンなんかも定義しておくと、さらに安心ですネ！！

まとめ ― Harness Open SourceでセルフホストDevOpsを今すぐ始めよう

キミ！！長い記事を最後まで読んでくれて、ありがとうですヨ！！😆 最後にガッツリまとめていきますネ！！

Harness Open Sourceが解決する課題

ツール乱立問題：SCM・CI/CD・Gitspaces・レジストリが1つのOSSで完結
ライセンスコスト問題：Apacheライセンス2.0で商用利用完全フリー
セキュリティ事故リスク：Gitleaks統合でシークレット漏洩をプッシュ前に防止
環境構築の非再現性問題：Gitspacesで全員が同じ環境でコードを書ける
データ主権問題：セルフホストだから全データが自分のインフラに

4機能まとめ

機能	代替できるサービス	主なポイント
SCM	GitHub / GitLab	Gitleaks統合でセキュリティ強化
CI/CD	GitHub Actions / Jenkins	Drone互換YAML・コンテナネイティブ
Gitspaces	GitHub Codespaces	devcontainer.jsonで環境統一
アーティファクトレジストリ	Harbor / DockerHub	SHA-256ダイジェストで不変管理

キミへの次のアクション ― 今すぐ試してみヨ！！

まず開発環境で試す：docker run 1行でローカル起動（30秒！！）
パイプラインYAMLを書いてみる：既存のDroneユーザーならほぼそのまま動く
Docker Composeで本番構成を建てる：PostgreSQL + MinIOで本格セルフホスト運用スタート
チームに展開する：Gitspacesを設定してオンボーディングコストを激減させる

「まず30秒で動かしてみる」ところから始めれば、あとは自然にわかってくるヨ！！僕が保証しますヨ！！😆 キミならできるヨ、絶対ネ！！

参考リンク

Harness Open Source GitHubリポジトリ：https://github.com/harness/gitness
Harness Open Source 公式ドキュメント：https://developer.harness.io/docs/open-source
Gitleaks GitHub：https://github.com/gitleaks/gitleaks
MinIO 公式ドキュメント：https://min.io/docs/minio/linux/index.html
devcontainer.json仕様（Dev Containers）：https://containers.dev/

Harness Open Source完全ガイド：SCM・CI/CD・Gitspaces・レジストリをOSS一択で完結させる方法