configure-git-webserver

Git Webserver を設定する

概要

このスキルでは、Git リポジトリにプッシュすると、コンテンツが Web サーバーに自動でデプロイされる、Git ベースの Web デプロイシステムの設定方法を説明します。一般的なワークフローでは、ベア Git リポジトリを作成し、コンテンツをデプロイする post-receive フックを設定してから、デプロイ済みのファイルを配信する Web サーバーを起動します。

アプローチ

コンポーネントの特定

実装する前に、必要なコンポーネントをすべて特定します。

1. ベア Git リポジトリ - プッシュを受け取る中央リポジトリ
2. Web コンテンツディレクトリ - デプロイ済みファイルの配信元
3. Post-receive フック - プッシュ時のデプロイを自動化
4. Web サーバー - デプロイ済みコンテンツを配信
5. ユーザーアクセス - リポジトリにプッシュするユーザーの権限

実装の順序

依存関係の順にタスクを実行します。

1. まずベア Git リポジトリを作成します（ほかのコンポーネントはリポジトリの場所に依存します）
2. Web コンテンツディレクトリを作成します
3. post-receive フックを作成して設定します（リポジトリと Web ディレクトリの両方が必要です）
4. Web サーバーを起動します（Web ディレクトリが存在している必要があります）
5. 必要に応じてユーザーアクセスを設定します

Post-receive フックの設計

post-receive フックには、次の要件があります。

• 複数のブランチ名（互換性のため master と main の両方）に対応する
• git --work-tree を使って Web ディレクトリにチェックアウトする
• 実行可能にする（chmod +x）
• 適切なシバンを含める（#!/bin/bash）

フックの構成例：

#!/bin/bash
while read oldrev newrev ref
do
    branch=$(echo $ref | cut -d/ -f3)
    if [ "$branch" = "main" ] || [ "$branch" = "master" ]; then
        git --work-tree=/path/to/web/dir --git-dir=/path/to/repo checkout -f $branch
    fi
done

Web サーバーの選択肢

環境に応じて、利用可能な選択肢を検討します。

• python3 -m http.server - シンプルで、通常は利用可能ですが、シングルスレッドです
• nginx - 本番環境に適していますが、インストールが必要です
• node http-server - Node.js が必要です
• busybox httpd - 軽量で、最小構成の環境でも利用できることが多いです

検証方法

コンポーネント単位の検証

ワークフロー全体をテストする前に、各コンポーネントを個別に検証します。

1. リポジトリの検証：ベアリポジトリが存在し、正しい構造になっていることを確認します

   ls -la /path/to/repo  # Should show HEAD, objects/, refs/, etc.
   

2. フックの検証：フックが存在し、実行可能であることを確認します

   ls -la /path/to/repo/hooks/post-receive
   

3. Web サーバーの検証：サーバーが実行中で、リッスンしていることを確認します

   ss -tlnp | grep :PORT  # or netstat -tlnp, or ps aux | grep server
   

エンドツーエンドテスト

ワークフロー全体をテストします。

1. リポジトリをクローンします（初回のテストではローカルパスを使います）
2. テストファイルを作成してコミットします
3. リポジトリにプッシュします
4. ファイルが Web ディレクトリに現れることを確認します
5. HTTP 経由でファイルにアクセスできることを確認します

利用可能なコマンドの事前確認

試行錯誤を減らすため、システムコマンドを使う前に利用可能か確認します。

command -v netstat || command -v ss  # Network status
command -v systemctl || command -v service  # Service management

よくある落とし穴

永続性の問題

問題：バックグラウンドプロセス（python3 -m http.server & など）は、システムの再起動後に実行を継続しません。

対策：本番環境では、systemd サービスを作成するか、プロセスマネージャーを使用します。テストではバックグラウンドプロセスを使用してもかまいませんが、この制限を明記してください。

権限の問題

問題：ユーザーがリポジトリにプッシュできない、またはフックが Web ディレクトリに書き込めません。

対策：

• リポジトリの所有権と権限を確認します
• フックを実行するユーザーが Web ディレクトリへの書き込み権限を持っていることを確認します
• フック自体が実行可能であることを確認します

ブランチ名の処理

問題：フックが master のみを処理する一方、ユーザーは main にプッシュしている（またはその逆）。

対策：フックのロジックで、一般的なデフォルトのブランチ名の両方に対応します。

テスト方法

問題：ローカルパス（/git/server）でのテストは成功しても、SSH を使ったアクセス（user@server:/git/server）は失敗することがあります。

対策：SSH アクセスが必要な場合は、Git/Web の機能とは別に、SSH の設定とユーザーアクセスを確認します。

フックのエラー処理

問題：フックの失敗が通知されず、デバッグが困難になります。

対策：フックにエラー出力とログ記録を追加します。

exec 2>&1  # Redirect stderr to stdout
set -e     # Exit on error

シングルスレッドの Web サーバー

問題：python3 -m http.server のようなシンプルな Web サーバーはシングルスレッドであり、同時アクセスには適していません。

対策：この制限について記載してください。本番環境では、nginx のような適切な Web サーバーを使用してください。

タスク分解の指針

タスク管理で細分化しすぎないようにしてください。関連する操作はまとめます。

• 適切：「post-receive フックを備えた bare Git リポジトリをセットアップする」
• 避ける：「ディレクトリを作成する」「git init を実行する」「フックファイルを作成する」「フックを実行可能にする」を個別のタスクにする

個々のコマンドではなく、論理的なマイルストーンを中心にタスクを管理してください。