Viewing entries in
Atlassian

Atlassian Stashの耐障害性を高めよう その4 分散ストレージ設定編

Atlassian Stashの耐障害性を高めよう その4 分散ストレージ設定編

今回もStashの高可用性を目指してクラスタを組んでいきたいと思います。
前回までで、サーバーとStashのプロセスの冗長化は一旦完了したので、
今回は一番重要なデータ保存領域の冗長化を目指します。

お知らせ

今までAtlassian Stash を冗長化しようと頑張ってきましたが、つい先日なんとAtlassian Stashがなくなってしまいました。
今度からは生まれ変わった? Bitbucket Server をよろしくお願いします。

・・・閑話休題・・・

それでは、Stash改めBitbucket Serverのストレージを冗長化したいと思います。

Atlassianの公式によるとストレージは GFS2 + DRBD でストレージの冗長化を行っていますが、
今回は個人的な興味で、GlusterFSを使って冗長構成をしてみたいと思います。

事前準備

VagrantにDISKを追加

Virtualbox コンソール経由で、node01,node02 にDISKを追加します。
Stashのデータに使用するので、保存するデータの容量によって大きさを考える必要があります。
今回は仮に8GBとして データ用にパーティション /dev/sdb1 を作成しました。

GlusterFSのインストール(全ノード)

パッケージのインストール

    cd /etc/yum.repos.d/
    curl -o glusterfs.repo http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo
    yum install glusterfs-server

通信ポートの開放

まずは、通信に必要なポートを開放します。
今回は実験用途なのでどこからでも通信可能に設定してしまいます。

/usr/lib/firewalld/services/glusterfs.xml を以下の内容で作成します。

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>GlusterFS</short>
  <description>GlusterFS</description>
  <port protocol="tcp" port="1111"/>
  <port protocol="tcp" port="24007-24100"/>
    <port protocol="tcp" port="49152"/>
</service>

作成したファイルをもとにfirewallの設定を変更します。

firewall-cmd --permanent --add-service=glusterfs
firewall-cmd --reload

GlusterFS Volumeの作成

次にGlusterFSで使用するディスクの準備をします。

ファイルシステムの作成

GlusterFSは共有するボリュームのファイルシステムをXFSにする必要があります。
まずはデータ用のボリュームをXFSで用意します。

mkfs.xfs /dev/sdb1

/etc/fstab の末尾にエントリを追加します。

/dev/sdb1       /data                      xfs     defaults        0 0

マウントします。

mount -a

GlusterFSの起動

systemctl start glusterd
systemctl enable glusterd    

GlusterFSのノード登録

node01

gluster peer probe node02

node02

gluster peer probe node01

GlusterFSのVolume作成(任意の1ノードで実行)

mkdir -p /data/atlassian/stash
gluster volume create stash_vol replica 2 node01:/data/atlassian/stash node02:/data/atlassian/stash
gluster volume start stash_vol

GlusterFSのマウント

マウントポイントの作成

まずマウントポイントを作成します。
既存のStashのデータディレクトリはあとでGlusterFS上にコピーするためリネームして退避しておきます。

mv /var/atlassian/application-data/stash /var/atlassian/application-data/stash.org
mkdir -p  /var/atlassian/application-data/stash
chown atlstash:atlstash /var/atlassian/application-data/stash

fstabの修正

次に各ノードで /etc/fstab にエントリを追加します。

node01

node01:stash_vol        /var/atlassian/application-data/stash   glusterfs       defaults        0 0

node02

node02:stash_vol        /var/atlassian/application-data/stash   glusterfs       defaults        0 0

ファイルシステムのマウント

次に、両方のノードでglusterfsをマウントします。

mount -a

既存データのコピー

次に、今までのデータをどちらか一方のノードでコピーします

