Atlassian Stashの耐障害性を高めよう その2 HAセットアップ編

今回は 前回 「Atlassian Stashの耐障害性を高めよう その1 プランニング編」 の続きとして、
HAクラスタのセットアップを行いたいと思います。

手順はredhat向けのHIGH AVAILABILITY ADD-ON リファレンス を参考に行っていきます

今回の構成

今回は、LinuxのHAクラスタミドルウェアの定番であるPacemakerを使用してクラスタを構成します。

ソフトウェア バージョン
CentOS 7.1
Pacemaker 1.1.12
Corosync 2.3.4
pcs 0.9.137

ノード設定
|ホスト名|IP|備考|
|—|—|—|
|node01|192,168.33.21|Stash node #1|
|node02|192,168.33.22|Stash node #2|
|stash|192,168.33.101|Stash VIP|

事前準備

クラスタ構成の際にお互いのノード名を解決出来ないとイケないので、 /etc/hosts にホストを追加しておきます。

/etc/hosts

1
2
192.168.33.21 node01
192.168.33.22 node02

次にクラスタの通信に使用するポートを開放します

1
2
firewall-cmd --permanent --add-service=high-availability
firewall-cmd --add-service=high-availability

ソフトウェアのインストール

それでは、必要なソフトウェアをインストールしていきます。

1
# yum install pcs fence-agents-all

コマンドを両方のノードで実行します。
これだけでHAクラスタに必要なソフト一式がインストールされます。

インストールが無事完了したら、クラスタの構成を行うコマンドのデーモンである pcsd を起動します。


また、再起動時に自動的に起動するように設定します。

1
2
systemctl start pcsd
systemctl enable pcsd

クラスタの構築

次に、node01,node02をメンバーとして、HAクラスタを構築します。

hacluster ユーザーのパスワードを設定

ここでは、マニュアルの推奨に従って、両ノードともに同じパスワードを設定します。

1
passwd hacluster

これも両ノードで実行します。

クラスタノードの認証

クラスタノード間の認証設定をします。

1
pcs cluster auth node01 node02 -u hacluster -p hacluster

クラスタの作成

クラスタを作成します

1
pcs cluster setup --start --name stash node01 node02

クラスタ状態の確認

作成したクラスタの状況を確認します。

1
pcs cluster status

1
2
3
4
5
6
7
8
9
10
Cluster Status:
Last updated: Mon Sep 14 09:46:54 2015 Last change: Mon Sep 14 09:42:40 2015 by hacluster via crmd on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 0 resources configured
Online: [ node01 node02 ]
PCSD Status:
node01: Online
node02: Online

両ノードがOnlineとなっていればOKです。

STONITH の無効化

ここで、/var/log/messages を確認すると。

1
2
3
4
5
6
Sep 14 11:16:14 localhost pengine[4158]: error: Resource start-up disabled since no STONITH resources
have been defined
Sep 14 11:16:14 localhost pengine[4158]: error: Either configure some or disable STONITH with the ston
ith-enabled option
Sep 14 11:16:14 localhost pengine[4158]: error: NOTE: Clusters with shared data need STONITH to ensure
data integrity

といったエラーが発生しています。

このページによると

STONITHと呼ばれるノードが不安定になった場合、自動的に再起動を行う機能を実現するためのリソースが無いためエラーとなってしまっているようです。

現時点ではSTONITHを使用しないため、

1
pcs property set stonith-enabled=false

を実行し、機能を無効化します。

リソースの作成

クラスタの設定が終わったところで、次にリソースを設定します。
クラスタでのリソースとは特にクラスタノード間で共有するリソースのことを指します。例えばアクティブノードが使用する仮想IPなどです。

今回は、ユーザーがアクセスする際に指定する、サービス用の仮想IPをリソースとして追加します。

どちらかのノードでコマンドを実行します。

1
pcs resource create stash_vip IPaddr2 ip=192.168.33.101 cidr_netmask=24 op monitor interval=6s

これで、6秒ごとに死活確認を行うIPアドレスの共有リソースが設定されました。
アクティブノードに 192.168.33.101 のIPエイリアスが設定される様になります。

ノード切り替えのテスト

サービス用の仮想IPが割り当てられることが確認出来ました。

アクティブノードの障害

アクティブノードの障害時に正常に切り替わるか確認してみましょう。

Active : node01
Standby: node02

の状態で、node01の電源をOFFしてみます。

実施前

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:14:31 2015 Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured
Online: [ node01 node02 ]
Full list of resources:
stash_vip (ocf::heartbeat:IPaddr2): Started node01
PCSD Status:
node01: Online
node02: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled

2ノードともオンラインで、stash_vip は node01に割り当てられています。

ここで node01 の電源をOFFにします

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:18:31 2015 Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured
Online: [ node02 ]
OFFLINE: [ node01 ]
Full list of resources:
stash_vip (ocf::heartbeat:IPaddr2): Started node02
PCSD Status:
node01: Offline
node02: Online
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

正常に node02 にIPが切り替わりました。
この間pingを192.168.33.101宛に行っていましたが、途切れる事なくノードが切り替わりました。

スタンバイノードの追加

では、次に稼働中のクラスタに、node01を追加します。

node01を起動し、node01でクラスタを起動します。

1
pcs cluster start

正常に node01がクラスタに参加しました、ただアクティブノードはnode02のままです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:24:38 2015 Last change: Mon Sep 14 11:51:35 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured
Online: [ node01 node02 ]
Full list of resources:
stash_vip (ocf::heartbeat:IPaddr2): Started node02
PCSD Status:
node01: Online
node02: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled

アクティブノードの手動切替

最後に、アクティブノードを切り替えます。
片系ずつ切り替えながらメンテナンスする際に威力を発揮しそうです。

アクティブノードをスタンバイ状態にし、強制的にきりかえます。
アクティブノード上で下記のコマンドを実行します。

