前回の導入ガイドに引き続き、Getting Started の日本語（参考訳）です。今回は実践編です。実際に Vault をインスト－ルし、開発用サーバ（dev mode）を起動し、シークレットの作成・削除、AWS 上のアクセス・トークンの動的な生成、GitHub認証、認証とポリシー設定など、Vaultの基本的な動作を試す＆理解の手助けになればと思っています。 内容には十分配慮していますが、意味が分かりづらい所や、間違っているところがありましたら、ご指摘いただけると助かります。 — ■ Vault のインストール https://www.vaultproject.io/intro/getting-started/install.html まずはじめに Vault を自分のマシンにインストールする必要があります。Vault がサポートしているプラットフォームやアーキテクチャ向けのバイナリ・パ

HashiCorp から新しいツール Vault がリリースされました。credentialや機密情報的なものを管理するためのツール。例によって参考訳です。変なところありましたら、ご指摘いただけると助かります。 Vault – HashiCorp https://hashicorp.com/blog/vault.html ※今回も一応書いておきますと、本blogでの投稿は私個人の意志によるものであり、所属する組織の意見を代表するものでもなく、仕事でもなく、誰からの指示をうけているわけでもなく、すべて興味本位であり、ぶっちゃけ好き勝手に書いています。これまでも、これからも。 ■ Vault 機密情報を管理するツール 今日私達は Vault という安全な機密情報の管理と暗号化データ転送を行うツールを発表します。credential や API 鍵の保管から、ユーザ・サインアップ用のパスワードの

HashiCorp の Blog に Terraform の新バージョンに関する投稿がありました。例によって、翻訳してみました。参考程度にどうぞ。 Terraform 0.4 – HashiCorp https://hashicorp.com/blog/terraform-0-4.html ■Terraform 0.4 私達は Terraform 0.4 をリリースします。Terraform は安全かつ効率的にビルド・組みあわせ・インフラの立ちあげを行います。 Terraform 0.4 は、これまでで最大のリリースです。私達はAWSの広範囲をサポートするような、複数の主要な機能を提供します。Terraform 0.4 は 新しいコア・コミッターの Paul Hinze と Clint Shryock 、そして80人ものコントリビューターにより、これまで最もコミュニティが関わりました。 T

