Hacker News Reader

Hacker News

Comment by Chilinot | Hacker News Reader

Parent Full thread

Chilinot

Terraform allows us to implement development practices into our sysadmin lives. Such as code reviews, etc.

For example, at my work this is what i do to apply changes to our AWS setup:

1. Fetch the latest version of our git repo.

2. Create a new git branch named after the Jira ticket im working on.

3. Solve the jira ticket by modifying the terraform code accordingly.

4. Submit a pull request and assign one of my colleagues as reviewer.

5. They review my solution, tell me to correct some issues that there might be, or straight up approves my solution.

6. My PR is merged into master.

7. I download the latest master version and apply the codebase.

This way we always have at least two people verify any changes to our infrastructure, minimizing the risk of fuckups and ensures solutions are as good as possible.

View on HN

Reading the sister comments, I kind of understand the appeal of terraform for huge/multi cloud infra systems.

Now, managing changes in code doesn’t look too far from dealing with kubernetes’ json/yml config and applying them to the current cluster, provided it would be trickier when expanding to multiple cluster or doing complex orchestrating.

I guess TF makes a lot more sense for on-premise, bare metal VMs ?

I think the right way is to use TF to provision the kubernetes cluster and underlying resources such as storage connections, dns, etc, and then use kubernetes to deploy the app.

Also cloud hosted services. E.g., terraform knows how to manage hundreds of AWS resource types (IAM roles, DynamoDB tables, S3 buckets), sometimes even before CloudFormation does.

There seems to be some kind of https://github.com/aws-controllers-k8s/community in early beta, but I don’t know how much it supports so far or whether it can diff a resource and modify it in-place.

> I guess TF makes a lot more sense for on-premise, bare metal VMs ?

No, not necessarily. If you have an API for orchestrating your on-premise infrastructure (openstack etc), then sure.

Where terraform shines is managing resources in your cloud provider.

I.E. creating the GCP project and GKE cluster that you need before you can apply your k8s YAML. Or creating the cloudsql databases, GCS buckets, etc that the apps running in your k8s cluster need.

Use Terraform for bringing up the Kubernetes cluster and other related cloud resources (storage, load balancers, DNS, etc).

Once you have a cluster up and running you can just use kubernetes yml to manage the cluster.

It is possible to also use Terraform to manipulate kubernetes resources (or AWS ECS or another container platform) but I personally like a clear separation between infrastructure (bringing up the environment using Terraform) and scheduling work on a cluster (using kubectl)

So TF would come where you would otherwise use gcloud commands, if I get it.

One part of the cluster building that caught me off-guard with GCP is that cluster options effectively change over time, as the k8s versions march forward.

For instance some feature go out of beta and become the default, and trying to rebuild a cluster exactly similar to one built year ago would require specific “don’t use that new feature” flags added to it. Or using these new features require adapting the other resources to the new configurations.

I guess TF is still useful in that it helps audit and reproduce the same infra inbetween changes, and will be nicer as an interface than bash scripts, even if it won’t save from dealing with nitty gritty of the platform.

Indeed, I see TF mostly as an automation/idempotency tool for setting up and maintaining infrastructure components like Kubernetes clusters, ECS clusters, load balancers and all that. Something you would normally do with gcloud or aws-cli or by clicking around in GCP/AWS web console.

Yes, the "provider churn" is real: defaults on cloud platforms can change and platform-specific TF providers can change as well. The way I usually deal with that is to make sure my TF repo's stays in shape by applying them regularly. If you haven't applied a TF repo in over a year chances are real that your repo has rotted. In a similar way to an old Ansible playbook that has rotted because some apt packages have new dependencies. Keep applying them regularly and manage changes in small chunks instead of once a year.

Auditing is really useful. I would recommend preventing developers from applying TF to production directly, and have it all managed by a CI pipeline.

Also with some careful planning and structuring of your TF repository. It's pretty straightforward to duplicate environments: for example: spin up an extra development environment to experiment with a newer K8s version, or to validate some infrastructure changes.

> I guess TF makes a lot more sense for on-premise, bare metal VMs ?

Sure. And also for Kubernetes json/yml. You don't just create infrastructure but it will also change -> delete/create.

And establishing a process how to delete your Kubernetes json/yml files in some form of codereview or in some way so you know what it actually deployed, you end up with a tool like terraform.

Reply on news.ycombinator.com