ククログ

Fluentdで古くなったプラグインを検出する試み

Fluentd v0.14.xはFluentd v0.10.xのAPIがいくつか廃止されていて古いAPIを使っているプラグインが動作しなくなっています。また、他にも以下の観点でFluentd v0.14では使わない方がよい3rd party製プラグインが見つかっています。

古くなっていてメンテナンスされていないもの
最新のFluentdに添付されているプラグインでは、その機能が取り込まれているため使う意味がないもの
対象のミドルウェアがメンテナンスされなくなっているもの
対象のウェブサービスがサービス提供を終了しているもの
旧バージョンのRubyでのみ意味があったもの
ある問題を解決するためにrubygems.orgで公開されていたが、アップストリームで対応されるなどして問題が解決されたため不要になったもの

Fluentdを使いたいユーザーがプラグインを探すときはプラグイン一覧を見ると思いますが、ここのリストは機械的に更新されています。ユーザーが使いたいプラグインをより見つけやすくするために、もう使わない方がよいプラグインをリスト化してメンテナンスしています。

このリストは手動でメンテナンスされていてfluent/fluentd-websiteにPull requestを送ると取り込まれて、翌日にはウェブサイト上に反映されるはずです。

記事執筆時点では約40個のプラグインがこのリストに載っています。このリストを見れば、使わない方がよいプラグインを確認することができます。新しく使用するプラグインを検討するときは、このリストを目視で確認していくとよいのですが、既にインストール済みのプラグインがたくさんある場合は、目視で確認するのはとても大変です。

そこでFluentd起動時に確認できるfluent-plugin-obsolete-pluginsというプラグインを作ってみました。

このプラグインは、Fluentd起動時に非推奨プラグインのリストを読み込んでその環境で利用可能なgemのリストと比較し、非推奨なプラグインがインストールされていたら警告します。このプラグイン自体はFluentd v0.14 APIを使用して実装したレコードを素通しするFilterプラグインです。v0.14 APIを使用して実装したので、Fluentd v0.12以前のバージョンでは利用できません。

Fluentd v0.14の検証のついでに、非推奨なプラグインのチェックも一緒にしてみてはいかがでしょうか。

2017-07-03

Gecko Embeddedプロジェクト

はじめに

クリアコードは、組み込みLinux向けにMozilla Firefoxのブラウザエンジンを移植するプロジェクトGecko EmbeddedをWebDINO Japan（旧Mozilla Japan）様と共同で立ち上げ、開発を進めております。Yoctoを使用してFirefoxをビルドしたりハードウェアアクセラレーションを有効化する際のノウハウを蓄積して公開することで、同じ問題に悩む開発者の助けになることを目指しています。

ターゲット

組み込みLinuxと一口に言っても、対象となるハードウェア及びソフトウェア環境は多岐にわたります。しかし投入できる開発リソースには限りがあるため、当面のターゲットは以下の環境に絞っています。

SoC: Renesas RZ/Gシリーズ
ビルドシステム/OS: Yocto 2.0 (Jethro)
ウィンドウシステム: Wayland 1.10以降
ツールキット: GTK+ 3.20以降

GTK+を使用せずに直接WaylandあるいはDRMで描画するバックエンドを作成した方がより組み込み向けらしいとは言えます。しかし過去の事例から考えても、Mozillaが正式にサポートするプラットフォームから大きくかけ離れたバックエンドを作成すると、その後のバージョンアップに追従するコストが高くなり、やがてはメンテナンスされなくなっていく未来が見えてしまいます。このため本プロジェクトでは、少なくとも現段階ではGTK+を使用し、成果を本体へフィードバックしていくことで、バージョンアップに追従していくコストを抑えることを目指しています。

現在のステータス

Wayland対応

Firefoxは正式にはWaylandをサポートしていませんが、Red Hat社のMartin Stransky氏がWaylandへの移植作業を行っています。 Stransky氏のパッチはFirefoxの最新バージョンを対象としていますが、Gecko Embeddedプロジェクトではこのパッチを52ESRに移植した上で、安定化作業を進めています。本プロジェクトで発見した問題や、作成したパッチはStransky氏に随時フィードバックしています。Stransky氏のWayland対応パッチは、徐々にmozilla-centralに取り込まれていっています。

