4 ms·

If you are new to both and to IaC and DevOps as a whole: Ansible is for 'inside' virtual machines or computers, Terraform is for 'outside' virtual machines or

If you are new to both and to IaC and DevOps as a whole: Ansible is for 'inside' virtual machines or computers, Terraform is for 'outside' virtual machines or computers. Inside a machine you might have software, configuration, assets. Outside a machine you might network connections, firewalls, disks, dns etc. This isn't a comprehensive comparison, but when you start from nothing, it doesn't really help to do a syntax, provider or imperative vs. declarative.

bryogenic 7y ago
Ansible also does 'outside' virtual machines. See https://docs.ansible.com/ansible/2.3/list_of_cloud_modules.html https://docs.ansible.com/ansible/2.3/list_of_cloud_modules.h...
- scoot_718 7y ago
  My advice would be to avoid Ansible for that sort of thing like the plague. All the nice things like idempotency and having the same script for setting things up and tearing them down no longer function when using those modules. Essentially you need to 1. do the checks to ensure your playbook won't just create a new set of VMs every time it's run if they already exist 2. maintain a teardown playbook alongside your setup one because Ansible is entirely procedural and the steps would be reversed in that case and 3. do queries first to determine what actually exists in the cloud and do lots of jinja manipulations to work on the right things. Did you know EC2 has default subnets and routing tables? Did you know that the Ansible module will error out if you try to delete those objects? If only there was a thing like Terraform that could just rely on a single description of the setup you'd like. Seriously. There's an Ansible module that will run a Terraform .tf file, and there's a provider for terraform that will run Ansible on the servers it provisions.
  - PaywallBuster 7y ago
    I think you're exagerating. I use Ansible to provision dev environments on each PR, it works fine, every time a deployment occurs Ansible will deploy if required, otherwise proceeded with the deployment. Destroying the environment is done separate, triggered by a webhook once the PR is closed.
    - scoot_718 7y ago
      If you're just provisioning software on an individual server, then sure. I agree. It kinda works okay. What I'm talking about is using the cloud modules to spin up servers, and god help you, entire VPC set ups.
      - PaywallBuster 7y ago
        Each PR will provision a new server and then configure/deploy.
        scoot_718 7y ago
        So wait, you make a playbook per individual server instance? Why?
        zufallsheld 7y ago
        He didn't say that. He presumably uses one playbook that creates vms and provisions the software for every PR. With ansible this can be idempotent and creating vms is by default idempotent.
- oneplane 7y ago
  Yep it does indeed, Ansible also can talk to AWS, GCP etc, but that is not the point ;-) (And Terraform can SSH in to machines and execute commands just fine) If someone is new to this, having a strong boundary makes it much easier to process how those systems are intended to be used and how they are built. There are certain assumptions made in both that make them work differently, i.e. being command centric vs. resource centric. That's interesting when someone is up to the point where you can apply what you know in a more general or generic sense, because then he systems themselves matter less.

bryogenic 7y ago

Ansible also does 'outside' virtual machines. See https://docs.ansible.com/ansible/2.3/list_of_cloud_modules.html https://docs.ansible.com/ansible/2.3/list_of_cloud_modules.h...

scoot_718 7y ago
My advice would be to avoid Ansible for that sort of thing like the plague. All the nice things like idempotency and having the same script for setting things up and tearing them down no longer function when using those modules. Essentially you need to 1. do the checks to ensure your playbook won't just create a new set of VMs every time it's run if they already exist 2. maintain a teardown playbook alongside your setup one because Ansible is entirely procedural and the steps would be reversed in that case and 3. do queries first to determine what actually exists in the cloud and do lots of jinja manipulations to work on the right things. Did you know EC2 has default subnets and routing tables? Did you know that the Ansible module will error out if you try to delete those objects? If only there was a thing like Terraform that could just rely on a single description of the setup you'd like. Seriously. There's an Ansible module that will run a Terraform .tf file, and there's a provider for terraform that will run Ansible on the servers it provisions.
- PaywallBuster 7y ago
  I think you're exagerating. I use Ansible to provision dev environments on each PR, it works fine, every time a deployment occurs Ansible will deploy if required, otherwise proceeded with the deployment. Destroying the environment is done separate, triggered by a webhook once the PR is closed.
  - scoot_718 7y ago
    If you're just provisioning software on an individual server, then sure. I agree. It kinda works okay. What I'm talking about is using the cloud modules to spin up servers, and god help you, entire VPC set ups.
    - PaywallBuster 7y ago
      Each PR will provision a new server and then configure/deploy.
      - scoot_718 7y ago
        So wait, you make a playbook per individual server instance? Why?
        zufallsheld 7y ago
        He didn't say that. He presumably uses one playbook that creates vms and provisions the software for every PR. With ansible this can be idempotent and creating vms is by default idempotent.
oneplane 7y ago
Yep it does indeed, Ansible also can talk to AWS, GCP etc, but that is not the point ;-) (And Terraform can SSH in to machines and execute commands just fine) If someone is new to this, having a strong boundary makes it much easier to process how those systems are intended to be used and how they are built. There are certain assumptions made in both that make them work differently, i.e. being command centric vs. resource centric. That's interesting when someone is up to the point where you can apply what you know in a more general or generic sense, because then he systems themselves matter less.