AWS+PlantUML+Gitで柔らかい「見えるインフラ」を作る

AWS+PlantUML+Gitで柔らかい「見えるインフラ」を作る:

柔らかい「見えるインフラ」を作る

初めに

書いている人

インフラ入門者です。

至らない点があればつついてご指導ください。

誰向けの記事？

• AWSでインフラを作る・作っている人
• 必要なタイミングで柔軟に変更に対応しつつ、それをチームで共有するために見える化もしないといけない人
• インフラを秘伝のレシピや封印された地雷原にせず、適切にバージョン管理の配下に置きたい方

つまり、ToB的な方向のプロジェクトでインフラを任されたけど、

仕様変更がちょくちょくあって、

しかも仕様書に合わせて更新するような自動化とか許されなくて、

いやーもうこまっちゃうなーってなってる人。

（ぼくはちがいます、ちがいますって。。。。ぷるぷる。。。）

個別要素の説明

PlantUML

試すだけならオンラインのジェネレータでpngなどにしてもらえますが、

業務利用する場合はセキュリティのためにローカルでやります。

• 
  基本的にはこのページにある通りでできちゃいます。
  
  
  
  
  • Java環境を作って
  • plantuml.jarを落としてきて
  • 
    java -jar plantuml.jar file.pumlを呼ぶ
• 個人的にはMarkdown Preview Enhancedを組み合わせて、UML付きのドキュメントを作るのがおすすめです。

無事にPlantUMLが導入できたら、UMLやその他もろもろ、開発でほしい図は大体これで賄えます。

見た目を気にしないなら。

PlantUMLでリッチなAWSのグラフが欲しい

問題は見た目ですね。

チームでの共有なら通常のPlantUMLの見た目でもよいですが、

お客様に説明するときは偉い人から「もう少し見た目を」と言われて、

ドキュメントをわざわざ華やかにするというお仕事が発生します（呪）

まあ、見た目の良いドキュメントは使っていて気分が良いので構いませんが、

どうせ変更されるのにというむなしさもあり。

そんなお仕事を気持ちよくさせてくれるのが、

PlantUMLのために公開されているAWSのライブラリです。（感謝）
https://github.com/milo-minderbinder/AWS-PlantUML

こちらのリポジトリを導入すると、

かなりリッチな見た目でAWSの構成を表現できます。

例えば、ユーザーからのコメントをフィルタリングして、

対応窓口の負担を減らしたい、という場合をサクッと図にしてみましょう。

(いろいろ省いてますが)

Gitで管理しよう

PlantUMLの最大の利点はテキストから生成できることですね。

上記のumlを生成するために必要なテキスト量はたったこれだけ。

@startuml 
!define AWSPUML https://raw.githubusercontent.com/milo-minderbinder/AWS-PlantUML/release/18-2-22/dist 
 
!includeurl AWSPUML/ApplicationServices/AmazonAPIGateway/AmazonAPIGateway.puml 
!includeurl AWSPUML/common.puml 
!includeurl AWSPUML/Storage/AmazonS3/AmazonS3.puml 
!includeurl AWSPUML/Storage/AmazonS3/bucket/bucket.puml 
!includeurl AWSPUML/Compute/AWSLambda/AWSLambda.puml 
!includeurl AWSPUML/Compute/AWSLambda/LambdaFunction/LambdaFunction.puml 
 
LAMBDAFUNCTION(push,UserComment) 
        LAMBDAFUNCTION(filter,Filtering) 
 
AMAZONAPIGATEWAY(api) 
 
AMAZONS3(temp, "Temp") 
AMAZONS3(date, "User data") 
 
user1 -d-> api  
user2 -d-> api  
user3 -d-> api  
 
api --> push 
push -d-> temp 
temp -u-> filter 
filter -d-> date 
@enduml 

テキストベースなので当然Gitで管理できて、

誰がいつ何の目的でどこを変更したのか、

そして最新版がどれなのか（）

確実に管理できるわけです。

どう変わるのか

上で乗せたユーザーのコメントに関する図をお客様に見せて、

「Filteringしたデータなんだけど、

ブラックリストのデータも作りたいからS3は二つにしてよ」

なんて言われた場合、これまでなら大きな手間でした。

今まで

お客様の前で直せる程度の変更なら良いですが、

だいたい面倒なので更新するために一度持ち帰り、

エンジニアに依頼して正しい構成になるように図を修正してもらい、

書き直した図で大丈夫かをお客様に再度確認してもらい、

確認をもらってからチーム全体に共有し、

今まで使っていたドキュメントから新しいドキュメントに切り替え、、、、

つまり、めんどくさい。

これから

しかし、これからはその場でささっと書き変えて、

OKをもらった状態でコミット、

エンジニアには後から修正を頼めば、

それが正しい仕様としてチームで共有できるわけです。

天国！

柔らかい「見えるインフラ」へ

正直に言えば、AWSに限らず、IaaSのサービスはだいたいGUIやデータ内容が複雑です。

「インフラ簡単になりました」は間違いじゃないですが、

「インフラ誰でも触れるようになりました」はまだ間違いです。

しかし、こうしたツールを使うことで敷居も下がりますし、

かかわるコミュニティが広がることで、

UIも含めたノウハウはより洗練されていくはずです。

願うなら、エクセルとZipで賄おうとする現場がなくなりますことを。。。。

追記

それぞれのサービスのアイコンについて、

一覧になっているページがないので、

とりあえずまとめて画像にしてPR出しています。

PRがマージされたら更新しますが、

それまで僕のリポジトリの画像フォルダのURLを置いておきます。

https://github.com/AtsushiYamashita/AWS-PlantUML/tree/add/category-images/examples/images

こういう感じで一覧にしたものを並べています。