2017年3月25日土曜日

AWS EC2上のGitLabリポジトリを別サーバーのRedmineから参照する

オフィス狛 技術部です。

早くもGitLab のインストール・設定シリーズ第5回目となります。
第3回でリポジトリを移行した結果、ある問題が発生しました。

移行前のリポジトリは Redmine がインストールしてあるサーバーに存在したので、
Redmine からリポジトリを参照出来たのですが、別サーバーに移行したら参照する事が出来なくなりました。

そう、「Redmineは、自サーバーにあるリポジトリのみ参照可能」なのです。

折角 GitLab に移行したのだから、GitLab の issue を使う、という事も考えたのですが、
Redmine の工程管理(チケット)とリポジトリの関連付けはやっぱり便利なんですよね・・・・。

というわけで、今回は、AWS EC2 上の GitLab リポジトリを Redmine から(間接的に)参照出来るようにしたいと思います。

その他の記事は、以下をご覧下さい。
第1回(AWS EC2 に GitLab をインストールする)
第2回(AWS EC2 に GitLab をインストールする(メールの送信テスト編))
第3回(AWS EC2 の GitLab へリポジトリを移行する)
第4回(AWS EC2 にインストールした GitLab と Slack の連携)

1)GitLab のリポジトリをクローンする

現在、メインのリポジトリは、GitLab側のEC2(サーバーA)になるので、
そこから、Redmine側のEC2(サーバーB)へリポジトリをクローンします。

【注意】クローンする場所(ディレクトリ)に対しては、Redmine が動作しているWebサーバー(ここではApache)が参照権限を持っている必要があります。

では、サーバーAのリポジトリをクローンします。
sshで接続するので、サーバーAの鍵が必要になります。鍵は、「/home/[ec2_user]/.ssh」に格納します。
※[ec2_user]は、サーバーBにログインしているユーザーで置き換えて下さい。

そして、コマンドを簡略化させる為に、同じディレクリに「config」というファイルを作成し、
Host gitlab_git
  User git
  HostName gitlab.hogehoge.co.jp
  IdentityFile ~/.ssh/keyname
上記の内容を記述します。

 Host : コマンドに含める簡略名になります。 
 User : 接続するサーバーのユーザー
 HostName : 接続するサーバー
 IdentityFile : 使用する鍵

これで準備が出来たので、早速クローンします。
$ git clone --bare ssh://gitlab_git/hogehoge-dev/RipoTest.git
「hogehoge-dev」はGitLab側のユーザー or グループになります。

クローンしたリポジトリは、対象となるRedmineプロジェクトから「設定 > リポジトリ」で参照出来るように設定しておきます。


2)redmine_github_hookのインストール

ここでRedmineのプラグインをインストールします。
$ cd /var/lib/redmine/plugins
$ git clone git://github.com/koppen/redmine_github_hook.git
$ touch /var/lib/redmine/tmp/restart.txt
ここでは、redmineのホームディレクトリが「/var/lib/redmine」の場合を想定しています。
「restart.txt」を作成しておく事で、apacheの再起動無しで、Redmineの再起動を行う事ができます。
(ファイル作成後に、ブラウザでRedmineに接続した時に再起動が行われます。)

正しくインストールされていると、Redmineの「管理 > プラグイン」から、以下のように確認出来ます。

3)GitLab の Webhooks の設定

続いて、GitLab側で Webhooks の設定を行います。
連携したいプロジェクト(リポジトリ)を選択し、右上の歯車プルダウンから「Webhooks」を選択します。


そして、次の設定画面のURLに
http://redmine.hogehoge.co.jp/github_hook?project_id=redmine_identifier
のように入力します。それぞれの環境に合わせて、「redmine.hogehoge.co.jp」と「redmine_identifier」を変更してください。

 redmine.hogehoge.co.jp : Redmine側のEC2(サーバーB)のドメイン or IPアドレス。 
 redmine_identifier : Redmineにおけるプロジェクトの識別子

Triggerも適宜チェックつけますが、単純な連携であれば、Pushだけでも良いかもしれません。