Consul ( http://www.consul.io/ ) という新しいツールが4月17日(日本時間18日)に発表されました。Vagrant や Serf の作者さんが所属している Hashicorp 社としての新しいプロダクトです。 サイトによると、Consul は、’solution for service discovery and configuration’ とあり、サービス検出と設定のためのソリューションであり、具体的には、サービス（データベースやメール等々）を監視し、問題発生時にはトラフィックを迂回させるなどといった情報を、KVS を通して提供するもの、と書かれています。 また、複数のデータセンタにまたがる非常に大きなインフラ（基盤）上で、既に数ヶ月間利用されてきた実績もあるようですね。 4/19追記：背景やアーキテクチャのドキュメントは、別途本厄翻訳しました Cons

Consul について、自分の中の理解を深めるために関連ドキュメントの参考訳を作成しました(4/19現在)。せっかく作ったのに、自分の引き出しの中にしまっておくだけでは勿体ないと思い、公開します。Consul や Serf に興味を持っている方の参考になれば幸いです。 Consul の意味は、’領事’や’執政官’です。Serf は’農奴’ ですから、まるで、農民(Serf)を支配し、使役するお代官様(Consul)のような関係がイメージされます。実際のところ、Consul は内部の Serf クラスタ上に構築されていますが、Consul の機能や役割は、Serf の持つものとは異なるように見えます（現時点の公開情報では）。詳しくは、ドキュメントをご確認ください。 実際に使いたい！という場合は、先日の投稿 Consul を使ってみた、をご覧下さい。 当ページのドキュメントについては、あくまで

https://github.com/zembutsu/serf-munin Github 上に、オーケストレーションツール Serf の、イベントハンドラ用スクリプトを公開しました。機能は、serf のメンバに存在するとき(join時)、munin-node の監視設定ファイルを自動設置します。メンバから外れた時（leave/failed時）は自動的に設定ファイルを削除します。 ■設置方法 Munin マスタ（監視元）のサーバに、このファイルを設置します。 $ wget https://raw.github.com/zembutsu/serf-munin/master/serf-munin.sh # mkdir /opt/serf-munin-node/ # mv ./serf-munin.sh /opt/serf-munin-node/ # chmod 755 /opt/serf-mu

Munin の監視ノードが増えてくると、ストレージの IO がボトルネックになりがち。Munin によるランダムなファイルの読み書きが主な原因。改善するためには、 rrdcached と Munin を連携する方法が手軽で確実な方法です。Muninサーバの処理が重いなと思ったら、SSD など高速ストレージを導入する前に、まずは rrdcached の導入がおすすめです。 記事内容は、rrdcached のメリット（1台で300ノードまでの監視に対応）と、RHEL5 で導入したときの手順メモ、そして rrdcached の効果を知る為の rrdcached プラグインの導入方法です。 ■rrdcached を何故使うのか？ Munin は収集データを RRD ファイルに格納し、グラフ描画時に再び参照します。このとき、ストレージに対する読み書き(IO)が増えます。 とりわけ、負荷になりがちなの

ZABBIX 2.0 の新機能、ローレベルディスカバリ(Low Level Discovery、以下 LLD)は、自動的にアイテム・トリガ・グラフを生成してくれるもの。サーバ内の状況に応じ、動的に監視対象を変化させる事ができます。 本記事は、LLD の概要と、実際に設定を行うチュートリアルで構成しました。既に公式ドキュメントを読まれた方には、不要かと思います。自分が理解に時間がかかってしまったので、、これから LLD を始める方が迷わないようにと、チュートリアル形式で記事をまとめてみました（SNMP の効率的な OID データ収集に関しては、途中記事を飛ばして読んでいただいて構いません。） 本記事の概要 Zabbix 2.0 からローレベルディスカバリ機能(LLD)が使えるようになった。 検出用の標準キーは3種類（vfs.fs.discovery＝ファイルシステム検出、net.if.di

「Muninが重い（ #＾ω＾）ﾋﾟｷﾋﾟｷ」 という時、ありませんか？ありますよね。この「重い」には、実は種類があります。１つは「Muninの動いているサーバが重い」場合。もう１つは、動的にHTML/画像を生成している場合「Muninの描画(表示)が重い」場合です。 今回の記事は、「Muninの何が重いか？」を視覚化する munin_stat プラグインと、ノード毎のデータ収集時間を計測する munin_update プラグインをご紹介します。 munin_stats プラグインのグラフ。HTML生成やグラフ生成など、Muninの定時処理で何処が重いのか把握しやすくなります。ちなみに、このグラフのサーバでは動的に画像を生成させているため、グラフ部分はカウントされていません。 ■俺のMuninがこんなに軽いはずがない Munin のサーバが重たい原因、一般的には、ノード数が増加して描画対象

自分用φ(..)メモメモ ZABBIX(赤)でmunin-node(緑)プロセスを監視しようとしても、zabbix-agentのバージョンが1.4系の場合は key に proc.num[munin-node] を指定しても、常に結果が 0 。正常に検出することが出来ない。代案として、proc.num[perl,,,”munin-node”] を用いることで、munin-node の稼働状況を確認することが出来た。以下は、通常の監視方法と、代替案を見つけるまでの手順を記す。 ■ ZABBIX でも munin-node を監視したい！ Linux サーバ上で稼働する munin-node を監視するために、ZABBIX を用いた。目的は munin-node を監視して、停止している状況があれば、通知して復旧するため。ZABBIXの代わりに、もちろん、他の監視ツールでも良い。たまたま監視対

Munin でサーバを監視するには、munin-node が必要。けれど、munin-node が入らない場合、pmmn を使う方法があります。pmmn ( A Poor Man’s Munin Node ) は munin-node の代替ツールで、munin-node が動作しない環境からもデータを取得出来ます。そんな、pmmn のセットアップと使い方を紹介します。 ■ pmmn は munin-node の手軽な代替ツール pmmn は munin-node 代替ツールです。Munin 開発者の Steve Schnepp 氏が Github に公開しています。pmmn は、’A Poor Man’s Munin Node‘ の略で、’お手軽な munin-node’ といった意味合いです。その名前の通り、munin-node が多くの CPAN で配付されている Perl モジュー

PSSH ( Pararell-ssh ) は、Linux 上で複数のサーバに対して同時に SSH ログインし、コマンドを実行するだけのシンプルなツール。様々なデプロイ用のツールがある中で、古くから、純粋にコマンドを叩くことに特化しているツールが pssh 。シンプルながら、必要十分な機能を備えています。Verion 2.x 系の情報はまとまっていないようなので、自分のメモがてら、簡単なセットアップ方法と、簡易チュートリアルを掲載しました。 ■ PSSH とは何ぞ？ PSSH は Parerll-ssh (並列 ssh) の名前の通り、複数のサーバに対して同時に ssh を走らせることが出来るツールです。例えば、手許に複数のサーバがあるとして、同時に uptime コマンドを走らせたい時や、十数台の httpd.conf を一斉に書き換えて apache 再起動することも、手軽です。 PS

監視ツール ZABBIX には、トリガ（障害）発生時にメールを送信する機能があります。ただ、このメールはスレッド化（階層化）されません。通知・復旧毎にメールを送信している場合や、複数の監視環境が入り乱れてしまうと、どのアラートが対応中で、どのアラートが復旧しているのか、状況確認に手間取る場合があります。↓大量に届く通知メールの想像イメージ もしも、ZABBIXのメールがスレッド化していたら、仕事が楽になるのになぁ…と思い、少しスクリプトを書いてみました。少々甘いところはありそうですが、ひとまず自分が必要な機能は実装できたので、公開します。 ■ZABBIXの通知メールをスレッド化したい！概要 まずはじめに、メーラーで表示されるメールをスレッド化するために必要なものは、RFC 2822 で定義されています。やりたい事はシンプル。ZABBIXが通知するメール毎に、ヘッダを付与するだけで、スレッド

自分用(._.) φ メモメモ ■CentOS6(x86_64)にEPEL版Zabbix 2.0.5を入れる EPEL版リポジトリの Zabbix 2.0 に関する情報が無いようなので、簡単にまとめました。 Zabbix オフィシャルのパッケージセットアップ手順は、以下 URL に纏められています。 3 Installation from packages [Zabbix] https://www.zabbix.com/documentation/2.0/manual/installation/install_from_packages ですが、パッケージ構成がオフィシャルと EPEL では異なります。そのため、ページに沿って作業をしようとすると、途中で詰まります。というか、私が詰まって涙目だったので、次からハマらないようにまとめました。 ハマった点 ・どのパッケージを入れれば良いのか分か