Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform 1.0

github.com

Post reply on HN
Print view View original

311–315 of 315 posts

Re: Terraform 1.0

#311

Post by randomswede »

tehbeard wrote: post #307
randomswede wrote: post #304

Earlier quoted context omitted.

In Ansible, you declare a set of actions, that are then performed, one by one. Occasionally being skipped, if a certain condition holds true. So, you are basically saying "do this, do that, then do that". In a declarative model, you would say "this is how the end result should look" and the tool would then go off and make that happen, in whatever order its scheduling tools would say. Sort of the difference between Ru…

I guess I need an example of the declarative model, as I can see the Ansible model in my head and it still looks declarative to me atleast at the singular module level. in Ansible, you say "make sure these packages are installed" and they'll be installed as needed, to match that state, or ignored if already there. Even the file level stuff you can say "make sure this line is in the file" and it either adds it or says…

It is not declarative. The simple fact that the playbook will ALWAYS be run in the order you specify, even if a later step is (technically) a prerequisite of a previous step, means that you are in an imperative mode.

Puppet is declarative, you simply say "these things must, or must not, hold" and a combination of user-declared and inferred dependencies arrange the sequencing, which can be different in each run (as long as the before/after dependencies hold).

Re: Terraform 1.0

#312

Post by gjhr »

throwaway894345 wrote: post #151
gjhr wrote: post #143

Earlier quoted context omitted.

terraform state mv [old name] [new name] I'd much rather explicitly state when real resources are renamed than have terraform diffing my code and guessing whether I wanted to rename it or I am actually trying to recreate something. I can only imagine the headaches that would happen with a tool trying to track changes to infra as well as changes to code without explicitly tying infra state to version control somehow.…

> I'd much rather explicitly state when real resources are renamed than have terraform diffing my code and guessing whether I wanted to rename it or I am actually trying to recreate something. But you're not renaming real resources, you're just renaming the Terraform identifier that corresponds to them. There's no reason that changing this identifier should destroy and recreate the resource it corresponds to. If you…

OK but how does Terraform know you are renaming a resource? It is not a daemon always running and watching everything you type. It only gets a snapshot of your code to work from when you run it, it doesn't know what your code was before, just the saved state from your last run and the real state in your cloud provider. The only way it can track the state is through the name which you have provided it, if you change that name it cannot know without inferring something. Maybe it matches up all the attributes in your code and state and infers that a rename has happened. What happens when only 95% of attributes match? What happens when multiple things match (An ec2 instance only requires 2 attributes so this is plausible)?

Example 1:

You have 2 essentially identical EC2 VMs with terraform names vm1 and vm2. You decide these are not good descriptive names so change them to webserver1 and webserver2, before running that change you also realise you only need 1 of the servers so delete webserver2 from your code. Terraform runs a plan and sees there is now only a single VM definition but 2 VMs in state. Neither of the terraform identifiers match the original resources. How does it know which one was renamed and which one to delete?

Example 2:

You use Terraform for IaC and something like Chef for configuration management so your Terraform code exclusively deals with the "hardware". A service is being migrated to a new implementation so you need to delete the old VM and bring up a new one. Both old and new implementation have the same exact hardware requirements. You make the change in your Terraform code, deleting the old resource and creating a new one with the same requirements but a different name, and run a plan. Terraform tells you there's nothing to change because its inferred that you wanted to rename.

Re: Terraform 1.0

#313

Post by tehbeard »

randomswede wrote: post #311
tehbeard wrote: post #307

Earlier quoted context omitted.

I guess I need an example of the declarative model, as I can see the Ansible model in my head and it still looks declarative to me atleast at the singular module level. in Ansible, you say "make sure these packages are installed" and they'll be installed as needed, to match that state, or ignored if already there. Even the file level stuff you can say "make sure this line is in the file" and it either adds it or says…

It is not declarative. The simple fact that the playbook will ALWAYS be run in the order you specify, even if a later step is (technically) a prerequisite of a previous step, means that you are in an imperative mode. Puppet is declarative, you simply say "these things must, or must not, hold" and a combination of user-declared and inferred dependencies arrange the sequencing, which can be different in each run (as lo…

Ah so it's that the playbooks are imperative and "dumb" (does exactly what you tell it, rather than inferring "these actions must happen, do them in a sensible order"). That makes sense.

Dove into the puppet docs/wiki article, I guess part of the difference as well is that puppet considers each "unit" a resource, vs. ansible being a "module/action".

It does seem like ansible roles have a dependency mechanism, I guess that might be the intended level for a "declarative" approach in ansible, to encapsulate the playbooks/modules underneath that are more of an implementation detail at that point.

Re: Terraform 1.0

#314

Post by buggeryorkshire »

jimpudar wrote: post #116
buggeryorkshire wrote: post #72

Earlier quoted context omitted.

Yup, that's the best use-case. The more that cloudy / container stuff takes over the less I use Ansible tbf.

A lot of post provisioning tasks I used to do with Ansible are now handled with cloud-init.

Exactly. We use it in the pipeline for building the AMI unfortunately at my current place but it's not optimal.

Re: Terraform 1.0

#315

Post by jimpudar »

buggeryorkshire wrote: post #314
jimpudar wrote: post #116

Earlier quoted context omitted.

A lot of post provisioning tasks I used to do with Ansible are now handled with cloud-init.

Exactly. We use it in the pipeline for building the AMI unfortunately at my current place but it's not optimal.

I like Packer + Ansible for building machine images. I haven't really tried any alternative workflows but that has been great for my needs so far!
Post reply on HN