JetBrainsのJunieを使ってTerraformのコードを生成する

前回の「TerraformでAmazon EKSクラスタを構築して、ArgoCDでアプリケーションをデプロイする」ではTerraformによるIaC化の説明をしました。実はこのコードのほぼすべては生成AIを使って作成したものでした。(流石に解説文までは生成AIを使ってはいません)

本記事では、環境構築ためのコードをどうやって生成させたかについてご紹介します。

準備

IntelliJ IDEA 2025.1.1.1をインストールして、IntelliJを起動後に「JetBrains Junie」のプラグインをインストールします。

IaCコードの生成と環境構築

VPCとEKSクラスタの構築

EKSクラスタクラスタに必要となるVPCの構築のため、Junieの画面で以下のプロンプトを入力しました。

プロンプト
terraformディレクトリにEKSのクラスタを作成するコードを書いてください。EKSはt4g.mediumのスポットインスタンスを使って、リージョンはus-west-2 に作成してください。Terraform AWS modulesを使用してください。

プロンプト入力後に以下のようにファイルが生成されました。

terraform/
├── README.md
├── main.tf
├── outputs.tf
├── providers.tf
├── terraform.tfstate
└── variables.tf

ファイルの中身を確認すると、TerraformのproviderやmoduleやKESのバージョンが古いので最新のバージョンに変更しました。それ以外は修正の必要はありませんでした。

EKSクラスタの動作確認

前回の記事ではクラスタ構築後に次の作業のHelmプロバイダの設定に取り掛かっていますが、この段階でEKSクラスタが正常に構築できたのかを確認しています。この確認用のコードもJunieに生成させました。

プロンプト
sample/sample-nginx ディレクトリに nginxのインスタンスをLoadBalancer経由でインターネットに公開する、Kubernetesのマニフェストファイルを作成してください。

プロンプト入力後に以下のようにファイルが生成されました。

sample
└── sample-nginx
    ├── README.md
    └── nginx.yaml

親切な事にREADMEまで作成してくれています。ここにデプロイ方法や確認方法も記載されていたので指示通りに確認しました。

    ## How to Deploy

    After your EKS cluster is up and running, you can deploy this sample using kubectl:

    ```bash
    # Configure kubectl to connect to your EKS cluster
    aws eks update-kubeconfig --region us-west-2 --name lean-saas-eks

    # Apply the manifest
    kubectl apply -f nginx.yaml

    # Check the deployment status
    kubectl get deployment nginx

    # Check the service status and get the external IP/hostname
    kubectl get service nginx
    ```

    ## Accessing the Application

    Once the LoadBalancer is provisioned (which might take a few minutes), you can access Nginx using the external IP or hostname provided by the LoadBalancer:

    ```bash
    # Get the external IP/hostname
    export SERVICE_IP=$(kubectl get service nginx -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

    # Access Nginx
    curl http://$SERVICE_IP
    ```

Helmプロバイダの導入

次にHelmプロバイダを導入するため以下のプロンプトを入力しました。

プロンプト
TerraformにHelmプロバイダを追加してください。

providers.tfファイルにHelmプロバイダを導入してくれたのですが、やはりバージョンが古いものでしたので最新のバージョンに変更しました。

AWS Load Balancer Controllerのインストール

インストールするために以下のプロンプトを入力しました。

プロンプト
TerraformでHelmチャートを使用してaws-load-balancer-controllerをインストールしてください。aws_iam_policy は https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json を使うようにしてください。

terraform/alb_controller.tf ファイルが生成されバージョンを更新したのですが、 data リソースを使って iam_polycy.json を取得するようにはなっておらず、手動でダウンロードしてファイルを配置する必要がありました。ですので、以下のような記述が必要でした。

# IAM Policy for AWS Load Balancer Controller
data "http" "aws_load_balancer_controller_policy_json" {
  url = "https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json"
}

resource "aws_iam_policy" "aws_load_balancer_controller" {
  name        = "AWSLoadBalancerControllerIAMPolicy"
  description = "IAM policy for AWS Load Balancer Controller"
  policy      = data.http.aws_load_balancer_controller_policy_json.body
}

AWS Load Balancer Controllerの動作確認

AWS Load Balancer Controllerが正常に動作するかを確認するため、以下のプロンプトを入力しました。

プロンプト
sample/sample-nginx-alb ディレクトリに nginxのインスタンスをAWS ALB経由でインターネットに公開する、Kubernetesのマニフェストファイルを作成してください。

ここでもREADMEの内容に従って確認しました。

ArgoCDのインストール

ArgoCDをインストールするため、以下のプロンプトを入力しました。

プロンプト
TerraformでHelmチャートを使用して、ArgoCDをインストールしてください。ArgoCDはALBでインターネットからHTTPSでアクセスできるようにしてください。

terraform/argocd.tf ファイルが生成されたので中身を確認します。バージョンを最新化して、さらに「# Replace with your actual domain」と実際のドメイン名に変更する必要があるとのコメントがあったので修正しました。生成AIでコードを生成する時は、修正が必要な記載のあるコードが生成される場合もあるので、生成内容のレビューは必要なようです。

この段階で terraform apply を実行したのですが、Load BalancerのACM証明書が保留中のままの状態になっていました。そこで以下のプロンプトを入力して修正を依頼しました。

プロンプト
ACM証明書のステータスが「保留中の検証」になっています。何を確認すれば良いですか?

