🔫

SNMP検証環境作成用のTerraformを書き直した

2024/03/28に公開

AWS

以前pythonによるsnmpについて検証した記事にて，Udemy見て少しお作法を覚えたTerraformを書いてみたんですが，あんまりよろしくないコードになっていたので，それを今ある知識の範囲で直してみました．
前回の記事も直し，githubに放り投げてたコードも直しました．

直した点１　ハードコーディング

access_keyとprivate_keyをハードコーディングするように書かれてしまっていたので，tfvarsから引っ張ってくるように直しました．

あとはssh用の秘密鍵の名前もTerraformを実行する人によって異なるので，tfvarsファイル側で編集してもらうようにしました．
もっと変数は工夫できたかもですが，とりあえず上記だけです．

# 変数定義
variable "aws_access_key" {}
variable "aws_secret_key" {}
variable "key-name" {}

# AWS Provider
provider "aws" {
  region     = "ap-northeast-1"
  #アクセスキーとシークレットキーを用意．テストならそのままでベタで良いかも．
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

### 略 ###
#EC2
resource "aws_instance" "test-instance-manager" {
  ami               = "ami-0310b105770df9334"
  instance_type     = "t2.micro"
  availability_zone = "ap-northeast-1a"
  #key_nameは自身の環境に合わせて
  key_name          = var.key-name
  network_interface {
    device_index         = 0
    network_interface_id = aws_network_interface.test-nw-interface-manager.id

  }

### 略 ###

直した点２　パブリックとプライベートにサブネットを分けてみる

両方プライベートにしても良かったというか，その方が健全？な気もしていたのですが，イメージとしてはDMZ上にあるサーバをSNMPのエージェントとしてリソース監視するみたいな形で構成を組みなおしました．マネージャーはプライベートサブネットに在籍です．
とはいえど，マネージャーを起動して，snmp,pysnmp等をインストールしなければいけないので，NATゲートウェイを設置しました．

１つ悩ましかったのが，マネージャーへのssh接続です．
いくつか案を考えました．
・エージェントを踏み台にしてsshする
ネットだと鍵をローカルに落とした後scpで踏み台サーバに送ってましたが，うーん…と思いました．
22番開通しているとはいえ，鍵を送付して良いものなのか…
ローカルがセキュアとも言い切れないんですがね…

・エージェントを踏み台にするけど，別の認証
ちょっと難しそうなのでスキップ…

・とりあえずコンソール画面から
EC2インスタンスコネクトを使えばブラウザから出来るじゃん！と思ったのでググってみたらTerraformで意外に簡単に作成できそうで，これに決めました！

コードはこっちで（結局）

準備できたらapplyします．
initとかplanとかは端折ってます．満足したらdestroyしませう．特に僕みたいに個人で遊んでいる人はお金かかるので…

terraform apply -var-file hoge.tfvars

所感

奥深いTerraform

今回はのターゲットはAWSですが，GCPやAzureなどのケースもあると思うと，マルチクラウド環境ではもっと色々調べないといけないじゃん！って感じでした．
AWSの機能についてもSAAの参考書をさっと読んだレベルで，今のプロジェクトでは扱う機会がないので，TerraformだけでなくAWSから調べなければいけなかったり，調べていくうちに知らんプロトコルが出てきて，積読状態のネスぺの参考書引っぱり出したり等々…使いこなすまでの道のりは長いな～とも思いました．

日本語の書籍が少ないため，やはり公式のドキュメント，よくわからなかったら先人の日本語サイトとかに頼ることになるんですかね．今回ChatGPT使ってないですけど，ChatGPTにもいろいろ聞くことになりそう…

行数増えすぎワロタ

ネット記事を参照していると，皆さん幾つかにtfファイルを分けていらっしゃるので，そうすればよかったなと思いました．
単純な構成であれば１個のファイルでも良いですが，今回の構成だけでも，NATゲートウェイについて書いて，インターネットゲートウェイについて書いて，ルートテーブルについて書いて，あれテレタビーズはどこ？みたいな状態になってました．

大変だけどおもろい

書いて書いて書いて，よし，apply！で成功すると爽快です．
GUI操作でポチポチいろいろなページに飛ぶより，こっちのほうが性に合ってる気すらします．
ただ実際の本番環境で構築する場合，なかなか骨が折れそうだなと思いつつ，これはこれで数日位悩むのも良いんじゃない？と思いました．

これはベストプラクティスではない

文字通りです．
上にも書いたけど，ドキュメント，EICの箇所なんかは先人のパクリまくりですので，理解がまだまだな部分があると思い，理解がまだまだということは改善の余地があるということかと．
セキュリティ面も前回よりは気を配りましたが，例えばサーバでインストールするpythonライブラリ含めてちゃんと精査した方が良い？とかとかですかね．