Infrastructure of code is just the process of writing down what makes a particular machine unique, in a way that both computers and humans can understand. (When I say infrastructure here, this is most often the servers that make up and support a given application or service.)
Depending on what configuration management software you choose to help you with this, you might be using Ruby, Python, or even Bash.
Does it run an http server? Does it have an increased number of file descriptors? What config files need to be in place for it to operate?
This resultant code can be run to recreate a machine or if it was changed incorrectly, even bring it back inline with how it should be if changes were made manually.
Having the definition be code allows you to do some things like:
- Versioning it. You can know when a change was made, by whom, and see the difference between versions.
- You can review changes. Since the definition is code you can begin to apply your peer review process (you do have a peer review process right?).
- It makes it easier to do the right thing. Ever find yourself SSH’d into a server (perhaps even prod?!) and making a change, all the while thinking “I’ll document this later, after I make sure it works.” IAC helps you avoid this. The way to make the change is the same way to codify it.
How does this differ from documentation? The code is human readable, but also machine runnable, so servers can be recreated/updated as needed where as with docs, there are separate steps, update the machine (by hand?) and then update the docs.
With infrastructure as code, defining/updating the state that you want is the same thing as documenting it.
Infrastructure as code is not the same as documentation. Just having the definition of a server codified and recreatable is not a replacement for documentation, but it allows you to focus on your docs on different things.
Instead of having to go through and write everything down all over again about what’s on the server, you can write about why that server does what it does and how it relates to other infrastructure or applications.
For example instead of having to say Server X is a CentOS server that runs Application Y and has ruby version 2.2.3 and is firewalled with such and such iptables rules. You can instead focus on docs like server X is a server for Application Y and is critical for it to continue running. If you need to know what’s on the box and its version, see the code.
What do you think? Leave a comment. For more like this see: https://thaiwood.io/DevTo
Top comments (0)