GraylogをTerraformで管理する

    Graylogのリソースを terraform で管理するために作った terraform provider を紹介します。 Graylogとは何かはこちらを読んでください。 Graylogには様々なリソースがあります。 User Role Input Index Set Stream Stream Rule Dashboard Alert etc これらのリソースはWeb UIから作成したり出来るわけですが、 Web UIでポチポチするのは疲れますし、ソースコードで管理したいものです(Infrastructure as Code)。 また、Web UIからでは細かな権限管理は出来ず(限られた権限管理しか出来ない)、APIを使ってする必要があります。 APIを使って管理できるツールを探したものの見つからなかったので、 APIを使ってGraylog用のterraform providerを自作しています。 https://github.com/suzuki-shunsuke/go-graylog GraylogのAPIの種類は非常に多く、残念ながらカバーできているのは一部だけですが、以下のようなものをサポートしています。 Alert Condition Alert Notification (Alarm Callback) Input User Role Index Set Stream Stream Rule Dashboard Ldap Setting Role はサポートしているので権限管理は問題なく出来ます。 Dashboard Widget もサポートしたいです。 出来れば Alert の設定も出来ると良いのですが、Alertに関するCRUD APIが提供されていない(GETのみ)ので、サポートできません。 terraform を使った管理方法 以下では自分の管理方法を紹介します。 https://github.com/suzuki-shunsuke/example/tree/master/graylog-terraform にサンプルが置いてあります。 基本はプロジェクトごとに Index Set, Stream, Role といったリソースを作成 User に Role を付与 という流れになります。

    Graylog で log を管理する

    Java 製の OSS ログ管理システム Graylog の紹介です。 Graylog については幾つかに分けて記事を書きたいと思います。 今回はGraylogの入門的な内容になります。 なお、本記事中で「現在」「現時点」といった場合、特に断りがなければ記事執筆時点 2018-11-27 を指します。 Graylog のバージョン 検証に用いるGraylogのバージョンは 2.4.6 になります。 OSSバージョンとEnterpriseバージョンがありますが、本記事ではOSSバージョンを使用します。 Graylog とは https://www.graylog.org/ https://github.com/Graylog2/graylog2-server Kibana と Elasticsearch(以下ES) を使ったことがある人は、Kibanaに代わるものだと思っていただくとイメージしやすいかと思います。 ログはGraylogそのものが保持するのではなく、ESにインデキシングされます。 Kibana同様、ESに収集されたログを検索したり、ダッシュボードを作ったり出来ます。 ダッシュボードに関してはKibanaのほうが優れているようにも思えますが、 Graylogは認証・認可によりダッシュボードやログを操作できる人を制限・管理することが出来ます。 Graylogでログを管理する場合、ユーザーは直接ESにはログを送らず、Graylogを経由して送ります。 ESに対するGraylog以外のアクセスを制限し直接ESにアクセスされるのを防ぐことが出来ます。 Graylog は多機能なシステムであり、ログを整形したり、アラートを飛ばしたり、他のシステムにログをフォワードしたりすることも出来ます。 marketplace でサードパーティの plugin が公開されており、機能を拡張することが出来ます。 APIも提供されており、ある程度自動化が可能です。 認証・認可 オンプレミスでログを管理する場合、社外からは勿論社内からのアクセスも制限したいです。 Graylog では LDAP や Active Directory によってアクセスを制限できます。 リソース毎に誰が何を出来るか設定できます。 http://docs.graylog.org/en/2.5/pages/users_and_roles/external_auth.html ログの収集 ログの収集をするには Graylog で幾つかのリソースを作成する必要があります。 Input Index Set Stream Stream Rule Input はログの入力のフォーマットの設定であり、 どのポートでどういったフォーマットのログを受け付けるかという設定になります。 フォーマットは様々なものがサポートされています。 AWS Flow Logs AWS Cloud Watch Logs AWS Cloud Trail Beats CEF AMQP CEF Kafka CEF TCP CEF UDP Fake HTTP Message GELF AMQP GELF HTTP GELF Kafka GELF TCP GELF UDP JSON Path NetFlow UDP Raw AMQP Syslog AMQP Syslog Kafka Syslog TCP Syslog UDP この設定はログを収集するアプリケーションごとに設定するというより、グローバルな設定なので、他のアプリケーションで既に同じ形式でログを収集していたら新たに設定する必要はありません。

    akoi - binary installer

    自作のOSS akoi の紹介をします。 なぜこんなものを作ったのか akoi と ansible を使ってサーバにバイナリをインストールする方法 について主に説明します。 まとめ akoi はバイナリファイルのインストーラ 設定ファイルで管理できる 冪等であり、効率よくインストールできる 並列インストール Accept-Ranges による分散ダウンロード ansibleでサーバにバイナリをインストールするのを補助してくれる ansible で真面目にバージョンコントロールして効率よくインストールするのは難しい(ほとんどの ansible role は出来ていない) akoi とは akoi はバイナリファイルのインストーラです。 設定ファイルにインストールするファイルのダウンロードURLとインストール先を記述して管理します。 インストールするバイナリのバージョン管理が可能であり、既にインストールしてあるバージョンへの切り替えはシンボリックを作り直すだけなので一瞬で終わります。無駄にダウンロードをしたりはしません。 複数のバイナリを並列でインストールしたり、Accept-Ranges ヘッダによる分散ダウンロードをサポートしています。 分散ダウンロードについては https://qiita.com/codehex/items/d0a500ac387d39a34401 が参考になります。 Goで書かれています。 https://github.com/suzuki-shunsuke/akoi/releases からバイナリをダウンロードしてインストールできます。 詳細はREADMEを読んでください。 なぜ作ったのか サーバにバイナリをインストールする ansible role を書くのが辛かったからです。 最近は色々なソフトウェアがGoで書かれ、バイナリで配布されています。 そういったバイナリをサーバへインストールするのは ansible で行っているという方も少なくないのではないでしょうか? 有名なソフトウェアをインストールする ansible role は大抵Ansible Galaxy で公開されています。 しかし、ほとんどの role は「真面目に」バージョン管理していません。 ここでいう「真面目に」とは バージョンを指定できる バージョンを変更できる 指定したバージョンが既にインストールされている場合は無駄にダウンロードしたりしない といったことです。

    gomic - Goのモックジェネレータ

    自作のOSS gomic の紹介をします。 なぜわざわざこんなものを作ったのか 生成されたモックの簡単な使い方 を主に説明したいと思います。 まとめ gomic は Goのinterfaceを実装したモックを生成するCLIツール モックを手で書くのが辛すぎた & 既存ツールで満足できなかったため作った 自動生成できるコードは自動生成すべき 設定ファイルで管理するため、interfaceの更新に合わせてmockの更新が容易 生成されるモックはシンプルなAPIのみ提供するので学習コストが低い gomic とは gomic は Goのinterfaceを実装したモックを生成するCLIツールです。 これによってモックを使ったテストの作成を効率化します。 単調な作業を自動化し、本来注力すべきことに注力できるようにするためのツールです。 Goで書かれています。 https://github.com/suzuki-shunsuke/gomic/releases からバイナリをダウンロードしてインストールできます。 同様のツールは幾つかあります。 https://github.com/avelino/awesome-go#testing https://github.com/golang/mock (以下 gomock) https://github.com/gojuno/minimock (以下 minimock) 特に gomock は有名ですね。 なぜ作ったのか 上述のように既に同様のツールはありますし、 gomock と minimock は試しました。 しかしあまり満足のいくものではなかったため、自分で作ることにしました。 自分が欲しかったのは学習コストの低いシンプルなAPIです。 interfaceのメソッドを実装した関数をモックに渡すことで 簡単にメソッドの実装を切り替えたいのです。 // Getwd メソッドのモック mock.SetFuncGetwd(func() (string, error) { return "/tmp", nil }) mock.Getwd() // "/tmp", nil これは非常にシンプルで分かりやすく、柔軟性のあるパターンです(minimockはこのパターンもサポートしています)。

    go-gencfg - viperの個々のアプリケーション用のラッパーのコードジェネレータ

    自作のOSS go-gencfg を紹介します。 Golang で viper という汎用的な設定管理ライブラリがありますが、 特定のアプリケーション用に viper のラッパーを生成するCLIツールです。 使い方や開発の背景を書こうかと思いましたが、だいたい README に書いてあるので そちらを御覧ください。 https://github.com/suzuki-shunsuke/go-gencfg/blob/master/README.md