2014年8月27日水曜日

JenkinsでFULL head 413を返すとき

Jenkinsを利用中にログインが出来なくなって確認したところレスポンスが
FULL head 413を返していました。

FULL head 413はどうやらリクエストの内容が大きいとのこと。

413 Request Entity Too Large
リクエストエンティティが大きすぎる。リクエストエンティティが
サーバの許容範囲を超えている場合に返す。

ふとCookieを見てみると名前が「JSESSIONID」から始まるCookieが大量に存在していました。
Cookieが怪しいと思い、削除すると問題なくJenkinsを利用できるようになりました。

少し前にプラグインを新規インストールしたりしていたので、プラグインが原因かなと悩みました。
他のブラウザでは利用できていたので、今回はCookieが原因だったのかも知れません。

何か問題が起きたときはまず、次の項目を試そうと思います
  • 別のブラウザで操作する
  • 同じブラウザで履歴やCookieが残らないシークレット ウィンドウ(Chromeの場合)で操作する
同じ症状が出ないときは問題が起きたブラウザのデータが原因かも知れないです。
413は初めて見たので、最初は何事!?と軽くパニックになりました。

同様の内容が Jenkins の issue に報告されていました。

2014年8月25日月曜日

JenkinsのプラグインをCLIでインストールするときにハマった

VagrantでJenkinsを構築するときにプラグインをCLI(コマンドライン)でインストールしたときに
ハマったので残しておこう。

Jenkins起動直後ではJenkinsにアクセスできない

Jenkins起動直後だとJenkinsをCLIで操作するためのjenkins-cli.jarファイルが
ダウンロードできませんでした。
service jenkins startした後はsleep 30とかで待機時間を設けることで対応できました。

Jenkinsのインストールから起動+プラグインのインストールまで実行を一度に実行するときにはプラグインのリストを手動で更新する必要がある

プラグインのアップデートサイトのリスト(ファイル)がJenkinsのインストール直後は存在しないようで
その状態でプラグインのインストールを実行するとプラグインのインストールが失敗します。
次のコマンドで手動でプラグインのリストを更新できました
curl -L http://updates.jenkins-ci.org/update-center.json | sed '1d;$d' | curl -X POST -H 'Accept: application/json' -d @- http://localhost:8080/updateCenter/byId/default/postBack

java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin [プラグイン名]で指定するほうが良さそう

// 次の方法でプラグインのインストールは成功
java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin git

// 次の方法ではプラグインのインストールが失敗
// レスポンスの内容を見るとプラグインが存在するサイトが移動したことを示すドキュメントが返ってきたのでURLでの指定は行わないほうが無難
java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin https://updates.jenkins-ci.org/latest/git.hpi

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://mirrors.jenkins-ci.org/plugins/git/2.2.5/git.hpi">here</a>.</p>
<hr>
<address>Apache/2.2.14 (Ubuntu) Server at updates.jenkins-ci.org Port 443</address>
</body></html>

2014年8月15日金曜日

WindowsのVirtualBoxの仮想マシン保存フォルダの場所を変更する

VirtualBoxの仮想マシンを保存するフォルダ(VirtualBox VMs)を別の場所に変更する方法
作成済みの仮想マシンは一度、一時停止か停止をしといたほうが良いです。

  1. 変更先のフォルダを作成
    変更先フォルダ D:\VirtualBox VMs
  2. 変更前のフォルダ内のファイルやフォルダを変更先のフォルダ内にコピー
  3. VirtualBoxを起動してメニュー[ファイル]の環境設定を選択
  4. 一般にある[デフォルトの仮想マシンフォルダー]で選択ボックスから[その他]を選択
  5. 変更先のフォルダを選択して[OK]
今後、作成する仮想マシンは変更先のフォルダに作成されます。
作成済みの仮想マシンはVirtualBoxの仮想マシン一覧から右クリックで[除去]を選択し[除去のみ]を選択
メニュー[仮想マシン]の[追加]から変更先フォルダに移動した仮想マシン(ファイルの拡張子は.vbox)を
選択します。
起動してみて起動が出来たら場所の変更は無事に出来たと思います。
変更前のフォルダを削除して終了です。

環境
VirtualBox 4.3.12

.vagrant.dフォルダの場所を変更する

Windowsでインストーラからインストールするとユーザフォルダ直下に
.vagrant.dフォルダが作成されます。
このフォルダにvagrant box addで追加したボックスが保存されますが、ボックスも
容量があるので別のドライブに移動する方法を実践してみました。

  1. 変更先の場所にフォルダを作成する
    変更先のフォルダはD:\Vagrant\.vagrant.d
  2. 変更先のフォルダ内に現在の.vagrant.dフォルダ内のファイルやフォルダをコピーする
  3. フォルダの場所を変更するには環境変数にVAGRANT_HOMEを追加する
    (特にシステム全体で参照する必要も無かったので、ユーザー環境変数として追加しました)
    変数名
    VAGRANT_HOME
    変数値
    D:\Vagrant\.vagrant.d
  4. 念のため、再起動
  5. vagrant box removeとかで変更先のフォルダの状態が変更されて、変更前のフォルダの状態が
    何も変更されていなければフォルダの場所の変更は無事終わったと思います
無事終わったら場所変更前のフォルダを削除して終了。

環境
Vagrant 1.6.3
VirtualBox 4.3.12

2014年8月14日木曜日

VagrantでAnsibleのPalybookを書くときに役に立つプラグイン

AnsibleのPlaybookを作成するとき「あーでもない、こーでもない」、「あー間違った!
はい!やり直しorz」と何度も思いながら作成していましたが、こんな思いを軽減してくれる
Vagrantのプラグインがありました。

