Como fazer com que o templatefile do Terraform ignore as variáveis ​​bash padrão?

Para que o Terraform ignore quaisquer variáveis ​​bash, você precisa adicionar um $. $Observe as sequências de escape do Terraform .

Em outras palavras, você precisa corrigir o arquivo de modelo para ficar assim:

#!/bin/bash

#Colors for terminal

#RED
R="\e[31m"

#GREEN
G="\e[32m"

#YELLOW
Y="\e[33m"

#NORMAL
N="\e[0m"

validation(){

    if [ $$1 -eq 0 ];
    then 
        echo -e "$${G}$$2 is successful$${N}"
    else 
        echo -e "$${R}$$2 has Failed$${N}"
        exit 1;
    fi
}

echo -e "$${Y}Configuring Cart Service$${N}"

cart_config="/etc/systemd/system/cart.service"

cat << EOF >$$cart_config

Environment=REDIS_HOST="${redis_ip}" #I want TF to only substitute these
Environment=CATALOGUE_HOST="${app_lb_dns}"

Environment=CATALOGUE_PORT=8082

EOF

validation $$? "Configuring Cart Service"

Como o Bash e o Terraform usam ${ ... }pontuação para representar a interpolação, se você usar a sintaxe de modelo do Terraform para gerar um script Bash, precisará usar a sintaxe de escape do Terraform em qualquer situação em que uma sequência de interpolação deva ser interpretada pelo Bash em vez do Terraform.

Por exemplo:

echo -e "$${Y}Configuring Cart Service$${N}"

Observe que a linguagem de modelo do Terraform trata apenas ${como especial, enquanto o Bash suporta ambos $fooe ${foo}. Você só precisa escapar a sequência ${em particular; não é necessário escapar um cifrão individual que não seja seguido por uma chave de abertura.

Tudo depois disso é explorar algumas maneiras diferentes de resolver o problema que têm outras compensações, mas se você estiver satisfeito em apenas escapar de tudo, então tudo bem e você pode parar de ler aqui.

Você pode evitar esse tipo de conflito reorganizando seu script para que ele tenha apenas uma pequena parte de modelo e seja basicamente um arquivo estático.

Por exemplo, se você colocar a maior parte do seu script em um arquivo de script bash estático chamado , cart.shvocê poderá gerar a pequena parte dinâmica separadamente dentro da user_dataexpressão, evitando tratá-la cart.shcomo um modelo do Terraform:

  user_data = <<-EOT
    #!/bin/bash

    declare -r cart_config=<<EOF
    Environment=REDIS_HOST="${data.aws_ssm_parameter.redis_ip.value}"
    Environment=CATALOGUE_HOST="${data.aws_ssm_parameter.app_lb_dns.value}"
    Environment=CATALOGUE_PORT=8082
    EOF

    ${file("${path.module}/../userdata/cart.sh")}
  EOT

Observe que isso usa fileem vez de templatefilepara ler o cart.sharquivo e, portanto, o Terraform levará o conteúdo completamente ao pé da letra e não tentará interpretá-lo como um modelo.

O código em cart.shpode ser escrito para se referir à variável cart_config, que é declarada usando o declarecomando templated no resultado geral. Como essa é a única variável que precisa incluir dados dinâmicos de outras partes do módulo Terraform, isso evita a necessidade de escapes extras no cart.sharquivo.

echo >/etc/systemd/system/cart.service "$cart_config"

A solução baseada em modelo embutido acima deve funcionar funcionalmente, mas eu pessoalmente achei seu formato irritante de manter e então escrevi um provedor de utilitário apparentlymart/bashque sabe como gerar declareinstruções adequadas e inseri-las no início de um script Bash.

O exemplo anterior poderia ser reescrito usando meu provedor de serviços públicos para ficar algo assim:

# Terraform requires that your module must declare a
# dependency on this provider in order for its functions
# to be available for use elsewhere in the module.
terraform {
  required_providers {
    bash = {
      source = "apparentlymart/bash"
    }
  }
}

resource "aws_instance" "example" {
  # ...
  user_data = provider::bash::script(file("${path.module}/../userdata/cart.sh"), {
    cart_config = <<-EOT
      Environment=REDIS_HOST="${data.aws_ssm_parameter.redis_ip.value}"
      Environment=CATALOGUE_HOST="${data.aws_ssm_parameter.app_lb_dns.value}"
      Environment=CATALOGUE_PORT=8082
    EOT
  })
}

A chamada para provider::bash::scriptneste exemplo deve produzir um resultado semelhante ao modelo escrito à mão no meu exemplo anterior.

Esta função fornecida pelo provedor também pode suportar mapas de strings e declará-los como "matrizes associativas" do Bash, o que permite uma alternativa onde os detalhes da sintaxe do arquivo "cart config" podem ser tratados dentro do script bash, em vez de dentro da configuração do Terraform:

# (...again, a required_providers block must appear in your module...)

resource "aws_instance" "example" {
  # ...
  user_data = provider::bash::script(file("${path.module}/../userdata/cart.sh"), {
    environment = tomap({
      REDIS_HOST     = data.aws_ssm_parameter.redis_ip.value
      CATALOGUE_HOST = data.aws_ssm_parameter.app_lb_dns.value
      CATALOGUE_PORT = "8082"
    })
  })
}

O acima significa que haverá uma variável Bash chamada environmentcujo valor é uma matriz associativa com os três elementos fornecidos, que você pode então iterar dentro do próprio script Bash:

cart_config="/etc/systemd/system/cart.service"
# Create the file, or truncate it if it already exists
> $cart_config
# Append each pair from "environment" as a line in the file
for k in "${!environment[@]}"; do
    echo >>$cart_config "Environment=${k}=\"${environment["$k"]}\""
done

É discutível se essa complexidade adicional vale a pena para essa situação simples, mas essa técnica pode ser útil quando as chaves do mapa que serão usadas no script são escolhidas dinamicamente, já que o script reagirá apenas a quaisquer pares chave/valor que lhe forem fornecidos, em vez de esperar um conjunto fixo.

(A técnica acima é complicada se os nomes ou valores das variáveis ​​puderem incluir caracteres que o Bash interpretaria de forma não literal, como símbolos "globbing". Há algumas ideias sobre isso em Outras dicas de robustez do Bash na documentação do meu provedor. Como isso está usando o Bash para gerar outra linguagem — a linguagem do arquivo de unidade do systemd — você também precisará garantir que as strings de chave e valor não contenham nada que torne isso inválido da perspectiva do systemd.)