Perl のおまつり、 YAPC::Asia に参加しています。
昨年はプライベートでドタバタしていたので、2 年ぶりの参加でした。前回に比べて参加者も多く、それでいてスムーズなイベント進行と素敵なトークの数々でとても楽しい時間を過ごしています。 ひとまず 1 日目を振り返りつつ、聞いたトークをまとめておこうと思いました。

振り返ると、インフラ寄りな内容を選んでいたこともありますが、今日は Perl に限らない話も多かったように思います。それだけ広い知識と経験が必要で、いろんな所でいろんなひとが挑戦していることがわかってわくわくしましたが！

github で管理されている OSS を利用するとき、少しカスタムして使いたいという場合があったりします。もちろん、fork すれば github 上で自分が push できる状態にはなりますが、カスタムしたバージョンを利用する範囲が社内だったりすると github 以外で管理したくなったりもします。

そこで、こんな感じの構成を目指して、github 上のプロジェクトの fork をプライベートな git サーバで管理してみました。

|プライベートなリモートリポジトリのメインブランチ|origin/master| |github のプロジェクトのメインブランチ|github/upstream|

クックパッドさんのオフィスで開催された「サイバーエージェント×クックパッド合同勉強会」に参加してきました。 両社で検証や本番導入しているクラウドサービスな話題がメインで、とても興味深いものでした。

分散 SCM とはいえ、バックアップはあるとうれしいものです。git のリモートリポジトリが破損した場合などに復元元を探すために、誰が持っているのが最新のリビジョンで、、というような作業が発生することは避けたいからです。

git のリモートリポジトリから別のサーバにバックアップを作成するのは、hooks を利用することで簡単に設定できます。例えば、対象となるリポジトリの post-receive で下記のようなコマンドを設定しておくとできます。

• バックアップ先のサーバ:ディレクトリは targethost.example.jp:/var/lib/git
• バックアップのための SSH 接続で利用するユーザは syncuser
• gitosis ユーザは syncuser 権限で git コマンドが利用出来るように visudo を設定

1
2
3
4
5
6
7
8

#!/bin/sh
#####
# hooks/post-receive
#####

MIRROR_HOST='targethost.example.jp'
REPO_NAME=`pwd | perl -e '$t=<stdin>;$t=~ s!^.*/!!;print $t'`
sudo -u syncuser -H git push :mirror syncuser@${MIRROR_HOST}:/var/lib/git/${REPO_NAME}

":mirror" オプションを付けることで、バックアップ先にも bare のままディレクトリが作成されます。 リモートリポジトリとして利用するサーバと別のサーバで Redmine や Trac、あるいは gitweb などを動作させてリポジトリブラウザを利用する場合などでも bare を付けます。

hooks/post-receive は、リポジトリに加わる変更を受信したタイミングで実行される hook script です。cron などで仕込むものとは異なり、push されたタイミングで sync されるので無駄にコネクションが張られることがありません。 ただし、push するタイミングで別サーバへの push が実行されるため、ユーザからみると push 自体の時間が少し長くなるのが欠点です。

業務で使い始めた Git ですが、高機能過ぎて未だに使いこなせている自信がありません。 一方で、かつて利用していた Subversion はコマンドを忘れてしまって使うたびにググるほどに記憶が抜けつつあります。

そんな Git を複数メンバー・複数環境で利用する場合、マスターリポジトリを利用することがあります。これにより、Subversion のような中央集約型のソースコード管理をしつつも Git の恩恵を受ける開発スタイルを取ることができるます。 マスターリポジトリとして GitHub を利用するのが最も手っ取り早いですが、プライベート（= メンバーのみが閲覧できる）なリポジトリを作成するためには有料オプションにしなければなりません。しかも地味に高い。

こんな時、gitosis を利用すると手軽にプライベートな Git サーバを構築することができます。もちろん、リポジトリを利用するメンバー全員が SSH での接続ができるサーバに bare リポジトリを作ることでも Git サーバとして機能しますが、それでも gitosis を使う優位性は以下のような点にあります。

• 公開鍵認証を用い、通信にSSHを利用するため安全に利用できる
• 公開鍵でユーザを識別し、リポジトリに対するアクセス制御が設定できる
• サーバにアカウントとは切り離して、リポジトリへのアクセスアカウントの作成ができる

gitosis はマスターリポジトリとして利用するサーバのみインストールします。リモートから clone / pull / push をするクライアントには、通常通りの Git がインストールされていれば利用することができます。