Posted inDevOps

クラウドを脱却する：GiteaとActionsで軽量なセルフホストDevOpsスタックを構築

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

クラウドGitホスティングへの過剰な支払いをやめた理由

GitホスティングやCI/CDの標準的なクラウドプロバイダーは便利ですが、予測不能な価格設定、ベンダーロックイン、プライバシー面での妥協といった課題が伴うことがよくあります。GitLabは非常に強力ですが、メモリ要件が高く、安定稼働には少なくとも4GBのRAMが必要です。対照的に, GiteaはGoで書かれた単一のバイナリであり、月額5ドルのVPSや、わずか250MBのRAMしか積んでいないRaspberry Piでも快適に動作します。

DevOpsエンジニアにとって、プライベートでエアギャップ（隔離）されたCI/CDパイプラインをデプロイできる能力は大きな強みです。高セキュリティ環境で作業している場合でも、単に「GitHubがダウンした」ことによる生産性の低下を避けたい場合でも、Giteaは完全な自律性を提供します。最近Gitea Actionsが成熟したことで、JenkinsやDroneのような複数のツールを連携させる必要もなくなりました。使い慣れたGitHub Actionsの構文を使用して、独自のインフラ内で直接ワークフローを実行できるようになっています。

Gitea Actionsの威力

Giteaがリポジトリ管理を担い、Gitea Actionsが自動化の重労働を管理します。このシステムは、nektos/actプロジェクトをベースにしたツールであるact_runnerに依存しています。GitHub Actionsと同じロジックを共有しているため、既存の.github/workflowsファイルを、設定変更なしでそのままGiteaに移植できることが多々あります。これは、月額料金を支払うことなくGitHubに近い体験を得られる、最も近い選択肢です。

デプロイ：Docker ComposeでGiteaを起動する

Docker Composeはこのスタックを管理する最も簡単な方法です。アプリケーションのロジックとデータを分離できるため、バージョンタグを変更するだけで簡単にアップグレードが行えます。GiteaはSQLiteをサポートしていますが、データの整合性と同時実行ユーザーの処理能力を確保するために、チーム環境ではPostgreSQLを使用することをお勧めします。

プロジェクトフォルダを作成し、以下の設定をdocker-compose.ymlとして保存します。

version: "3"

networks:
  gitea:
    external: false

services:
  server:
    image: gitea/gitea:1.21.7
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=gitea_password
    restart: always
    networks:
      - gitea
    volumes:
      - ./gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:22"
    depends_on:
      - db

  db:
    image: postgres:15-alpine
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=gitea_password
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

次のコマンド1つでスタックを起動します。

docker-compose up -d

http://localhost:3000にアクセスしてセットアップを完了します。SSHポートを2222に、GiteaのベースURLを実際のサーバーIPに設定することを忘れないでください。これらをデフォルトのままにすると、GitのクローンURLが最初から正しく機能しなくなります。

CI/CDエンジンの有効化

Gitea Actionsはリソースを節約するため、デフォルトではオフになっています。有効にするには、ボリューム内の./gitea-data/gitea/conf/app.iniにあるapp.iniファイルを編集する必要があります。ファイルの最後に以下の行を追加してください。

[actions]
ENABLED = true

変更を反映させるためにコンテナを再起動します。

docker-compose restart server

Act Runnerেরプロビジョニング

Gitサーバー自体はコードを実行せず、その作業をランナーに委譲します。セキュリティとパフォーマンスを向上させるため、通常はランナーを別のホスト、あるいは少なくとも別のコンテナに配置します。これにより、重いビルドジョブがGitのWebインターフェース全体をクラッシュさせるのを防ぐことができます。docker-compose.ymlに以下のサービスを追加してください。

  runner:
    image: gitea/act_runner:latest
    environment:
      - CONFIG_FILE=/config.yaml
      - GITEA_INSTANCE_URL=http://server:3000
      - GITEA_RUNNER_REGISTRATION_TOKEN=<YOUR_TOKEN>
      - GITEA_RUNNER_NAME=prod-runner-01
    volumes:
      - ./runner-data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - gitea
    depends_on:
      - server

GITEA_RUNNER_REGISTRATION_TOKENを取得するには、管理者としてログインし、サイト管理 > Actions > ランナーに移動します。新しいランナーを作成をクリックし、表示された文字列をコピーしてください。

/var/run/docker.sockをマッピングすると、ランナーにホストに対する強力な権限が与えられることに注意してください。これにより、ランナーはCIステップのためにイメージをプルしたりコンテナを起動したりできるようになります。本番環境では、セキュリティリスクを最小限に抑えるためにrootless Dockerの使用を検討してください。

新しいパイプラインのテスト

すべてが正常に動作するか確認しましょう。新しいリポジトリを作成し、リポジトリ設定でActionsが有効になっていることを確認します。次に、.gitea/workflows/test.yamlに以下の内容でファイルを作成します。

name: Gitea Actionsテスト
on: [push]
jobs:
  check-environment:
    runs-on: ubuntu-latest
    steps:
      - name: チェックアウト
        uses: actions/checkout@v3
      - run: echo "パイプラインがGitea上で実行されています！"
      - run: npx --version

これをプッシュしたら、Actionsタブを確認してください。数秒以内にジョブが「Waiting（待機中）」から「Success（成功）」に変わるはずです。もし停止したままの場合は、docker logs -f gitea-runnerを使用してランナーのログを確認し、接続の問題がないかチェックしてください。

メンテナンスとヘルスチェック

セルフホストするということは、あなた自身がSRE（サイト信頼性エンジニア）になるということです。Giteaには/metricsという組み込みのメトリクスエンドポイントがあり、app.iniで有効にすることでPrometheusにデータを取り込むことができます。これはデータベースの接続プールやリポジトリのサイズを追跡するために不可欠です。

よくある落とし穴の1つはDockerキャッシュです。時間が経つにつれて、act_runnerには宙ぶらりんなイメージやビルドレイヤーが蓄積され、簡単に20GBや30GBのディスク容量を消費してしまいます。ランナーホストで週に一度docker system prune -fを実行する簡単なcronジョブを設定することをお勧めします。これにより、CI/CD環境を軽量に保ち、「ディスク容量不足」によるビルドの失敗を防ぐことができます。

Giteaに移行することで、データと自動化ロジックの完全な所有権が得られます。SaaSアカウントよりもセットアップに少し手間はかかりますが、そのスピードとコスト効率の高さは非常に魅力的です。

Share:
Tags: