プログラマになりたい このページをアンテナに追加 RSSフィード

     文系SEです。いい年なってもコード書き続けます。
     やっぱグレートなプログラマになりたいっす。

2013-02-25

[]密かに便利。githubの.gitignore集

 gitでバージョン管理する時の最初のお仕事。それは、.gitignoreを編集して、不要なファイルまでリポジトリに格納されないようにすることではないでしょうか?

 .gitignoreは基本的には、同じプラットフォームだと同じモノを適用できます。一方でプロジェクトごとのスペシャルなモノもあります。というところで、プロジェクトの最初に別のプロジェクトの.gitignoreを持ってきて、ちょっと編集とすることが多いと思います。これが意外に面倒くさい。気の利いた人だったら、ひな形のファイルを何処かに置くとかWikiにまとめてくれるということをしてくれるかもしれません。あったら便利ですね〜。

 と思って、ググってみたらGitHubで用意されていました。

github/gitignore · GitHub


例えば、Railsだとこんな感じです。便利〜。これこそ、ソーシャル・コーディングですね。

f:id:dkfj:20130225230911p:image

2013-02-16

[][][][]GitLabのPublic AMIを公開しました。

f:id:dkfj:20130216210703p:image


 前回、GitLabのインストール手順をまとめました。しかし、手順はかなり複雑で、たぶん殆どの人がハマると思います。そもそもAWSだから誰かがAMIを作って公開したら良いのはと考えて、試しに自分のAMIをPublicで公開することにしてみました。

 このAMIをPublic AMIから検索してください。

ami-f1af28f0


初期設定の仕方


 AMI選択後に起動してec2-userでログインしてください。ログイン後にrootになってsetup.shを起動してください。gitlabユーザからgitにsshで接続する為の鍵と、gitoliteの設定を行います。

$ sudo su -
# ./setup.sh

 後は、Webでログインしてください。ID・パスワードはデフォルトの通りです。

login.........admin@local.host

password......5iveL!fe


お願い


 PublicでAMIを公開するのは初めてですので、お作法等は把握しておりません。また動作検証も充分というレベルではないので、何か不具合があればご指摘いただければありがたいです。コメントもしくはTwitterで連絡ください。このAMIの利用は自己責任でお願いします。またAMIの利用によって生じたいかなる損害についても一切の責任を負い兼ねますのでご了承ください。


2013/3/1 追記

ついでにCommunity Contributionsに登録してみました。

AMI: GitLab-4.1.0-Amazon-Linux-AMI-2012.09


See Also:

Amazon Linux AMIにGit + Gitolite + Gitlabをインストールして、プライベートGitHubを構築する



2013-02-13

[][][]Gitのフック機能で、リポジトリをAmazon S3にバックアップする

 Gitのリポジトリ運用の要となるのが、バックアップ運用です。一般的には、定期的なバックアップを仕込むといった運用をしている所が多いと思います。一方で、定期作業であれば最終バックアップから障害発生時点でのデータ消失という危険性はあります。ということで、プッシュごとにフルバックアップが取れれば理想です。それも利用者が意識しない形でないといけません。

#Gitなので分散リポジトリから復旧という話もありますが。


 ということで、Gitのフック機能でAmazon S3にバックアップするパターン例です。やり方は簡単で、リポジトリ毎のhooksの部分に同期スクリプトを呼び出すコマンドを書けば良いだけです。


post-receive,post-update等に記載

#!/usr/bin/env bash
/foo/var/sync.sh &

ポイントは、&でバックグランドプロセスにした上で同期プログラムを呼び出すことです。何故ならデータ量に応じて、同期に時間が応じます。その間、コミットしたユーザを待たせるのを防ぐためです。


同期方法は、s3syncでもs3cmd syncでも何でも構いません。

sync.sh

s3cmd sync --verbose --recursive --delete-removed --reduced-redundancy /some/git/project s3://yourbuket/git/project

 簡単便利で、安心のgit+s3のバックアップでした。もちろん、GitではなくSubversionでも大丈夫です。是非、お試しあれ!!


See Also:

Amazon EC2からS3にバックアップする為のS3Sync

Amazon Linux AMIにGit + Gitolite + Gitlabをインストールして、プライベートGitHubを構築する

Git+DropBoxで、プライベートリポジトリ作成。或いはGitをAmazon S3でバックアップ

