概要
Graphvizを使ってインフラ構成図をdotファイルで管理してみました
過去にRubyからGraphvizを使う方法を紹介しましたが、今回はGraphvizのみを使ってDotという言語でサーバの構成管理をしてみました
環境
- CentOS release 6.6 (Final)
- Graphviz (dot) 2.26.0
インストール
Graphvizのインストール
CentOSであればyumコマンドを使ってインストールすることが可能です
yum -y install graphviz
サンプルの動作確認
軽くサンプルの動作確認をしてみます
- touch sample.dot
以下の内容を記載します
digraph sample {
LB -> server001;
LB -> server002;
server001 -> db001;
server002 -> db001;
}
これをPNG形式の画像に変換してみます
dot
というコマンドを使って画像を作成します
dot -T png sample.dot -o sample.png
「-T」オプションで出力する画像のタイプを指定します
「-o」オプションで出力先のファイル名を指定します
出力されたPNGファイルを確認すると以下のようになっていると思います
これだけでも構成図っぽいですがもう少し拡張してみます
もう少し拡張してみる
サーバをroleごとに管理する
例えば今回の場合はserver001とserver002はいわゆるWebアプリケーションサーバだとします
「web」というロールを作成してそこにserver001と002を属するようにrole分けしてみます
sample.dotを以下のように拡張します
digraph sample {
LB -> server001;
LB -> server002;
server001 -> db001;
server002 -> db001;
subgraph cluster_web {
// node [style = filled];
// style = filled;
server001;
server002;
label = "web";
color = blue;
}
}
subgraph
という命令を使います
ポイントはsubgraphの名称が「cluster」で始まらないと線が描画されない点です
好きな名前を使うと線が描画されない現象にハマるので注意しましょう
最低限記載したほうが良さそうなのは属性は「label」と「node名」かなと思います
「label」を指定すると囲った線内にラベルを表示してくれます
「node名」を指定すると指定したnode名を線で囲ってくれます
その他、レイアウトや色を指定するオプションがありますが、ここは自由に指定するといいと思います
この状態で出力される画像は以下の通りです
LISTENしているポートを記載する
例えばLBは80番でLISTENしていてサーバの8080に流すと言ったパターンは多くあると思います
今回はポート情報をノード内のテーブル構成を使って表現してみたいと思います
sample.dotを更に以下のように拡張します
digraph sample {
node [shape = record];
LB [label = "{ 80 | LB }"];
server001 [label = "{ 8080 | server001 }"];
server002 [label = "{ 8080 | server002 }"];
LB -> server001;
LB -> server002;
server001 -> db001;
server002 -> db001;
subgraph cluster_web {
// node [style = filled];
// style = filled;
server001;
server002;
label = "web";
color = blue;
}
}
ポイントは各種ノード情報にlabel属性を指定して表示をテーブル構造に変更する点です
テーブル構造を使うためにはnode [shape = record]
を指定する必要があります
shapeにはrecord or Mrecordを指定することができます
Mrecordを指定すると若干角が丸まった図形を使用することができます
これで画像を作成するとnodeの上部にポート番号が表示され下部にリソース名が表示されるようになると思います
DBのサーバだけ図形のスタイル変更する
現在はすべての図形が同じ形の図形ですがDBサーバはわかりやすいように別の形にしたいということはあると思います
なので、DBサーバだけ別の形にしてみたいと思います
sample.dotを更に以下のように拡張します
digraph sample {
node [shape = record];
LB [label = "{ 80 | LB }"];
server001 [label = "{ 8080 | server001 }"];
server002 [label = "{ 8080 | server002 }"];
db001 [shape = box3d];
LB -> server001;
LB -> server002;
server001 -> db001;
server002 -> db001;
subgraph cluster_web {
// node [style = filled];
// style = filled;
server001;
server002;
label = "web";
color = blue;
}
}
db001のnodeに対してshape属性を追加することで個別に形を変更することができます
今回は「box3d」を指定しました
他にもいろいろな図形を指定できるので、その他の形についてはこちらを御覧ください
これでDBサーバだけそれっぽい形に変更することができました
なぜこんなことをするのか
インフラ構成図を作成するときに自分がよく見るケースはパワポ等を使ってオートシェイプでポチポチ作成するケースです
パワポ等で作成するとインフラ構成に変更があった場合などに、いちいちパワポを開いて編集しなければならないとかいろいろと面倒です
今回はとりあえずDot言語で管理できるようにしてみました
これだけでもgit等のバージョン管理システムを使えるので大きなメリットだと思っています
ただ、結局Dotファイルを手動で変更していると作業工数的にはパワポでの作業とあまり変わらなくなってしまいます
なので自分が最終的にやりたいと思っているのは
- インフラ構成の情報をクラウドAPIを使って取得して
- その情報をDotファイルに落としこんで
- 作成したDotファイルをJenkinsがビルドして画像を作成し
- 作成した画像をクラウドストレージにアップロードして
- ブラウザ上で閲覧できるようにする
- というJenkinsのジョブを毎日回す
ということが最終的にできればと思っています
これができればクラウド上に動的にサーバが作成されても何も編集することなく新しいサーバ構成図を作成し確認することができます
クラウドストレージにアップロードするのは、アップロードすること自体が目的ではなく、サーバ構成図をURIでアクセスできるようにするのが目的です
最後に
いかがでしたでしょうか
もちろん、この方法がインフラ構成の管理方法として完全な正解ではないと思っています
もっと効率的かつ簡易に管理する方法はあると思っています
ただ「Infrastructure as Code」という言葉があるように少なくともコードで管理することは重要だと思っています
もちろん Chef や Puppet のコードがすでに見える化されているならばこんなことはする必要ないと思いますし、二重管理にもなるのでやること自体微妙かと思います
それでも Chef や Puppet はあくまでもサーバの設定自体をコード化するツールかなと思っているのでインフラ構成自体を見える化するにはやはり別のツールや手法が必要なのかなと思っています
(もしかしたら Chef のレシピからサーバ構成図を作成するツールがすでにあったりするかもしれないですが)
0 件のコメント:
コメントを投稿