結局は目的・動機だったなぁというGWのおもひで

5/3～5/7の5日間、近年稀に見る有意義なGWを過ごしたと思うので、今後の自分のためにもちょっと纏めておこうと思います。

なにをしてたか

一言で言うと、5日間にわたって、会社で使用しているMattermostにbotを設置しました。

Mattermostはチャットツールです。オンプレミスで使用できます。

about.mattermost.com

botは、bot作成フレームワークの hubot を使用して作成しました。

hubot.github.com

※各ツールの概念・仕組みについては、この記事では省きます。

5日もかけてとかﾌﾟｹﾞﾗ

ググると、大概Qiitaとかで「10分で導入うんぬん」とかいう記事、よくヒットします。しかし今回の環境としては基本的に「会社のプロキシサーバ配下」となっております。（この苦しみは分かる人にしか分からないと思います……）

思い返せば、5日間のうち2日間くらいはプロキシサーバと戦ってた覚えがあります。

技術的な設定ファイル云々は、今後区分けしてQiitaとかに投稿するつもりです。

こんな大変なのは経験は、私が1回すれば十分です。

もったいなくてなぁ、お前（ら）なんかにやれるかよ！（プラネテス

さぁというわけで、5日間の泥沼の戦いを振り返ります。各日の内容全てにプロキシ存在のバイアスがかかっていると思って下さい。地獄でした。

……

…

1日目(5/3)

hubotは

bot本体
アダプタ

という2階層から成っているそうです。（ここで既に1時間くらい経過！）

じゃあ、hubotのMattermost用のアダプタがあればいいわけですね！

hubotのアダプタ一覧はこちら

Mattermost用のアダプタは2種類あるようです。

hubot-mattermost （一覧だと Mattermost ）
hubot-matteruser （一覧だと Mattermost - WebSocket ）

GithubのREADMEを見た感じ後者 hubot-matteruser の方が思ってた感じ（詳しくはラスト）になりそう。

ですが、せっかく休日だしWebhookが使ってみたかったので、まずは試しに前者の hubot-mattermost を使用しました。 hubotの稼働は、覚えたてのDockerで行いました。

（苦節うん時間）

一応できました！

f:id:saikou9901:20170507184710p:plain

でもやっぱり思ってた感じではない。

というわけでGithubページを見た感じよさそうな後者に挑戦。

しかしこちらには、セキュリティとか厳しい会社ではなかなかハードルの高いアイテムが必要でした。

そう、 bot用メールアドレス です。

会社のドメインなんてよっぽどの理由が無いとゲットできない、外部のWebメールなんて全部フィルタで弾かれる。

……

…

よし、

ローカルにメールサーバ立てるか

2日目(5/4)

はい、メールサーバです。

大分慣れてきたDockerでやりたかったので、こちらを使用させてもらいました。

github.com

適宜メンテナンスされているようですし、結構使用されてそうなので。

ここで、ローカルメールサーバの要件をおさらいします。

Mattermostから飛ばすメールサーバは１つなので、会社ドメイン（社員ユーザ）もローカルユーザ（bot）もこのローカルメールサーバに飛ばす
そのうち、会社ドメインのメールは、本来の会社のSMTPに転送してあげる
一応会社の皆で触れるようにIMAP設定する

です。

さぁというわけで Postfixの勉強からスタート しました。

（ひたすらWebページを見ているマウスの音）

ド、ドメインのリレー……（リレーっていうんだ……）

http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#relay_domains

（docker-compose upする音）

ユーザ作ったし、立ちあがったからOutlookしてみるか……

なんでIMAPできへんねん……

（telnet叩く音）

平文認証はデフォルトでOFFられてるのか…… どうやってONにするんだ……

（docker-compose up, down, up, downする音）

送信元、宛先アドレスが、ローカルアドレスでもリジェクトされないようにしないといけないのか……

http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#smtpd_sender_restrictions http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#smtpd_recipient_restrictions

というか、docker内部のPostfixのmain.cfを上書きする形だからコンテナの内部の設定分からないといけないのか……

（docker run bashで/etc/postfix/main.cfみる音、コンテナにvimはいってなかったからcatする音）

……

Outlookでメール送受信できたーーーーーーーーーーーーーーーーーーーーー！