今まではやり直しとなったときはvagrant destroy→vagrant upしてました。
provisionのときにインストールするパッケージが多いとダウンロードだけでも結構な時間が必要でした。

vagrant-vbox-snapshot

Vagrantの仮想マシンのスナップショットをとるプラグイン
provisionを実行した直後の状態を残しといてゴニョゴニョした後、丸ごとやり直したいとき
provisionで必要なパッケージを仮想マシンにインストールする時間とダウンロード時間を節約する
// プラグインインストールコマンド
vagrant plugin install vagrant-vbox-snapshot

# スナップショットの取得、SNAPSHOT_NAMEはスナップショットの一覧に表示する名前
#  [vm-name]はVagrantfileで仮想マシンに名前を設定しているときに必要
vagrant snapshot take [vm-name] [SNAPSHOT_NAME]
# スナップショットの一覧表示
vagrant snapshot list [vm-name]
# 直前のスナップショットの復元
vagrant snapshot back [vm-name]
# 任意のスナップショットを削除
vagrant snapshot delete [vm-name] [SNAPSHOT_NAME]
# 任意のスナップショットの復元
vagrant snapshot go [vm-name] [SNAPSHOT_NAME]

sahara

仮想マシンでサンドボックスモードを有効にするプラグイン
新しいバージョンでは利用できない情報とかあったので不安でしたが、実際はインストールできて利用できています。

インストールするデータベースの設定方法が間違ったとき、戻したいけどprovision直後までは
戻したくないとか、少し前の状態に戻したいときに有用です。
サンドボックスモードを有効後、仮想マシンにゴニョゴニョしてからコミットして確定すれば
その後加えた変更が間違ったときはロールバックすることでコミットしたタイミングに戻れます。
// プラグインインストールコマンド
vagrant plugin install sahara

# サンドボックスモードを有効
vagrant sandbox on [vm-name]
# 現在の仮想マシンの状態をコミットする
vagrant sandbox commit [vm-name]
# コミットした状態に戻る
vagrant sandbox rollback [vm-name]
# サンドボックスモードを無効
# コミットしていなければ変更した状態は無かったことになる
vagrant sandbox off [vm-name]
環境
Vagrant 1.6.3
VirtualBox 4.3.12

2014年8月10日日曜日

AnsibleでCentOS5をセットアップする(準備)

デプロイツール、オーケストレーションツールとして分類されるAnsibleを利用して
仕事でも利用しているCentOS5のサーバをセットアップしたいと思います。

Ansibleの呼び方が最初「あんしぶる」と思っていたのですが「あんしぼぉ」のようです。
恥ずかしい。

必要なもの

ローカル
CentOS6のepelリポジトリを利用してインストールする方法が手っ取り早かったので
vagrantも利用してCentOS6を用意しました。
Windows上で扱うのは出来るかどうかわからなかったので、仮想マシンを用意しました。
// epel repository追加
rpm -ivh http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
// Ansibleインストール
yum -y install ansible
サーバ
AnsibleはPythonが必要なのですが、基本的には標準でインストールされています。
インストールされているバージョンが2.5以上なら問題ないようですが、CentOS5の場合は
2.4のためpython-simplejsonが必要です。
Ansibleでの実行結果がJSON形式で返ってきますが、2.4ではJSONを扱う?
パッケージが無いようなのでインストールする必要があります。

Ansibleでサーバをセットアップする前に

SSHでサーバにアクセスできる必要があります。
Ansibleで対象のサーバを操作する場合はインベントリファイル(inventory-file)と呼ばれる
ファイルに設定した内容しか操作対象にされません。
// インベントリファイルは実行時に指定することが出来るのでファイルを作成します
echo [サーバのIPアドレス] > hosts
// Python2.4がインストールされている場合はpython-simplejsonをインストール
// rawモジュールでpython-simplejsonをインストール
// -i:インベントリファイルの指定
// -k:このオプションを指定するとSSH接続するときのパスワードを求められます
// (サーバ側でパスワードなしのSSH接続の設定を行っていない場合このオプションをつけないとサーバへの認証が失敗するので、今回はこのオプションを付けました)
// -u:サーバ接続時のユーザの指定
// -m:実行するAnsibleのモジュールの指定
// -a:モジュールの引数の指定
// (""で括らないと失敗してしまいました)
ansible -i hosts [サーバのIPアドレス] -k -u [サーバのユーザ名] -m raw -a "yum -y install python-simplejson"
疲れてしまいましたので今回はこのあたりで。

2014年7月16日水曜日

Vagrantで利用するコマンド-仮想環境 起動とか停止とか

Vagrantで利用するコマンド

vagrant -h
ヘルプを表示
vagrantで実行できるコマンドの一覧を表示する

vagrant [コマンド] -h
vagrant [コマンド]のオプションや引数のヘルプを表示する

vagrant init
仮想環境をセットアップする
Vagrantで起動するために必要なVagrantfileが生成される

vagrant up
Vagrantfileで指定したBoxから仮想環境を起動する

vagrant suspend
起動中の仮想環境を一時停止する
仮想環境の復帰時間は少ない

vagrant halt
起動中の仮想環境を終了する
仮想環境の電源を落とすので復帰時間はvagrant suspendよりかかる

vagrant destroy
作成した仮想環境を破棄する
仮想環境にあるデータはすべて消去される
オプションをつけなければ事前に破棄するか確認メッセージが表示される
一からやり直したいときにはvagrant destroyしてvagrant upする