mallowlabsの備忘録 このページをアンテナに追加 RSSフィード

2017-01-24

Wercker からマイグレーションせよというメールが来たので対応してみた

CI サービスの Wercker からマイグレーションせよという以下のメールが来た。

Attention: Manual Migration required on your Wercker Account

Hi Mallowlabs,

We informed you a couple of months ago that we're going to start deprecating our non-Docker (or classic) stack in the future.

Since you have projects on our classic stack, we are pleased to announce that the time has come.

Non Docker-based applications will require a manual effort to migrate please follow this link to our stack migration wizard to start the process.
...


今回、このマイグレーションに対応した記録を共有する。

まずは https://app.wercker.com/applications/migrate にアクセスする。

f:id:mallowlabs:20170124210406p:image
Heroku deploy targets を使っているのがまずいらしい。

該当アプリの Deploys から edit をクリックする。
f:id:mallowlabs:20170124210836p:image

更に Edit をクリックする。
f:id:mallowlabs:20170124211100p:image

Delete Target をクリックして、Deploy Target を削除する。
f:id:mallowlabs:20170124211302p:image

もう一度 https://app.wercker.com/applications/migrate にアクセスすると、以下のような表示になるのでチェックを入れて、Migrate をクリックする。
f:id:mallowlabs:20170124211636p:image

リロードすると Up-to-date になる。
f:id:mallowlabs:20170124211757p:image

アプリの Workflows タブから Add new pipeline をクリックする。
f:id:mallowlabs:20170124212039p:image

Name に heroku-deploy、YML Pipeline name に deploy を入力して Create をクリックする。
f:id:mallowlabs:20170124212321p:image

環境変数を設定する画面に遷移するので、以下の3つを入力する。

  • HEROKU_APP_NAME
  • HEROKU_USER
  • HEROKU_KEY

f:id:mallowlabs:20170124212920p:image

Workflows タブに戻って build の後ろに heroku-deploy Pipeline を追加する。
f:id:mallowlabs:20170124220753p:image

ここでやっとソースを変更する。

diff --git a/config/mongoid.yml b/config/mongoid.yml
index ccd80db..b658599 100644
--- a/config/mongoid.yml
+++ b/config/mongoid.yml
@@ -3,7 +3,7 @@ development:
   database: asakusa_satellite_development

 test:
-  host: <%= ENV['WERCKER_MONGODB_HOST'] || 'localhost' %>
+  host: <%= ENV['MONGO_PORT_27017_TCP_ADDR'] || 'localhost' %>
   database: asakusa_satellite_test

 production:
diff --git a/wercker.yml b/wercker.yml
index 0ce7ab5..80c1a0b 100644
--- a/wercker.yml
+++ b/wercker.yml
@@ -1,6 +1,6 @@
-box: wercker/rvm
+box: ruby:2.3
 services:
-  - wercker/mongodb
+  - id: mongo
 build:
     steps:
         - bundle-install
@@ -19,3 +19,10 @@ build:
     after-steps:
         - mzp/http-notify:
             url: $DASHBOZU_URL
+deploy:
+  steps:
+    - heroku-deploy:
+        key: $HEROKU_KEY
+        user: $HEROKU_USER
+        app-name: $HEROKU_APP_NAME

ポイントとしては以下の通り。

  • box を指定したところは Docker コンテナを指定するようにする
  • MongoDB などの services も Docker になるのでホスト名等を工夫する
  • Heroku deploy は heroku-deploy を使うようにする

このあと、 変更を master に push すれば Wercker でビルド後、Heroku に deploy される。

所感

Wercker のドキュメントが Wercker Workflows に対応していないものが多くて苦労した。
この記事が誰かの役にたてば嬉しい。

2016-12-25

ホビー用途の mLab でリモートバックアップする

環境

  • MongoDB 3.2.11
  • dbxcli 1.4.0
  • heroku-toolbelt 3.43.15
  • heroku-buildpack-mongodb Rev. 59b9e8d
  • heroku-buildpack-dbxcli Rev. d67845a

モチベーション

ホビー用途の Heroku アプリmLab アドオンを Sandbox プランで利用している。
mLab の DBバックアップは Sandbox プランでは提供されないので、リモートバックアップを設定したい。
ホビー用途なので、できればお金をかけない範囲で行いたい。

heroku-buildpack-mongodb

Heroku の buildpack に MongoDBバイナリを使えるようにする heroku-buildpack-mongodb があるので、これを使って Heroku Scheduler で mongodump を呼び出せば、バックアップは取れそうである。

ストレージ

問題はストレージをどうするかである。
普通に考えたら S3 だが、ホビー用途で AWS はあまり使いたくない。IAM や MFA など、考えることが多いためだ。
そこで Dropbox を利用することを考えた。
dbxcli というワンバイナリDropbox を操作できるツールを Heroku Scheduler から使えれば良さそうだ。

heroku-buildpack-dbxcli

ということで heroku-buildpack-dbxcli という Buildpack を作った。
この Buildpack を使えば、dbxcli を Heroku 上から簡単に使うことができる。

Heroku 設定

まずは以下のような backup.sh を作って git commit しておく。

#!/bin/sh

# backup xxx
$ mongodump -h xxx.mongolab.com --port xxx -d heroku_appxxx -u heroku_appxxx -p xxx -o xxx_dump --excludeCollection=system.users

# archive
$ tar cvzf xxx_dump.tgz xxx_dump

