NetAPPのquotaを自動で適用するデーモンを開発した@福岡Ruby会議

皆さん!福岡Ruby会議02楽しんでますか!? 僕はというもののCFP期限を逃し、全く何も生み出していないので、セッションの合間にデーモンを書いていました。 NetAPPではqtreeやVolumeに対してファイル数やディスク容量のクォータを設定することが出来ますが、クォータを設定するだけでは有効にならないので、一度クォータをVolume単位でOFF,ONして上げる必要があります。 今回開発したデーモンを利用すると、指定秒数間隔でクォータをOFFし、指定秒数間隔でクォータがONされます。それぞれの処理はgoroutineで並列実行されるため、300秒間隔で、OFFし、10秒間隔でONするようにすると実質5分毎にクォータが有効になるような実装です。 例外時は停止するよりも通知だけ行い、処理は継続すべきと考え、エラーログを出力し、Slack通知だけして処理は継続する設計です。実運用時はsystemdなどと組み合わせて利用するのがよいと思います。 このあとは @k1LoW さんと @matsumotory

More

パッケージの脆弱性管理サービスVeetaをリリースしました

キャプチャ

以前より個人で開発していたパッケージ脆弱性管理サービスVeetaをリリースしました。 現状はAWSで個人資金にて運用しているため、1オーガニゼーション5台までの制限がありますが、無料で利用できます Veetaのアーキテクチャは下記の通りです。 利用方法は、ドキュメントにも記載がありますが、以下の手順ですぐに始めることができます。 オーガニゼーションを登録する 認証トークンを発行する クライアントをインストールし、認証トークンを設定する この作業を行うだけで、クライアントであるVazがサーバ内のパッケージ情報を取得し、Veetaにアップロードし、自動的にスキャンしてくれます。 スキャンした結果はVeetaのコンソール上で確認することができ、脆弱性の詳細を確認したり、無視することができます。また、脆弱性の有無はレポート機能でメールやSlackに指定した時間に通知することが可能です。 解決したかった課題 以前よりペパボでは一部でVulsを利用して脆弱性の管理を行っておったのですが、Vulsには以下の課題がありました。 スキャンユーザーでのSSHログイン設定が必要、もしくはローカルスキャンの環境作成が必要、ディープスキャンを行うには特権が必要 Vulsはパッケージのドキュメント(changelog)をパースして、 CVE-xxxxxxxの文字列を拾っているだけで、必ずしも脆弱性の有無をチェックしているわけではない 追記 vulsはv4.0でバージョンでの比較にも対応しているようです!@kotakanbeさん有難うございます! Vuls開発者の神戸です。v0.4.0でバージョン比較での検知に対応してます。誤解を生まぬよう修正お願いします" Vulsはパッケージのドキュメント(changelog)をパースして、 CVE-xxxxxxxの文字列を拾っているだけで脆弱性の有無をチェックしているわけではない — Vulsのちょんまげ (@kotakanbe) November 1, 2017 引用元: https://github.com/future-architect/vuls/blob/master/README.ja.md#fast-scan 特に、複数サービスを運用するペパボではサーバの権限管理の観点から共有ユーザーに特権を与えるような運用は厳しい現状がありました。それを解消すべく、今回はクライアントサーバ方式を採用しています。 またVeetaのスキャン方式は取得したパッケージのバージョンとCVEデータベースの情報を全件チェックしているため、Vulsと比べて脆弱性の検知の精度が高い設計です。まだサービス導入期なのでサーバ台数は比較的少ない状態ですが、今後の利用者増加に合わせてスケールアウト可能な構成にしています。 追記 VulsはOVALの対応も行われていたため、いま時点ではVulsのほうが検出精度が高い場合が多いです。この機能はVeetaでも実装したいと思います。 あと、これ事実ですか??VulsはOVALも併用して使ってるので信じがたいっす。。“CVEデータベースの情報を全件チェックしているため、Vulsと比べて脆弱性の検知の精度が高い設計です — Vulsのちょんまげ (@kotakanbe) November 1,

More

builderscon Tokyo 2017で圧倒的な敗北をもらって来た

