faultlineのGitHub連携機能をGH:Eに対応した / faultline-go をリリースした

faultline更新情報です。

faultlineのGitHub連携機能をGH:Eに対応しました

faultlineのGitHub連携機能をGitHub Enterpriseに対応させました。faultline v1.2.0 から利用可能です(ただ、バージョンアップされる方は最新にすることをおすすめします)

具体的には以下のURLに説明がありますが、GitHub連携の設定項目に新たに endpoint が増えました。

faultline/notifications.md at master · faultline/faultline · GitHub

GH:Eのホスト名が https://ghe.example.com だった場合は、指定するendpointは https://ghe.example.com/api/v3 になります。

faultline-go をリリースしました

周りでGoのエラートラッキングのニーズが高まっていたのと、少しづつGoがわかるようになってきたので、faultline-goをgobrakeからフォークして作成しました。

github.com

注意点として、 faultline-go の利用のためには faultline本体を v1.3.0 以上にする必要があります 。(原因はスキーマ設定のミスです🙇)

今後faultlineでやりたいこと

faultlineは一度デプロイするとずっと稼働できてしまうので、更新をサボりがちになりますね。。。

現時点でやっていきたいなと思うのは

  • faultlineのNodeバージョンのアップデート
  • 各言語用のライブラリのアップデート
  • バックエンドで活用しているDynamoDB AutoScalingのサポート
  • faultline自体のステータス監視

などです。ここらへんを今まで同様に「運用レス」ファーストでやっていきたいと思っています。

どうぞよろしくお願いします。

asciinema / asciicast2gifでターミナルのアニメーションGIFをつくる

ターミナルでのコマンド実行のアニメーションGIFを作るとき、自分はasciinemaとasciicast2gifを使っています。

github.com

github.com

ターミナルのアニメーションGIFを作るツールはいろいろありますし自分でも試したのですが、今のところ使い勝手が良いのと出力されるGIFが良い感じなのでこれらに落ち着いています。

使い方

asciinemaをインストール

MacであればHomebrewでインストール可能です

$ brew install asciinema

それ以外だと pip でインストールすることになります

$ sudo pip3 install asciinema

asciinemaはDockerも用意されていてそちらも利用可能なのですが、自分は手元のコマンド環境を録画することが多いのと、自分でカスタマイズしたターミナルのままで録画したいので直接インストールしてしまいます。

asciinemaで録画

asciinemahttps://asciinema.org にアップロードされる想定で作られていますが、今回は使いません。asciicastというファイルフォーマットで出力する形で録画をします。

以下のコマンドで録画が開始されます。

$ asciinema rec mycli.cast

Ctrl-Dexit で録画が終了します。mycli.cast というファイルが出力されているかと思います。

asciicast2gifでGIFに変換する

asciicast2gifもDockerが用意されているので、こちらはDockerで実行します。

$ docker run --rm -v $PWD:/data asciinema/asciicast2gif mycli.cast output.gif

オプションも充実しているので、速度やサイズなどを調整します。

これで終わりです。

では実際の流れを見てみましょう

インストールからアニメーションGIF作成まではこんな感じです。

f:id:k1LoW:20180501001604g:plain

実際にできたアニメーションGIFはこんな感じです。

f:id:k1LoW:20180501001547g:plain

という感じに asciinemaの録画をasciinemaで録画できるくらい優秀なので 是非使ってみてください。

cgroupの状況を確認するコマンドcgrpsを作った

  • cgrps v0.5.0 から cgrps ps コマンドは削除しました
  • cgroup / cgroups 問題について下記に追記しました。それに伴いタイトルと文章も修正しました。

以前のエントリで書いたようにcgroupの状況を確認するコマンドはあります。

k1low.hatenablog.com

ごく普通のcgroupsの使い方であれば上記エントリにある systemd-cgtop systemd-cglslscgroup などで十分です。

しかし、 たまたまなのですが 私が関わっているプロダクト ではコンテナをフル活用しているためcgroupが大量に作成されることがあり、systemd-cgtop などではなかなか厳しいことになってきていました。

また、同じcgroup階層のサブシステムの状況は「同じグループとして」確認したいという気持ちもありました。

cgrps

というわけで、cgroupとGoの勉強がてらに cgrps というコマンドを作ってみました。

github.com

img

cgrps は以下のような特徴があります

  • cgroupの各サブシステム内の同じ階層(例えば /sys/fs/cgroup/cpu/my-cgroup-name/sys/fs/cgroup/memory/my-cgroup-name )を同じグループとしてまとめる
  • 状況を確認できることに特化して、cgroupの操作系はない

使い方

基本的に peco などのフィルタリングコマンドとの併用を想定しています。