メール送受信になんだかタイムラグがあるけど、きっとブラックリストサーバ探そうとしてるだけなので気にしないでおきましょう。

さぁ、明日はいよいよbotをつくります。

3日目(5/5)

というわけで hubot-matteruser を使ってbotを作ります。

ローカルメールで認証して、作成したユーザを環境変数でbotに渡して……

無事にping／pongできました！！ （botの様子はラストに）

いやー長い戦いでした。

さぁ、もうMattermostのユーザは確定したので、Webhookの時に作ってたMattermostのお試しユーザを消しておきましょうか。

どうも Mattermost CLI というのを使用するのだそうです。

じゃあ、ページ見てみましょうか。

Command Line Tools

……ん？

https://docs.mattermost.com/administration/command-line-tools.html#platform-user-activate

f:id:saikou9901:20170507193004p:plain

は？アクティベート……アクティベート！？できるの！？

メール認証は！？

昨日の苦労は！？

……

まぁ、メールサーバ立てる勉強になったし、いや、まじで役に立ったし（震え声

……

さぁ、bot立ったということで、次はあれをしましょう。

あと、今日は精神的に疲れたからビールたらふく飲んでとっとと寝ましょう。

4日目(5/6)

最近会社のサーバに Concourse というCI/CDツールを導入してみたので、これを使用して、hubotの Gitbucket リポジトリにプッシュされたら、Dockerデプロイされるようにしましょう。つまりCDだけです。

github.com

CDの概要は次の通りです。

hubotコンテナのDockerfileで、Gitリポジトリからbot本体ソースを取得するようにしておく
Concourseのgitリソースを使ってGitリポジトリのmasterを監視する
masterにpushされたら、hubotコンテナが稼働しているDockerホストにSSHアクセスして、コンテナの再構成・実行を行う
Concourseのslack通知機能（サードパーティ）を使ってMattermostに通知する

特に試行錯誤したのは、

masterにpushされたら、hubotコンテナが稼働しているDockerホストにSSHアクセスして、コンテナの再構成・実行を行う

です。

openssh-clients を使用してログインするんですが、対話形式で「Credential受入れてOK？」という質問と、パスワードの入力に回答しなければなりません。

これには expect で対応しました。新たにQiita記事にするまでもないのでさらっと書いてしまいます。

expect -c "
set timeout -1
spawn ssh -l root 【dockerホスト】 【docker再構成用につくったスクリプト】
expect \"Are you sure you want to continue connecting (yes/no)? \" {
    send -- \"yes\n\"
    expect \"root@【ホスト】's password: \"
    send -- \"【パスワード】\n\"
} \"root@【ホスト】's password: \" {
    send -- \"【パスワード】\n\"
} \"Permission denied (publickey,gssapi-keyex,gssapi-with-mic).\" {
    exit
}
interact
"

set timeout -1 をしておかないと、パスワード問合わせまで時間が掛る場合があるので、タイムアウトがよく発生してしまいます。

……

というわけでここは粛々とページを読みまくって、無事にできるようになりました。

ですが、ちょっとパイプラインに無駄が多いので、ちょっと改善しましょう。

5日目(5/7)

さぁ5/7、つまり、今日の話。

CDにあたって、次の時間がかかる要因がありました。

ConcouseのTaskを実行するdocker-imageに、パイプライン実行の度に openssh-client と expect をインストールしていた
hubot本体をGitリポジトリから取得してくるのをDockerfile内で実行していたため、デプロイ時にはイメージから再作成しなければならなかった

まず 1. です。

こちらはもう……Dockerhubにイメージ作っちゃいました。ローカルのDockerリポジトリとかまだ勉強しきれてないので。

https://hub.docker.com/r/saikou9901/centos-for-concourse/

これだけでかなり速度改善されました。

次に 2. 。

これは、 git clone と npm install あとbot本体の実行開始を、いわゆる entrypoint.sh に移しました。これで、イメージの再作成は省かれ、コンテナ再作成からで済むようになりました。

（entrypoint.shの改行コードが CRLF になってしまっていたせいで、先頭の #!/bin/bash がずっと no such file or directory ってなって30分くらい格闘してたのは内緒）

以上2つの改善により、デプロイ時間は半分以下になりました。