#terraform (2024-07)

If the user_data_replace_on_change is set then updates to this field will trigger a destroy and recreate.
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#user_data

user data used to be a replacing change, now it is only optionally so. by default changes will only stop/start the instance

there are also ways to get user data to run on every startup, but i think that’s more of a cloud-init or ec2-config thing, and not specifically an aws or terraform thing

I didn’t know about the user_data_replace_on_change Going to give that a go..

here’s how to setup per-boot scripts with cloud-init, if you want to go that route… https://cloudinit.readthedocs.io/en/latest/reference/modules.html#scripts-per-boot

Thanks a million :slightly_smiling_face: user_data_replace_on_change did the trick!

I think @Michael has

Note, Terramaid is a a very young project under active development.

@Allan Swanepoel I created the tool as a learning project, but I’m actively working on it each day, so stay tuned for it to get more mature!

thats awesome @Michael

This is an internal debate we struggle with on a regular basis. Where is the line drawn? Typically, modules are used inside of other modules, and things like IAM policies are better expressed as HCL. That said, would you be open to proposing an issue with the hypothetical interface?

We can discuss that and if it looks good, and you’re willing to implement it, then go for it.

Yep. In our case, we deploy using terragrunt, so being able to deploy straight off of the terraform registry module (not having to create a wrapper module just to add one resource for the permissions) would actually help. I also kind of like how the author of the lambda config then gets to decide who can invoke it (similar to how they can define the lambda IAM role permissions). Also, this would be optional (for_eached with a default of []), so one could still declare the permissions elsewhere if a more complex setup is needed. I can whip up a simple PR with a proposal to discuss this further. Thanks for the quick response

https://github.com/cloudposse/terraform-aws-lambda-function/pull/69

Can you run make init && make readme

I’ve updated the PR with readme updates. I had missed this step on my previous PR, too, so the diff now includes docs for the inline IAM policy feature as well.

@Jeremy White (Cloud Posse) or @Ben Smith (Cloud Posse) can you do the final sign off?

Looks like terratest is failing with complaints about the new s3 bucket resource.

@Jeremy White (Cloud Posse) At first glance, it looks like the lambda permission and the s3 notification resource creation are racing (creation of the notification requires the permission). I’ll have a look at fixing this, when I’m back at a computer (on vacation right now).

This is now merged and released, thanks for all the help.

@Andriy Knysh (Cloud Posse)

@Junk please see the related thread here https://sweetops.slack.com/archives/C031919U8A0/p1719132460159829

in short, when you use Go templates, you are manipulating text files (the fact that the files are YAML is not relevant to the templating engine)

and Go templates work with strings only

so in your files, you have to “shape” the result strings into the correct data types. For example, for lists, you can use the toJson function (since JSON is a subset of YAML), or the range function (see the thread)

I was lacking a reference, so thank you for explaining it so well. I’ll try to test it out.

We use an internal module context for this, and I actually think it is quite nice. Because we can generate naming standards internally. Like we can use ctx.prefix_global or just get region with ctx.region. Then we can set prefixes to contain or build namespaces automatically based on context. Best of all we can use that across providers. So one can use the same context for both an aws provider and a postgres provider.

Interesting! do you have any examples for that, please?

I don’t directly, because it is internal, but it is something like this:

module "ctx" {
  source  = "gitlab.internal/foo/context/aws"
  version = ">= 1"

  active    = var.active
  env       = var.env
  erect     = var.erect
  namespace = var.namespace
}

module "core" {
  source  = "gitlab.internal/foo/core/aws"
  version = "~> 2.4"

  azs = var.azs
  env = module.ctx.env
}

locals {
  api_name = "${module.ctx.prefix}-api-int"
}

thanks for the details, that helps

Yes, Cloud Posse has a provider

https://github.com/cloudposse/terraform-provider-context

With an example of using it here: https://github.com/cloudposse/atmos/tree/main/examples/demo-context

This example is with atmos

that is amazing, exactly what I was looking for, thanks a lot!

depends a little on whether you need a taco to provider a runner, or if you want to use runners for gitlab-ci or github-actions… for the former, probably yes. for the latter, you have cli tools like digger/terramate/atmos that integrate with the build system and the repo hosts

seems like atlantis it is for now then. thanks!

Depends a little bit about your requirements