これで、GitLabへのPushはRedmineが参照しているリポジトリに連携され、常に最新状態が保てる事になります。
(何だか二度手間になっている感は拭えないですが)


, , , , ,

2017年3月12日日曜日

AWS EC2 にインストールした GitLab と Slack の連携

オフィス狛 技術部です。

GitLab のインストール・設定シリーズ第4回目の今回は、Slack との連携を行います。

その他の記事は、以下をご覧下さい。
第1回(AWS EC2 に GitLab をインストールする)
第2回(AWS EC2 に GitLab をインストールする(メールの送信テスト編))
第3回(AWS EC2 の GitLab へリポジトリを移行する)

では、早速やり方を説明して行きますが、前回までと違い、今回はブラウザ側の設定で完結出来ます。

1)通知用のチャンネルを作る(Slack側作業)

1-1) 作業の目標はGitLabへのPushをSlackに連携する事なので、
何はともあれ通知用のチャンネルを作成します。


2)通知用のアプリを作る(Slack側作業)

2-1) Slackのメイン画面で、チーム名の横にある「下矢印」をクリックし、メニュー表示後、
「Apps & integrations」を選択します。


2-2) 新たに表示された画面の右上「Build」をクリックします。


2-3) さらに新たな画面に遷移するので、そこで画面中央の「Start Building」をクリックします。


2-4) 続いて、アプリ名を入力し、通知するチームを選択してアプリを作成します。


2-5) アプリが作成されるので、アプリの種類として「Incoming Webhooks」を選択します。


2-6) 「Incoming Webhooks」の設定画面になるので 、まず右上のスイッチを「ON」にし、
その後、「Add New Webhooks to Team」をクリックします。


2-7) 通知を行うチャンネルとして、先程作成したチャンネルを選択し、「Authorize」をクリックします。


2-8) 先程の画面に戻りますが、Webhook用のURLが表示されるので、これをコピーしておきます。


3)通知の設定を行う(GitLab側作業)

ここからは、GitLab側での設定になります。

3-1) 管理者でログインし、管理トップの画面から、右上の歯車から「Service Templates」を選択します。


3-2) Slackを選択


3-3) まず設定を有効にする為、「Active」にチェックを付けます。
後は、どのトリガーで通知を行うか設定します。
下記画像だと、「Push」、「Merge request(GitHubで言う所のPullRequest)」「Tag push」の時に、
「gitlab-notification」へ通知するようにしています。


そして、先程コピーしておいたWebhook用のURLを設定し、「Save」します。
※「Service Templates」で設定しておくと、全てのプロジェクトに反映されるので、便利です。


3-4) 続いて、各プロジェクトで設定を確認してみます。
プロジェクトのトップ画面で、右上の歯車から「Service」を選択します。


3-5) Slackを選択します。
※「Service Templates」で Activeにしているので、緑のマーク(有効マーク)が付いているはずです。


3-6) 設定自体は、「Service Templates」と同じになっていると思いますので、
「Test setting」を押して、通知のテストをしてみましょう。


3-7) 下記のようなメッセージがSlackに出てくれば成功です。
(テスト通知の場合、直近のPush情報が通知されるようです。)

※ちなみに、Slackに表示される画像と名称は、Slack側のアプリ側で変更可能です。
上記は変更後の状態です。
何も設定していないと、Slack API のアイコンが表示されるはずです。


以上です。
開発初期などは、通知が飛び交う事になるので、ちょっとウザいと感じるかもしれません。
(弊社でも最初はそう感じました)
ただ、慣れてくると、誰がいつどんなPushを行なったのか、どの不具合の修正が行われたのか、
など、かなり有意義に思えてきます。
特に、管理する立場から言うと、進捗状況がリアルタイムで分かるのは、かなり助かります。

余談(設定方法はコロコロ変わる)

実は、この記事は、少し前に記載は終わっていて、後は公開するだけの状態でした。
今回、公開しようと思って、情報の確からしさをチェックしたら、
Slack側の設定方法がガラッと変わっていた為、
書き直しをする事になってしまいました。
ブログの記事は寝かしちゃいけないな、と反省しました。


, , , , ,