1
pcs cluster standby

正常にノードが切り替わり、node01がアクティブになりました。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:44:33 2015 Last change: Mon Sep 14 12:44:24 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured
Node node02: standby
Online: [ node01 ]
Full list of resources:
stash_vip (ocf::heartbeat:IPaddr2): Started node01
PCSD Status:
node01: Online
node02: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled

ただ、このままですと node01に障害が発生した場合でもnode02に切り替わらないので、node02のスタンバイ状態を解除します。
スタンバイ状態のノードで以下のコマンドを実行します。

1
pcs cluster unstandby

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
pcs status
Cluster name: stash
Last updated: Mon Sep 14 12:46:29 2015 Last change: Mon Sep 14 12:46:27 2015 by root via crm_attribute on node02
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 1 resource configured
Online: [ node01 node02 ]
Full list of resources:
stash_vip (ocf::heartbeat:IPaddr2): Started node01
PCSD Status:
node01: Online
node02: Online
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled

node02がアクティブになりました。

今回はここまで

これでひと通りのクラスタ切り替えの動作の確認が出来ました。
しかしながら、IPの切り替えだけではStashの冗長化は出来ません。
次回は、ストレージの冗長化を設定しStashの冗長化を完成させたいと思います。

参考資料:
RED HAT ENTERPRISE LINUX 7 向け HIGH AVAILABILITY ADD-ON のリファレンスドキュメント
リファレンスなので、ひと通り情報は乗っているが、ステップバイステップで構築の手順となっていなく、コマンド例ももう一声ほしいところ。
総じて、読み解くのに読者の頑張りが必要なドキュメント。。。

CentOS7.1でPacemaker+corosyncによるクラスタを構成する(Part.1)
CentOS7 + Pacemaker でのクラスタ構築からVIP設定までが非常に丁寧にステップバイステップで解説されています。
最終的には、このエントリもほぼ似たような感じになってしまいました。

Atlassian Stashの耐障害性を高めよう その1 プランニング編

はじめに

私の所属しているプロジェクトではAtlassian Stash (Git)でソースコードを管理しています。

普段何気なく使用しているGitですが、もはや手放すことが難しい存在です。

そんな中、ふと「もしもStashのデータが消失したら。」と言う事態を想像してみました。

Gitは分散バージョン管理なので、各々のローカルのGitリポジトリをかき集めれば必要なものは復旧できそうです。

どうやらソースコードの消失などの最悪の事態は発生しないことはわかりましたが、

Stashを使用していればサーバーの冗長構成は必要ないでしょうか。

Atlassianのドキュメントによると、Stashに障害が発生した場合、復旧作業をおこなっている間、下記の様な状況になります。

  • できること

    • 開発者
      • コードのコミット
      • ブランチの作成
      • ブランチの切り替え
      • 過去のコミットと差分確認
      • Stashを経由せずに他の開発者のリポジトリからフェッチする
  • できないこと

    • 開発者
      • リポジトリのクローン
      • セントラルリポジトリ(Stash)からのフェッチ
      • セントラルリポジトリ(Stash)へのプッシュ
      • Stash UI へのアクセス (プルリクエストの操作など)
    • CI/CDサーバー
      • リポジトリのクローン
      • 変更点の取得

作業は続行不可能では無いですが、チーム開発を進めていく上でかなりの制限となってしまいそうです。

というわけで、転ばぬ先の杖ということでStashの冗長化に挑戦してみたいと思います。

Stash冗長化について調べてみたところ、本家Atlassianに冗長化についてのドキュメントが用意されていました。

冗長構成のパターン

Atlassianのドキュメントによると、冗長構成には以下の様なパターンがあるようです

構成 復旧時間
Single node hours-days 単一ノード
Cold Standby 2-10 min サーバーはActive StandByともに起動させておくが、StashはActive側のみ起動しておく構成。Active側が障害となった場合StandBy側のStashを起動させ、切り替える。
Warm Standby 0-30 Sec Active Standby 双方にStashを起動させておき、Active側が障害となった場合切り替える
Active-Active <5 Sec マルチマスタ&負荷分散構成 ただし Stash Data Center が必要

この構成の内、Active-Active構成をするためには Stash Data Centerを使う必要があるらしく、
予算的に厳しい様な予感がするので今回は見送ることとします。

また、Warm StandBy 構成 はStashがメモリ上にロック情報などを持っているため、現時点でこの構成は取れないそうです。

そうすると、コストとメリットのバランスを考えた場合Cold Standby構成を取るのが良いようです。

(Atlassianのドキュメントもこの構成でクラスタを組んでいます。)

図で表すと、下記の様になります。おおむねAtlassianのドキュメント通りですが、データベースのみ、他のAtlassianプロダクトと共有することを考えて、Stashとは別のサーバーとしています。

atlassian_stash_cluster_network_diagram

細かいソフトウェアのバージョンなどはもう少し調べてみてから決定していきたいと思います。

というわけで、だいたいの構成の目処がついたところで、今回はここまでとしたいと思います。

次回は実際のクラスターの構築を行ってみたいと思います。

Atlassian製品のアドバンテージ「Application Link」

Application Linkとは

アプリケーションリンクとは、Atlassian製品にデフォルトで含まれている、Jira, Confluence, Stash, FishEye, Crucible, Bambooの各製品を相互に連携させるための機能です。
アプリケーションリンクを設定すると、リンクさせた製品同士が相互に情報をやりとりしたり、お互いの機能を利用することが出来ます。
例えば、JiraとConfluenceをリンクさせた場合、JiraのチケットをConfluenceのマクロを利用してリンクさせたり、
Confluenceで任意の文字列を選択した状態で右クリックからJiraのチケットを作成するなど、お互いの利便性を向上させることが出来る機能です。