One option is using route53 health checks and failing over to another service which could be your maintenance page

In requirments is a possibility for devs to turn on and off maintenance mode

It depends though at what level. e.g. if you want to work on the load balancer, it needs to be at a higher level.

thanks @Erik Osterman (Cloud Posse) we keep experimenting and pushing the DX to be 10x better than a code editor, I’m betting that an IDE plugin is a piece of the puzzle but so much more is needed. I’ll post more on that as things come up.

@Andriy Knysh (Cloud Posse)

https://github.com/cloudposse/terraform-aws-waf/releases/tag/v1.8.0. @galais.jerome thanks

Thank you for your reactivity

if Atmos logs messages, it should log it to stdterror if configured correctly

see https://atmos.tools/cli/configuration/#logs

Atmos does not eliminate ANSI codes, but it should be logging to /dev/stderr

It may log to stderr, but if I atmos terraform plan <name> -s platform-use2-dev -no-color, Terraform output (plan info) is uncolored, but atmos itself is injecting ANSI-colored/styled text such as Terraform has been successfully initialized! (in green). There does not seem to be a way to turn that off (unlike grep, say, which has a--color=never option, or Terraform which has -no-color). Atmos seems to always emit ANSI into my output, which makes it harder to copy output plans into GitHub comments, Jira tickets, etc.

Here’s an example of what that looks like when pasted into GitHub comment:

ok, so this command works

atmos terraform plan <name> -s platform-use2-dev -no-color

but -no-color is only applied to terraform plan

while it also executes terraform init

which outputs those color messages (before terraform plan, which does not output ANSI codes)

Gotcha. So that ANSI output is an embedded tf init’s output. I don’t generally like to post-process formatting out of a document, but in this case, a sed or similar post-cleaner seems to make sense. Don’t want to worry about whether stacks are initialized or not. Leaving that to atmos is part of the value prop.

I’m actually quite surprised how bad GitHub is at consuming ANSI. Other popular tools (thinking Jupyter notebooks here) are surprisingly good at parsing colored/styled text inline and never miss a beat.

The hivemind suggests sed -r 's/\x1B\[[0-9;]*[mK]//g' as a de-ANSI tool and indeed atmos terraform plan <stuff> | sed -r 's/\x1B\[[0-9;]*[mK]//g' >plan seems work as desired. Pure text, no formatting in plan

@Jonathan Eunice have you considered https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_in_automation

@Andriy Knysh (Cloud Posse) https://sweetops.slack.com/archives/CB6GHNLG0/p1721857756341849?thread_ts=1721854899.495519&cid=CB6GHNLG0

he can add --skip-init to avoid that

I did find the -no-color CLI option, but when used in Atmos context, only affects the last tf command, not the implicit init.

However TF_CLI_ARGS='-no-color' atf plan <stuff> does work. That feels like a win compared to post-processing the ANSI styling out.

using TF_CLI_ARGS is a nice idea @Jonathan Eunice

Yea, good call

btw, I see you’re using shell aliases. Have you also seen the atmos aliases?

You could add this to atmos.yaml

aliases:
  tp: terraform plan

Then add the shell alias alias a=atmos and run a tp if you like things short

@Andriy Knysh (Cloud Posse)

@Ido this is exactly one of the reasons that Atmos exists - to separate code (terraform/opentofu components) from configuration (stacks), and to make the configurations DRY and reusable across many environments, accounts, regions

the config you showed can be defined in Atmos stacks, and then yes, using just one command atmos terraform apply <component> -s <stack> it can be deployed into different environments

@Andriy Knysh (Cloud Posse) I didn’t understand how to achieve that from your tutorial.

I have the following structure

.
├── atmos.yaml
├── components
│   └── terraform
│       └── weather
│           ├── README.md
│           ├── main.tf
│           ├── outputs.tf
│           ├── variables.tf
│           └── versions.tf
└── stacks
    ├── catalog
    │   └── station.yaml
    └── deploy
        ├── dev
        ├── dev.yaml
        ├── prod.yaml
        └── staging.yaml

But this allows me to have 1 station (cluster) per environment. I need to have multiple per environment that are using the same component, and can be deployed separately or together. Is this possible?

@Ido you are prob referring to Multiple Component Instances in the same stack, please see this doc https://atmos.tools/design-patterns/multiple-component-instances