cp -rp /var/atlassian/application-data/stash.org/* /var/atlassian/application-data/stash/.

これで課題だったDISKの冗長化も出来、Stash改めBitbucketServerのクラスタリングが完了しました。
実際の運用では、定期的なデータのバックアップは行う事はあっても、クラスタリングをすることはまれかもしれませんが、
クラスタリングを検討されている方の参考になれば幸いです。

※ このシリーズの記事はあくまで検証用途でクラスタの設定を行っているため、実際の環境では使用に耐えない可能性があります。
実際にHAを構成を行う場合には十分な検証を行うことをおすすめします。

Atlassian Stashの耐障害性を高めよう その3 HAリソースセットアップ編

Atlassian Stashの耐障害性を高めよう その3 HAリソースセットアップ編

今回も引き続きStashの高可用性(HA)クラスタを組むべく進めていきたいと思います。

ATLASSIAN STASHの耐障害性を高めよう その2 HAセットアップ編はHAクラスタをくんだものの、
IPアドレスの設定のみで終わってしまい、全くStashの可用性が高まらないまま終わってしまいました。

このままでは表題に偽りありと言われても反論出来ないので、今回こそは、Stashの可用性を高めていきたいと思います。

前回は、ノードが切り替わる際にIPアドレスが自動的にアクティブノードに付与されるように設定を行いました。
ただ、アクティブノードにIPアドレスが付与されるだけでは、Stashにアクセス出来ません。

というわけで今回は、ノードの切り替わり時に自動的にStashが起動する様にします。

前提条件

  • 前回までの設定が終わっている
  • Stashが各ノードにインストール済み&初期設定済み
  • Stashの自動起動がOFFになっている
  • StashのデータベースはStash以外のサーバーのものを使っている

ここまでの設定が終わっている前提で進めていきます。
Stashはインストーラーを利用しても、tar.gzを利用しても問題ありません。

なお、今回のStashはインストーラーを利用してセットアップしました。

リソース制御スクリプトの追加

今回クラスタの制御に使用しているPacemakerは、一般的なクラスタリソースの制御スクリプトが最初から用意されています。
また、クラスタリソース制御スクリプトが用意されていない場合、
Pacemakerの指定する形式に沿った自作のスクリプトを所定のディレクトリに配置すると、制御対象のクラスタリソースを追加することが出来ます。

Atlassian Stashも残念ながらPacemakerにスクリプトを用意されるほどにはメジャーになっていないようなので、自作のスクリプトを配置する必要があります。

このスクリプトを一から自作するとなかなか大変なのですが、Atlassian社がサンプルで用意しているリソース制御スクリプトがあるので、今回はそれを拝借します。

CentOS 7.1 + Pacemaker 1.1 の構成では
/usr/lib/ocf/resource.d/ 以下に
自作スクリプトを配置することによりクラスタリソースが追加されます。

ということで、このファイルを各ノードの /usr/lib/ocf/resource.d/heartbeat に配置します。

cd /usr/lib/ocf/resource.d/heartbeat
curl -o stash https://bitbucket.org/atlassian/stash-ha-example/raw/1397712da2b11ab4894c91446009aacae94fcf3d/vagrant/scripts/heartbeat-stash
chmod 755 /usr/lib/ocf/resource.d/heartbeat/stash

リソースが定義されているかの確認をします。
pcs resource list コマンドの結果に
ocf:heartbeat:stash が含まれていればOKです。

# pcs resource list
--中略--
ocf:heartbeat:slapd - Manages a Stand-alone LDAP Daemon (slapd) instance
ocf:heartbeat:stash - Manages a Stash instance
ocf:heartbeat:symlink - Manages a symbolic link
ocf:heartbeat:tomcat - Manages a Tomcat servlet environment instance
--以下略--

Stashリソースの定義

リソースを定義する準備が整いましたので、クラスタにリソースを追加します。 下記コマンドを実行して、stashのリソースを定義します。

pcs resource create stash_res ocf:heartbeat:stash params stash_user=atlstash stash_home=/var/atlassian/application-data/stash stash_inst=/opt/atlassian/stash/3.11.3 op monitor interval=15s op start timeout=240s

次にstashが単一のノードでしか起動しないように設定します。

pcs resource meta stash_res migration-threshold=1

最後に、stashのプロセスと、VIPが同時に同じノードで起動するように設定します。

pcs constraint colocation add stash_vip with stash_res INFINITY

リソースを定義した後、クラスタの状態を確認しこのようにstashvipとstashresが同じノード上でStartedになっていればOKです。

# pcs status
Cluster name: stash
Last updated: Sun Sep 20 10:07:15 2015        Last change: Sun Sep 20 09:32:39 2015 by root via cibadmin on node01
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 2 resources configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01
 stash_res    (ocf::heartbeat:stash): Started node01

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
  

ノード切り替えの確認

それでは、設定が出来たのでノード障害時に自動的に切り替わるか確認したいと思います。

まず現状を確認します。
諸事情で、node02がアクティブになっています。

# pcs status
Cluster name: stash
Last updated: Sun Sep 20 11:03:59 2015        Last change: Sun Sep 20 09:32:39 2015 by root via cibadmin on node01
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 2 resources configured

Online: [ node01 node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node02
 stash_res    (ocf::heartbeat:stash): Started node02

PCSD Status:
  node01: Online
  node02: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
  

では、ここでnode02の電源をOFFします。

# pcs status
Cluster name: stash
Last updated: Sun Sep 20 11:08:36 2015        Last change: Sun Sep 20 09:32:39 2015 by root via cibadmin on node01
Stack: corosync
Current DC: node01 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 2 resources configured

Online: [ node01 ]
OFFLINE: [ node02 ]

Full list of resources:

 stash_vip    (ocf::heartbeat:IPaddr2):   Started node01
 stash_res    (ocf::heartbeat:stash): Started node01

PCSD Status:
  node01: Online
  node02: Offline

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
  

しばらく後にクラスタの状態を確認したところ無事にnode01に切り替わっていることが確認出来ました。

さいごに

今回で、ようやくStashが切り替わる様になりました。これで可用性が高まって枕を高くして眠れるかと思いましたが、実はまだ設定が足りませんでした。
実は、Stashはハードディスク上にもデータを保存しているのです。

というわけで次回はディスクを冗長化して、こんどこそ真のStashの耐障害性向上を成し遂げたいと思います。

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

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

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

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

今回の構成

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

ソフトウェアバージョン
CentOS7.1
Pacemaker1.1.12
Corosync2.3.4
pcs0.9.137

ノード設定

ホスト名IP備考
node01192,168.33.21Stash node #1
node02192,168.33.22Stash node #2
stash192,168.33.101Stash VIP

事前準備

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

/etc/hosts

192.168.33.21 node01
192.168.33.22 node02

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

# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability

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

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

# yum install pcs fence-agents-all

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

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

# systemctl start pcsd
# systemctl enable pcsd

クラスタの構築

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

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

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

# passwd hacluster

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

クラスタノードの認証

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

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

クラスタの作成

クラスタを作成します

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

クラスタ状態の確認

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

# pcs cluster status
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 を確認すると。

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
 
といったエラーが発生しています。
この[ページ][0]によると STONITHと呼ばれるノードが不安定になった場合、自動的に再起動を行う機能が有効になっているものの、その機能を実現するためのリソースが無いためエラーとなってしまっているようです。 現時点ではSTONITHを使用しないため、
pcs property set stonith-enabled=false

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

リソースの作成

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

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

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

# 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してみます。

実施前

# 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にします

# 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宛に行っていましたが、今回はpingが途切れる事なくノードが切り替わりました。

スタンバイノードの追加

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

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

# pcs cluster start

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

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

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

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

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

 # pcs cluster standby
 
正常にノードが切り替わり、node01がアクティブになりました。
# 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のスタンバイ状態を解除します。
スタンバイ状態のノードで以下のコマンドを実行します。

# pcs cluster unstandby
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の耐障害性を高めよう その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製品のアドバンテージ「Application Link」

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側で確認することが出来ます。

ブランチの自動作成

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

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

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

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

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

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

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

Stash

JIRA+Confluence

Bamboo+Confluence

RedmineなどのAtlassian製品以外のツールでも、CIサーバーや、リポジトリ管理ツールなどとの連携は可能ですが、 Atlassian製品で揃える事による「設定が簡単でハマりにくい」というメリットは大きいです。

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

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

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

BambooとCrowdの連携

こんにちは、KEYチームの円城寺です。

前回(記事はコチラ)はBambooのインストールを行いましたが、今回はその続きとして、いよいよBambooとCrowdを連携させて、 ユーザーをCrowdで一元管理できるようにしたいと思います。

作業は、公式の手順(リンクはコチラ) に沿って 「Crowd設定」 -> 「 Bamboo設定」 という流れでですすめていきます。

Crowd設定

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

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

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

ユーザーの追加

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

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

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

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

グループの作成

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

「Groups」>「Add Group」リンクをクリック

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

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

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

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

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

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

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

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

アプリケーションの作成

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

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

下記の情報を入力し「Next」をクリック

項目 設定値
Apprication type Bamboo
Name Bamboo
Password 任意のパスワード

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

BambooとCrowdの通信設定を入力し「Next」をクリック

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

ユーザーディレクトリの選択

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

グループの選択

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

登録内容の確認

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

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用の設定がコメントアウトされているので、コメントを外します。

<!--<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に設定したパスワードを入力します。

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

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

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

Atlassian Summer Campaign

Atlassian Summer Campaign

KEY チームのアライです。

突然ですが、Atlassian ページ再開記念と暑い夏を吹き飛ばそう企画として、
「JIRA + JIRA Agile」25ユーザー版ライセンス(サーバー版)の無償利用キャンペーンを実施します。
以下応募条件を全て満たした企業様の中から、独自審査で1社を選定し、約1年間無償でご利用いただきます。

JIRA とは、「作業を計画し、タスクを共有、追跡するプロジェクト管理ツール」
JIRA Agile とは、「スクラム、カンバンでアジャイル開発を手助けするツール」

【応募概要】

  • Atlassian 「JIRA + JIRA Agile」25ユーザー版ライセンス(サーバー版)
  • 応募期間:2015年8月11日から8月31日
  • 当選企業発表日:2015年9月7日(予定)
  • 応募条件:
    1. 企業であること
    2. 応募理由(利用用途、想定ユーザー数含む)をアツく説明できること
    3. サーバーが用意できること
    4. 年数回の利用レポートを行うこと
    5. 貴社名を出して利用レポートを弊社ブログなどで公開可能なこと


再開した Atlassian ページのコチラからご応募下さい。
沢山のご応募お待ちしております!!

Atlassian Bamboo + Crowd 前編:Bambooの導入

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

インストール

最新版のダウンロード

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

展開と配置

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

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 を以下の様に修正します。

bamboo.home=/var/atlassian/application-data/bamboo

  • Bambooメモリ設定の変更

/opt/atlassian/bamboo/bin/setenv.sh のメモリ設定を任意の値に変更します。 最大1GB程度にしておけばひとまず問題ないと思われます。

JVM_MINIMUM_MEMORY="512m"
JVM_MAXIMUM_MEMORY="1024m"

データベースの準備

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

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

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

/opt/atlassian/bamboo/lib

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

起動

ひとまず起動します

cd /opt/atlassian/bamboo
bin/start-bamboo.sh

初期設定

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

  • ライセンスキーの入力

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

  • Bambooディレクトリ設定

通常であれば変更の必要がないため、そのままContinueします。

  • データベースの選択

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

  • データベース接続パラメータの設定

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

  • データ移行

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

  • 管理ユーザーの作成

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

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

Raspberry Pi で XFD

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や、仮面ライダーに押されているとはいえ、 エンジニアといえばガンダムです。

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

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

DSC_0097

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

DSC_0098

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

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

動作例

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

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

bamboo_build_failed

光ります。

DSC_0084

これでだいぶ危機感が増しました。

ジムがやられる前になんとしてもビルドエラーを修正しなければなりません!!

まとめ

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

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

Atlassian crowd インストール編

Atlassian crowd インストール編

こんにちは KEYチームの円城寺です。

せっかく Atlassian Expert なので Atlassian の記事を書いてみよう第2弾ということで、
今回は Crowd サーバーのインストールをしてみます。

下記の環境に Crowd をインストールしていきたいと思います。

  • OS : CentOS 7
  • Java : OpenJDK 1.7
  • mariadb : 5.5
  • Atlassian : Crowd 2.8

K. 仮想環境の準備

今回は 予算の都合上 実験ということで、MacOSX 上の「VirtualBox+Vagrant」の仮想環境に環境を構築します。
専用のサーバーを用意されている方はこの部分は読み飛ばして頂いて結構ですが、
気軽に壊せる環境というのも便利ですので、今回の実験用に試しに構築してみるのもよろしいかと思います。

 Virtualbox のインストール

Virtualbox の以下サイトより、お使いのプラットフォームに合わせたバイナリをダウンロードして、セットアップしてください。
https://www.virtualbox.org/wiki/Downloads

 Vagrant のインストール

Vagrant の以下サイトより、お使いのプラットフォームに合わせたバイナリをダウンロードし、セットアップしてください。
https://www.vagrantup.com/downloads.html

 VMの準備

1. vagrant box を準備する

        $ vagrant box add centos7.0 [任意のCentOS7のBoxファイルURL]
        $ mkdir crowd
        $ cd crowd
        $ vagrant init centos7.0


2. Vagrantfile の下記部分のコメントを外して、内部IPで通信できるようにする
config.vm.network "private_network", ip: "192.168.33.10"

3. VM を起動する

        $ vagrant up


これでひと通り仮想環境の準備は完了です。

E. Crowd のインストール

さて、環境も整いましたので、いよいよ Crowd のインストールと参ります。

 前提条件の準備

早速 Crowd をインストールといきたいところですが、Crowd を動かすための前提ソフトウェアをまずインストールしましょう。

1. Java のインストール
まずは Java をインストールします。
今回は yum で簡単にインストールできる OpenJDK を使用しましたが、
Oracle の JDK(こちらのほうが無難という噂もあり)をご使用される場合は適宜インストールをお願いします。

        $ sudo yum install java-1.7.0-openjdk


2. mariadb のインストール
次に Crowd のデータ保存先であるデータベースのインストールです。
今回は MySQL ではなく、CentOS7 系なので、mariadb を使用します。

        $ sudo yum install mariadb-server


3. mariadb の起動

        $ systemctl start mariadb


 Crowd のインストール

さて、とうとう Crowd のインストールです。
基本的には 公式ドキュメント( https://confluence.atlassian.com/display/CROWD/Installing+Crowd )にそってインストールを行っていきます。

1. 最新版のダウンロード
まずは、以下公式サイトより最新版をダウンロードします。
https://www.atlassian.com/software/crowd/download
今回は Crowd Standalone 版をダウンロードします。

        $ wget http://www.atlassian.com/software/crowd/downloads/binary/atlassian-crowd-2.8.0.tar.gz


2. 展開と配置
次にダウンロードしたバイナリを Crowd のインストール先ディレクトリに展開します。
今回は便宜上、

  • Crowd のインストール先を /opt/atlassian/
  • crowd home を /var/atlassian/crowd

としていますので、 /opt/atlassian にダウンロードしたバイナリを展開します。

        $ tar -xf atlassian-crowd-2.8.0.tar.gz
        $ sudo mkdir /opt/atlassian
        $ sudo mv atlassian-crowd-2.8.0 /opt/atlassian/
        $ sudo ln -s /opt/atlassian/atlassian-crowd-2.8.0 /opt/atlassian/crowd


3. crowd home の準備
次に、Crowd のデータ保存先になる crowd home を準備します。

        $ sudo mkdir -p /var/atlassian/crowd


4. 設定ファイルの編集
次に、Crowd の環境依存部分の設定を設定ファイルに設定します。
対象のファイルは以下。
${crowdインストール先}/crowd-webapp/WEB-INF/classes/crowd-init.properties
このファイルの crowd.home を下記のように先ほど作成したディレクトリに変更します。

crowd.home=/var/atlassian/crowd


 Crowd 用データベースの準備

次に Crowd のデータ保存先であるデータベースを準備します。

1. データベースの作成

        create database crowd character set utf8 collate utf8_bin;


2. Crowd ユーザーを作成し、権限を付与

        GRANT ALL PRIVILEGES ON crowd.* TO 'crowduser'@'localhost' IDENTIFIED BY 'crowdpass';


3. Crowd 用に mariadb に設定を追加
/etc/my.cnf の[mysqld]セクションに以下の4設定を追加

[mysqld]
---中略---
character-set-server=utf8
collation-server=utf8_bin
default-storage-engine=INNODB
transaction-isolation = READ-COMMITTED


4. mariadb(mysql)の Java ドライバをインストール

        $ yum install mysql-connector-java.noarch
        $ cp /usr/share/java/mysql-connector-java.jar /opt/atlassian/crowd/apache-tomcat/lib/.


Y. Crowd の起動

さて、準備が整いましたので、Crowd を起動してみます。

 Crowd の起動

        $ cd /opt/atlassian/crowd/
        $ ./start_crowd.sh


 Crowd の初期設定

1. Crowd 初期設定画面へアクセスする
Crowd の初期設定画面 http://localhost:8095 にアクセスします。
設定画面へは、Crowd のサーバー上からしかアクセス出来ないようなので、
別サーバーからつなぐ場合は SSH トンネルなどを用意します。
(例)

        $ ssh vagrant@192.168.33.10 -i ~/.vagrant.d/insecure_private_key -L 8095:localhost:8095


初期設定画面にアクセス出来た後は、画面の指示にしたがって必要な情報を入力してゆきます。

以降は今回の設定例です。必要に応じで参考にしてください。
あくまでテスト用の設定ですのでご注意ください。

Set up Crowdボタンを押して設定をスタートします。

ライセンスを入力します。お試しの場合は、ライセンス入力エリアの下にあるリンクより評価ライセンスを取得することが出来ます。

ライセンスを入力します。お試しの場合は、ライセンス入力エリアの下にあるリンクより評価ライセンスを取得することが出来ます。

今回は新規インストールなので、 New instllationにチェックをしてContinueします。

今回は新規インストールなので、 New instllationにチェックをしてContinueします。

先ほど設定したデータベースの接続情報を設定します。

先ほど設定したデータベースの接続情報を設定します。

設定を確認してContinue

設定を確認してContinue

今はメールサーバーを設定しないので、Laterを選んでContinue

今はメールサーバーを設定しないので、Laterを選んでContinue

今回は初期設定でContinue

今回は初期設定でContinue

初期管理者の情報を入力してContinue

初期管理者の情報を入力してContinue

今回はこのままContinueします。

今回はこのままContinueします。

これで初期設定は完了です。

ログイン画面より、先ほど設定した管理者アカウントでログインできるようになっていると思います。

次回は、Crowd と他の Atlassian プロダクトを連携させてみたいと思います。

 

Atlassian ID 管理ツール Crowd

Atlassian ID 管理ツール Crowd

こんにちは 、 KEYチーム所属の円城寺です。

当社は Atlassian Expert と呼ばれる Atlassian 社のパートナー企業の一社として名を連ねさせて頂いております。

そんな当社ですが、あまり Atlassian Expert であることをアピールしていませんでした。
ということで、せっかく Atlassian Expert なので、Atlassian の記事を書いてみようと思います。

今回は、JIRA や Confluence などに比べて注目されにくいものの、
意外と便利な Crowd についてどのようなものかを書かせていただきます。


Crowd とは

Crowd とは Atlassian 社が提供する、ユーザー管理、シングルサインオンソフトウェアです。

公式には、

「使用、管理、統合がとても簡単なシングルサインオンとユーザー ID のためのツールです。
Active Directory、LDAP、Crowd 自身、あるいはそれらの組み合わせでも何でも、ユーザー情報を取り込めます。
アトラシアン製品、Subversion、Google Apps、独自アプリなど全てのアプリケーションのパーミッションを一箇所で制御できます。」

と説明されていますが、JIRA や Confluence に比べてマイナーであり、
最近では Atlassian のクラウドサービスである、Atlassian OnDemand が Atlassian Cloud に名称変更し、
Crowd と Cloud というややこしい事になったりといろいろあるプロダクトです。

そんな Crowd ですが、実は Atlassian 製品と連携することにより、ユーザーIDと権限(グループ)を集中管理することができ、
また、シングルサインオン環境を構築することも可能な縁の下の力持ちなプロダクトなのです。

Crowd 以外にシングル・サインオンなど同様の機能を持つプロダクトとして、shibboleth などが存在します。


Crowd ができること

  • アカウント管理の一元化

Atlassian 製品を通常の手順でインストールすると、ユーザーIDと権限管理は、JIRA であれば JIRA のユーザーと権限、
Confluence であれば Confluence のユーザーと権限というようにプロダクト毎の管理となってしまいます。
ユーザー・プロダクトが増えてくるに連れて、管理者視点からは、ユーザーアカウント管理コストの増加の問題、
ユーザー視点からはパスワード管理・変更のコストが増えるというデメリットがあります。
ユーザーIDを Crowd で一元管理する事により、管理者、ユーザー双方のID管理コストが削減できます。
また、ユーザーの削除漏れや権限付与・剥奪漏れなどの管理ミスが起こりにくくなり、それに起因するセキュリティリスクの軽減にもつながります。

  • シングルサインオンの実現

Crowd を利用することにより、JIRA や Confluence のID一元的に管理することができます。
ただ、IDの一元管理だけであれば、JIRA でも同様のことが可能であるため、わざわざ Crowd を使う必要はありません。
JIRA に対しては Atlassian 製品および、Crowd に対応した製品間でのシングルサインオンが実現できることが Crowd のアドバンテージといえます。

  • Atlassian 製品との連携

Crowd は Atlassian 製であるため、当然 Atlassian 製品との親和性が高いです。
JIRA や Confluence などの Atlassian 製品と Crowd との連携は、各製品の管理画面から簡単に設定することができます。
ただし、シングルサインオン構成を行う際には、設定ファイルの修正など、JIRA などシングルサインオンを提供される側の対応が必要です。

  • Atlassian 製品以外との連携

Atlassian 製品との連携は当然簡単にできる Crowdですが、Atlassian 以外の製品との連携も可能です。
使用するプロダクトの対応状況にもよりますが、Apache のBasic 認証を Crowd でおこなうことなどが可能です。
また、独自に Crowd との連携部分を開発することも可能で、自社のサービスを Crowd に対応させたりすることも可能です。


つぎは

さて、Crowd の概要はこのくらいにして、 (もし、続けば) 次回からは実際の Crowd のセットアップや、各サービスとの連携設定について具体的な例を上げてご紹介させていただきたいと思っております。