Gitlabを試してみる
昨年度GitHubのEnterprise版を試した感想のようなものをGitHub Enterpriseを試してみるにまとめた。
年が明けてからは、EnterpriseではなくOSSのGitHub、というか、Gitのホスティング管理ソフトウェアGitlabを試してみた。
GitHub上でソースコードが公開されていて、インストール関係の作業をshにまとめたものも公開されている。
個人的にはGitHubでのprivateリポジトリでプロダクトを管理している会社も多いのではないかと思う。
Businessプランとして提供されているものは最安コースだと$25、月3000円に満たないので、さほど大きくないPJやチームでは、SCMサーバの運用費よりも安く、手軽に使えると感じてこのコースを選ぶケースが多そうだ。
会社全体でSCMの主流をSVNからGitに据え、規模が大きくなるとGitHub Enterpriseという選択肢も出てくる。
ただ、GitHubはprivateなものは有料、畑は違うけれどプロジェクト管理ソフトウェアのRedmineのようにOSSの提供はされていない。
金銭面的な理由でとことんローコストを貫きたい、あるいは中身を自分達でカスタムしたいなら、GItHubのOSSに手を出すことになると思う。
ということで、一度は触ってみようと思い立ち、GitLabを試してみることにした。
環境構築
マシンのセットアップに使ったもの
VirtualBoxのインストール手順は割愛する。Vagrantのインストールを行いBase Boxesと呼ばれるVirtualBoxで使えるOSのtemplateを使用して、サーバを構築する。
$ gem install vagrant $ vagrant box add ubuntu-1110-server-amd64 http://timhuegdon.com/vagrant-boxes/ubuntu-11.10.box $ vagrant init ubuntu-1110-server-amd64 $ vagrant up
Ubuntuを選んだ理由は、Gitlabのページに書かれている通り、GitlabのofficialサポートのOSはUbuntuかDevianだから。
Fedora、CentOS、Red Hastでも稼働し、Mac OS X、FreeBSDでも動かせるけれど、今回は環境を縛る条件がなかったので、公式サポートを名言されているUbuntuを選択した。
インストール
遊び場ができたので、後はGitlabのインストール。ここで選択肢が二つある。
一つは、手動セットアップ、とはいってもWikiに公開されている手順を踏んでいくだけで、すんなり入る。
もう一つは、上記のセットアップ手順をshにまとめたものがGitHub上で公開されているので、そちらを使うこと。
最初は手動でセットアップして、その後にインストールshを使ってやってみた。
後は、Passengerで動かすのと、Passenger×Nginx、Unicorn×Nginxで動かすのをそれぞれ試してみたくらい。
Unicornを選ぶ理由としては、再起動時にダウンタイムを限りなく0に近づけられるから。
正直SCMサーバとして使う上では、使うユーザ数を考慮すればパフォーマンスの理由でApplication ServerやHTTP Serverを悩む理由はなさそう。
また、手動セットアップとインストールshでは細かい違いはあるけれど(インストールshの方では、システムユーザとしてnginxというアカウントを追加する)、
基本的な動きはほぼ同じ。ただ、Gitlabのバージョンやブランチを細かく指定したいなら、インストールshをいじらないといけない。
さらに付け加えるなら、インストールsh内部でユーザの追加やpythonのインストールなどもしているので、一度は手動セットアップするか、インストールshの中身をじっくり見た方がよい。(とはいっても、この手の作業をする人でshの中身を見ない人はいないと思う)
詰まりどころ
- よくWebでも書かれているのはPermissionの設定ミス
Gitlab内に登録されたリポジトリは、/home/git/repositories/以下に配置されるので、Gitlabを起動しているユーザにここへの書き込み権限がないといけない。
- SSH鍵による認証
Gitのリポジトリ書き込みは原則としてSSHによる認証。このため、GItlabを起動しているユーザは、鍵認証情報を保持している必要がある。
- Nginxを使う場合のNginxの起動ユーザ
NginxのWorkerプロセスを立ち上げているユーザもGitlabを起動しているユーザと同様に、というか、Gitlabを起動しているユーザがWorkerプロセスを立ち上げる必要がある。
いくつかはまる部分はあるけれど、半日もあればGitのホスティングサーバがセットアップできる。更新も定期的に行われているので社内でGitのホスティングサーバを無料で立てたいというのにはおすすめだと感じた。
ただ、最終的に常日頃から使いなれたGitHubと比較すると、どうしても使いづらいという感覚が拭えない。Redmine/Trackのように目的は同じだけどUIは全然違う、ではなく、目的は同じでUIも似通った感があるせいか、逆に違和感が払拭できない。
まあ、最終的には使いたいものを使えばいいと思ったのと、Railsアプリを公然と使えて楽しめたからいいやー、という結論に落ち着いた。
2011年の振り返り
一年を振り返るといっても、長過ぎるので今年に入ってから興味を持つようになったことを振り返る。
- 今年興味を持ったこと
開発プロセス、安定したリリープロセス、のベストプラクティス、これらを支えるツールとか。
- 興味をもったきっかけ
短いながらアプリケーション開発業務に携わってきて環境が快適で製造物が安定していると視野を広く持て、逆にちょっとした作業をするのにいちいち手間がかかったりする環境で製造物が不安定だと気持ちに余裕がなく、視野が狭くなりがちだと気づいたことがきっかけだった、と今は思っている。(もちろん、全てが環境による問題ではないけれど、どんな人でも多かれ少なかれ環境による影響はあると思っている。)
環境によって自分の視野がかわるなーと気づいてから、どんな職種でも共通していえるのは環境というのは、自分自身が思っている以上に周囲や自分に影響を与えていて、そこって個人のスキル面とは別な部分で大切な部分だと、そういうことを考え始め、開発プロセスやリリースプロセスのベストプラクティス、という部分から入り、開発作業を支える環境というものに興味を持ち始めた。
- 興味をもってから考えたこと
じゃあ、そういう快適な環境って個人が作れるものなのかというと、答えはYESだと思っている。多少の個人差はあるけれど、人は面倒くさがりだと思うので、同じ作業を毎回毎回何時間もかけてやるのは嫌がるし、あれこれ手間をかけるも嫌、もっと楽な方法があるならそれを使いたいと思う人が大半だと思う。そうして、自分なりに楽な方法、快適な環境を整えたりしていく。
自身も自分のローカルマシンの環境を細々整えたり、チームで開発環境を改善していったりしたので、こういう部分は個人、あるいはチームで整えていくという箇所もあると思う。現実的にプロジェクト単位でリリース手順とかは違うので、そういった実際の作業まで落とし込んだ部分はチームで考えていくことだと思っている。
ただ、そういった実際の作業手順まで落とし込む前、もっとざっくりとした開発の流れとかは個人個人や個々のチームで模索してやるよりは、考えを浸透させた上で、仕組みとして入れてしまうのが全体でみれば効率がよくて、相手にとっても嬉しいこと(アプリケーションの開発プロセスなど特にそうで、自分で色々な方法を考えるのも楽しいけど、ベストプラクティス的な手法があればそれに乗っかりたいと私は思う)なんじゃないかと考え始めた。
- 興味をもってからやりはじめたこと
先月から新たな職場で働くことになり、色々と仕組みづくりの部分に目を向けるようになった。その一環として、今までは技術系の勉強会に参加していたけど、開発プロセスの勉強会にも参加するようになった。
リーン開発、アジャイル開発、ワンクリックデプロイなど、単語は知っていたけどそれが何者なのか知らなかったこと、実際に経験してきたこと、どちらも勉強会に出ることによって今までより理解を深めることができたと思っている。
後は、色々なチームのリリース手順や開発手法を見ること、他人のコードを見ること、を習慣づけるようにした。
- 何故ブログを書いたのか
自分が興味をもったことを振り返って、何故そこに興味をもったのか、どういったことがきっかけで何をやりたいと考えたのか、そういったことを一度整理したかったというのが理由の一つ。
もう一つは、振り返りというものを定期的にする習慣をつけたかったのが理由。
来年の話をすると鬼が笑うというけれど、来年も年末に自分自身を振り返るなにかを書きたいなと思う。
女子部イベントに釣られてMongoDBをMacに入れてみた
昨日参加したMongoDB女子部Startupのイベントで、久しぶりにMongoDBという単語に触れた。MongoDBの特徴とか実際にイベントでお話された内容はこちらのブログで紹介されているので、自分はMac OS X(10.6.8)にMongoDBをインストールする部分だけ書いてみることにした。
まず、MongoDBのOfficialにあるQuickstart OS Xを見てみた。入れ方は2種類あって、バイナリからとPackage managersからのどちらか。今回はPackage managersで入れてみることにした。MacのPackage managersということで、MacPortとHomebrewが紹介されていて、最近会社で使い始めたHomebrewで入れてみることにしたが、そもそもHomebrewを自分のMacに入れていないことに気づいた。なのでやることは1つ増えた。
やること
- Homebrewのインストール
- MongoDBのインストール
まずはPackage managersのHomebrewから。こちらもオフィシャルにあるInstallationを見ていれる。nodeとかpowもそうだけどインストールはスクリプト化されていて、インストール作業は1行だけ。
$ ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
これでbrewのインストールが終わり。ただ、インストールの条件としてMacOS X 10.5以上、Intel CPU,XCode,Javaが必要。私の環境はこれらの条件を満たしていたので、上記のコマンド1行で行けた。
Homebrewをいれたので、今度はMongoDBのドキュメントに戻り、brewコマンドでMongoDBを入れる。
$ brew update $ brew install mongodb
これでMongoDBのインストールも終わり。Quickstartの続きでは、下記の2行が書いてる。これはmongodbのDBファイルが格納される場所がデフォルトでは/data/db以下になっているために作成している。mongodbの起動時に--dbpathオプションでDBファイルの場所は任意のディレクトリに置き換えられるので自分の好きなディレクトリに作ってもいい。
$ sudo mkdir -p /data/db/ $ sudo chown `id -u` /data/db
いよいよ起動。
$ mongod
オプションをつけないと下記のようなメッセージが出力される。プロセスID、使用ポート、DBファイルの各の場所、ホスト名、DBバージョン、Gitベージョン、ビルド情報、journalディレクトリの場所、webコンソールのポート番号が吐き出されている。後は、ローカルの54919ポートからのコネクション接続の確認?最後のだけよく意味がわからなかった。54919からの接続を受け入れ後、すぐにコネクションが閉じられているけど、これは何かに使うのだっけ。。
Sun Dec 11 14:39:45 [initandlisten] MongoDB starting : pid=36510 port=27017 dbpath=/data/db/ 64-bit host=kondou-misa-no-MacBook-Pro.local Sun Dec 11 14:39:45 [initandlisten] db version v2.0.1, pdfile version 4.5 Sun Dec 11 14:39:45 [initandlisten] git version: 3a5cf0e2134a830d38d2d1aae7e88cac31bdd684 Sun Dec 11 14:39:45 [initandlisten] build info: Darwin erh2.10gen.cc 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 BOOST_LIB_VERSION=1_40 Sun Dec 11 14:39:45 [initandlisten] options: {} Sun Dec 11 14:39:45 [initandlisten] journal dir=/data/db/journal Sun Dec 11 14:39:45 [initandlisten] recover : no journal files present, no recovery needed Sun Dec 11 14:39:46 [websvr] admin web console waiting for connections on port 28017 Sun Dec 11 14:39:46 [initandlisten] waiting for connections on port 27017 Sun Dec 11 14:40:46 [clientcursormon] mem (MB) res:14 virt:2416 mapped:0 Sun Dec 11 14:40:59 [initandlisten] connection accepted from 127.0.0.1:54919 #1 Sun Dec 11 14:41:03 [conn1] end connection 127.0.0.1:54919
立ち上がったので、早速webコンソールにて確認。無事に動いている様子。
http://localhost:28017/
続いてターミナルからの接続を確認する。こちらも無事動いている様子。
$ mongo $ > db.foo.save( { a : 1 } ) $ > db.foo.find() $ { "_id" : ObjectId("4ee449c64b6d8bfb990f72d9"), "a" : 1 }
インストールと起動までは1時間弱で十分終了する。(自分の場合はrbenvやruby1.9.3のビルドもしてたから、2時間くらいかかったけど)
折角勉強会に出たんだし、実際にスライドで説明されていたものとかを自分の環境で動かしたいので、これからMongoDBの2系を家で触ってみようと思う。
GitHub Enterpriseを試してみる
先月からGitHub EnterpriseのTrialを試している。
GitHub EnterpriseはGitHubを自社内に持つことを可能とするサービス。
GitHubは登録すれば誰でも使えるのに対してGitHub Enterpriseは自分達のイントラネット内に利用者を絞れる。
何故、Webで提供されているサービスがあるのにそれを使わないのかといわれると、TwitterとYammerの関係に近いと個人的には感じている。会社と個人をわけるというよりは、情報があふれすぎている中、社内のみに情報発信者を絞ることで、情報の発信者を見やすくするという目的がある。
例えば、1000人の人がいて、その中に自分の興味を持つ分野と同じ分野に興味を持つ人が10人いたする。その10人の中で同じ会社の人がいるかどうかを調べたりなんてわざわざしない。少なくとも私はしていない。大体が、なんとなく話が合いそうと感じた人をfollowしたりlikeしたりする。
Web上での知り合いは、そういった意味で自分が普段縁のない人と知り合える面白さがあるけど、実際に直接顔をあわせた上で頻繁に情報をやり取りできるのは会社の人の方。特に自分が仕事で調べていることは6〜7割くらいの確率で社内の誰かが知っていると思う。分散型のバージョン管理、スピード感のある開発作業(fork,pull request,merge)、それに加えて社内ナレッジの共有に一役買ってくれそうだということで、導入を進めたいと思った。
費用面としては1人あたり1年間2万。これを高いととるか、安いととるかはケースバイケースなので、横においておく。
導入したいけど実際使ってみないとわからないこともあるのでトライアルを申し込んだ。待つこと10日、GitHubから返事がきた。Webフォームからの申し込みだけど、auto-replyメールは届かない。最初はメールアドレスを間違えたかと思ってどきどきしたけど、そうじゃなくて、申請者が所属している会社所有のメールアドレスから送られているか確認しているらしい。(返答が遅いと思って、個人のメールアドレスを利用して再度問い合わせたら、個人用のメールじゃなくて、会社のメール使ってくださいとお返事がきたので判明した事実。)
そして、いよいよ届いた、招待メール。メールに記載されているURLの先はこのページ。
トライアル版の有効期限や通知が表示されるDashboar画面にDownload、Profile、Logoutのリンクがあるのみ。すごくシンプル。でもIntroduction的なものがなにもなくて、少し驚いた。早速Download画面にいって、ファイルを落とす。ファイルは全部で3つあり、OVFファイル、ライセンスファイル、ソフトウェアパッケージの構成となってる。Virtual Applianceとして配布されていることを、この時点で初めて知った。
なにもわからぬままえいやでトライアルを申し込んだけど、設定にはさほど困らなかった。OVFをツールでVMDKに変更してVMware Fusionの仮想マシンとして立ち上げ。
setup画面にアクセスしてと出ているので、setup画面にアクセス、ライセンスファイルとソフトウェアパッケージを登録する画面が出てくるので、ファイルをアップ、インスタンスの作成処理が開始される。インスタンスの作成処理が完了すると、後はGitHubと同じ見慣れた画面が表示される。違うところは、右上にAdminのボタンが表示され、Management Consoleなるものが見えること。立ち上がった仮想マシンはどうするかというと、実はまったくいじれない。仮想マシンの中身というかプロセスや動きを見るにはどうしたら?と質問したら『中はいじれないし見れないよ、Management Consoleから制御してね!』と返事がきた。『バックアップはスナップショットで取ってね!』とのこと。ManagementConsoleで各ミドルウェアの再起動ができ、ページヘッダにディスク使用率、レスポンスタイム、CPUの使用率などが表示されるので、そこを見て運用するらしい。つまり、完全にソフトウェアとしての販売であり、仕組み的な部分でのカスタマイズできる余地はない。
もちろんDNSの設定やSMTPサーバの指定はManagementConsole上でできる。アカウントも既存のLDAPサーバの認証と連携できるし、Webサービスをそのまま社内ネットワークにのせたというGitHubの表現は多いに正しい。
そんなこんなでGitoriousというオープンソースのGitHubコピーを自分たちでカスタマイズした方が自由度は遥かに高い。だけど、便利な機能やUpdateされた部分は自分たちでいじらないと反映されないし、セットアップは少し手間がかかる。ここはオープンソースの醍醐味で、これはこれで楽しい。後は運用するコストに対する考え方だと思う。ただ、往々にしてこういったツールは社内のリソースが足りないと優先度がさげられ更新されずに初期に導入したバージョンのまま運用するというのが現実としてよくある。(個人的な経験で言うと、Redmineを導入して、入れるタイミングでは最新版を入れたけど、その後にまめにバージョンをあげているチームはあまりない。だいたいチームの発足が古ければ古いほどRedmineのバージョンも古い。)
色々な会社や個人がGitHubやGitorious等を使い始めている中で、こういったツールを検証できたのはちょっと楽しかった。ツールはあくまでツールなので、どう使うかは使い手次第だけど、個人的にはGitHubの提唱するソーシャルコーディングというのは、とても効率がよく、そして参加者にとってのメリットが高いサービスだと思うので、なんとかうまいこと社内にソーシャルコーディングを導入したいなと思った。
トライアル版を試してみての感想をまとめてみた、ただそれだけ。
Capistranoのdeploy.rbを今更よんでみて、タスクの挙動をまとめてみた(その2)
最近はデプロイもツールを使って一発になったけど、タスクの挙動をよく忘れてしまうので、備忘録をつけてみた。
フレームワーク:RubyOnRails
バージョン:3.1.0
デプロイツール:Capistrano
バージョン:2.9.0
書き方の例
$ 実際に打つコマンド # 内部処理
リリースしたけど、バグが出たので、1つ前のソースに巻き戻す。
1つ前のリリースに戻し、再起動をかけ、最新のリリースソースを削除する。リリース後、バグが発覚し、巻き戻すならこれ。
$ cap deploy:rollback # revision # restart # cleanup
1つ前のリリースに戻し、最新のリリースソースを削除する。再起動は行わない。
$ cap deploy:rollback:code # revision # cleanup
カレントディレクトリの向け先を1つ前のリリースディレクトリに変更する。シンボリックリンクの付け替え。
$ cap deploy:rollback:revision # シンボリックリンクの削除、シンボリックリンクの作成
シンボリックリンクの向き先が最新のディレクトリでなかった場合、そのディレクトリを不要とみなして削除する。
$ cap deploy:rollback:cleanup # シンボリックリンクの向け先を確認して、リンク先でなければ削除
最新ソースの配置、migrate、シンボリックリンクの付け替え、再起動。
$ cap deploy:migrations # update_code # migrate # symlink # restart
プライマリである(つまりマスタ)DBにmigrationをかける。ここは結構カスタムができるので。セットする値も抜粋。でも、これは完全にRails用だから、別の部分でmigrateするなら、それ用のタスクを自分で作成した方がよさそう。
$ cap deploy:migrate # set :rake, "rake" # set :rails_env, "production" # set :migrate_env, "" # set :migrate_target, :latest # #{rake} RAILS_ENV=#{rails_env} #{migrate_env} db:migrate
過去のリリースソースのお掃除
リリースディレクトリを含んで、最新N個のディレクトリ以外は削除する。不要ファイルをつもらせないために定期的にやった方がよさそう。最悪N個はディレクトリが残るので、N-1前のリビジョンまでは残せる。リリース回数がN回より少ない場合は、何もしない。(Nはデフォルトで5)
$ cap deploy:cleanup
停止状態からのサービスの起動。
ソースの配置、シンボリックリンクの作成、migrate、スタートをしてくれる。停止と再起動のどちらでもなく、ただの起動なので、アプリケーションが動いていない状態で行うコマンド。
$ cap deploy:cold # update # migrate # start
Capistranoのdeploy.rbを今更よんでみて、タスクの挙動をまとめてみた(その1)
最近はデプロイもツールを使って一発になったけど、タスクの挙動をよく忘れてしまうので、備忘録をつけてみた。
フレームワーク:RubyOnRails
バージョン:3.1.0
デプロイツール:Capistrano
バージョン:2.9.0
書き方の例
$ 実際に打つコマンド # 内部処理
稼働しているサービスにリリース作業=デプロイを行う。
deployのDefaultのタスクはソースの更新と再起動。起動していることが前提。
$ cap deploy # update # restart
新規に追加したサーバに初期ディレクトリを作成する。
Capistrano用のディレクトリの作成。既存のサーバには影響がない(既にディレクトリが存在する場合はなにもしない)ので、新規にアプリケーションサーバを1台追加した時などは、まずこのコマンドをたたく。
$ cap deploy:setup # setup_directory
再起動をしないでデプロイだけする。
ソースの更新とcurrentディレクトリのシンボリックリンクの向け先の変更。ただし再起動はしない。
$ cap deploy:update # update_code # symlink
以下は個別ではおそらく使わないだろうタスク。
ソースファイルの配布のみ
設定したSCMのリポジトリからソースコードの取得、最新ディレクトリの作成までを行う。失敗した時のrollback処理は、作成した最新ディレクトリの削除。
$ cap deploy:update_code # rollback処理の準備 # deploy # finalize_update
現在のタイムスタンプをもとに最新ディレクトリを作成、sharedのlog,system.pidsのディレクトリにシンボリックリンクを張る。
$ cap deploy:finalize_update # ディレクトリのクリーン&作成 # シンボリックリンクの作成
カレントディレクトリから最新ディレクトリにシンボリックリンクをはる。
$ cap deploy:symlink # シンボリックリンクの作成
緊急用?
一部のファイルだけあげたいといった場合に使う。結構緊急で使いそうかつ、ファイルの指定方法とか忘れそうなので、コマンドもメモ。
$ cap deploy:upload #ex $ cap deploy:upload FILES=templates,controller.rb #ex $ cap deploy:upload FILES='config/apache/*.conf'
自分で設定するもの
ここは特になにも記載されていない。各自の環境にあわせて起動、再起動、停止処理を自分で作成したdeploy.rbに記載する。
$ cap deploy:start $ cap deploy:restart $ cap deploy:stop
とりあえず、ここまで。deploy.rbの半分くらいまでしかまだ読んでいない。続きは明日かな。
東京Node学園祭とExpressの初めの一歩
先日東京Node学園祭に参加してきた。昨年から色んなところできいているNode.jsを知ることが主な目的。
Rails3.1系から正式採用となったCoffeeScriptの勉強会にて、Macにnodeとnpmをインストールしたけれど、それ以後nodeそのものは触っていなかった。その後、MongoDBの勉強会でも耳にしたり、Webサーバとしても耳にしたり、色んなところでNode.jsの単語に触れる機会があった。
サーバーサイドでのJavaScriptコンパイラ、Webサーバとしても大活躍、色々な記事が出ていたけれど、こちらのサイトの説明がわかりやすかった。その上で東京Node学園祭でのいくつかのセッション内容をふまえた初めの感想は、スレッドではなくイベント駆動&ロックをしないことによる並列処理が基本、そして並列処理能力が求められる(多数のユーザからの同時接続が想定される)Webアプリケーションを構築する際に有効な手段であるなーといったところ。
もちろん、他の使い方もあるし、出てきたばかりだからモジュールとかは安定していないけれど、汎用性が非常に高いのがNodeである。色んなところで大活躍、ここまでJavaScriptでかけるってすごいよね!という結論に落ち着いた。(同時に自分のJavaScriptスキルの低さに絶望した。)
で、落ち着いたはいいけれど、今までNodeを使ったことがないので、なにはともあれNodeを使って Webアプリケーションを作ってみたい!という気分になった。どうせなら有名どころのフレームワークも勉強したかったので東京Node学園祭で数回出てきたExpressというフレームワークを使ってみることにした。
- はじめに環境を用意しよう
nodeはあるか?→Yes
npmはあるか?→Yes
ということで、環境設定はほとんど必要なかった。後はExpress Guideを写経。expressはnpmからモジュールとしてインストールできるので、expressのインストール、プロジェクトの作成、npmによる各モジュールの依存関係の解消、サーバの起動。
$ npm install -g express $ express /tmp/foo && cd /tmp/foo $ npm install -d $ node app.js
これからExpressの構成とか、設定方法を見つつ、何かしらのアプリを作ろうと思う。ある程度なれたらSocketStreamも勉強してみたい。