Atlassian以外の製品でも、CIツールと、リポジトリ管理ツールの連携や、課題管理ツールとCIツールの連携などが用意されている場合もありますが、
違うプロダクトを連携させる場合とくらべてAtlassianのアプリケーションリンクはより密接な連携ができるというメリットがあります。
また、設定も簡単にできるため、「サクッと連携できると思っていたけのに意外とハマった。」ということが起こらない点もメリットといえると思います。

Bamboo + Stash をリンクすると

では、具体的にはどうなるのでしょうか。
Bambooの公式ドキュメント によると、
リンクをすることにより以下のことができるようになります。

  1. Stashのリポジトリに新しいコードがpushされると自動的にビルドを実行させることが出来ます。(Stash以外のリポジトリの場合はBambooが定期的に更新を確認する必要があります)
  2. Stashの指定したリポジトリに新しいブランチが作成された場合、Bambooが自動的にそれを検知し、ブランチのビルドプランを作成します。
    また、ブランチが削除された場合はBamboo上のブランチに対するビルドプランを自動的に削除することも可能です。
  3. Bambooのビルド結果から、そのビルドに含まれているコミットの変更差分確認画面へダイレクトにジャンプ出来ます。
  4. Bambooのビルドに含まれているStashのコミットのリストをBambooのビルド結果から確認出来ます。
  5. コミットやプルリクエストに対するビルド結果をStash側で確認することが出来ます。

ブランチの自動作成

アプリケーションリンクの機能は業務でも使用していますが、今回はその中でも便利だと感じているブランチの自動作成機能を紹介します。

  • Bambooのビルドプラン設定からブランチの自動作成設定が出来ます、すべてのブランチを作成することもできますし、正規表現にマッチするブランチだけを自動作成することも出来ます。
    GitFlowで開発している場合に、featureブランチのみ自動作成するという設定も可能です。

20150904_0936_myproject_-_myplan__Edit_plan_configuration_-_Atlassian_Bamboo_01

  • Stashで(もしくはGitコマンド経由で)ブランチを作成すると。

20150904_0939_ブランチの作成_-_Stash_01

  • Bambooが自動的にブランチをビルドプランに追加してくれます。

20150904_0948_myproject_-_myplan__Edit_plan_configuration_-_Atlassian_Bamboo_01

ビルド対象のリポジトリが少ないうちは、Bambooの管理画面から手動でブランチを追加する作業も苦になりませんが、
リポジトリが増えてくるに連れて徐々に便利さが実感できるようになってきます。

その他の製品のApplication Linkについて

さて、こんなに便利なApplicationLinkですが、今回例に上げたBambooとStashの組み合わせ以外にも様々な組み合わせが存在します。
ApplicationLinkを設定することでどんなメリットがあるかは下記リンク先のドキュメントをご参照ください。

Stash
https://confluence.atlassian.com/stash/integrating-stash-with-atlassian-applications-414812190.html

Jira+Confluence
https://confluence.atlassian.com/doc/use-jira-and-confluence-together-427623543.html

Bamboo+Confluence
https://confluence.atlassian.com/bamboo/integrating-bamboo-with-confluence-289276944.html

RedmineなどのAtlassian製品以外のツールでも、CIサーバーや、リポジトリ管理ツールなどとの連携は可能ですが、
簡単で設定でハマりにくいという点でAtlassian製品ツールが完結させられるというメリットは大きいです。

もし、Atlassian製品をお使いなら、非常に便利ですので、是非アプリケーションリンクを活用してみてください。

Atlassian Bamboo + Crowd 後編:Crowdとの連携

BambooとCrowdの連携

今回は前回の続きとして、BambooとCrowdを連携させて、
ユーザーをCrowdで一元管理できるようにしたいと思います。

前回同様、基本的には公式の手順 に沿ってすすめていきます。

全体的な流れは

  1. Crowdにユーザーとグループ、Bambooとの連携設定を行う
  2. Bamboo側でCrowdへの接続設定を行う
  3. Bambooのユーザー認証をCrowdに切り替える

です。

Crowd設定

まずはCrowd側にBamboo用のユーザーの作成と、連携のための設定を行います。

Crowdに以下のユーザーを作成してBambooと連携します。

ID Group Bambooのロール
bamboo bamboo-admin 管理者
bamboo-user bamboo-user 一般ユーザー

ユーザーの追加

Bamboo用にユーザーを追加します。

  • Top画面から「Users」タブをクリック

0810_1111_Atlassian_Crowd_-_Administration_console

  • 「Add User」リンクをクリックし、ユーザー登録画面にて必要な情報を入力し「Create」ボタンをクリック

0810_1118_Atlassian_Crowd_-_Users

  • 同様に一般ユーザーも追加します

0810_1511_Atlassian_Crowd_-_Add_user

グループの作成

Bambooでユーザーのロール制御を行うため、ロールに対応したグループを作成します。

  • 「Groups」をクリック

0810_1512_Atlassian_Crowd_-_Groups

  • 「Add Group」リンクをクリックし、グループ登録画面にて必要な情報を入力し「Create」ボタンをクリック

0810_1513_Atlassian_Crowd_-_Add_group

  • 同様に一般ユーザー用グループも作成します

0810_1514_Atlassian_Crowd_-_Add_group

グループへユーザーを登録

作成したグループへユーザーを登録します。
管理者にしたいユーザーは bamboo-admin グループへ。
一般ユーザーにしたいユーザーは bamboo-user グループへ登録します。

  • 「Groups」をクリック、「bamboo-admin」リンクをクリック

0810_1943_Atlassian_Crowd_-_Groups

  • 「Direct members」タブをクリックし「Add Users」ボタンをクリック

0810_1944_Atlassian_Crowd_-_View_group

  • 「Search」ボタンをクリックすると、ユーザーが表示されるので、管理者にしたいユーザーにチェックをし、「Add Selected Users」ボタンをクリック