8/4〜8/6にかけてbuilderscon Tokyo 2017にスピーカーとして参加させていただきました。当日話した資料については下記の通りです。 今回はmrubyの言語そのものの魅力と、僕たちが実装し、運用している内容について紹介させていただきました。 発表後、いくつかの質問や、Twitterでも質問をいただきすごく嬉しかったです。 一方で、今回の登壇は自分の現実をいい意味でフィードバックもらえる機会だったなと感じています。 具体的には当日全く集客ができませんでした。 会場としてはメインホールをいただいており、この上ない状況だったのですが、自身の実力がたりず、会場の10分の1も埋められていなかったのではないかなと思います。 こればっかりは当日にはどうすることもできない話ではあるのですが、つまるところ、その前段で、日常的にいかにアウトプットして、世界にインパクトを与え続けられているということが実践できてないのだなと感じました。 これまで積んで来たもので、それなりのステージに立てるようにはなって来たものの、まだまだ広く認められるというレベルには全く至っていないので、胡座をかくことなく、コードでも文章でもアウトプットし続けなければならいと身が引き締まりました。 僕はベストスピーカーの土俵にすら立てなかったので、また来年、強くなって帰ってこようと思います。 ここまでがスピーカーとしての話で、参加者としては、海外からのゲストスピーカーを始め、非常に幅広いテーマでこのカンファレンスでしか聞けない!!!という話しが多くあり非常に楽しく過ごすことができました。 個人的な話にはなるのですが、ペパボの縁がありつつも、会えそうで会えなかったmizzyさんとお会いし、さらには晩御飯をご馳走になったり、現在進行形で執筆を進めさせていただいている技術評論社の@inaoさんにダイレクトに原稿の催促をいただくなど、東京のカンファレンスだからこそ味わえる体験をさせていただきました。 ついに会ってしまった2人…! pic.twitter.com/y3Lzjyh3Wr — Shinya Tsunematsu (@tnmt) August 3,

More

YAPC::Fukuoka 2017 HAKATAでロリポップのAPIについてトークしてきた

僕にとって、YAPC::Fukuoka 2017 HAKATAは非常にロングランで濃いものだった。まずは前日に自社のオフィスで開催された、全然野菜に始まる。 これは元々同僚である @hsbt さんが社のSlackで下記の投稿をしたことから全てが始まった。 現在ペパボ@福岡はオフィス改装中で、ペパステというステージを設けて、登壇イベントをパッケージングしているのでほとんど準備することなく飲み物の準備をするくらいで、当日 #全然野菜 がバズるくらいには盛り上がって大変良かった。 YAPC::Fukuoka 前々夜祭(非公式) きた、ペパステという空間がおしゃれ #全然野菜 #yapchttps://t.co/lrA4cM89lL pic.twitter.com/vk1nglSPiE — うずら (@uzulla) 2017年6月30日 その後は公式の前夜祭に移動し、 @udzura が酔って変なテンションになりながらも、Perlと称してClangのライブコーディングをやり遂げるさまを眺めたりしていた。 こんにちは〜 pic.twitter.com/zpXDzk926t — SHIBATA Hiroshi (@hsbt) 2017年6月30日 そんなこんなでLTソンも終わり、 @hsbt と談笑していると、後ろから肩を誰かにぐわっと捕まれ、 「魚っ!おすすめ!」のような検索ワードか!!という勢いで @songmuさんに声をかけられたので、前夜祭のあとは次の日のトップバッターが両方存在するというチキンレースのような面子で鯖郎へ。 これが管理職ですよ — songmu (@songmu) 2017年6月30日 今年もとても良い YAPC だった! #yapcjapan pic.twitter.com/Mw27xOHh4s — 大沢和宏

More

スレッドセーフなmruby-signal-threadを書いた

最近仕事でmrubyを触り始めて、だいぶC言語に触れ合う時間が増えてきたので、@matsumotoryのススメもあって、mgemを書きました。 なぜ作ったのか mrubyには既にmruby-signalというCRubyのクローン実装のmgemも存在するのですが、マルチスレッドでの動作を考えた場合に、グローバル変数にmrb_stateを持つことから、意図しない動作となるケースがあるため再実装しました。シングルプロセス、シングルスレッドで使うにはmruby-signalで十分なので、今回はコントリビュートではなく別実装とした意図があります。 使い方 シンプルにこのような実装にしました。mruby-threadにシグナルを指定可能にしたようなイメージが近いと思います。 工夫 実装するにあたり工夫が必要だったのは、下記のコードです。 今回の実装はSignalThread#trapが実行されるごとに、mruby-threadを利用して、そのシグナルを処理する専用のスレッドを起動し、スレッドでsigwaitするような実装としています。しかし、その場合、複数のスレッドを起動した場合に、先に起動したスレッドに後続のスレッドが処理するはずのシグナルが配送されてしまう事が起こりえます。 HUPを処理するスレッド1を起動 USR1を処理するスレッド2を起動 USR1シグナルを送る この場合に、スレッド1にUSR1が配送されてしまうケースに該当します。スレッド1のsigwaitはHUPのみを待ち受けているのですが、そこにUSR1が配送されても意図したハンドラ処理を行うことが出来ません。この辺のシグナルの流れは同僚の@harasouが書いたLinux

More