Otaku In The World

Jenkins+Virtualenv

Jenkinsでビルドする時に、そのプロジェクトの依存モジュールをpipでインストールしたりしますが、その際できればプロジェクトごとにvirtualenvで環境を作りたかったりします。

調べてみたら、日本語の解説が全くなかったので、まあ書いておきますね。

まず、Jenkinsの設定画面(Manage Jenkins –> Configure System)からPATHの設定をします。

Global propertiesのEnvironment variablesをチェックして、nameには"PATH"、valueには".env/bin:$PATH"を入力して保存して下さい。

続いてジョブの設定です。下記のスクリプトをジョブの最初に実行して下さい。

#!/bin/bash
if ! [ -d '.env' ]; then
    virtualenv .env
fi
source .env/bin/activate

これでvirtualenvが適用されるようになったので、後は適当に"pip install"とかするといいです。

Jenkins+Git+ViewGit

Jenkinsはデフォルトで対応しているSCMがSVNとCVSしかありません。

そのため、他のSCMを使用するためにはプラグインを追加する必要があります。

今回はGitからソースをチェックアウトし、さらに変更点をViewGitで参照するための手順を掲載します。

Gitプラグインのインストール

まず、JenkinsにGitのプラグインをインストールします。

トップの Manage Jenkins –> Manage Plugins から、プラグイン画面へ行きます。

Available タブを選択し、 Jenkins GIT plugin をチェックします。

一番下の Install without restart か、 Download now and install after restart をクリックします。

以上でGitプラグインのインストールを完了です。

ジョブの設定画面のSCMの項目にGitが表示されるようになります。

ViewGitのインストール

ViewGitとは、Gitのツリー情報などをWebから見れるようにするフロントエンドツールです。

phpでできているので、phpが動くようになっている必要があります。

今回は、nginx+php-fpmでの動作を前提として解説します。

まず、Source Forgeから最新のソースをダウンロードします。

解凍したら、それをnginxから参照できる場所に配置しましょう。

nginxからphp-fpmの設定をします。