0810_1945_Atlassian_Crowd_-_View_group

  • 同様に一般ユーザーも一般ユーザー用のグループへ登録します

0810_1949_Atlassian_Crowd_-_View_group

アプリケーションの作成

Crowdで作成したユーザーとBambooを関連付けるため、アプリケーションを登録します。

  • 「Application」-> Add application」をクリック

0810_1659_Atlassian_Crowd_-_Applications

  • 必要な情報を入力し「Next」をクリック
項目 設定値
Apprication type Bamboo
Name Bamboo
Password 任意のパスワード

ここで設定するパスワードはBambooとCrowdが連携する際の認証に使用します

  • BambooとCrowdの通信設定を入力し「Next」をクリック
    URLにユーザーがアクセスするURLを、Remote IP AddressにBambooサーバーとCrowdサーバーが通信する際のBambooサーバーのIPアドレスを設定します。

0810_1702_Atlassian_Crowd_-_Add_application

  • ユーザーディレクトリの選択
    Bambooの認証で使用するユーザーが存在する、ユーザーディレクトリを選択します。
    今回では、先ほどの手順でユーザーを作成した際に指定したディレクトリを選択します。

0810_1703_Atlassian_Crowd_-_Add_application

  • グループの選択
    Bambooで認証に使用するグループを追加します。

0810_1708_Atlassian_Crowd_-_Add_application

  • 登録内容の確認
    登録内容を確認し登録します。

0810_1709_Atlassian_Crowd_-_Add_application

Bamboo の設定

Crowdとの通信設定

  • crowd.properties の編集
    {BAMBOO_ROOT:/opt/atlassian/bamboo}/atlassian-bamboo/WEB-INF/classes/crowd.properties を編集します。

マニュアルには以下の4点を変更せよと書いてありますが、session.validationintervalはデフォルトの2分で問題ないためそのままにします。

項目 内容
application.name bamboo
application.password {CrowdのApplication設定で設定したパスワード}
crowd.server.url http://127.0.0.1:8095/crowd/services/
session.validationinterval 2
  • Bambooの認証システムのCrowdへの切り替え
    • atlassian-user.xml の編集
      {BAMBOO_ROOT:/opt/atlassian/bamboo}/atlassian-bamboo/WEB-INF/classes/atlassian-user.xml を編集します。

Crowd用の設定がコメントアウトされているので、コメントを外します。

1
2
3
<!--<crowd key="crowd" name="Crowd Repository"/>-->
<crowd key="crowd" name="Crowd Repository"/>

ユーザーディレクトリの設定

  • Bambooに管理者でログインし 「右上の歯車マーク > Overview」をクリック
  • 「Bamboo administration」画面が表示されるので 「Security」グループの「User repositories」をクリック

  • Server URL, Application Nameを確認、 Application PasswordにCrowdに設定したパスワードを入力します。

0810_1934_User_repositories_-_Atlassian_Bamboo

これでめでたくBambooの認証をCrowdに統合することが出来ました。

連携しているサービスがBambooだけですとそれほどメリットが感じられないかも知れませんが、 ここで上げたBamboo以外、Jira、Confluence、StashなどのAtlassianの製品を導入していくにつれてユーザー管理コストの軽減効果が実感できるものと考えております。

また、ユーザーの追加・削除漏れなどのセキュリティリスクの軽減にもつながりますので、Atlassian製品導入の際には合わせてCrowdの導入もご検討ください。

Atlassian Bamboo + Crowd 前編:Bambooの導入

Bambooとは

Atlassian社製のCI(継続的インテグレーション)/CD(継続的デリバリー)を実現するソフトウェアであり、同様のソフトウェアにはJenkinsやCircleCI、TravisCIなどが存在します。

今回は、そんなBambooをセットアップし、ユーザー管理を以前紹介したCrowdに統合する方法をご紹介したいと思います。

これにより、システム管理者、運用者の負荷を軽減してくれるBamboo。それ自体の管理負荷を下げて、より生産的で楽しいことに注力できるようにしたいと思います。

今回は、前編として、Bambooのインストール方法をご紹介させて頂きます。

Bamboo の インストール

基本的には公式手順にのとって進めていきます。

前提条件

システム環境

  • OS : CentOS 7.0
  • Java : Oracle JDK 8u51
  • DB : 5.5.40-MariaDB

Bamboo配置先

  • インストール先 : /opt/atlassian/bamboo
  • データディレクトリ : /var/atlassian/application-data/bamboo

インストール

最新版のダウンロード

  • 公式サイトより最新版をダウンロードします。
1
wget https://www.atlassian.com/software/bamboo/downloads/binary/atlassian-bamboo-5.9.3.tar.gz

展開と配置

ダウンロードしたBambooのアーカイブを展開し、配置します。

1
2
3
tar xf atlassian-bamboo-5.9.3.tar.gz
mv atlassian-bamboo-5.9.3 /opt/atlassian/
ln -s /opt/atlassian/atlassian-bamboo-5.9.3 /opt/atlassian/bamboo

bambooの初期設定

  • Bambooデータパスの設定

マニュアルに記載のある通り
/opt/atlassian/bamboo/atlassian-bamboo/WEB-INF/classes/bamboo-init.properties
を以下の様に修正します。

1
bamboo.home=/var/atlassian/application-data/bamboo
  • Bambooメモリ設定の変更
    /opt/atlassian/bamboo/bin/setenv.sh のメモリ設定を任意の値に変更します。
    最大1GB程度にしておけばひとまず問題ないと思われます。
1
2
JVM_MINIMUM_MEMORY="512m"
JVM_MAXIMUM_MEMORY="1024m"

データベースの準備

次にデータ保存先であるデータベースを準備します。
今回はBambooのデータ保存先としてcrowdインストール編で用意したMySQL(MariaDB)を使用します。

  • データベースの作成
