Giteaと過ごした6ヶ月:なぜGitLabと「別れた」のか?
アウトソーシングのチームを立ち上げたばかりの頃、一番「プロフェッショナル」だと評判だったGitLabを意気揚々とインストールしました。しかし、それが間違いの始まりでした。当時月額20ドルの4GB RAMのVPSは頻繁にフリーズし、メンバーがコードをプッシュするたびにCPU使用率が100%に跳ね上がりました。一週間のストレスの末、Giteaへの移行を決意し、これこそがまさに探し求めていたものだと確信しました。
GiteaはGo言語で書かれているため、非常に軽量です。10人のチームで実際に運用しリソースを確認したところ、消費メモリはわずか120MB〜150MB程度でした。月額5ドル(1GB RAM)のVPSでも,GitHubに引けを取らないプルリクエスト、イシュー、Wiki、カンバンボードをサクサク動かすことができます。
クイックデプロイ:Docker ComposeでGiteaを5分で立ち上げる
Dockerを使用するのが環境管理において最も迅速な方法です。将来的にサーバーをアップグレードする必要がある場合も、フォルダごと移動するだけで済みます。以下は、本番環境で安定稼働させるために調整した設定ファイルです。
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:
- ./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:/var/lib/postgresql/data
あとの手順は非常に簡単です。ファイルをdocker-compose.ymlとして保存し、次のコマンドを実行します。
docker-compose up -d
ブラウザを開き、http://IP-SERVER:3000にアクセスしてください。直感的な設定画面がすぐに表示されます。
実プロジェクト運用のための推奨設定
1. データベースの選択:PostgreSQLを推奨
個人用途でいくつかのスクリプトを保存する程度ならSQLiteで十分です。しかし、本格的なプロジェクトやチームでの利用を想定しているなら、PostgreSQLを選択してください。コンカレント処理(並行処理)がより安定し、データのバックアップも格段に安心です。
2. SSHポートの処理(ホストとの競合を避ける)
デフォルトのポート22は通常、サーバーへのログインに使用されています。上記の設定ファイルでは、ポートを2222:22にマッピングしています。コードをクローンする際、SSHリンクはssh://[email protected]:2222/user/repo.gitのようになります。
ヒント:Web上での初期設定時に、SSH_DOMAINとSSH_PORT=2222を正しく入力することで、Giteaがクローン用のリンクを自動的に生成してくれます。
NginxとSSLでポート3000を隠蔽する
ポート3000をそのまま使うのはプロフェッショナルとは言えず、セキュリティ面でも懸念があります。私は常にNginxをリバースプロキシとして使用し、Let’s Encryptで無料のSSLを導入しています。設定のテンプレートは以下の通りです。
server {
listen 80;
server_name git.yourdomain.com;
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;
}
}
certbot --nginxを実行するだけで、システムが自動的にHTTPS証明書を発行します。これで、リポジトリはhttps://git.yourdomain.comで利用可能になります。
Gitea Actionsによる自動化 (CI/CD)
Gitea ActionsはGitHub Actionsと全く同じYAML構文を使用するため、学習コストがかかりません。重いJenkinsをインストールする代わりに、軽量なgitea-runnerを用意するだけで、メインブランチへのマージ時にDockerイメージのビルドやデプロイを自動化できます。
実体験から得た「血の滲むような」教訓
VPSのディスクを過信しないこと
以前、最新のバックアップがない状態でVPSのディスクが突然故障し、2日分のコードを失ったことがあります。それ以来、毎晩データをダンプするcronjobを実行しています。Docker内でのクイックバックアップコマンドは以下の通りです。
docker exec -u 1000 gitea /app/gitea/gitea dump -c /data/gitea/conf/app.ini
生成されたzipファイルには、すべてのコード、データベース、設定が含まれています。このファイルを別のサーバーやS3に転送しておけば、安心して眠ることができます。
ブランチ保護によるリスク回避
同僚が「うっかり」git push --forceをしてメインブランチを壊してしまい、肝を冷やしたことはありませんか?すぐに Settings -> Branches -> Add Rule からmainブランチにルールを追加しましょう。強制プッシュ(force push)を禁止し、マージにはプルリクエストを必須にします。小さな設定ですが、不必要な惨事からあなたを救ってくれます。
Giteaは、月額費用を抑えつつソースコードを自前で管理したい小規模チームにとって、最高の投資です。この記事が、あなた専用の「コードの倉庫」を構築する際の一助となれば幸いです。