EGL対応

暫定パッチを当てることにより、EGL/OpenGL ESを使用して以下のアクセラレーションを有効化できることを確認済みです。

Compositor
Canvas
WebGL1

ただし上記パッチは必ずしもWaylandやGTK+の描画機構に即した形にはなっておらず、いくつかの問題を抱えているため、本体へフィードバックする際には抜本的な見直しが必要です。また、CanvasやWebGLについては安定性の面でさらなる対応が必要です。

OpenMAX IL対応

H.264の動画再生については、OpenMAX IL対応コードを追加することで動作を確認済みです。現在はまだ画像データのゼロコピーを実現できていませんが、これを実装することにより今後の性能改善が期待できます。

なお、一般的に、組み込みLinuxでの動画再生はGStreamerによって実装されますが、現在のFirefoxでは諸般の理由からGStreamer対応コードが削除されています。このため本体にコードを取り込んでもらえる可能性は低いですし、独自にGStreamer対応コードを保守するのもコストが嵩みます。一方でOpenMAX ILについてはFirefox OS用の類似のコードが残されており、保守が容易で本体へフィードバックできる可能性も高いため、現時点ではOpenMAX ILを使用する方法を選択しています。

ただし、将来的に他のボードへの対応を行う際には、OpenMAX ILコンポーネントを提供されていないボードもありますので、いずれにしてもGStreamerやその他の方法での対応が必要となるかもしれません。

ビルド方法

前述のリファレンス環境におけるビルド方法については、以下のページにまとめてあります。

https://github.com/mozilla-japan/meta-browser/wiki/Build-RZ-G1E-Yocto2.0

CanvasやWebGLの有効化については、それぞれ以下の設定を追加する必要があります。

~/.mozilla/firefox/xxxxxxxx.default/user.js:

user_pref("gfx.canvas.azure.accelerated", true);
user_pref("webgl.force-enabled", true);

他のボードでも類似の方法でビルドできるかもしれませんが、相応の対応が必要と思われます。

デモ動画

ミラクル・リナックス社がYouTubeでデモ動画を公開して下さっています。

まとめ

Gecko Embeddedプロジェクトと現在のステータスについて紹介しました。組み込みLinux上のFirefoxでもハードウェアアクセラレーションを有効化して、実用的なパフォーマンスを発揮できることは確認できていますが、安定化や、さらなるパフォーマンス改善、他のSoCのサポートなど、やるべきことはまだまだ残されていますので、興味がある方は協力して頂けるとありがたいです。問題を発見した場合はGecko EmbeddedプロジェクトのIssueページに報告して下さい。

この記事の続き

2017-07-06

OSS on Azure 非公式コミュニティ #5 『Azure Database』勉強会：MySQLとPostgreSQLと日本語全文検索 - Azure DatabaseでMroonga・PGroongaを使いたいですよね！？ #AzureDB

品川のマイクロソフトさんのオフィスに行ったのはRubyHiroba 2013以来な気がする須藤です。

db tech showcase OSS 2017の懇親会でAzure Database for MySQL / PostgreSQLというセッションがありました。Azure DatabaseでMroonga・PGroongaを使えるようになったりしませんか！？と聞いてみたところ、「月末にAzure Databaseを開発している人がくるAzure DatabaseのイベントOSS on Azure 非公式コミュニティ #5 『Azure Database』勉強会があるので、そこでMroonga・PGroongaを紹介すると話が進むかも！？」ということだったので紹介してきました。

MySQLとPostgreSQLと日本語全文検索 - Azure DatabaseでMroonga・PGroongaを使いたいですよね！？

内容

この発表では次のことを紹介しました。

Mroonga・PGroongaが高速なこと
Mroonga・PGroongaはMySQL・PostgreSQLユーザーなら簡単に使えること
Mroonga・PGroongaはWindowsでも動くこと
PGroongaではJSON内のテキスト全部を全文検索できること
PGroongaでは簡単に入力補完を実現できること