1
create database bamboo character set utf8 collate utf8_bin;
  • ユーザーを作成し権限を付与
1
GRANT ALL PRIVILEGES ON bamboo.* TO 'bamboouser'@'localhost' IDENTIFIED BY 'bamboopass';
  • DBドライバの配置

Mysqlのドライバを予めBamboo配下に配置しておきます。

/opt/atlassian/bamboo/lib

以下に ドライバのjarファイルを配置しておきます。

起動

ひとまず起動します

初期設定

http://{bambooインストールIP}:8085/ にアクセスすると、
初期設定画面が表示されるので、画面に従って初期設定を行います。

  • ライセンスキーの入力
    事前に用意してあればそのライセンスキーを入力します。
    評価用であればAtlassian公式サイトよりトライアルキーが取得出来ますので、それを入力します。

Bamboo_setup_wizard_-_Atlassian_Bamboo_1006

  • Bambooディレクトリ設定
    通常であれば変更の必要がないため、そのままContinueします。

General_configuration_-_Atlassian_Bamboo_1008

  • データベースの選択
    Bambooのデータを保存するデータベースを選択します。
    今回はMySQLに保存するため、MySQLを選択しContinueします。

Choose_a_database_configuration_-_Atlassian_Bamboo_1443

  • データベース接続パラメータの設定
    データベースの準備で作成したデータベースへの接続パラメータを入力しContinueします。
    Continueを押すと、データベースの初期設定が始まります。
    しばらく時間がかかるので、根気よく待ちましょう。

Choose_how_you_wish_Bamboo_to_connect_to_your_database_-_Atlassian_Bamboo_1449

  • データ移行
    今回は新規インストールですので、「Createa new Bamboo home」を選択しContinueします。

Select_starting_data_for_Bamboo_-_Atlassian_Bamboo_1537

  • 管理ユーザーの作成
    任意のIDとパスワードで管理ユーザーを作成します。

Set_up_administrator_user_-_Atlassian_Bamboo_1538

以上で、Bambooのインストールは完了です。
次回は、以前インストールしたCrowdとBambooを連携させて、ユーザー管理をCrowdに統合したいと思います。

Play! Scalaを Macで始める

Play! Scalaを Macで始める

久しぶりにPlay!に触ったら昔とだいぶ違ったのでメモ。

今回の目標

  1. Play!をインストール
  2. プロジェクトのスケルトンを作成
  3. IntellijIDEAで開発スタートする準備をする
    ところまでが目標。

Play!のインストール

しばらくぶりにPlay!にさわろうと思ったら、playコマンドがなくなっていて、今はtypesafe-activatorにその役目を譲っているらしいので、typesafe-activatorをインストールします。
typesafe-activatorとその開発元のTypesafe社は http://osdn.jp/magazine/13/08/15/150000 http://osdn.jp/magazine/11/05/13/0340257 この辺りをご参照ください。
(私の所属している会社も最近パートナーの末席に仲間入りしました。 https://www.typesafe.com/partners/systemintegrator-partners#community )

typesafe-activatorはhomebrewでインストールできるので、おもむろにbrewコマンドでインストールします。

1
2
3
4
5
$ brew install typesafe-activator *[feature/merge]
==> Downloading https://homebrew.bintray.com/bottles/typesafe-activator-1.3.3.mavericks.bottle.tar.gz
######################################################################## 100.0%
==> Pouring typesafe-activator-1.3.3.mavericks.bottle.tar.gz
🍺 /usr/local/Cellar/typesafe-activator/1.3.3: 4 files, 1.2M

プロジェクトのスケルトンを作成

プロジェクトの作成

playコマンドの代わりにactivatorコマンドを使用してスケルトンを作成します。
いくつか質問されるので順次答えます。

  1. テンプレートは 6 の play-scala
  2. アプリケーション名は任意のものを指定
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ activator new
Fetching the latest list of templates...
Browse the list of templates: http://typesafe.com/activator/templates
Choose from these featured templates or enter a template name:
1) minimal-akka-java-seed
2) minimal-akka-scala-seed
3) minimal-java
4) minimal-scala
5) play-java
6) play-scala
(hit tab to see a list of all templates)
> 6
Enter a name for your application (just press enter for 'play-scala')
> your-project-name
OK, application "your-project-name" is being created using the "play-scala" template.
To run "your-project-name" from the command line, "cd your-project-name" then:
/Users/enjoji/projects/your-project-name/activator run
To run the test for "your-project-name" from the command line, "cd your-project-name" then:
/Users/enjoji/projects/your-project-name/activator test
To run the Activator UI for "your-project-name" from the command line, "cd your-project-name" then:
/Users/enjoji/projects/your-project-name/activator ui

動作確認

プロジェクトが出来たので試しに起動してみます。
プロジェクトのディレクトリに移動し、 activator run を実行しエラーなく起動すればOKです。

1
2
3
$ activator run
Getting org.scala-sbt sbt 0.13.8 ...
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.10.4/scala-compiler-2.10.4.jar

どうやらJava8じゃないと起動しない模様

IntelliJで使う

Intellij Install

  • まずは IntalliJ IDEA をインストールします。

  • 次に必要なプラグインをインストールします

    • Plugin
      • SBT
      • Scala
        プラグインをインストール

ソースのインポート

ソースコードをIDEAプロジェクトとしてインポートします。

  1. メニューを File>New>Project from Existing Source とたどります。
  2. ソースルートを選択
  3. Import project from external model
  4. SBTを選択
  5. Project SDK に Java8 を選択し Finish

以上で、Play+ScalaのスケルトンプロジェクトができてIDEAでの開発準備が整いました。

Mackerel + Raspberry Pi で 職場環境をモニタリング

Mackerel + Raspberry Pi で 職場環境をモニタリング

皆さんMackerelをご存知ですか?