例えばあるcgroupで動いているプロセスを確認したいときは

$ cgrps ps $(cgrps ls | peco)

とすると peco でcgroupを絞り込んで確認ができます。

当然、cgroupの階層がわかっていれば

$ cgrps ps /my-cgroup-name

としても確認可能です。

現在は cgrps ls cgrps ps cgrps stat がありますが、今後はそれぞれの機能拡張( cgrps stat も対応サブシステムが少ない )に加えて、 cgrps top が欲しいです。あとJSON出力ですね。

勉強にちょうどいい。

余談

cgroupはファイルシステム

開発当初は https://github.com/containerd/cgroups を使っていたのですが、表示したいものを作っていくうえで痒いところに手が届かない感じだったので(そもそも使い方が違う)、結局最後は /sys/fs/cgroup 内のファイルを直接見にいく形に変更しました。

CLK_TCK

udzuraさんの便利エントリにもあるように cpuacct.stat の値を秒単位で表示するためには クロック/秒 を知る必要があります。これをcgoを使わずにどうやって取得しようかなと考えたのですが、getconf というコマンドがだいたいのディストリビューションにあることを知って、採用させていただきました。

github.com/shirou/gopsutil ++

RedHatの資料がかなり充実している

ギョーム中にpyamaさんに教えてもらいました。

リソース管理ガイド - Red Hat Customer Portal

ギョーム中もcgrpsを作っている間もずっとにらめっこしてました。

というわけで

なかなか使う機会はないかもしれませんが、cgroupsの勉強などに是非。

ところでcgroupsなのかcgroupなのか。。。 解決しました!

cgroupの状況を確認するコマンドcgrpsを作った - Copy/Cut/Paste/Hatena

便利感ある / cgroup(s?) の問題は <a href="http://tenforward.hatenablog.com/entry/20160425/1461583475" target="_blank" rel="noopener nofollow">http://tenforward.hatenablog.com/entry/20160425/1461583475</a> などご参照のこと

2018/04/26 13:02
b.hatena.ne.jp

JAWS-UG福岡#6 でロリポップ!マネージドクラウドについて発表した #mclolipop

JAWS-UG福岡:6度目もちょっと濃い目にAWSの話をしてみよう というAWSなイベントでマネージドクラウドの発表をさせてもらいました。

もともと自分はAWSをよく使っていて、いろいろなツールを作っていたこともあって、JAWS-UG福岡の中の人たちにはお世話になっていましたが、今回も「面白ければ良い」ということで発表の機会をもらえました。ありがとうございます!

さらにロリポップ!マネージドクラウド正式版リリース最速での発表を「一番最後にJOINした」自分が話すという、完全に「いいところをかすめとった」感じになっていて、ちょっと申し訳ない気持ちも。

せっかくの新参なので、外から見ていたマネージドクラウド(の理解とその誤解)と、実際のマネージドクラウドとのすり合わせができて価値が理解できるような資料を作るよう心がけてみました。

結果、様々な疑問・質問やフィードバックをもらうというありがたい状況になり、発表して良かったなと思いました。JAWS-UG懐デカい。

(このあと懇親会ではさくらインターネットの方とも濃い話ができて嬉しいことに)

より、もっとわかりやすくしていくのは今後の課題です!

ありがとうございました!

ロリポップ!マネージドクラウドのチームメンバーとして正式版リリースに参加できた #mclolipop

今日マネージドクラウドの正式版リリースがされました。

mc.lolipop.jp

前々から(使う側として)目をつけていたサービスの開発チームにまさかJOINできるとは思っていませんでした。

たった1ヶ月半で、何も知らないところから、技術面にもビジネス面にもいろいろ関わらせてもらい、新しい挑戦も さらに失敗まで 経験することができました(当然チームメンバーのリカバーがありました)。

本当に濃すぎる。

これからやりたいことももっと良くするためにやるべきこともたくさんあります。

マネージドクラウドも、今でも「使える」「楽ができる」良いサービスですが、アーキテクチャを知っている立場からすると、実はまだまだ追加で面白くできそうな要素があります。

自分ですら思うのですから他のメンバーはもっと思っているでしょう(逆に収束させるのが難しいくらいで困る)。

新しい技術だから夢が広がるのはしょうがない。

ところで

マネージドクラウドは従来のレンタルサーバとも従来のクラウドとも違います。

レンタルサーバーとクラウドのいいとこどり」

どんなサービスなのか「使う側」として知りたいとは思いませんか?

当然、マネージドクラウドを構成しているのは「技術」ですから得意な領域はありますし不得意な領域もあるかもしれません。