root {ViewGitのインストール先};
index index.php;
location ~*\.php$ {
    fastcgi_pass  unix:{php-fpmのソケットパス};
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

viewgit/inc/config.php でリポジトリの設定をします(この設定はlocalconfig.phpからでもできます)。

$conf['projects_glob'] = array('{リポジトリディレクトリのパス}/*.git');

最後に viewgit/inc/localconfig.php を作成して完了です(中身は空でもかまいません)。

以上で、nginx経由でViewGitが見れるようになったはずです。

Geshiのインストール

ただし、このままだとソースコードのシンタックスハイライトが効かないので、Geshiを入れてみましょう。

Source Forgeから最新のソースをダウンロードし、解凍します。

解凍してできたgeshiディレクトリをそのまま viewgit/inc/ 以下に移動します。

viewgit/inc/config.php の54行目付近を以下の様に書き変えます。

$conf['geshi'] = true;
$conf['geshi_path'] = 'inc/geshi/geshi.php';

これで、Geshiが有効になり、ViewGitでソースコードを見た時にハイライトされるようになったはずです。

JenkinsでViewGitの設定をする

最後に、Jenkinsの変更点をViewGitで見られるように、設定しましょう。

ジョブの設定画面から、 Repository browser で viewgit を選択します。

ViewGit root url には先程設定したURLを入力し、 Project Name in ViewGit にはリポジトリ名(ViewGitで参照した時に、urlのクエリでp=で表示されている部分)を入力します。

これで、ジョブの Changes に viewgit のリンクが表示されるようになりました。

UbuntuにJenkinsをインストールしてnginx経由でアクセスする

JenkinsというCI(継続的インテグレーション)ツールがあります。

昔はHudsonという名前だったので、こっちの名前の方が有名かもしれません。

で、このJenkinsをインストールした時の手順です。

インストール

インストールはaptで行いたいので、キーを追加します。

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -

続いて、 /etc/apt/sources.list に以下を追加します。

deb http://pkg.jenkins-ci.org/debian binary/

最後に、aptをアップデートしてインストールします。

sudo apt-get update
sudo apt-get install jenkins

8080で起動

インストールが完了したので、早速起動してみましょう。

sudo service jenkins start

これで、8080から接続できるようになりました。

nginx経由で80番からアクセスする

このままだと、8080からしか接続できないので、nginxを経由して80番ポートからアクセスできるようにしましょう。

nginxの設定ファイルに以下の様に記述します。

server {
    server_name [サーバー名];

    location / {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

これで、nginxを再起動すると、設定したサーバー名で8080にプロキシしてくれます。

8080でのアクセスを禁止する

ただ、これだと元の8080でのアクセスは残ったままなので、ちょっと微妙です。

Jenkinsのバインドを127.0.0.1に変更して、8080で外部からはアクセスできないようにしましょう。

Jenkinsの起動設定は /etc/default/jenkins にあります。

この中の最後の行、JENKINS_ARGSに以下を追加しましょう。

--httpListenAddress=127.0.0.1

これでJenkinsを再起動し、外部から8080でのアクセスができないことを確認して終了です。

Read the Docsでautodocする

Read the DocsはデフォルトのままだとSphinxのautodocを生成してくれません。

autodocを生成するためには、whitelistに自分のアカウントを登録する必要があります。

元のサービスの場合は、その旨をメールすればいいそうなのですが、自前でインストールした場合には以下の様にして自分自身をwhitelistに登録する必要があります。

  • まずは、"/admin"をキックしてDjangoの管理画面にアクセスします。
  • そして、ログインに成功したら、テーブルから Core –> User Profiles を選択します。
  • 最後に、自分のアカウントを選択し、"Whitelisted"をチェックすれば完了です。

以上で、Read the Docs上でもautodocできるようになります。

ただ、動作はあまり完璧ではなく、一部きちんと生成されないものもあるようです。

また、Sphinxでautodocするためにはconf.pyでextensionやpythonpathの設定を行なう必要があります。

Read the Docsを自前サーバーにインストールして使う

Read the Docsを自前サーバーにインストールすることができたので、手順を記載しますよ。

Read the Docsって何よ?

Sphinxのドキュメントをホスティングしてくれるサービスです。 本来はサインアップして使うものなんですが、社内のドキュメントとかをまとめようと思うと細かいアクセス制御とかが必要になるので、そのままだと使えません。

ただ、Read the Docs自体はDjangoのアプリなので、ソースからインストールして自前で使うことができます。

何ができんの?

リポジトリにコミットするだけでSphinxドキュメントを自動でビルドしてくれます。他にもいろいろあるんでしょうが、とりあえずメインはそんなとこだろうと思います。

どうやんの?

では、細かい手順の説明に移ります。

まずはgithubからソースを手に入れましょう。

git clone http://github.com/rtfd/readthedocs.org.git

続いて必要なモジュールをpypiからインストールします。

pip install -r readthedocs.org/pip_requirements.txt

続いてアプリケーションの初期化をしましょう。

readthedocs.org/readthedocs/manage.py syncdb

migrateしろと言われるので、migrateします。

readthedocs.org/readthedocs/manage.py migrate

この時点ですでにDjangoのmanage.pyを使用して起動することができるので、まずは一度起動してみましょう。

readthedocs.org/readthedocs/manage.py runserver [ホスト]:[ポート]

接続して画面がでればとりあえずOKです。

しかし、このままだと80番から接続できないので、fcgiで起動して、nginx経由で接続するようにします。

まずは、fcgiを起動します。

readthedocs.org/readthedocs/manage.py runfcgi [ソケットもしくはホスト]

この時、flupが必要になるので、持ってない場合はインストールして下さい。

pip install flup

最後に、nginxの設定をして、画面が表示できれば完了です。

location / {
    fastcgi_pass [ソケットもしくはホスト];
    include fastcgi_params_django;
}

location /media/admin {
    alias [Djangoのパス]/contrib/admin/media;
}

fastcgi_params_djangoは下記の様に設定して下さい。

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# Django
fastcgi_param  PATH_INFO          $fastcgi_script_name;
fastcgi_pass_header               Authorization;
fastcgi_intercept_errors          off;

nginxのデフォルトサーバー設定

nginxのデフォルトサーバーの設定がわからずハマったのでメモ。

nginxの設定をする時に、例えば以下のような3つのserverを設定したとします。

server {
    server_name hoge.com;
    ....
}

server {
    server_name fuga.com;
    ....
}

server {
    server_name foo.com;
    ....
}

そしてこの状態で、上記のどれにもあてはまらないbar.comとかでリクエストを送った場合、nginxは最初に設定されたhoge.comをデフォルトとして適用します。

ですので、デフォルトとして設定したい場合は最初に書くといいでしょう。

しかし、site-availables/*のような設定をしたりなど、明示的にデフォルトとして指定したい場合もあるでしょう。

そういう時はlistenパラメータにポート番号に続けてdefault_serverと記述するとそれをデフォルトとして扱ってくれます。

具体的には以下のように設定します。

server {
    server_name bar.com;
    listen 80 default_server;
    ....
}

詳しいことはこちらを参照して下さい。

Rubyでbundler使ってみた

Ruby の bundler とかいうのを導入した時の記録です。

やりたかったこと

  • Ruby でアプリ作る時に必要な gems を全部一撃でインストールしたい。
  • かつシステム共通の gems を汚したくない。
  • っていうか node の package.json と npm install みたいなことをしたい。

というわけでまず gem から bundler をインストールしましょう。

gem install bundler

次に、プロジェクトディレクトリに Gemfile を作成します。

source 'http://rubygems.org'
gem "nokogiri" #インストールしたいgemを記述
gem "rails", "3.0.0.beta3" #バージョンの指定もできる
gem "rack",  ">=1.0" #こういう書き方も可能
gem "thin",  "~>1.1" #>=1.1 + <2.0

source は gem の取得先です。上記の様に gem のバージョンを細かく指定することもできます。5行目の ~> という書き方だけはちょっと特殊で、この場合だと 1.1 <= バージョン < 2.0 という指定になります。詳しくはドキュメントを参照して下さい。

で、 .bundle/config を以下の用に記述します。

--- 
BUNDLE_DISABLE_SHARED_GEMS: "1"
BUNDLE_PATH: bundle

3行目の BUNDLE_PATH はプロジェクトディレクトリ内の gems のインストール先なので、自由に設定して下さい。

では、実際に bundler から gem のインストールをしましょう。

bundle install

これで bundle ディレクトリ以下に gems がインストールされます。

最後に bundler 経由で gems を読み込むために、エントリーポイントの .rb ファイルに以下のような記述をして終了です。

require "rubygems"
require "bundler/setup"
# ここから下に使用するgemsを書いていく
require "nokogiri"
...

.gitignore や .hgignore に bundle ディレクトリを含めないように書いておけば、ライブラリをコミットしなくて済みますし、clone した時は bundler install 一発で環境構築できます。

Posterousに移行してみた

BloggerからPosterousに移行したので、つらつらと練習がてら理由などを書いてみます。

まあ、主な理由は3つあって、

  1. markdown記法が使える
  2. 独自ドメインが使える
  3. 無料で使える

みたいな感じです。

細かいこと言うともっと色々ありますが、大きな理由としてはこの3つかな。

Bloggerは2と3はあてはまるけど、markdownが使えない。

はてなは1と3があてはまるけど、独自ドメインが使えない。

プロにすると独自ドメイン使えるけど、そうすると有料になる。

というわけで、Posterousにしました。

これでmarkdownでゴリゴリ書けます。

markdownかわいいよmarkdown。