週末プログラマにお薦め!!Subversion+DropBoxで似非分散型バージョン管理


2013-02-12

[][]Amazon Linux AMIにGit + Gitolite + Gitlabをインストールして、プライベートGitHubを構築する

 半年くらい下書きフォルダーにあったGitLabのインストール記事をサルベージしました。今回は、Amazon Linux AMIと最新のGitLab 4.1系でインストールしています。が、あまりに長く面倒くさいので、三行でまとめてみました。

  • GitLabはGitHubのクローンで、セキュリティー・ポリシー的にGitHubがNGな会社に最適
  • GitLabの中身は、Git + GitoliteをラッパーしたWebインターフェース
  • インストールが死ぬほど面倒くさいので、後でAWSのPublic AMIとして公開するよしたよ

GitLabのPublic AMIを公開しました。


以下、手順です。気が長い人は読んでください。

ライブラリのインストール


 素のAmazon Linux AMIを立ち上げたら、まずライブラリをインストールしましょう。一部sudoでやっていくと詰まるところがあったので、素直にrootになってからインストールしています。

$ sudo su -
# yum install -y gcc-c++ patch readline readline-devel zlib zlib-devel libyaml-devel libffi-devel
# yum install -y make bzip2 openssl-devel
# yum install -y gettext libcurl-devel gdbm-devel mysql-server mysql-devel git python-devel libicu-devel postfix
# yum install -y python-pip redis --enablerepo=epel
# yum -y install httpd httpd-devel mod_ssl
# yum -y install perl-Time-HiRes

 Amazon Linux AMIは、デフォルトではExtra Packages for Enterprise Linux (EPEL)のアクセスがオフになっています。そのため、python-pipとredisは --enablerepo=epelをつけてインストールしましょう。


サービスの開始


 インストール終了後に、サービスを開始しましょう。特に特別なことはないです。

# chkconfig httpd on
# chkconfig redis on
# chkconfig mysqld on
# /etc/init.d/httpd start
# /etc/init.d/redis start
# /etc/init.d/mysqld start

rvmのインストール


 Amazon Linuxのrubyは、1.8系です。これを1.9系に変えると、awsのrubyツールが動かなくなるので、rvmで1.9系をいれることにします。

# \curl -L https://get.rvm.io | bash -s stable --ruby
# echo '[[ -s "/usr/local/rvm/scripts/rvm" ]] && . "/usr/local/rvm/scripts/rvm" # Load RVM function' >> /etc/bashrc
# source /etc/bashrc

ユーザの作成


 GitLabとGitolite用のユーザを作成します。Gitoliteがgitを、GitlLabがgitlabを使用します。また同じグループに属して、gitディレクトリへのグループアクセス権を付与します。

# useradd git
# useradd gitlab
# usermod -G git gitlab
# chmod g+rx /home/git

gitlabアカウント用の鍵ファイルを作成


 GitLabインストールの最大の難関である、gitlabユーザからgitへのsshでのログイン設定を行います。そもそも何故これが必要かというと、GitLabはgit及びgitoliteの薄いラッパーのWebインターフェースとして作られている為です。画面から操作を受け付けると、GitLabを動かしているgitlabユーザがssh経由で所定のコマンドを実行しています。この構造を理解していないと、GitLab動かねぇよとハマることになります。(ハマって初めて理解できました。)

 手順としては、gitlabアカウントで秘密鍵・公開鍵を作成します。その後、gitアカウントのauthorized_keysにgitlabの公開鍵を追加します。

# su - gitlab
$ ssh-keygen -t rsa -f ~/.ssh/gitadmin
(パスフレーズは空でO.K.です)
$ exit #rootに戻る
# cp /home/gitlab/.ssh/gitadmin.pub /home/git

Gitoliteのインストール


 ここまで設定が出来たらGitoliteのインストールです。Gitoliteは、gitユーザの管理をしてくれるアプリケーションです。GUIでのUIはいらないけど、gitのアカウント管理は面倒臭いという場合は、Git+Gitoliteでも充分重宝すると思います。

# su - git
$ git clone git://github.com/sitaramc/gitolite
$ gitolite/install
$ gitolite setup -pk /home/git/gitlab.pub"
$ vi /home/git/.gitolite.rc
#UMASKの値を0077から0007
$ exit

 ここでのポイントは、.gitolite.rcを編集してUMASKの値を0077から0007に変更することです。私もここでハマりました。