Mackerel とは はてな社が提供しているサーバー監視のサービスで、
サーバーにエージェントと言われるモジュールを設置するだけで、サーバーの状況がブラウザからグラフィカルに確認できるサービスです。

また、監視ルールを設定しておくことにより、サーバーが特定の状態(CPU使用率90%以上など)になった場合アラートを通知したり
無料プランでも一部制限はありますが、サーバー5台まで監視可能など、お手軽、便利、太っ腹なサービスです。

今回は、そんな本来はサーバー監視のサービスであるMackerelを本来の用途以外に使ってみようと思います。

突然ですが、夏ですね

だんだん気候も夏めいて来た今日このごろ、やはり気になるのはオフィスの環境。
健康を害するような環境で仕事をしないためにも、暑さで仕事の効率が落ちないためにも職場環境には気を使いたいところです。

というわけで、今回は職場(でなくてもいいですが)の温度と湿度を計測したいと思います。

温度・湿度を測定する

では、実際に監視システムを構築していきたいと思います。

今回使うもの

  • Raspberry pi 2 Type B
  • 温湿度センサー
  • Raspberry pi と 温度センサー接続用のブレッドボードやジャンパ線
    • 温度センサーとRaspberry Pi をつなぐための線を必要な分用意します。
  • 以前に使用したズゴック(オプション)

ハードウェアの準備

Raspberry Pi と AM2320 を接続する

この実体配線図のようにAM2320をRaspberry Pi と接続します。
AM2320は型番のシルク印刷を表に見た場合、
左から

  • VDD <-> Pin #2 5V
  • SDA <-> Pin #3 SDA
  • GND <-> Pin #20 等 GND
  • SCL <-> Pin #5 SCL
    と接続します。

raspi_am2320

ソフトウエアの準備

Raspberry Pi で I2C を使えるようにする

今回使用する AM2320 という温湿度計モジュールは I2C インターフェース経由でデータを取得します。
RaspberryPIは初期状態ではI2Cが有効になっていないため、
こちらのページ https://blog.ymyzk.com/2015/02/enable-raspberry-pi-i2c/ を参考にし、I2Cを有効にします。

AM2320からデータを取得するプログラムを用意する

こちらのコード https://github.com/takagi/am2321 をベースにし、出力をMackerelに対応させたコードがこちらです。



これをRaspberryPI上でコンパイルし、パスの通った場所に配置します。

1
2
3
4
5
6
curl -LO https://gist.githubusercontent.com/yenjoji/40d135519a0741d3718b/raw/5c7835651a539f16f3446108e15aa482f6c2111f/am2321.c
gcc -lm -o am2321 am2321.c
chmod a+x am2321
mv am2321 /usr/local/bin

Mackerelとの連携

Mackerelに登録してオーガニゼーションを作成する

http://help-ja.mackerel.io/entry/getting-started
の手順にそって、オーガニゼーションを作成します。

maeckrel-agent をインストールする

パッケージをダウンロードし、インストールします。

1
2
curl -LO http://file.mackerel.io/agent/deb/mackerel-agent_latest.all.deb
sudo dpkg -i mackerel-agent_latest.all.deb

ARM 版バイナリに実行ファイルを置き換える

通常ならば、パッケージをインストールすれば完了ですが、
RasperryPiはもともとMackerelが想定しているCPUとアーキテクチャが違うためかそのままではうまく起動しません。
そのため、RaspberryPiのCPUにあったアーキテクチャのMackerelの実行ファイルで上書きします。

1
2
3
4
5
curl -LO https://github.com/mackerelio/mackerel-agent/releases/download/v0.17.1/mackerel-agent_linux_arm.tar.gz
tar xf mackerel-agent_linux_arm.tar.gz
sudo mv /usr/local/bin/mackerel-agent /usr/local/bin/mackerel-agent.org
sudo mv mackerel-agent_linux_arm/mackerel-agent /usr/local/bin/mackerel-agent

maeckrel-agentの設定

インストールが完了したので、設定をしていきます。

設定ファイルに apiKeyとカスタムメトリクスの設定を追加します。
/etc/mackerel-agent/mackerel-agent.conf に オーガニゼーションの画面に表示されているAPIKEYと
以下のカスタムメトリクスの設定を追加してください。

1
2
3
# Get room status
[plugin.metrics.temperature]
command = "/usr/local/bin/am2321 -m"

mackerel-agent 起動

以上で設定がひと通り完了しましたので、エージェントを起動します。

1
sudo /etc/init.d/mackerel-agent start

これで、先ほど作成したオーガニゼーションに自動的にホストが追加され、
mackerelのデフォルトの監視項目と、温湿度計のデータが記録されていくようになります。

mackerel-room

アラートの設定

無事に温度と湿度の記録が始まりました。
しかしながらこれだけでは、職場が危機な状況になっても気づくことが出来ません。

ということで、職場の労働環境を監視する尺度として、不快指数を使って職場環境をモニタリングしたいと思います。

実は先程のMackerelカスタムメトリクス取得プログラムには、温度、湿度以外に不快指数も取得できるようにしてあります。
なので、手順通りに設定した場合は、すでにカスタムメトリクス上に不快指数が記録されていると思います。

wikipediaによると、日本人は不快指数が77を超えた辺りから一部の方々が不快を覚え始め、80を超えるとみんなが不快感を感じるそうなので、
この値を超えた場合に通知が来るように設定したいと思います。

  1. Macerel管理画面から Monitor メニューをクリックし、監視ルールを追加ボタンをクリックします。
    mackerel-monitor_001
  2. ポップアップしたウィンドウに監視条件を入力し作成ボタンをクリックします。
    今回は不快指数(custom.room.1.discomfortindex)を選択し、77でWarning、80でCriticalとなるように設定します。
    mackerel-monitor_002
  3. 作成した関し条件が一覧に表示されていれば成功です。
    これで不快指数がしきい値を超えるた際にメール通知がされるようになりました。また、チャットなどメール以外の通知方法も用意されています。(私はHipChatにも通知しています。)
    momongar-discomfortindex