話の最初と最後でAzure DatabaseでMroonga・PGroongaを使いたい人はどのくらいいるか聞いてみました。最初は1割くらいでしたが最後は半分くらいの人が使いたい気持ちになっていました。Azure Databaseの開発をしている方は持ち帰ってチームで検討すると言っていました。Azure Database for MySQL/PostgreSQLは今はまだプレビュー期間中ですが、一般公開時にはMroonga・PGroongaをサポートしているかもしれません。Azure Database for MySQL/PostgreSQLでMroonga・PGroongaを使いたい方はぜひAzure Databaseのサポートに「Mroonga・PGroongaを使いたい！」とフィードバックしてください。

まとめ

Azure DatabaseがMySQLとPostgreSQLをサポートしようとしています。どちらも現状では日本語全文検索が苦手ですが、Azure DatabaseがMroonga・PGroongaをサポートすれば日本語全文検索が得意なDBaaSになります。まだMroonga・PGroongaをサポートすることになったわけではないので、Azure DatabaseでMroonga・PGroongaを使いたい方はサポートにフィードバックしてください。

おしらせ

8月1日（火）14:00-16:00にMySQL・PostgreSQL上で動かす全文検索エンジン「Groonga」セミナーを開催します。Mroonga・PGroongaを検討しているという方はぜひこの機会をご活用ください！

2017-07-19

第115回 PHP勉強会＠東京：PHPでPostgreSQLとPGroongaを使って高速日本語全文検索！ #phpstudy

はじめてまともにPHPを書いた須藤です。

第115回 PHP勉強会＠東京で「PHPでPostgreSQLとPGroongaを使って高速全文検索！」という話をしました。

PHPでPostgreSQLとPGroongaを使って高速日本語全文検索！

内容

PGroongaを使えばPHPで簡単にリッチで高速な全文検索システムを作れるよ！ということを伝えたかったので、実際にPHPで「PHPのドキュメントを全文検索するシステム」を作ってそれを紹介しました。詳細はスライドで説明していますが、次のような機能があります。

探したいものが見つかる高速全文検索機能（基本機能）
- 公式ドキュメントの検索は関数やクラス名の検索のみで説明文では検索できない
- Google custom searchを使ったサイト内検索機能は一般的な文書の検索に特化しているため、PHP固有の「@」で「エラー制御演算子」を検索することができない（英語として検索すると「at sign」でヒットする）
キーワード周辺のテキストをハイライト（基本機能）
入力補完（基本機能）
- ローマ字でも入力補完可能（リッチな機能）
  - 例：「seiki」→「正規表現」

サービスとしては動かしていないのですぐに試せませんが、ソースコードはフリーソフトウェアとして公開しているのでローカルで動かすことができます。動かし方のドキュメントは書いていませんが、標準的なLarabelの使い方だと思っているので、Larabelを使ったことがある人なら動かせるのではないかと思います。

私はこれまでまともにPHPを書いたことがありませんでしたが、3日で実装できました。簡単にリッチで高速な全文検索システムを作れることが示せたのではないかと思います。

おねがい

このイベントのために作ったPHP document searchですが、PHPユーザーにとって有用なサービスになるのではないかと思うので、だれかサービスとして運用したり、メンテナンスしたりしませんか！？私は日常的にPHPを書くことはないのでサービスとして運用する予定はないのですが、技術的なサポートはするつもりです。

興味がある方はissueで連絡してください。

まとめ

PHPユーザーにPGroongaを紹介する機会があったのでPHPのドキュメントを検索するPHP document searchを作ってそれを元にPGroongaを紹介しました。PHP document searchの運営者・メンテナーを募集しているので、ぜひご連絡ください！

おしらせ

8月1日（火）14:00-16:00にMySQL・PostgreSQL上で動かす全文検索エンジン「Groonga」セミナーを開催します。PGroongaを使いたくなった人はぜひこの機会をご活用ください！

この記事の続き