gitlabアカウントからgitへのログイン確認

# su - gitlab
$ ssh -i .ssh/gitadmin git@localhost
$ exit #ログイン出来る事を確認して、ログアウト
$ vi ~/.ssh/config
  Host localhost
  HostName localhost
  User git
  IdentityFile ~/.ssh/gitadmin
$ chmod 600 .ssh/config

Gitlabのインストール


 遂にGitLabのインストールです。GitLabのインストール自体は難しくないのですが、動かしてみて問題点を解決するというのが何度か繰り返すことになるでしょう。

# sudo su - gitlab
$ git clone https://github.com/gitlabhq/gitlabhq.git gitlab
$ cd gitlab/
$ git checkout 4-1-stable
$ chown -R gitlab log/
$ chown -R gitlab tmp/
$ chmod -R u+rwX  log/
$ chmod -R u+rwX  tmp/
$ cp config/database.yml.mysql config/database.yml
$ bundle install --deployment --without development test postgres
$ git config --global user.name "GitLab"
$ git config --global user.email "gitlab@localhost"
$ cp ./lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive

# chown git:git /home/git/.gitolite/hooks/common/post-receive
$ bundle exec rake gitlab:setup RAILS_ENV=production
$ mysql
create database gitlabhq_production  CHARACTER SET utf8;

# bundle exec rake db:setup RAILS_ENV=production --trace
# bundle exec rake db:seed_fu RAILS_ENV=production

 このメッセージが出れば、成功です。

login.........admin@local.host

password......5iveL!fe

Updating repo permissions ...

remote: Counting objects: 10, done.

remote: Compressing objects: 100% (7/7), done.

Receiving objects: 100% (10/10), 1.30 KiB, done.

Resolving deltas: 100% (1/1), done.

remote: Total 10 (delta 1), reused 0 (delta 0)

... done

Creating satellites for ...skipping, because you have no projects


rootで起動設定も行います。

# curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/4-1-stable/init.d/gitlab
# chmod +x /etc/init.d/gitlab
# chkconfig gitlab on
# /etc/init.d/gitlab start

gitlabユーザで、下記のコマンドでステータスチェックが行えます。

$ bundle exec rake gitlab:env:info RAILS_ENV=production
$ bundle exec rake gitlab:check RAILS_ENV=production

passengerのインストールとapacheとの連携


 passegerを使ってapacheと連携します。ポイントは、gitlabからgitへの接続の為、apacheをgitlabユーザで起動することです。

#gem install passenger --no-ri --no-rdoc
#gem install charlock_holmes --version '0.6.9'
#passenger-install-apache2-module

apacheの設定。インストール後のサンプルに従って、設定。/etc/httpd/conf.d/passenger.confを作成します。

LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.3-p385/gems/passenger-3.0.19/ext/apache2/mod_passenger.so

PassengerRoot /usr/local/rvm/gems/ruby-1.9.3-p385/gems/passenger-3.0.19

PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p385/ruby

<virtualhost *:80>

# ServerName www.yourhost.com

# !!! Be sure to point DocumentRoot to ‘public’!

DocumentRoot /home/gitlab/gitlab/public

<directory /home/gitlab/gitlab/public>

# This relaxes Apache security settings.

AllowOverride all

# MultiViews must be turned off.

Options -MultiViews

</directory>

</virtualhost>


apacheをgitlabユーザで動かします。(それが嫌なら、gitlabをapacheユーザで動かす必要があります。)

# vi /etc/httpd/conf/httpd.conf
#User apache
#Group apache
User gitlab
Group gitlab
# cd /var/log
# chown -R gitlab:gitlab httpd/
# /etc/init.d/httpd restart

トラブルシューティング


gitlabからgitへsshでログイン出来るものの、gitolite-adminがclone出来ない

git clone localhost:gitolite-admin
fatal: 'gitolite-admin' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
rake aborted!
unable to clone gitolite-admin repo

試してみると、こちらのコマンドではclone出来ます。

git clone git@localhost:~/repositories/gitolite-admin.git

素のsshでログインしていて、gitoliteのコマンドが通っていなかったことが解ります。.ssh/authorized_keysを


画面からリポジトリを作成すると、"git config 'core.sharedRepository' not allowed"のエラーが出る

 次のようなエラーがでたら、.gitolite.rcのGIT_CONFIG_KEYSを編集しましょう