ズゴックと連携する

以前作成した、ズゴックXFDですが、
チームのみんながちゃんとテストが通ることを確認してからソースコードをPushするため、ほぼ活躍する機会がありません。
このままだと ただ職場にガンプラをおいている人になってしまう ので、
ズゴックの存在意義を上げるべく温度計を連携させたいと思います。

温度計の実装

  1. ドリルで大まかな穴を開けた後、ニッパーで穴をつなぎ
    DSC_0093
  2. カッターで凹凸を整えます
    DSC_0094
  3. 温度計を開けた穴にはめ込み、配線を足経由で踵から外部に引き出せば完成です。
    DSC_0101
  4. 組み立てるとこんなかんじになります。
    DSC_0108
    DSC_0105

結果

晴れてズゴックに温度計が付き、職場の状況をモニタリングすることが可能になりました。

これで、自分の居室の不快指数を計測し放題です。
計測したところで、特に快適になったりはしないのは残念ですが、
計測データを元に現場のリーダーに職場環境のカイゼンをお願いする材料くらいにはなるはずです。

ただ、残念ながら、温度計を付けてもズゴック見た目に変化がないので、
相変わらず傍から見るとガンダム好きな人にしか見えないという点は今後の課題とします。

みなさんもMackerelと様々なセンサーを組み合わせて遊んでみるのはいかがでしょうか?

参考URL

Raspberry Pi の I2C を有効化する方法 (2015年版)

https://blog.ymyzk.com/2015/02/enable-raspberry-pi-i2c/

Raspberry Pi で湿度センサ AM2321 を使う

http://technology-memo.seesaa.net/article/404719464.html

Mackerelについて

http://qiita.com/ariarijp/items/838628e121b051524309

不快指数

https://ja.wikipedia.org/wiki/%E4%B8%8D%E5%BF%AB%E6%8C%87%E6%95%B0

2015/6/21 Agilesamurai Basecamp ふりかえり & TDD でお話させていただきました。

Agile Samurai Basecamp 2015.06 ふりかえり&TDD
の事例紹介セッションでお話をさせていただきました。

柴田さん (@hsbt)、末吉さん(@sue445) という豪華すぎるメンツに気後れしつつも無事に?発表出来ました。
基本一発ネタですが、スライドをアップしました。

事例紹介 「安心してください。テスト書いてます」

QA

質疑応答で質問されたことを覚えている範囲で。

良いテストコードを書くにはどうしたらいいか

  • (直接の回答では無いですが)実際にコードレビューとかしている時に感じた事は
    • プロダクトコードの意図が汲み取れる様なテストだと嬉しいです。
    • 単にカバレッジ等を稼ぐために量産した意図のわからないテストは嬉しくないです。

Red Green Refactor を守った場合と守らなかった場合で定量的な差はあるのか

  • 私達の現場では定量的に計測していないため、わかりません。

TDD導入するときに、既存チームからの暖簾分けする際のメンバーはどういう基準で選びましたか?

  • これが正解というのはないですが、私達のケースでは生きのいい技術が好きな若者を投入しました。
    • 自分からどんどんテストを書いて、周りを巻き込んでテストを書くという流れを作ってもらおうという意図でした。
    • チームメンバーもテストを書くことについては肯定的だったので、リズムを作ればうまくいくと考えてました。

要求を満たしているかをTDDで担保するにはどうしたら良いか

  • 要求を満たしているかどうかはUnitテストでは担保できない(しにくい)と考えています。
    • 私の現場では、手動で行う結合テスト(受け入れテスト)が開発フロー上義務付けられているので、そこで担保できるようにしています。

同じ現場で働いている @setoazusa さんからのキラーパスをうっかり受けてしまったことから始まった今回の登壇でしたが、
豪華登壇者と並ばせていただくなど、本当に貴重な体験をさせていただきました。
こんな場を設けてくださったスタッフの皆様、超きれいな眺めのイイ会場を提供してくださったリクルートジョブズ様
拙い話を最後まで聞いてくださった参加者の方々に感謝致します。
有難う御座いました。

Raspberry Pi で XFD

突然ですがXFDをご存知ですか?

XFDとは

オブジェクト倶楽部 http://objectclub.jp/community/xfd/ によると

プロジェクトステータスやメトリクスは、目に見えにくい。見えないからこそ難しい。そんな悩みを解決してくれるのが、XFD(eXtreme Feedback Device)です。目に見えて、楽しい、ユニークな装置。目に付いて、絶対見落とさないような装置を指します。安上がりならなおよろし。

とのことです。

例えばCIによるビルドエラーに連動したパトランプ http://gitgear.com/xfd/ など、
そのままだと気づきにくいイベントを気づきやすくするデバイスを指すようです。

今回すること

今回はそんなXFDをRaspberry Piを利用して作成してみたいと思います。
なお、今回はAtlassian の CIサーバー Atlassian Bamboo を対象としますが、ビルド結果取得の部分だけ替えればJenkinsなどにも対応可能です。

用意するもの

  • Raspberry Pi x 1
    今買うなら Raspberry Pi 2 Type B がお得だと思われます。

  • 赤色LED x 1
    色はお好みで。
    今回はビルド失敗のエラー感を出すため 3mm径の赤色高輝度LEDとしました。

  • 330Ω抵抗 x 1
    LEDが壊れないよう基本に則って抵抗を使用します。

  • ブレットボード x 1

  • 配線用ジャンパワイヤ 適量
    その他配線用の機材を適宜用意します。

回路

上記のパーツを組み込むとこのようになります。

DSC_0078

一応実体配線図も作ってみました

raspi-XFD

プログラム

例えば以下のようにREST APIでBambooのビルド結果を取得します。
なお、今回はBamboo上に複数ブランチが登録されていることを前提としているため、ブランチがないと動きません。

