An interesting document is also what is actually covered by the 1.0.0 compatibility guarantee: https://www.terraform.io/docs/language/v1-compatibility-prom...
The v1 guarantee is they will break your code at anytime just like before v1.
Terraform 1.0
81–90 of 315 posts
Re: Terraform 1.0
#82Earlier quoted context omitted.
How does terraform compare to ansible?
Ansible focuses on provisioning machines whereas Terraform focuses on creating Cloud infrastructure. A common combo is using Terraform to provision VMs and networking settings then using Ansible to configure those VMs. I find few if any reasons to use Ansible over a shell script. IMHO Ansible is just a weird YAML syntax to generate a "shell" script with some utilities to ship that script to nodes over the network. I…
You can totally provision using ansible too, on most cloud vendors.
The reason to use ansible over a shell script is that the ansible playbook will be idempotent. That is to say you can run/rerun the playbook from any point without having to wipe any previous work, or worry about double applying your config changes.
Re: Terraform 1.0
#83Just be careful with your state file when upgrading!
I've gotten into the habit of manually creating a backup of the state file: # to view the state file $ aws s3 cp --quiet s3://terraform/production/terraform.tfstate /dev/stdout # to backup the state file $ aws s3 cp --quiet s3://terraform/production/terraform.tfstate > terraform.tfstate.bak
S3 automatic object versioning is useful for that.
Re: Terraform 1.0
#84I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…
I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…
Dang, your solution sound so much like kubernetes I'm not sure if you are joking or not.
Re: Terraform 1.0
#85I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…
Amen! I found it excruciating that the language was always a few simple steps away from being homomorphic to JSON. I desperately needed to be able to manipulate it as data structures, not as strings. All of the ways I found to work around its limitations made me wish for something else entirely.
Have you used it since they introduced HCL2? It supports other data structures much better than it used to. Maps, lists, sets, etc. are much easier to work with.
Re: Terraform 1.0
#86Serious question. What value does Terraform provide? Two years ago I looked into it and rather then having an abstraction from cloud providers it seemed to require to still target (and code against) each one specifically. So, I was quite disappointed as I thought the value proposition was to not have to know x cloud provider specific terminologies. Any insights much appreciated. Edit: I was a little worried asking su…
Abstracting over Cloud vendors is not a use case for Terraform itself. The value it brings is that you get to specify your infrastructure 'as code', which means you'll be able to re-create it from code, and reliably deploy changes. There's a lot more benefits, it depends on what you are comparing it against. Coming from a software development background, I'd like to compare it to a wordpress app vs webapp development…
So... is Terraform the Wordpress app or the rails app? :D
Re: Terraform 1.0
#87Earlier quoted context omitted.
This works even without the depends_on property. All you need to is have the module you use for creating the cluster have an output that is guaranteed to be a computed property. Then use that computed property as input variable for whatever you want to deploy into Kubernetes. We're using this with multiple providers and it works. Of course, an actual dependency that's visible would be better.
I'd love to see an example of this actually working, because I have had the opposite experience (explicitly with the Kubernetes and Helm providers); I've had to do applies in multiple steps.
This should work (as in, it will create the cluster and only then add the k8s resource to it, in the same plan/apply).
Here the module creates an EKS cluster, but this would work for any module that creates a k8s cluster.
module "my_cluster" {
source = "terraform-aws-modules/eks/aws"
version = "17.0.2"
cluster_name = "my-cluster"
cluster_version = "1.18"
}
# Queries for Kubernetes authentication
# this data query depends on the module my_cluster
data "aws_eks_cluster" "my_cluster" {
name = module.my_cluster.cluster_id
}
# this data query depends on the module my_cluster
data "aws_eks_cluster_auth" "my_cluster" {
name = module.my_cluster.cluster_id
}
# this provider depends on the data query above, which depends on the module my_cluster
provider "kubernetes" {
host = data.aws_eks_cluster.my_cluster.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.my_cluster.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.my_cluster.token
load_config_file = false
}
# this provider depends on the data query above, which depends on the module my_cluster
provider "helm" {
kubernetes {
host = data.aws_eks_cluster.my_cluster.endpoint
cluster_ca_certificate = base64decode(data.aws_eks_cluster.my_cluster.certificate_authority.0.data)
token = data.aws_eks_cluster_auth.my_cluster.token
load_config_file = false
}
}
# this resource depends on the k8s provider, which depends on the data query above, which depends on the module my_cluster
resource "kubernetes_namespace" "namespaces" {
metadata {
name = "my-namespace"
}
}Re: Terraform 1.0
#88Can someone explain in a few words what this is and who may be interested in this? The name does not give any hints, also the discription tells me nothing: "Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned…
You could have read more of the site or even looked it up on Wikipedia in the time it took for you to write your comment.
Re: Terraform 1.0
#89I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…
Have you tried Terragrunt [0]? It helps a lot with managing a set of related stacks. Still feels like a bandaid on a broken model, but it is what we have.
[0] https://terragrunt.gruntwork.io/
Regarding performance, last time I looked, Hashicorp's documentation implied there was no limit to the size of a Terraform stack. I think they meant theoretically in a science fiction universe where humanity had captured all of the sun's output to perform terraform plan and apply...
Re: Terraform 1.0
#90Earlier quoted context omitted.
Ansible focuses on provisioning machines whereas Terraform focuses on creating Cloud infrastructure. A common combo is using Terraform to provision VMs and networking settings then using Ansible to configure those VMs. I find few if any reasons to use Ansible over a shell script. IMHO Ansible is just a weird YAML syntax to generate a "shell" script with some utilities to ship that script to nodes over the network. I…
You can totally provision using ansible too, on most cloud vendors. The reason to use ansible over a shell script is that the ansible playbook will be idempotent. That is to say you can run/rerun the playbook from any point without having to wipe any previous work, or worry about double applying your config changes.
> is that the ansible playbook will be idempotent
This isn't really true. I think you are correct that most of the built-in operations are idempotent but you can also do this with a small library of functions in a shell/python script or whatever you prefer. Most things you want to do on provision are idempotent anyways (install this package, download this file) or are trivial to make so (create this directory).
I would take a real programming language any day for the minor cost of having to handle idempotency myself. It would take a couple of hours to reimplement idempotent primitives to replace the Ansible standard library in just about any language.
In my mind the main value of Ansible is playbooks that others have made for you, but many people avoid these anyways to have full control.