February 11, 2013 14:22 -> ERROR -> Gitolite error -> remote: FATAL: git config 'core.sharedRepository' not allowed

remote: check GIT_CONFIG_KEYS in the rc file

To git@localhost:gitolite-admin

75dc4de..5f42c35 master -> master

 下記の方法で解決です。

vi /home/git/.gitolite.rc
GIT_CONFIG_KEYS             =>  '.*',

まとめ


 結論としては、GitLabのインストールはとんでもなく面倒くさいです。個人でGitHubチックに使いたいのであれば、間違いなくGitHubを使いましょう。それが、あなたの為です。GitLabは、企業ユースでGitHubがNGの場合のみ使うのが良いのではないでしょうか。インストールは面倒臭いものの、使いはじめると中々便利です。Gitの管理者の手間も少なくなり、またコードの共有も進むことでしょう。

 でもやっぱり面倒くさいと思うので、Amazon Linux AMIでインストール済みのイメージを公開しようと思います。gitlabからgitへの認証キーの作成の部分を、対話式で行えるようなバッチを作ってから提供したいと思いますので、今しばらくお待ちください。


See Also:

Amazon-LinuxにRVMを利用してApache+Passenger+Railsのインストール

StatSVNのGit版 GitStatsを使ってみる

Gitのフック機能で、リポジトリをAmazon S3にバックアップする

Git+DropBoxで、プライベートリポジトリ作成。或いはGitをAmazon S3でバックアップ

GitLabのPublic AMIを公開しました。



参照:

gitlabhq/doc/install/installation.md at stable · gitlabhq/gitlabhq · GitHub

Trouble Shooting Guide · gitlabhq/gitlab-public-wiki Wiki · GitHub

CentOS6にGitLabをインストールする方法 | Ryuzee.com

CentOS6.2でGitLabのインストール - おおらかにいこう

Amazon Linux RVM/Ruby1.9/Apache2/Passenger3環境構築 - 130単位

ローカルで GitHub を構築! Git リポジトリ管理ツール「GitLab」を Mac OS X にインストールしてみた | クラスメソッド開発ブログ


2012-09-23

[][][]Git+DropBoxで、プライベートリポジトリ作成。或いはGitをAmazon S3でバックアップ

 2年程前に書いたSubversion+DropBoxの焼き直しです。今風にGitで書きなおして見ました。後は、同期だけでは心許無いので、バックアップ戦略について考えてみました。


まず解決したい問題は、下記の3つです。2年前から変わっていませんね。

  1. ソースのバックアップをどこか違うところに持ちたい
  2. ネットワークがオフラインの時でも、コミット出来るようにしたい
  3. 違う環境から作業しても、最新のソースを取れるようにしたい

 まず1のソースのバックアップについてです。厳密にはバックアップではなく、同期で実現しています。開発機単体ではなくDropBoxにコピーされるので物理的障害等に対する対策は充分です。一方でDropBoxの特性として、DropBox上に置いているリポジトリを消してしまうと、消された状態で同期されてしまいます。DropBox上のリポジトリと、ローカルのワーキング・リポジトリに分ければ問題はなくなります。保険の為にAmazon S3にバックアップも設定する方法も、併せて紹介したいと思います。

 次に2のネットワークがオフラインの時でもコミットしたいという点ですが、実はGitを採用している時点で実現できています。GitにDropBoxを併用することで、3の違う環境から作業しても最新のソースを取れるようにしたいを実現出来ます。それでは、具体的な手順を見て行きましょう


DropBoxの準備


 何はさておき、DropBoxのアカウントが必要です。まだアカウントを持っていない方は、この招待コードから開設して頂けたら通常で開設するより、+500MBの容量をゲット出来ます。(私のアカウントも+500MBになりますので、宜しければお願いします。)

 アカウント開設したら、Windows,Macそれぞれの手順に従ってDropBoxアプリをインストールしてください。あまり難しくないのと、バージョンごとにUI等の見た目が変わるので、手順は割愛します。


DropBox上にリポジトリの作成


 Macを想定してのコマンドです。Windowsの方は、適当にコマンド置き換えてください。

ポイントとしてはリポジトリの作成時にbareオプションを指定して、DropBox上のGitリポジトリにはGitの管理情報のみを作成するようにします。

