ラベル graphviz の投稿を表示しています。 すべての投稿を表示
ラベル graphviz の投稿を表示しています。 すべての投稿を表示

2015年4月23日木曜日

Graphviz 各種 Tips

概要

GraphvizのTipsをメモ

環境

  • CentOS 6.6 64bit
  • Graphviz 2.26.0-10

Tips

画像を埋め込む方法

jenkins [label = <<TABLE><TR><TD><IMG SRC="jenkins.png"/></TD></TR></TABLE>>, shape = plaintext];

HTMLライクな構文を使用すると埋め込むことができる
上記の場合はdotファイルと同じディレクトリにpngファイルを配置すればOK
shape=plaintextを画像のオブジェクトを枠線を削除するために利用

複数のclusterに所属させる方法

複数のsubgraphに所属される方法とも言うと思います

subgraph cluster_one {
  label = "one";
  subgraph cluster_two {
    host001;
    label = "two";
    color = blue;
  }
}

subgraphの宣言の中にsubgraphを書けばOK
上記の場合はこんな感じになります
test.png

cluster内のオブジェクトがエッジで接続されている場合にオブジェクトを並列にする方法

subgraph cluster_one {
  label = "one";
  subgraph cluster_two {
    rank = same {
      host001 -> host002;
    }
    label = "two";
    color = blue;
  }
}

rank = sameを使います
host001とhost002は横に並びます
rankdir=LRにすると縦に並びます
test2.png
rank = sameを使わないと以下の通り
test2-2.png

投稿者 時刻: 0 コメント
ラベル: ,

2015年4月6日月曜日

Graphviz を使って dot 言語で Server のインフラ構成を管理してみる

概要

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ファイルを確認すると以下のようになっていると思います
sample.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名を線で囲ってくれます
その他、レイアウトや色を指定するオプションがありますが、ここは自由に指定するといいと思います

この状態で出力される画像は以下の通りです
sample2.png

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の上部にポート番号が表示され下部にリソース名が表示されるようになると思います
sample3.png

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サーバだけそれっぽい形に変更することができました
sample4.png

なぜこんなことをするのか

インフラ構成図を作成するときに自分がよく見るケースはパワポ等を使ってオートシェイプでポチポチ作成するケースです
パワポ等で作成するとインフラ構成に変更があった場合などに、いちいちパワポを開いて編集しなければならないとかいろいろと面倒です

今回はとりあえずDot言語で管理できるようにしてみました
これだけでもgit等のバージョン管理システムを使えるので大きなメリットだと思っています
ただ、結局Dotファイルを手動で変更していると作業工数的にはパワポでの作業とあまり変わらなくなってしまいます

なので自分が最終的にやりたいと思っているのは

  • インフラ構成の情報をクラウドAPIを使って取得して
  • その情報をDotファイルに落としこんで
  • 作成したDotファイルをJenkinsがビルドして画像を作成し
  • 作成した画像をクラウドストレージにアップロードして
  • ブラウザ上で閲覧できるようにする
  • というJenkinsのジョブを毎日回す

ということが最終的にできればと思っています
これができればクラウド上に動的にサーバが作成されても何も編集することなく新しいサーバ構成図を作成し確認することができます
クラウドストレージにアップロードするのは、アップロードすること自体が目的ではなく、サーバ構成図をURIでアクセスできるようにするのが目的です

最後に

いかがでしたでしょうか
もちろん、この方法がインフラ構成の管理方法として完全な正解ではないと思っています
もっと効率的かつ簡易に管理する方法はあると思っています

ただ「Infrastructure as Code」という言葉があるように少なくともコードで管理することは重要だと思っています
もちろん Chef や Puppet のコードがすでに見える化されているならばこんなことはする必要ないと思いますし、二重管理にもなるのでやること自体微妙かと思います

それでも Chef や Puppet はあくまでもサーバの設定自体をコード化するツールかなと思っているのでインフラ構成自体を見える化するにはやはり別のツールや手法が必要なのかなと思っています
（もしかしたら Chef のレシピからサーバ構成図を作成するツールがすでにあったりするかもしれないですが）

投稿者 時刻: 0 コメント
ラベル: ,
登録: 投稿 (Atom)