というわけで、AWSVPSをずっと使ってきた自分が「クラウドな言葉で」マネージドクラウドの説明に挑戦します(アウェーなのに機会をもらって本当に嬉しいです。宣伝とかではなく絶対に知りたいことを伝えられるように頑張ります)。

jaws-ug-kyushu.doorkeeper.jp

というわけで、ロリポップ!マネージドクラウド、リリースしました!

cgroupの状況を確認する便利コマンドは存在した

cgroupの状況を確認するのに以下のコマンドが使えることを知りました

systemd-cgtop

名前の通りcgroupごとにグルーピングしてtopコマンドみたいにCPU, Memory, Block IO usageを確認することができます

f:id:k1LoW:20180409225537p:plain

systemd-cgls

こちらもcgroupごとにグルーピングして表示してくれます

f:id:k1LoW:20180409225550p:plain

なぜ知ることができたのか

cgroupごとのCPU利用率とかカジュアルに知りたいなと思って @udzura のとてもわかりやすいエントリを見ながら、「必要そうだから作ってみるかなー」と思って思いついた名前が「cgtop」で、「あ、なんかありそう。よく考えたらむしろ存在しないほうがおかしい。」と思って「cgtop」でググったらありました。

参考URL

udzura.hatenablog.jp

gentoo.hatenablog.com

qiita.com


これで今日もいろいろ進みそう

mod_mrubyとngx_mrubyのRPMリポジトリをpackagecloudに作った

マネージドクラウドのチームにJOINして、1ヶ月たちました。

ツイートから周りからは「楽しそうですね」と勘違いされているようですが、アーキテクチャや技術スタックのキャッチアップに大変な毎日を送っています。楽しいです。

Webサーバに機能を追加するということ

ところで、広く知られていることですが、マネージドクラウドではngx_mrubyがかなり活用されています。

何をもって活用されていると言えるのかは要出典ですが、NGINXが単なるWebサーバではなく「別の機能を持った何か」に見えるくらいには使われています。

「Webサーバに機能を追加する」という感覚は一般的なWebアプリケーションの上で生きてきた自分としては新鮮で、「最近のフレームワークは例えばMiddlewareというような階層構造で機能を付与するものがあるが、その一部をさらにその外に移譲しても良いんだ」という面白さがありました。

思えば、AWSでサーバーレスアーキテクチャを構築する上でも、機能を

  • CloudFrontのLambda@Edgeに持たせるのか
  • API Gatewayに持たせるのか
  • HTTPリクエストから発火したAWS LambdaのFunctionに持たせるのか
    • さらにそのFunction内のmiddyで多層化されている
  • はたまたバックのDynamoDBのストリームからイベント発火したAWSLambdaに持たせるのか

と、機能を持たせる場所というのがシステム全体のアーキテクチャを考える上で重要で、できれば選択肢が多いほうがより構成の選択肢が増えるのは実感としてわかっていました。

「もしかして、これは、そこまで規模の大きくないWebアプリケーションを開発する上でも、アーキテクチャとして『Webサーバに機能を追加する』という選択肢を持っていたら強いのでは?」

と思って、PHPカンファレンス福岡2018に「プログラマブルWebサーバ -Webサーバに機能を追加してみよう-」というタイトルで応募しました。

そして、不採択でした。残念。

mod_mruby / ngx_mrubyというレイヤー

mod_mrubyやngx_mrubyというレイヤー、GMOペパボではMiddleware Configuration as Codeと呼ばれて活用されています。

なんだか新しい、とっつきづらいもののように聞こえるのですが、作者の @matsumotory から聞いてちょっとおもしろかったことがあります。

mod_mrubyのApacheへの組み込まれ方は、実はmod_phpと同じだそうです。

Apacheが実行する(主に)Webアプリケーション用のインタプリタとして使われることを目的としているのか、Apacheの処理のさまざまな箇所でフックやフィルタように動かす用のインタプリタとして使われることを目的としているのかの違いだけです。

「mod_phpと同じだ」とか、途端に親近感がわきます。

とはいえ自前ビルドは技術採用のハードルになる

mod_mrubyもngx_mrubyもApacheやNGINXに組み込みます。

そうすると、「Webサーバも自前ビルドなのか?」「そうでなくてもmod_mrubyやngx_mrubyも自前ビルドなのか?」となり、運用を考えると躊躇してしまいます。

自前ビルドより yumapt-get を使いたいです。よね?

そういったわけでRPMリポジトリを作ってみました。

作ったRPMリポジトリ