cd ~/Dropbox/
mkdir git
mkdir git/project1
cd git/project1
git --bare init --shared=true

DropBoxからクローンして、ローカルで開発する


 プログラミング等の作業用ディレクトリは、DropBox以外のローカルディスク上につくります。

cd ~/projects
git clone ~/Dropbox/project1

 後は、通常のGitの使い方と同じです。

cd ~/projects/project1
〜プロジェクトのファイル等作成〜
git add .
git commit -m"最初のコミット"
git push origin master

 逆に、XCode等でローカルのGitリポジトリが既にある場合は、次のように追加します。

git remote add origin ~/Dropbox/git/project1/
git push origin master

共有してチームで使う


 またDropBoxの共有機能を利用することにより、GitHubのTeam共有的なことも出来ます。やり方は簡単で、DropBoxのWeb管理画面から該当のリポジトリを共有するだけです。そうすると、任意の相手を招待できます。共有した後の手順は、先ほどの手順と同じです。なんちゃって共有リポジトリの出来上がりです。

f:id:dkfj:20120923170653p:image

 注意点としては、同時にgit pushするとコンフリクトの恐れがあります。シビアな使い方をする場合は、GitHubのPrivateリポジトリを使うか、正規のGitサーバを用意しましょう。


Amazon S3を使ったバックアップの戦略


 最後に、DropBox領域のバックアップです。DropBoxの内部構造的には、Amazon S3のストレージを使っているので論理上の堅牢性はAmazon S3と同等の99.999999999%と9が11個並ぶレベルです。一方で、DropBox社や自分自身の問題でデータを消失する可能性は、一定の確率であると考えるべきです。その為のバックアップです。バックアップ先はどこでも良いと思うのですが、やはりクラウドのストレージにバックアップするのが便利で良いです。

 アーキテクチャ的に考えるとAmazon以外のクラウドにバックアップするのが本来良いのですが、私はAWS一押しなのでAmazon S3にバックアップします。単純にDropBoxの領域とS3を同期するだけでは全く意味が無いので、どうバックアップするか考える必要があります。

 まず防ぎたい事態とはDropBoxのGitのフォルダを間違えて消してしまい、それがそのまま消された状態で同期されることです。対策としては2つ考えられます。1つ目は、DropBoxの領域を定期的にバックアップして何世代か持つことです。誤って消してしまったとしても、世代が残っている間に気がつけば復元できます。問題は、何世代持つか。またバックアップの間隔をどうするか。間隔を長くすれば、その間に気づく可能性が高くなります。一方で前回バックアップからの差分が取りこぼされる恐れがあります。対策としては、間隔を短く世代数を多くすることです。ストレージ料が掛かる以外は、問題は少ないように見えます。

 一方でバックアップ間隔を短くしても、その間でバックアップ漏れが起こる可能性は否定できません。漏れを無くすにはgitのpush時にS3に対する同期コマンドを発行すれば良いのです。先ほど同期は意味がないと言いましたが、Gitコマンドをトリガーとする同期であれば、人的ミスによるリポジトリ消失を防ぐことが出来ます。

 また全く別の方法として、S3自体にリポジトリを置くという方法があります。JGitを使えば実現できますが、クライアント側の制約がある程度つきます。これについても、また機会を改めて紹介したいと思います。


GitのHookコマンドによる同時の実行


 Gitには、各種のフックが用意されています。主にクライアント側とサーバー側のフックの2種類があります。今回はサーバ側のフックであるpost-updateで実行します。これはgit pushが実行された後に実施されます。ここに同期プログラムを仕込めばよいです。S3への同期はs3syncもしくはs3cmdで可能です。この辺りにまとめてるので、参照してください。


まとめ


 DropBox+○○という組み合わせは、今では色々と出ています。これはDropBoxの単純性+手軽さが優れている点だと思います。一方でDropBoxだけでは解決出来ない問題は、他のサービスと組み合わせを試してみてください。効果抜群になるケースも沢山ありますよ。


See Also:

週末プログラマにお薦め!!Subversion+DropBoxで似非分散型バージョン管理

StatSVNのGit版 GitStatsを使ってみる

XcodeでGitのリモートリポジトリ(remote repository)を追加する方法

Amazon EC2からS3にバックアップする為のS3Sync


参照:

Git 7.3 Git のカスタマイズ - Git フック