Gemini Advanced/Terraformを利用して、仮想マシンを構築してみる


皆さん、こんにちは。

前回のTerraformの投稿、準備編チュートリアル編から大分時間がたってしまいましたが、改めてTerraformを利用してAzureリソースを作成したいと思います。

そろそろやらないとな、と思っていた矢先にGoogleのGemini Advanced / Utlra 1.0がリリースされました。折角なので、Gemini Advancedに協力をもらいながら、TerraformでAzure用リソースのコードを作成し、仮想マシンを構築してみたいと思います。

Terraformはインフラ環境のコード化:IaCツールとしてのデファクトスタンダードといっても過言ではないほどに定着しているツールになります。AIと組わせるとどうなるのか…

それではやっていきましょう!!!

1. 目指す先

以下が目指す環境になります。今回はとてもシンプルに、仮想マシンをAzureテナントにデプロイします。

もちろん、リソースグループを始めとした、仮想ネットワーク/サブネット、ネットワークセキュリティグループも含めて、同じタイミングで展開します。

余談ですが、もっと慣れてくれば、ハブ&スポーク環境も簡単にコードできそうになるなという実感がありますね。

2. コード生成

既にTerraformの準備は完了しているので、早速コードの作成に取り組みたいと思います。

Terraformのインストール等は過去の投稿からご確認ください。

さて、今回はGoogle Geminiを利用してコードを生成していくわけですが、今回使用するプロンプトは、

I want to set up a Virtual Machine that could run WordPress

としました。なるべく簡潔にすることで、どれほどの正確性で出力してくれるか把握するために敢えてそうしています。

日本語訳としては、ワードプレスを稼働できる仮想マシン環境を構築したい、となります。

※すみません、事前にTerraform/Azureを利用していることは指定しています。。。

出力結果はこちらになります。1回目の出力でパブリックIPアドレスについては、必要であれば作成してください、となっていたため、今回は2回出力しています。

パブリックIPアドレスは必要になるため、パブリックIPアドレスを生成してほしいともう一度依頼しました。

I need public IP Address

その出力結果が…

しっかりとネットワークインタフェースの項目にもパブリックIPアドレスの情報を追記してくれました。

このオリジナルを元に、必要に応じて変更したいと思います。

変更するものとして、

  • Terraformのバージョン指定(お作法的にも)
  • ローケションをjapaneastに変更
  • 命名規則に基づいた名称変更
  • ネットワークセキュリティグループにSSHを追加
  • IPアドレスをBasicからStandardに変更
  • Standard変更に伴い、IPアドレスのアロケーションをStatic(固定)に変更
  • UbuntuOSのバージョンとして22.04-LTSを指定

22.04-LTSを指定するにあたり、イメージオファーとSKUの書き方が異なるため、そちらも合わせて修正したいと思います。

こちらが完成品になります。

「–」、はTerraformとしてはコメントアウトとして認識しないため、正式な「#」へ変更もしています。

完成したので実行してみたいと思います。

3. 実行

PowerShellを実行します。Azureへのログイン、Terraformのファイルの初期化から、実際のファイルを実行して成功するか見てみましょう。

まずは、Terraformを利用してAzureリソースを展開するために必要な環境変数を指定します。

登録が完了しているかは下記のコマンドから確認できます。

それではAzureにアクセスします。

無事ログインが完了しました。念のため、自分がデプロイしたいサブスクリプションが指定されていることを確認します。

それでは、Terraformファイルの初期化から実行まで進めていきます。

初期化が完了しました。

planでも、しっかりと7リソースが追加されることが確認できました。問題なさそうですので、

Applyを実行します。

残念ですが、エラーが出てしまいました。仮想マシンの作成時のエラーのようです。これもGeminiに聞いてみましょう。

How do I fix this error, At least one admin_ssh_key must be specified when disable_password_authentication is set to true

丁寧にSSH Keyの生成方法について解説してくれました。

Terraformファイルに追加する場合は、public_key変数に、Keyファイルのパスを指定します。

デフォルトは’true’と判定されるようです。今回はシンプルに、disable_password_authentication = ‘false’を明記する形にしたいと思います。

では、再実行します。

無事作成されたことを確認しました。では、Azure Portal画面からも確認してみようと思います。

Azure Portal上からも作成を確認できました。ネットワークセキュリティグループも意図したように設定されています。

では、仮想マシンにアクセスができるのか…あーー、アクセスができません。

ふとコードを見直したら、Network Interface(NIC)とNetwork Security Group(NSG)が紐づいていないことに気が付きました。

Geminiにコードを分析してもらいましたが、問題ないと返事がきます。おかしいですね。。。

Microsoftに載っているTerraformコードを参考に修正します。折角なので聞いてみましょう。

In my opinion, I think you need to attach your network security group to network interface. Example code follows.
resource “azurerm_network_interface_security_group_association” “example” {
network_interface_id = azurerm_network_interface.my_terraform_nic.id
network_security_group_id = azurerm_network_security_group.my_terraform_nsg.id
}

すると、

You’re absolutely correct! That’s the missing piece. Currently, your Terraform code defines the network interface and network security group but doesn’t explicitly associate them with each other.

それが原因だ!と回答もらえました。正解だったようです。

そして、exampleだった箇所を適切な名称へ変更してもらえました。

これを追加して、今一度Terraform Applyを実施します。既にデプロイされているリソースは無視されるため、関連付けのみが実行される想定になります。

Terraformが差分部分のみ認識してくれました。問題ないため、yesとして続行します。

無事作成が完了しました。

Azure Portal画面からも確認します。

関連付けられたことが確認できました。今一度、アクセス確認したいと思います。

無事、Teratermからアクセス確認ができました。仮想マシンの構築完了です。

4. まとめ

Gemini単独でのコード生成ができませんでしたが、環境構築の時間を大幅に削減できるなという印象を持てたのではないでしょうか。

仮想マシンの管理者パスワード設定や、NICとNSGでの関連付け等、やはり人の目によるダブルチェックは必要となり、エンジニアは必要不可欠かと思います。

今回の検証を通じて感じたこととしてはAIを盲信しないことであり、AI×人の組み合わせによって最大限の効果を発揮するものであるといった点です。

少なくとも、AIは我々の業務効率化を助けてくれるツールであることは間違いはありませんので、今後もうまく付き合っていきましょう!

 

この記事を書いた人

森 信之介
テクニカルマーケターとして、ブログ執筆、セミナー講師を行っております!