Home/Start here/What these tools do
What these tools do
Three tools show up in almost every modern infrastructure job. Here is what each one is for, in plain words.
They are often talked about as if they compete. They do not. Each one owns a different layer, and a normal setup uses all three at once.
The one-line version
| Tool | What it does | When you reach for it |
|---|---|---|
| Terraform | Creates and changes things in a cloud account | You need a network, a virtual machine, a bucket, a database, a key, a permission |
| Ansible | Sets up the inside of machines that already exist | You need a package installed, a config file written, a service restarted, on many machines at once |
| Argo CD | Keeps a Kubernetes cluster matching a Git repository | You have containers running on a cluster and want what is running to match what is written down |
The idea underneath all three
Clicking through a cloud console works the first time. It stops working the fifth time, on a Friday, when the person who did it originally is on holiday and nobody wrote down which checkbox they ticked.
All three tools solve that the same way. You write down what you want in a file, the file goes into version control, and a tool makes reality match the file. That gives you four things that clicking never will:
- A record. Every change has an author, a date, and a reason.
- Review. Someone else can read the change before it happens.
- Repetition. The same file builds a second environment that actually matches the first.
- Reversal. Putting it back is one revert.
The shorthand for this is infrastructure as code. That is the whole idea. Everything else is detail.
Two words worth learning now
Declarative means you describe the end result and the tool works out the steps. You write "there should be one bucket, versioned, with public access blocked." You do not write "create a bucket, then turn on versioning, then block public access." If the bucket already exists and only versioning is missing, the tool turns on versioning and leaves the rest alone.
Idempotent means running it twice is safe. The second run looks at what is already true and does nothing. This is what lets you run the same thing on a schedule without fear, and it is the property that separates these tools from a shell script.
A first afternoon
If you want to learn by doing, these four templates in this order take you from one machine to a cluster. Each quick start is one file.
- Lock SSH down to keys only. Ansible against one Linux machine you already have. The smallest thing here, and it teaches you to read a run.
- Audit logs nobody can delete. Terraform in a scratch cloud account. You practise reading a plan, and the lock lasts one day so you can clean up tomorrow.
- Point Argo CD at a repository. The first thing to do on any cluster, and the moment the pull model makes sense.
- See what containers are doing while they run. Deployed through the thing you set up in step three, which is the whole idea working end to end.
Where to go next
Builds the thing. Start here, because most results need something to exist before the other two have anything to work on.
Sets up the inside of machines. No agent to install, works over SSH.
Keeps a Kubernetes cluster honest against what is in Git.
The handful of things that go wrong the first time, with each tool.
Plain definitions for the terms that get used without explanation.