[Knowledge Edition] Coding of infrastructure configuration. Learn the concept of "infrastructure as code" to make configuration management smarter.

name is Teraoka, and I'm an infrastructure engineer.
Today's blog post is about infrastructure as code.
Since it ended up being longer than I expected, I decided to split it into a knowledge section and a technical section.
First, let's start with the knowledge section . What is infrastructure as code

■What is “infrastructure as code”?

In a nutshell, coding infrastructure configuration . (That's exactly what it sounds like, even Google Translate would be surprised.)
These days, cloud services like AWS are mainstream, so
building new infrastructure or making changes can be done by simply clicking a button on a GUI screen, but
infrastructure as code , you don't do that.

You build infrastructure by writing everything as code, like a program, and then deploying it using a dedicated tool.
One such dedicated tool is "terraform,"
which I'll introduce in the technical section! (I'll write about it in a blog later.)

■Why "code" in the first place?

You wouldn't do something like this if there was no benefit to it. (There are benefits, though.)
To summarize, it's as follows:

Automating infrastructure construction

This is probably the biggest benefit.
If you need to build multiple servers with the same configuration,
doing it manually can often be a double effort.
Do you have to repeat the exact same work for each server? If possible, you don't want to do that.

In the previous section, I wrote the following:

by writing everything as "code" like a program and
deploying it using dedicated tools.

The infrastructure configuration you want to create is already written as code, so
all you have to do is tell the dedicated tool to create it like this. The rest is done automatically.
, you can be sure to get the same results no matter
who is doing the work This also helps prevent human error .

Centralized management of infrastructure configuration

When building or modifying infrastructure, it
is necessary to leave a tangible record of "what the configuration is" and "when and which parts were changed."
(These are called design documents or procedure manuals.)
If you don't leave a record, you won't know what the current configuration is.
(Once you lose track of this, operational errors will naturally occur.)

Also, when leaving design documents or procedure manuals,
you need to update the documents with the latest information after completing a task. This
is because the next time you perform the same task, you will need to refer to the documents.
However, since this is done manually by humans, mistakes are inevitable.
It is easy to think that someone will forget to update the documents.
When this happens, the contents of the documents and the actual structure may somehow differ. It

would be a disaster if the person who last updated the documents was your predecessor and has already left the site

With
infrastructure as code , infrastructure is built based on pre-written instructions, meaning that any
configuration changes require editing the code , eliminating the risk of forgetting to update.
version control with tools like Git is possible just like with program source code .

■It's convenient, but there are some concerns

The cost of learning will naturally increase

If you can't write code, you can't even change the configuration.
You also need to learn how to use new tools for deployment.
This will increase the learning costs to a certain extent.
Will we be entering an era where infrastructure engineers can't do their jobs if they can't write code?

The code causes an unexpected error

If there is an error in the code, the project will stop with an error (just like with any programming language).
Deploying with an error is not good for your mental health, so
to share the code on Github or elsewhere to prevent knowledge from becoming too personal and
to have a third party constantly look out for errors.

■Summary

To be honest, the knowledge section is just about reading long sentences (
I think it's an attractive idea if you can understand the system properly and operate it properly
Above all, the term "infrastructure as code" sounds cool
...Enough joking, next time we'll get to the technical part, so let's get to work. Stay tuned!!