docs ディレクトリを作成して、手動で検証する場合の手順とTerraformで自動的に行うコードのmarkdownファイルが生成されました。手動で検証する方針にすると、後任者のために手順のドキュメントが必要になるので、このようにファイルに出力されるのは便利ですね。ですがTerraformで一気にやってしまいたかったので、Terraformのコードを追加しました。これでACM証明書は発行済みになりました。ですがRoute 53の設定が生成されなかったため、以下のプロンプトを入力しました。

TerraformでRoute53にArgoCDのドメインを追加してください。

ここでも、ALBのDNS名がわからないらしく以下のコメントのブロックがあったので、AWSコンソール画面で確認した値に修正しました。

  # This is a placeholder. In a real-world scenario, you would need to get the ALB hostname dynamically.
  # For now, we're using a pattern that matches how AWS ALB Controller typically names the ALB.
  # You should replace this with the actual ALB hostname after the ALB is created.

それでもエラーが発生したので、エラーメッセージを入力すると修正されました。

これでArgoCDの管理画面にアクセスできるようになりました。

ArgoCDの動作確認

ArgoCDでデプロイできるのかの確認のため以下のプロンプトを入力しました。ここでは、GitOpsのリポジトリとTerraformのリポジトリは同一のリポジトリとなっていて、このリポジトリpublicリポジトリです。

プロンプト
sample/sample-nginx-alb をArgoCDのアプリケーションとしてTerraformで登録してください。

ここでは、特に問題なく動作確認できました。

ECRリポジトリの作成

業務でのSaaSアプリケーションを公開する時は、コンテナのイメージは非公開になっている場合が多いので、プライベートリポジトリを作成しました。以下のプロンプトを入力しました。

プロンプト
TerraformでECR リポジトリを作成し、EKSからアクセスできるようにしてください。

特に問題なく作成されたので、dockerコマンドでカスタマイズしたコンテナイメージをpushしました。

GitOpes用リポジトリのプライベート化

GitOpsで使用するリポジトリもprivateである場合が多いので、以下のプロンプトでプライベートリポジトリに対応しました。

プロンプト
TerraformでArgoCDがGitHubのプライベートリポジトリ <GitHubアカウント>/<リポジトリ名> のアプリケーションをデプロイできるようにしてください。

特に問題なくプライベートリポジトリからデプロイできるようになりました。

他に試していた事

上記ではすんなりと構築できたように見えますが、他のパターンを試していて上手く行かなかった事も多いです。実は色々と試してみて、こう言う指示の出し方をしたら上手く行きそうだなと勘所をつかんでやってみたのが、上記になります。ここでは上手く行かなかった事とその感想をご紹介します。

EKSのNodeのインスタンスをArmマシンにする

Thoutworks社のTechnology Radarで「Arm in the cloud」がTrialとして紹介されていたので最初はArmインスタンスを試そうとしました。

プロンプト
terraformディレクトリにEKSのクラスタを作成するコードを書いてください。EKSはt4g.mediumのスポットインスタンスを使って、リージョンはus-west-2 に作成してください。Terraform AWS modulesを使用してください。

確かにArmインスタンスを指定したTerraformが生成されましたが、Armインスタンスの場合はAMIイメージも指定が必要でエラーが発生しました。何かを変えた場合にそれに従って変更しなければいけない部分まで考慮してくれないようなので、x86系のインスタンスで構築する事にしました。

EKS on Fargate

2つぐらいのPodしか構築するつもりがなかったのでFargateを使おうとしていました。ですが、CoreDNSが立ち上がっていなかったり、ALBが作成できてもtargetの設定ができない状態になっていたりで、上手く構築できませんでした。

Claude Code、 OpenAI Codex CLI

実は、Junieを使う前にClaude CodeとOpenAI Codex CLIも試していました。どちらも前のプロンプトで作成したファイルや手動で修正した内容を考慮せずにファイルが生成されていました。JunieはIntelliJと密結合になっているためか、プロンプトを実行するたびにプロジェクト内のファイルを検査してからコードを生成しているように感じられました。もしかしたら、IntelliJの起動時のファイルのインデックス作成結果を、Junieは利用しているのかもしれません。

また、Junieも含め、Claude Code、 Codex CLIも、バージョンに関しては古いものを指定していました。 EKSのバージョンに至っては既にサポート切れになっているものが出力されていたので、必ず見ておく必要がありました。

一つのプロンプトでのタスクのサイズについて

今回は、一度に全部のセットアップをプロンプトで要求するのではなく、人間が細かく分けて指示を出していきました。どの程度の大きさのタスクを一度の指示でできるのかを見極めていく必要があるかもしれません。(ですが、この辺はモデルのバージョンアップによって、どんどん大まかな粒度で指示できるようになっていく部分だと思われます。)

まだ、どの程度の粒度で、どの順番で指示を出すかとか、エラーが起きた場合に人手で修正してしまうかの判断などは、プロンプト作成者のスキルに依存する部分があると思われます。ですので、雰囲気(vibe)でコーディングするのは、まだまだこれからだと感じました。ただし、以前構築したものと似たものを新たに作成する場合に、再び正式ドキュメントでパラメータを調べ直して自分で書くよりは効率的な印象でした。

まとめ

以上、Junieなどのコーディング・エージェントを使用して得られた知見等をご紹介しました。