1) custom_data使用(シェルスクリプト)

azurerm_virtual_machineブロック -> os_profile -> custom_data に実行したい内容をそのまま記載します。

resource "azurerm_virtual_machine" "tf_name_vm1" {
  # ※ここではcustom_dataに必要な部分のみ記載しています※

  os_profile {
    custom_data    = <<-EOF
      #!/bin/bash
      apt-get update
      apt-get -y dist-upgrade
      apt install -y nginx
      apt install -y nodejs
      apt install -y npm
      EOF
  }
}

スクリプトを別のファイルで管理したい場合は、custom_dataに$file変数を記載しても動きません。template_fileとしてファイルを記載し、custom_dataではそのrendered属性を参照する必要があります。

data "template_file" "my_init_script" {
  template = "${file("/home/azureuser/init_test.sh")}"
}

resource "azurerm_virtual_machine" "tf_name_vm1" {
  # ※ここではcustom_dataに必要な部分のみ記載しています※

  os_profile {
    custom_data = "${data.template_file.my_init_script.rendered}"
  }
}

custom_dataはroot権限で実行されるのでsudoは無くても構いません。

$ cat init_test.sh
#!/bin/bash
apt-get update
apt-get -y dist-upgrade
apt install -y nginx
apt install -y nodejs
apt install -y npm

2) custom_data使用(cloud-init)

Cloud Init に対応したOSであれば、同様に os_profile -> custom_data に実行したい内容をそのまま記載できます。

resource "azurerm_virtual_machine" "tf_name_vm1" {
  # ※ここではcustom_dataに必要な部分のみ記載しています※

  os_profile {
    custom_data    = <<-EOF
      #cloud-config
      package_upgrade: true
      packages:
        - nginx
        - nodejs
        - npm
      EOF
  }
}

スクリプトを別のファイルで管理したい場合も、同様にtemplate_fileとしてファイルを記載し、custom_dataではそのrendered属性を参照する必要があります。

data "template_file" "my_init_script" {
  template = "${file("/home/azureuser/cloud_init_test.yml")}"
}

resource "azurerm_virtual_machine" "tf_name_vm1" {
  # ※ここではcustom_dataに必要な部分のみ記載しています※

  os_profile {
    custom_data = "${data.template_file.my_init_script.rendered}"
  }
}

$ cat cloud_init_test.yml
#cloud-config
package_upgrade: true
packages:
  - nginx
  - nodejs
  - npm

3) provisioner(remote-exec)使用

remote-execはTerraformの機能で、Ansibleと同様に仮想マシンにSSH接続して設定を行うものです。以下が設定例です。

resource "azurerm_network_interface" "tf_name_nic1" { # NICの設定
  # ※ここではremote-execに必要な部分のみ記載しています※

  ip_configuration {
    private_ip_address_allocation = "Static"    # VM作成直後にSSH接続する必要があるため、
    private_ip_address            = "10.10.0.5" # 静的IPアドレスを割り当てる。
  }
}

resource "azurerm_virtual_machine" "tf_name_vm1" {
  # ※ここではremote-execに必要な部分のみ記載しています※

  os_profile {
    admin_username = "azureuser" # VM上のユーザ
  }

  os_profile_linux_config {
    ssh_keys {
      path     = "/home/azureuser/.ssh/authorized_keys"                  # VM上のユーザ(azureuser)の鍵設定
      key_data = "${file("/home/ubuntu/azureuser-key/.ssh/id_rsa.pub")}" # 設定する鍵(指定してあるファイルはTerraformを実行するユーザのローカルファイル)
    }
  }

  provisioner "remote-exec" {
    connection {
      host = "10.10.0.5" # azurerm_network_interfaceで設定したIPアドレス
      type = "ssh"
      user = "azureuser" # os_profileで設定したユーザ
      private_key = "${file("/home/ubuntu/azureuser-key/.ssh/id_rsa")}" # os_profile_linux_configで設定した鍵(のプライベートキー)
    }
    inline = [ # 実行するスクリプト
      "sudo apt-get update",
      "sudo apt-get -y dist-upgrade",
      "sudo apt install -y nginx",
      "sudo apt install -y nodejs"
      "sudo apt install -y npm"
    ]
  }
}

ここでのポイントは、

VM作成直後にSSH接続するため、静的IPを設定しておく
設定したIPと鍵を使うよう、provisioner(remote-exec)ブロック内の設定を記載する
鍵はパスフレーズなしにする必要がある

の3点です。現状、SSH接続に使う鍵にはパスフレーズが設定されていると実行エラーになってしまいます。

Error: Failed to read ssh private key: password protected keys are
not supported. Please decrypt the key prior to use.

以上が記法の例となります。

remote-execはドキュメントには「この機能は"last resort"で、クラウド標準の機能を優先して使うべき」という旨の記載があるのですが、実行すると結果が標準出力に出るのでエラーの調査がしやすいというメリットがあります（custom_dataを間違えて途中で止まった場合の調査は大変...）。実績のない設定の検証用途で使うのがよさそうです。

link

Terraform Docs: remote-exec
Terraform Docs: virtual_machine
Cloud Init