Fluentd v0.14.xはFluentd v0.10.xのAPIがいくつか廃止されていて古いAPIを使っているプラグインが動作しなくなっています。また、他にも以下の観点でFluentd v0.14では使わない方がよい3rd party製プラグインが見つかっています。
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の検証のついでに、非推奨なプラグインのチェックも一緒にしてみてはいかがでしょうか。
クリアコードは、組み込みLinux向けにMozilla Firefoxのブラウザエンジンを移植するプロジェクトGecko EmbeddedをWebDINO Japan(旧Mozilla Japan)様と共同で立ち上げ、開発を進めております。Yoctoを使用してFirefoxをビルドしたりハードウェアアクセラレーションを有効化する際のノウハウを蓄積して公開することで、同じ問題に悩む開発者の助けになることを目指しています。
組み込みLinuxと一口に言っても、対象となるハードウェア及びソフトウェア環境は多岐にわたります。 しかし投入できる開発リソースには限りがあるため、当面のターゲットは以下の環境に絞っています。
GTK+を使用せずに直接WaylandあるいはDRMで描画するバックエンドを作成した方がより組み込み向けらしいとは言えます。しかし過去の事例から考えても、Mozillaが正式にサポートするプラットフォームから大きくかけ離れたバックエンドを作成すると、その後のバージョンアップに追従するコストが高くなり、やがてはメンテナンスされなくなっていく未来が見えてしまいます。このため本プロジェクトでは、少なくとも現段階ではGTK+を使用し、成果を本体へフィードバックしていくことで、バージョンアップに追従していくコストを抑えることを目指しています。
Firefoxは正式にはWaylandをサポートしていませんが、Red Hat社のMartin Stransky氏がWaylandへの移植作業を行っています。 Stransky氏のパッチはFirefoxの最新バージョンを対象としていますが、Gecko Embeddedプロジェクトではこのパッチを52ESRに移植した上で、安定化作業を進めています。 本プロジェクトで発見した問題や、作成したパッチはStransky氏に随時フィードバックしています。Stransky氏のWayland対応パッチは、徐々にmozilla-centralに取り込まれていっています。
暫定パッチを当てることにより、EGL/OpenGL ESを使用して以下のアクセラレーションを有効化できることを確認済みです。
ただし上記パッチは必ずしもWaylandやGTK+の描画機構に即した形にはなっておらず、いくつかの問題を抱えているため、本体へフィードバックする際には抜本的な見直しが必要です。また、CanvasやWebGLについては安定性の面でさらなる対応が必要です。
H.264の動画再生については、OpenMAX IL対応コードを追加することで動作を確認済みです。現在はまだ画像データのゼロコピーを実現できていませんが、これを実装することにより今後の性能改善が期待できます。
なお、一般的に、組み込みLinuxでの動画再生はGStreamerによって実装されますが、現在のFirefoxでは諸般の理由からGStreamer対応コードが削除されています。このため本体にコードを取り込んでもらえる可能性は低いですし、独自にGStreamer対応コードを保守するのもコストが嵩みます。一方でOpenMAX ILについてはFirefox OS用の類似のコードが残されており、保守が容易で本体へフィードバックできる可能性も高いため、現時点ではOpenMAX ILを使用する方法を選択しています。
ただし、将来的に他のボードへの対応を行う際には、OpenMAX ILコンポーネントを提供されていないボードもありますので、いずれにしてもGStreamerやその他の方法での対応が必要となるかもしれません。
前述のリファレンス環境におけるビルド方法については、以下のページにまとめてあります。
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ページに報告して下さい。
品川のマイクロソフトさんのオフィスに行ったのは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を紹介すると話が進むかも!?」ということだったので紹介してきました。
関連リンク:
この発表では次のことを紹介しました。
話の最初と最後で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を検討しているという方はぜひこの機会をご活用ください!
はじめてまともにPHPを書いた須藤です。
第115回 PHP勉強会@東京で「PHPでPostgreSQLとPGroongaを使って高速全文検索!」という話をしました。
関連リンク:
PGroongaを使えばPHPで簡単にリッチで高速な全文検索システムを作れるよ!ということを伝えたかったので、実際にPHPで「PHPのドキュメントを全文検索するシステム」を作ってそれを紹介しました。詳細はスライドで説明していますが、次のような機能があります。
サービスとしては動かしていないのですぐに試せませんが、ソースコードはフリーソフトウェアとして公開しているのでローカルで動かすことができます。動かし方のドキュメントは書いていませんが、標準的な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を使いたくなった人はぜひこの機会をご活用ください!
クリアコードでは、独立行政法人情報処理推進機構(IPA)平成20年度オープンソフトウェア利用促進事業「迷惑メール対策を柔軟に実現するためのmilterの開発」の一環としてmilter managerの開発を行なって以来、milter managerの開発を継続しています。 最初のコミットを見ると2008年9月1日なので、約9年開発を続けています。
milter managerは、記事執筆時点では以下のLinuxディストリビューション向けにパッケージを作成しています。
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
としてほぼコンテナ内で作業を完結させることができました。
実際にパッケージを配布する環境でCIを実行することで、パッケージ作成を始める前に問題に気付くことができる可能性が上がります。これによって、パッケージ作成及びリリース作業にかかる時間を抑えることができそうです。
またUbuntuなどの新しいバージョンに対応するための最初の一手がとても簡単になりました。