2017-10-10: PHPカンファレンス2017 - PostgreSQLとPGroongaで作るPHPマニュアル高速全文検索システム - OSS Gate東京ワークショップ #phpcon2017

2017-07-20

TravisCI上で複数のLinuxディストリビューションのテストをする方法

クリアコードでは、独立行政法人情報処理推進機構（IPA）平成20年度オープンソフトウェア利用促進事業「迷惑メール対策を柔軟に実現するためのmilterの開発」の一環としてmilter managerの開発を行なって以来、milter managerの開発を継続しています。最初のコミットを見ると2008年9月1日なので、約9年開発を続けています。

milter managerは、記事執筆時点では以下のLinuxディストリビューション向けにパッケージを作成しています。

CentOS 6
CentOS 7
Debian Jessie *1
Debian Stretch
Debian Buster
Debian Sid
Ubuntu 14.04 LTS
Ubuntu 16.04 LTS
Ubuntu 16.10
Ubuntu 17.04

CentOS 7以外はi386とx86_64(amd64)向けのパッケージをビルドして提供しています。*2 以前はTravisCIのrvmを使ってRubyのバージョンだけを切り替えてテストしていましたが、パッケージを提供するという観点で考えるとTravisCIの動かしているUbuntu 14.04やUbuntu 12.04だとRubyだけ切り替えてもmilter managerが依存しているGLib等のライブラリのバージョンの違いについてはテストできていおらず不十分でした。開発を続けていくためには、サポートしているディストリビューションできちんと動作することを確認することが重要です。提供しているパッケージでは、それぞれのディストリビューションごとに1つのRubyバージョンをサポートしているので、CIでもそのようなテストを実行するべきです。

そのようなテストを実行するためには、TravisCI上で複数のディストリビューションを切り替えてテストを実行する必要があります。調べてみたところ、TravisCI上ではDocker Compose | Docker Documentationを使えることがわかりました。またDocker Hubを確認すると、それぞれのディストリビューションのOfficialイメージがありました。

これで材料は揃ったので、あとはどうやって.travis.ymlとdocker-compose.ymlとDockerfileを書いていくか考えるだけです。

Dockerfileはビルド環境を整えるところまでやることにしました。実際のビルドまでDockerfileでやってしまうと、ビルド環境が整っていなかった場合の修正に時間がかかるためです。また、milter managerのソースコードはTravisCIのホスト上にあるのでそれをそのまま使うことにしました。ローカル環境でイメージを作るときは、カレントディレクトリ以下のファイルを全てCOPYするので新規にgit cloneしてやった方がよいです。

FROM debian:sid

ENV CODE_NAME=unstable

RUN apt-get update && \
    apt-get install -qq -y \
      debhelper dh-systemd autotools-dev \
      libglib2.0-dev libev-dev ruby ruby-dev ruby-gnome2-dev ruby-test-unit-rr \
      intltool lcov git libtool sudo lsb-release apt-transport-https \
      rrdtool rsyslog && \
    curl -L https://raw.github.com/clear-code/cutter/master/data/travis/setup.sh | env CUTTER_MASTER=yes sh && \
    gem install --no-rdoc --no-ri coveralls-lcov && \
    gem install --no-rdoc --no-ri pkg-config && \
    useradd -m --user-group --shell /bin/bash milter-manager

WORKDIR /home/milter-manager/milter-manager
COPY . .
RUN chown -R milter-manager:milter-manager .
USER milter-manager

docker-compose.ymlは特に工夫したところはありません。無限に待ち続けるためにコマンドをtail -f /dev/nullにしたくらいです。 Dockerfile-*と連携してビルド環境を整えるところまでを意識しています。また、対応するディストリビューションが増えたときもコピペで簡単に増やせるようにしました。

version: "2"
services:
  ubuntu-trusty:
    build:
      context: .
      dockerfile: dockerfiles/Dockerfile-ubuntu-trusty
    command: tail -f /dev/null

  ubuntu-xenial:
    build:
      context: .
      dockerfile: dockerfiles/Dockerfile-ubuntu-xenial
    command: tail -f /dev/null
