Как я могу предоставить аргументы в свой скрипт, если он запускается как пользовательские данные в terraform?

Что касается Terraform и AWS, user_data — это буквально набор байтов, которые сохраняются в API EC2 без какого-либо конкретного значения. Программное обеспечение, работающее внутри вашего экземпляра EC2, затем извлекает эти данные с помощью API метаданных экземпляра и пользовательских данных и самостоятельно решает, как интерпретировать эти данные.

Для большинства образов компьютеров Linux общего назначения программное обеспечение user_data обрабатывает cloud-init , поэтому интерпретация вашего user_data контента аналогична описанной в Форматы пользовательских данных.

В настоящее время вы используете интерпретацию сценария пользовательских данных, которая просто записывает данные на диск в виде исполняемого файла и пытается его выполнить. В этом случае Cloud-init не передает скрипту никаких аргументов, поэтому ваш текущий скрипт не подходит для использования таким образом.

Самый гибкий вариант — установить user_data в Данные конфигурации облака, которые представляют собой формат YAML, определенный Cloud-init, который позволяет описывать различные действия, которые Cloud-init должен выполнять при запуске во время загрузки системы.

Cloud-init имеет два «модуля», которые потенциально могут быть полезны для ваших требований: Write Files для записи произвольных небольших файлов в файловую систему и Bootcmd для запуска встроенного скрипта один раз во время ранней загрузки.

Следующая конфигурация создает облачную конфигурацию user_data, которая инструктирует cloud-init сначала записать сценарий начальной загрузки в определенное место на диске, а затем запустить другой небольшой сценарий, который выполняет этот файл с определенными аргументами:

resource "aws_instance" "instance" {
  # ...

  user_data = <<-EOT
    #cloud-config
    ${yamlencode({
      write_files = [
        {
          encoding    = "b64"
          content     = filebase64("${path.module}/setup-lemp.sh")
          owner       = "root:root"
          path        = "/usr/local/bin/setup-lemp"
          permissions = "0755"
        },
      ]
      bootcmd = [
        [
          "cloud-init-per", "once", "setup-lemp",
          "/usr/local/bin/setup-lemp",
          "--db_root_password", "foo",
        ],
      ]
    })}
  EOT
}

Модуль bootcmd настроен на запуск следующей командной строки:

cloud-init-per once setup-lemp /usr/local/bin/setup-lemp --db_root_password foo

При этом используется вспомогательный инструмент Cloud-init под названием cloud-init-per, который обеспечивает выполнение данной команды позже в процессе загрузки. bootcmd на самом деле запускается раньше write_files в типичной конфигурации Cloud-init, поэтому этот дополнительный помощник позволяет отложить фактическое выполнение скрипта до более позднего этапа процесса, после того как файл уже должен быть записан.

Некоторые соображения и предостережения, которые следует иметь в виду:

• EC2 рассматривает user_data как обычный атрибут экземпляра EC2, поэтому его может получить любой, у кого есть доступ для получения атрибутов экземпляра EC2. Поэтому, если вы разместите здесь пароль root своей базы данных, этот пароль может быть виден другим людям, работающим с вашей учетной записью AWS.

  Альтернативой, позволяющей избежать этой проблемы, было бы вместо этого записать пароль в такой сервис, как AWS Secrets Manager, и использовать user_data, чтобы сообщить экземпляру, как получить пароль, вместо того, чтобы указывать пароль напрямую. Однако подробности этого выходят за рамки этого вопроса и ответа.

• Порядок, в котором Cloud-init запускает свои модули, настраивается человеком, создавшим ваш AMI. Я построил вышеизложенное, предполагая порядок, указанный в документации для системы Ubuntu, что приводит к порядку bootcmd, write_files, scripts_per_once и, следовательно, должно работать. Если вы заметили странное поведение и подозреваете, что шаги выполняются в другом порядке, вам может потребоваться проверить фактическую конфигурацию облачной инициализации вашей системы, чтобы убедиться, что модули выполняются в подходящем порядке.

• Некоторая часть работы, выполняемой вашим сценарием (в частности, установка пакета), при желании может быть выполнена с использованием других декларативных модулей Cloud-Init, а не императивного сценария bash, что может облегчить отладку результата, поскольку вы можете положиться на команды отчета о состоянии Cloud-init. Однако было бы сложно заменить весь ваш скрипт модулями cloud-init, поэтому в вашем случае в целом может быть проще разрешить всю проблему (кроме написания сценария в первую очередь) в bash.

Другой подход заключается в использовании следующих поставщиков:

resource "aws_instance" "instance" {

 #rest of config goes here

 provisioner "file" {
      source = "${path.module}/provision.sh"
      destination = "/home/ubuntu/provision.sh"
    }

    provisioner "remote-exec" {
      inline = [
        "chmod +x /home/ubuntu/provision.sh",
        local.final_provision_command
      ]
    }

    connection {
      type        = "ssh"
      user        = "ubuntu"
      private_key = "${file(var.private_key_path)}"
      host        = self.public_ip
    }
}

Это загрузит файл на сервер через поставщика файлов, а с помощью удаленного выполнения скрипт выполнится. Соединение настраивает ssh для соединения, которое будет использоваться для выполнения сценария.