今回作ったRPMリポジトリの要件は以下です。

  • ターゲットはCentOS7とCentOS6
  • ApacheCentOS公式のRPMリポジトリhttpd、NGINXはNGINX公式のRPMリポジトリのnginxが使えること
    • かなり重要。今運用しているシステムの構成に追加採用できる可能性が飛躍的にあがる
  • 全自動でhttpd、nginx、mod_mruby、ngx_mrubyのリリースを検知し、その組み合わせのRPMをビルドし使えるようにすること
    • パッケージメンテナの負荷をゼロに。RPMリポジトリがなくならない限り更新されていきます。

そのために、mod_mrubyとngx_mrubyの以下の機能をあきらめています。

  • mrbgemの追加ビルド
  • ngx_mrubyのTCPロードバランシング機能

mrbgemについては、もう少し知見が溜まったら、ゴールデンAMIならぬ「ゴールデンビルド」を決めてリリースしようと思います。

ngx_mrubyのTCPロードバランシング機能については、現時点ではNGINX自体のビルドオプションを変える必要があるため、なかなか難しそうです。

それでも十分強力なので、それなりの意義があると思っています。

作ったRPMリポジトリは以下です。

packagecloud.io

packagecloud.io

使い方

よくある外部RPMリポジトリの利用と同様に、RPMリポジトリの登録とインストールの2STEPになります。

RPMリポジトリの登録

packagecloud の機能をフル活用しているので、

mod_mrubyの場合は

$ curl -s https://packagecloud.io/install/repositories/k1low/mod_mruby/script.rpm.sh | sudo bash

ngx_mrubyの場合は

$ curl -s https://packagecloud.io/install/repositories/k1low/nginx-module-mruby/script.rpm.sh | sudo bash

で終わりです。

インストール

mod_mrubyの場合は

$ sudo yum install mod_mruby

ngx_mrubyの場合は

$ sudo yum install nginx-module-mruby

で終わりです。

モジュールの有効化

Apacheの場合は、confに

LoadModule mruby_module modules/mod_mruby.so

NGINXの場合は、eventディレクティブの前に

load_module modules/ndk_http_module.so;
load_module modules/ngx_http_mruby_module.so;

と追記すれば有効化されます。あとは使うだけです。

簡単ですね!

作ったときのはなし

以下は特に読む必要はないはなしです

実際に動いているCIのスクリプトは以下のリポジトリになります。

github.com

github.com

RPMパッケージを作るだけなのにそれなりに大変でした。

CentOSのGitやRubyのバージョンが古くて辛い

Rubyのバージョンが古くてpackage_cloud.gemがインストールできなかったり、Gitが古くてCircleCIがまともに動かなかったり、全然本流とは違うところで躓くことに。

そこはTwitterでCircleCIマスターの @kunit から直球の解法を教えてもらって、なんなく解決できました。ありがとうございました!

フィードフォースの皆さんありがとうございます!

CircleCIのScheduled Workflowが最高

今回作ったRPMリポジトリの「全自動化」はCircleCIのこの機能を知っていたからなのですが、もう最高です。

circleci.com

ようはcronでビルドを定期実行してくれるという機能です。うまく .circleci/config.yml を書ければいろいろな用途に使える機能なのでオススメです。

モジュールの利用にもSELinuxのポリシー設定が必要

RPMリポジトリからモジュールをインストールするだけではダメで、そのモジュールに適切にSELinuxのポリシーを設定する必要があるということを知りました。

/var/log/audit/audit.log を見たり、audit2allow で必要ポリシーを見つけたり、 ls -Z で他のモジュールとポリシーを比較したり、少しはSELinuxと仲良くなれたかもしれません。

NGINXのダイナミックモジュールのロードにはApacheのモジュールよりも一手間以上が必要

ngx_mrubyのダイナミックモジュールについては、ほぼ以下の記事で完結しています。本当にお世話になりました。

medium.com

実際に自分で手を動かしてみると、本当に面倒でした。

Dockerのバグ?にあたる。そしてCircleCIでは治っていない

やろうとしていたことはmod_mrubyのRPMビルドのために centos/7 イメージでhttpd-develを入れようとしただけなのですが、依存関係にあるhttpdがインストールされるときにエラーになるというものでした。

これは実は既に解決された問題のようで、ホストOS側のUbuntuでのAUFSの問題だったようです。

普通なら「じゃあホストOSのUbuntuを最新にしようか」ということになるかと思いますが、CircleCIのホストOSをいじれるわけはなく、仕方なくhttpdソースコードを取ってくるという形に変更しました。


たった2つのRPMリポジトリを実現するためだけに、なかなか大変でした。

リポジトリのパッケージ管理者の方には頭が上がりません。

なお

このRPMリポジトリの成果の一部はGMOペパボ福岡の有志開発合宿で作成されたものです。