6 ms·

Because the state exists regardless. When you write code that interfaces with AWS, there's always something that exists on the other side of the AWS API. The qu

Because the state exists regardless. When you write code that interfaces with AWS, there's always something that exists on the other side of the AWS API. The question you have is, how do you programmatically keep a copy of that state on your side of the API? The naive approach that tries to do this without state in code goes something like: a) invoke the remote API to look for something that should exist b) if it doesn't exist, invoke the remote API to create it c) use the property of the thing to do something else What Terraform does is cleanly separate your state (don't look stuff up you already know exists) from the API (which is handled by an open-source library, aka the provider) from your configuration (which can now be declarative). Because the state and API calls are abstracted away, the configuration itself is much more clean, easy to reason about, and easier to maintain.

mr_C 6y ago
Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the existing resources we already have... every time I run a playbook I know that everything will end up just like I want it to be. Not bad for a naive approach I guess.
- llbeansandrice 6y ago
  I haven't used Ansible so maybe I'm incorrect here but aren't tf and Ansible solving slightly different problems? Terraform feels like infrastructure management to me. We use it to provision underlying resources: Networking, Clusters, Nodes, Alerts, etc. All of the actual code deployments are entirely separate. Ansible is more of a configuration management right?
  - ggregoire 6y ago
    I've never used them but there are modules to provision stuff on AWS: https://docs.ansible.com/ansible/latest/scenario_guides/guide_aws.html https://docs.ansible.com/ansible/latest/scenario_guides/guid... Edit: seems limited to ec2 and s3: https://docs.ansible.com/ansible/latest/collections/amazon/aws/index.html#plugins-in-amazon-aws https://docs.ansible.com/ansible/latest/collections/amazon/a... Although you could provision other services with some custom modules using the aws-cli.
    - deleted 6y ago
      [deleted]
  - timdev2 6y ago
    Right. And you can use something like terraform-inventory[0] as a dynamic inventory source in Ansible. So TF manages all the bits and bobs floating around in AWS, and then ansible takes over to manage configuration on whatever EC2 instances are involved. [0]: https://github.com/adammck/terraform-inventory https://github.com/adammck/terraform-inventory
  - throwdbaaway 6y ago
    Not really. In terms of functionalities, I consider ansible as a superset of terraform, without all the state management stuffs. Distributed systems are hard, and I will just let my cloud providers to be the single source of truth of all the states. Here's a comment from the author of ansible when terraform was first released: https://news.ycombinator.com/item?id=8100036 https://news.ycombinator.com/item?id=8100036 > One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.
  - matwood 6y ago
    Yeah. I use packer and ansible to build/configure AMIs. Terraform manages the configuration that launches said AMIs (through things like autoscaling, etc...).
- diroussel 6y ago
  If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whereas terraform is much more declarative.
  - mr_C 6y ago
    Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.
    - erik_seaberg 6y ago
      Some cloud resources will cost money every month, forever. (I think this is an unappreciated side of the AWS business model; it’s not cost-effective to have a dev confirm that each resource can be safely decomm’d.) There’s also a risk that your legacy environments only work because some dangling resource wasn’t cleaned up, and a new clone of the environment will fail.
    - deleted 6y ago
      [deleted]
    - ncallaway 6y ago
      > Who cares if there is a dangling dns records somewhere or an extra allocated floating ip What if instead of a dangling dns record, its 15 large EC2 instances? Yes, you can come up with examples of trivial dangling resources, but it's just as easy for me to come up with non-trivial examples of dangling resources.
      - mr_C 6y ago
        I came up with trivial examples because no one forgets about non-trivial resources. In my opinion, if you decrease some instance count from 18 to 3, you'd rather waste 1 minute deleting 15 instances than dealing with all the problems a state management brings to the table.
- matwood 6y ago
  > upgrades between versions are smooth I use tf and ansible regularly. I wouldn't call ansible upgrades exactly smooth, they deprecate features just like anyone else.
- apple4ever 6y ago
  How do you ensure you have say 2 web servers created and connected to a load balancer? Is that part of your custom module?
  - mr_C 6y ago
    Using ec2_instance_info to check if the instance exists filtering by name (eg: selectattr('tags.Name', 'defined') | selectattr('tags.Name', 'equalto', server_name) ) and then standard ec2_instance module, same for lb.

mr_C 6y ago

Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the existing resources we already have... every time I run a playbook I know that everything will end up just like I want it to be. Not bad for a naive approach I guess.

llbeansandrice 6y ago
I haven't used Ansible so maybe I'm incorrect here but aren't tf and Ansible solving slightly different problems? Terraform feels like infrastructure management to me. We use it to provision underlying resources: Networking, Clusters, Nodes, Alerts, etc. All of the actual code deployments are entirely separate. Ansible is more of a configuration management right?
- ggregoire 6y ago
  I've never used them but there are modules to provision stuff on AWS: https://docs.ansible.com/ansible/latest/scenario_guides/guide_aws.html https://docs.ansible.com/ansible/latest/scenario_guides/guid... Edit: seems limited to ec2 and s3: https://docs.ansible.com/ansible/latest/collections/amazon/aws/index.html#plugins-in-amazon-aws https://docs.ansible.com/ansible/latest/collections/amazon/a... Although you could provision other services with some custom modules using the aws-cli.
  - deleted 6y ago
    [deleted]
- timdev2 6y ago
  Right. And you can use something like terraform-inventory[0] as a dynamic inventory source in Ansible. So TF manages all the bits and bobs floating around in AWS, and then ansible takes over to manage configuration on whatever EC2 instances are involved. [0]: https://github.com/adammck/terraform-inventory https://github.com/adammck/terraform-inventory
- throwdbaaway 6y ago
  Not really. In terms of functionalities, I consider ansible as a superset of terraform, without all the state management stuffs. Distributed systems are hard, and I will just let my cloud providers to be the single source of truth of all the states. Here's a comment from the author of ansible when terraform was first released: https://news.ycombinator.com/item?id=8100036 https://news.ycombinator.com/item?id=8100036 > One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.
- matwood 6y ago
  Yeah. I use packer and ansible to build/configure AMIs. Terraform manages the configuration that launches said AMIs (through things like autoscaling, etc...).
diroussel 6y ago
If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whereas terraform is much more declarative.
- mr_C 6y ago
  Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.
  - erik_seaberg 6y ago
    Some cloud resources will cost money every month, forever. (I think this is an unappreciated side of the AWS business model; it’s not cost-effective to have a dev confirm that each resource can be safely decomm’d.) There’s also a risk that your legacy environments only work because some dangling resource wasn’t cleaned up, and a new clone of the environment will fail.
  - deleted 6y ago
    [deleted]
  - ncallaway 6y ago
    > Who cares if there is a dangling dns records somewhere or an extra allocated floating ip What if instead of a dangling dns record, its 15 large EC2 instances? Yes, you can come up with examples of trivial dangling resources, but it's just as easy for me to come up with non-trivial examples of dangling resources.
    - mr_C 6y ago
      I came up with trivial examples because no one forgets about non-trivial resources. In my opinion, if you decrease some instance count from 18 to 3, you'd rather waste 1 minute deleting 15 instances than dealing with all the problems a state management brings to the table.
matwood 6y ago
> upgrades between versions are smooth I use tf and ansible regularly. I wouldn't call ansible upgrades exactly smooth, they deprecate features just like anyone else.
apple4ever 6y ago
How do you ensure you have say 2 web servers created and connected to a load balancer? Is that part of your custom module?
- mr_C 6y ago
  Using ec2_instance_info to check if the instance exists filtering by name (eg: selectattr('tags.Name', 'defined') | selectattr('tags.Name', 'equalto', server_name) ) and then standard ec2_instance module, same for lb.