結果

これで、Bambooの指定したブランチがビルドエラーになった際には、
接続されたLEDが点灯するようになりました。

DSC_0079

しかし、ちょっとこれでは寂しいので、ひと手間加えたいと思います。

最近はだいぶJOJOや、仮面ライダーに押されているとはいえ、エンジニアといえばガンダムです。

という訳で、ちょっとガンダムを足してみました。

DSC_0080

ドリルでモノアイ部分に穴を開けてLEDを装着し

DSC_0097

なるべく目立たないように配線をします。

DSC_0098

最近のプラモはよく出来ていて、関節可動部分が多くいので
昔のプラモのように脚部の中がスカスカでなかったのは誤算でした。

今回はちょっと妥協してこのくらいにしておきますが、機会があればもう少し綺麗に配線をしたいと思います。

動作例

さて、再度どうなるか試してみます。

万が一Bambooでのビルドが失敗した場合には

bamboo_build_failed

光ります。

DSC_0084

これでだいぶ危機感が増しました。
ジムがやられる前になんとしてもビルドエラーを修正しなければなりません!!

まとめ

Raspberry Piが発売されたことによって、ネットワークを利用した電子工作が簡単にできるようになりました。

電子工作初心者でも簡単に作れるオリジナルのXFDでプロジェクトを活性化して行きましょう!

2015/2/2 英語学習勉強会「英語のセッションを聴く」実践編 に参加してきました。

AXON_ACTIVE

牛尾さん(https://twitter.com/sandayuu)主催の、 Majide Perapera Project(http://mpp-group.doorkeeper.jp/)の勉強会

英語学習勉強会「英語のセッションを聴く」実践編
http://mpp-group.doorkeeper.jp/events/20267に参加してきました。

オフショア開発の実践者であり、
牛尾さんをして「ガチアジャイルの実践者」と言わしめる程のMarkusさんの貴重な話を聞け、
更には、自分の質問も聞いてもらった上に、自分の理解力のなさを棚に上げた「Could you summarize it, please.」などという無茶なお願いにも
「もう、十分要約してあるんだけどなぁ」
とか言いつつも非常に丁寧に答えてもらえ、超実践的な英語の勉強にもなる大変有意義な勉強会でした。

タイムテーブル

19:30 - 19:45 Introduction
19:45 - 20:30 My experience with IT outsourcing
20:30 - 20:45 Team discussion
20:45 - 21:30 Ask Mr. Markus

勉強会はこのような流れでした。(ただし、時間はなんとなくです。)

1. My experience with IT outsourcing

まずは、ベトナムでのオフショア開発を実践されている
AXON ACTIVE 社(http://www.axonactive.vn/)の
CEO Markus Baur さんによるオフショア開発の勘所と落とし穴に関するセッションです。

すべて英語のセッションだったため、けっこうな頻度で聞き取れないところがあったのが残念でしたが、それでも随所にためになるエッセンスが散りばめられていて非常に参考になりました。

  • 文化の違いを認識しなければならない
    • インド人?のYesはYesじゃないとか
  • アクセシビリティ
    • オフショア先にいつでもすぐに飛んでいける距離感がとっても大切
    • 時差は4時間ぐらいまでがいい
  • Project型ではなくDedicated Team でないと難しい

  • 短いスパンで頻繁な評価を

  • 重厚なドキュメントを作らず、最低限のテキストで素早く結果を見る
  • チームサイズは 5-10 人 で7人くらいがいい
  • 要求をまとめる人は一人にするべき

  • 何を置いてもオフショアチームと直接会うべき

    • 最低限年に4回は現地にいくべき
    • 現地で、一緒に話、ご飯を食べ、お酒を飲みましょう
    • お互いに歩み寄って、近い間柄になるべきです

2. Team discussion

次に、Markusさんの話を受けて、セッションの内容のチーム内での共有と
Markusさんに聞いてみたい質問をまとめるディスカッションタイムです。

質問のルールとして、チームディスカッションは日本語でOK、
英語への翻訳もチームメンバーの力を借りてOKですが、

実際の質問は質問する人が、英語でMarkusさんに質問をするというルールでした。

3. Ask Mr.Markus (コーナー名は勝手につけました)

チームディスカッションの結果を元に、Markusさんを囲んで全員で座り、
Markusさんへ質問をぶつけて答えてもらおうのコーナーでした。
当初は全員質問するのかなぁと思っていましたが、

個々の質問に対するMarkusさんの対応が丁寧、個々の話題が意外と盛り上がったこともあり、結局7,8件くらいの質問に答えてもらったところでタイムアップでした。

私は、ベトナムでは、けっこう転職が激しいという話も聞いたので、

「アジャイル開発において、チームメンバーが頻繁に入れ替わるのはよく無いと言われていますが、その問題にどう対応しますか?」
という質問を
「Turn over of members is problem of Agile development. how do you
avoid risk.」
という英語で質問しました。
回答は。
1.
開発者に権限を与えて(強制的に働かせたりせず)自己組織化して働いてもらうこと。

  1. 職場環境を整えて、(託児所を用意したりして)環境を良くすること
    という回答を頂きました。

ただ、そうは言っても文化の違いがあったりするので
(ベトナムは65%でOKとしてしまうらしいとか。)
締めるべきところは締めてやっていかなければとも感じました。

感想

オフショアバリバリやってる人の話をちょっと聞いてみようかなぁと
軽い気持ちで申し込んで。

申し込んだ後にこのツイートに気づき、全編英語にビビりまくり

一瞬参加やめようかと思ったりもしましたが、参加して良かったと感じました。

一緒にディスカッションした方が、Markusさんの話を聞いて言った
「これって日本でもおなじだよね」

といっていた言葉を聞いて、本質的なところは文化をこえるってことかなぁと一人感動したりしてました。