# ... 以下同じような内容が続くので略

.travis.yamlではmatrixを使って環境変数でテストを実行するコンテナを制御しました。 matrixのTARGET_DISTRIBUTIONの行を増やせば、対応するディストリビューションを増やせるようにbefore_script:以降を調整しました。ディストリビューションごとのパッケージの依存関係はDockerfileで解決し、Rubyのバージョンの違いや依存ライブラリのバージョン違いはautotoolsなどを使って解決しています。そのため.travis.ymlの内容はとてもシンプルになっています。

ただし、CentOS6だけは利用しているRubyも自分でビルドしたsuffix付きのものを使っているのでconfigureのオプションが異なっています。*3

dist: trusty
sudo: required
notifications:
  email:
    recipients:
      - milter-manager@ml.commit-email.info

services:
  - docker

env:
  global:
    DOCKER_COMPOSE_VERSION: 1.8.1
  matrix:
    - TARGET_DISTRIBUTION=ubuntu-trusty
    - TARGET_DISTRIBUTION=ubuntu-xenial
    - TARGET_DISTRIBUTION=ubuntu-zesty
    - TARGET_DISTRIBUTION=debian-stretch
    - TARGET_DISTRIBUTION=debian-buster
    - TARGET_DISTRIBUTION=debian-sid
    - TARGET_DISTRIBUTION=centos6 EXTRA_CONFIGURE_OPTIONS="--with-ruby=/usr/bin/ruby2.2 --with-bundled-ruby-glib2"
    - TARGET_DISTRIBUTION=centos7

before_install:
  - sudo rm /usr/local/bin/docker-compose
  - curl -L https://github.com/docker/compose/releases/download/${DOCKER_COMPOSE_VERSION}/docker-compose-$(uname -s)-$(uname -m) > docker-compose
  - chmod +x docker-compose
  - sudo mv docker-compose /usr/local/bin/

before_script:
  - docker-compose build ${TARGET_DISTRIBUTION}
  - docker-compose ps
  - docker-compose up -d ${TARGET_DISTRIBUTION}
  - docker-compose exec --user root ${TARGET_DISTRIBUTION} rsyslogd -f /etc/rsyslog.conf
  - docker-compose exec ${TARGET_DISTRIBUTION} ./autogen.sh
  - docker-compose exec ${TARGET_DISTRIBUTION} ./configure --enable-coverage --with-default-connection-spec="inet:10025@[127.0.0.1]" ${EXTRA_CONFIGURE_OPTIONS}
  - docker-compose exec ${TARGET_DISTRIBUTION} make

script:
  - docker-compose exec ${TARGET_DISTRIBUTION} ./binding/ruby/test/run-test.sh
  - docker-compose exec ${TARGET_DISTRIBUTION} ./test/run-test.sh

after_success:
  - docker-compose exec ${TARGET_DISTRIBUTION} lcov --compat-libtool --directory . --capture --output-file coverage.info
  - docker-compose exec ${TARGET_DISTRIBUTION} coveralls-lcov -v coverage.info

これでTravisCI上では一つのディストリビューションあたり7分から10分程度でテストが実行できるようになりました。トータルでは40分から60分程度かかります。 TravisCI上の実行時間の制限は、1ジョブあたり*450分なので特に問題ありませんでした。

導入してよかったこと

実際に、UbuntuやCentOSの新しいバージョンをサポートするときに、依存するライブラリのバージョンが開発環境であるDebian Sidと異なっていることが原因で修正が必要になることがありました。直近では、Ubuntu 17.04に対応するためにGLib2.52.0以降に対応しました。この対応をした時点では、Debian SidのGLibは2.50.xでした*5。

Ubuntu 17.04対応をしようとして、CIに新しいディストリビューションを追加したところ、Ubuntu 17.04だけCIに失敗したので対応が必要なことにすぐに気付くことができてとても便利でした。デバッグするときも、ローカルでdocker-compose up -d ubuntu-zesty && docker-compose exec ubuntu-zesty bash -iとしてほぼコンテナ内で作業を完結させることができました。