# upload to Dropbox
$ dbxcli put xxx_dump.tgz Backups/xxx_dump.tgz

次にその Git リポジトリを Heroku に push する。

$ heroku create --buildpack http://github.com/goodeggs/heroku-buildpack-mongodb.git
$ heroku buildpacks:add --index 2 http://github.com/mallowlabs/heroku-buildpack-dbxcli.git
$ heroku config:add DROPBOX_AUTH_TOKEN=<your token>
$ git push heroku master

Dropboxトークンは、手元で dbxcli で一度ログインして ~/.config/dbxcli/auth.json の内容を見て取得する(ちょっとかっこ悪い)。

あとは backup.sh を Heroku Scheduler から呼び出せば、Dropbox に mongodump の結果が保存されるようになる。

まとめ

  • dbxcli は便利!
  • Heroku Buildpacks も便利!

2016-06-11

GitBook で書いた文書の Redpen の警告を Jenkins Warnings Plugin で可視化する

環境

  • Jenkins 2.8
  • Jenkins Warnings Plug-in 4.56
  • Redpen 1.5.5

モチベーション

最近、技術ドキュメントを GitBook を使って Markdown で書いている。
GitBook は当然 Git リポジトリが使えて、WebHook まで使える。
こうなってくると Jenkins で CI をして、校正結果をグラフにしたくなってくるので、
Jenkins と同じ Java で書かれた Redpen を使ってみている。

Jenkins Warnings Plugin の設定

まずは Jenkins Warnings Plugin にパーサーを追加する。
設定は以下のようにする。

f:id:mallowlabs:20160611231909p:image

  • 名前 … Redpen
  • リンク名 … Redpen 警告
  • 推移レポート名 … Redpen 警告
  • 正規表現
(.+):(\d+?): ValidationError\[(.+)\], (.+) at line: (.+)
import hudson.plugins.warnings.parser.Warning
import hudson.plugins.analysis.util.model.Priority

String fileName = matcher.group(1)
String lineNumber = matcher.group(2)
String message = matcher.group(4)

return new Warning(fileName, Integer.parseInt(lineNumber), "Dynamic Parser", "Warning", message, Priority.NORMAL);

ジョブの設定

GitBook 側の設定

  • WebHook で Jenkins のジョブを実行する

実行イメージ

こんな感じ。
当然、警告のリンクをクリックすると該当行をハイライトしてくれたりするし、警告数の推移もグラフにしてくれたりもする。

f:id:mallowlabs:20160611232732p:image

まとめ

GitBook + Redpen + Jenkins Warnings Pluginin がお手軽で最高!

2016-08-03 追記

Markdown ファイルがサブディレクトリにあるとハイライトがうまく効かないみたい。
Redpen がディレクトリの情報を捨てちゃってるのでどうしようもない感じ。

2016-03-10

Maven 3 + cobertura-maven-plugin 2.7 で mvn site すると jar/war が壊れる件

環境

現象

Maven 3 と cobertura-maven-plugin 2.7 の組み合わせで mvn site をすると、生成される jar/war に Cobertura の instrument が混入したままパッケージが作られてしまう。
mvn package だけすると問題がないが、一つのコマンドラインで mvn package site のように同時にやってしまうと jar/war が壊れる。
Maven 2 を使っている場合には問題が無い。

原因

cobertura-maven-plugin 2.7 から integration-test フェーズでも実行されるように変更された。
この結果、mvn site でも package フェーズが実行されてしまうようになった。
Maven2 は integration-test フェーズが無いため問題がない。

対策

Mojo’s Maven plugin for Cobertura – Usage に書いてある通り。

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>cobertura-maven-plugin</artifactId>
  <version>2.7</version>
  <reportSets>
    <reportSet>
      <reports>
        <report>cobertura</report>
      </reports>
    </reportSet>
  </reportSets>
  <configuration>
    <inputEncoding>UTF-8</inputEncoding>
    <outputEncoding>UTF-8</outputEncoding>
    <formats>
      <format>xml</format>
      <format>html</format>
    </formats>
  </configuration>
</plugin>

のように reportSets を書くこと。これで site ゴールで Cobertura が走らなくなって、jar/war に instrument が混入することはなくなる。

まとめ

cobertura-maven-plugin 2.7 最高!

2015-08-29

Ruboty でカレンダーの予定をアラートするプラグイン「ruboty-calendar_alert」作った

ruboty-cron を使って、チャットに予定をアラートしてたんだけど、予定の登録がダルくなったので作った。

GitHub - mallowlabs/ruboty-calendar_alert: Mount alerting system to Ruboty to notify calendar schedules with iCal urls.

iCal (.ics) の URL を Ruboty に教えてあげると、定期的にフェッチして、予定の10分前になったら教えてくれるようになった。

使い方

Gemfile に以下のように記述する

# Gemfile
gem 'ruboty-calendar_alert', github: 'mallowlabs/ruboty-calendar_alert'

あとは Ruboty に iCalURL を教えてあげる。

@ruboty add calendar <ics_url>

そうすると予定の10分前にチャットに通知される。
フェッチは

  • 02:23
  • 08:23
  • 14:23
  • 20:23

に実行されるので、あんまり最近に登録された予定についてはアラートされないかもしれない。

f:id:mallowlabs:20150829210304p:image

こんな感じで仕事中でもアニメの一挙放送の開始に気づけて本当に便利です。

まとめ

キルラキル最高!