Q&A
やはりエンタープライズ系だと資料必要になりますよね。
共通設計＋差分としつつ、ドキュメント量をへらすのは有力ですね。
最近、業務でAWSを触り始めました。
下記のような主要機能の設定内容をExcelなどで管理したいと思っています。
- IAMユーザ、IAMポリシー、IAMロール
- セキュリティグループ、セキュリティルールグループの内容
- EC2やRDS(サーバ名、インスタンスタイプ、CPU/Mem、IPアドレスなど)
Excelで管理したいと思っても、上記のような情報は上手に縦横の表に表現できるものでもないですし、AWSコンソールを操作する中で複数が定義されたりするので、台帳的に管理すること自体がスジが悪いのかな？と思ったりもしています。
とはいえ、業務上はExcel等のドキュメント(台帳、パラメータシート、詳細設計書 等)として管理したいため困っているのですが、皆様はこのあたりはどのように管理しているものでしょうか？
回答5件
0
頑張ってExcelで管理しているのも過去に見たことはありますが、個人的にはやはり筋が悪いのでオススメしません。
Excelの更新は面倒なのでどうせ更新されなくなって実態と合わなくなるのがオチです。
もしくはExcelがボトルネックになって肝心の実環境の変更が遅くなるとか。
どうしても現状をどこかで管理したいならcliで実際の構成を出力して、それを成形したものをテキストとしてどこかに出力させるとかでいいと思います。
ぶっちゃけ「コンソール見ろ」のほうが早いかと。
それか、CloudFormationやCDK、Terraformなどで管理したい部分をコード化することを検討しましょう。
※追記
台帳管理に反対な理由は他にもあります。
AWSはサービスが増えたり機能追加されるのが非常に早いので、結局台帳がボトルネックになってそれらのサービスが使えない、という状態が頻繁に発生することです。
やはり既存環境を正としてcliなどで情報を落とし込むというのが無難なところではないでしょうか。
統制管理をしたいのであればAWS Configなども使うと良いです。
Excelファイルをどうしても作るなら、あまり厳密性は求めないほうがいいですね。
結局Excelファイルを整理するのが仕事、みたいになりかねません。
難しい問題ですが、クラウドインフラを扱うケースでは既存のドキュメントベースな管理ではクラウドのメリットを殺してしまう部分が大きく、利用に際して既存の組織の考え方を時には破壊し、新たな体制が必要なケースがあります。
熱量を持ってそういったことをやり遂げてしまう方もいらっしゃいますが、一般にはかなりハードルが高いのでAWSのコンサルティングパートナー（可能であればプレミアコンサルティングパートナー）の会社に協力してもらうことをおすすめします。
こちらに公式でパートナーを検索できるページがあります。
投稿2021/12/17 14:50
編集2021/12/18 06:25
総合スコア7640
0
ベストアンサー
わたしは台帳管理は賛成派です。Excel か Google Spreadsheet で書きます。
少人数のスタートアップなら台帳なんて不要という意見もわからなくはないですが、エンタープライズ系などは資料がないと「現状があるべき状態になっていることをどうやって担保するのか?」となるわけで。
terraform などの IaC は一覧性・可読性で劣る、設計意図などが見えづらいなどの欠点があるため、似て非なるものと思っています。
具体的な資料ですが、
上手に縦横の表に表現できるものでもない
というのは、結局シートを分ける、表を分ける等でなんとかするしかないのではと思っています。
例: https://dev.classmethod.jp/articles/excel_aws_spec_autogeneration/
とはいえ管理するドキュメント量はなるべく減らしたいので、共通設計を定義して個別の表にはなるべく書かない (差分のみ書く) ようにしています。理想は「EC2共通設計 + EC2 一覧の表を書いておしまい」という感じです。
terraform 等でも module で共通化 & 個別設定は上書きできるようにして、Excel と terraform の対応がおおむね取れている状態を目指しています。
投稿2021/12/18 05:23
総合スコア2067
0
既に回答されていますが、「管理した台帳を正として環境を維持」は以下のデメリットがあり、私もお勧めしません。
- 管理コストの増加によるアジリティの低下
- 台帳とリソースの同期がとれていることを保証できない
理想はTerraformやCloudFormationによる構成管理ですが、クラウドを導入したばかりの現場で、IaCはハードルが高いと思います。
現状としてはInfrastructure as a Codeのようなレベルにはまだ遠いので、CLIで必要な情報を抜いておくことが落とし所なのかもと思ってきました。
仰る通り、AWS CLI/AWS SDKなどのツールでリソース情報を出力するのが現実的かと思います。
参考までに、VSTOでExcelの環境定義書を生成する事例です。
投稿2021/12/18 01:04
編集2021/12/18 01:14
総合スコア843
やはり皆さん、同意見なんですね。出力用コマンドを決めておくしかないのかなぁ。
Excelの事例ありがとうございます。Excel等のドキュメントでのAWS管理みたいな話は、筋悪とはいえニーズがあるのかな？という気もしてきました。
筋が悪いかどうかはツールをどう運用するかによると思います。
Excelファイルを正としない（現状のリソースを正とし、リソースとの同期をとりたくなったらツールで再出力する）運用であれば、台帳による管理の弊害は解消できると思います。紹介した事例は、そのような運用を想定しているように見受けられました。
0
Excelファイルを出力するツールを探してみました。
What is Live Optics? – Live Optics Support
サンプルをみると、良さそうですね。
Excelにこだわらないなら、他にもありそうです。
投稿2021/12/18 03:31
編集2021/12/18 03:32総合スコア843
0
仕事でAWS使ってます。前の会社ではNotionにパラメータずらずらっと書いてました。
今の職場はWordでそれやってたら、Excelに書いてくれてと言われ、仕方なく書いてます。
yu_1985さんの仰る通り、Excelはバージョン管理に問題があり、あんまりお勧めしません。正直、良い方法がないものかと考えているところです。
その意味では良い質問かと思います。どなたか、これは良いよという方法があれば教えてください。コード化ももう一歩CloudFormationは日本語を使うとバグるらしいので苦慮してます。
投稿2021/12/17 15:32
退会済みユーザー
総合スコア0
同じような状況で、システム設計書であったり、それの変更来歴管理をExcel(or 何かドキュメント)でちゃんと行いましょうというのがルールとして求められている状況です。
もしそれにかわる良い方法があるならそれでも良いのかもしれませんが、まだ自分のAWSのレベルも低くCloudFormationも使いこなせておらず、どうしたものかという状況です。
ブログ記事、読ませていただきました。
CloudFormationのyamlからExcel化が良さそうということですね。
それにしても、それをサービスとしてやっている会社があるとは・・・。
おそらく、無料で楽にやるような定番の方法みたいなものは、現状は無いんだろうなー。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2021/12/17 15:18
2021/12/17 16:05
2021/12/17 22:20