【知識編】インフラ構成のコード化。構成管理をスマートにするための「infrastructure as code」という考え方を学ぼう。

インフラエンジニアの寺岡です。
今回のブログのテーマはこちら ⇒ infrastructure as code
書く内容を考えていると思いのほか長くなってしまったので、知識編と技術編で分けることにしました。
まずは知識編。infrastructure as codeってなんだろう？からまとめていきます。

■「infrastructure as code」ってなんだろう？

一言で言うとインフラ構成をコード化することです。（そのままですね、Google翻訳もびっくりです。）
最近はAWSなどのクラウドサービスが主流なので
インフラの新規構築・変更などはGUI画面からボタンをポチっとなで終わりますが
infrastructure as codeではそんなことはしません。
プログラムのように全てコードとして記述して
それを専用のツールを使ってデプロイすることでインフラを構築します。
専用のツールに「terraform」というものがあるので
それを技術編でご紹介しますね！（後日ブログで書きます）

■そもそも何故「コード化」するのか？

メリットがないのにわざわざこんなことしないですよね。（ちゃんとメリットがあります）
まとめると以下のようになります↓

インフラ構築の自動化

これが一番大きなメリットではないでしょうか。
同じ構成のサーバを複数台構築する必要がある場合など
手作業でやっていると二度手間なことが数多くあります。
全く同じ作業をサーバの台数だけ繰り返さないといけないのか。できればやりたくないですよね。

前の項目で以下のように書きました。

プログラムのように全て「コード」として記述して
それを専用のツールを使ってデプロイすることでインフラを構築します。

「こんなインフラ構成を作りますよ」という構成はすでに予めコードとして記述しているので
専用のツールに「こんな感じで作ってね」とお願いするだけです。後は自動で全てやってくれます。
また、コードを実行するだけなので誰が作業をしても必ず同じ結果を得ることができます。
これによってヒューマンエラーも防ぐことが可能です。

インフラ構成の一元管理

インフラを新規構築もしくは変更を行う場合は必ず
「どういう構成になっているのか」や「いつどの部分を変更したのか」を形として残す必要があります。
（設計書とか手順書って言われているものですね）
残しておかないと、「今どのような構成になっているのか」がわからなくなってくるからです。
（これがわからなくなってくると当然オペミスが発生します）

また、設計書や手順書を残す場合
何か作業を行ったときはドキュメントを最新の情報に更新しておく必要があります。
次に同じ作業を行うときはそのドキュメントを参照することになるからです。
しかし人間が手作業で行うから間違いは付き物。
ドキュメントの更新を忘れているなんてことは容易に考えられます。
そうなってくると、ドキュメントの内容と実際の構成が何故か違うというような状態に。
ドキュメントの最終更新者が前任者ですでに現場を離れている
なんてことになれば目も当てられません・・・

infrastructure as codeでは
予めコードという形で作成された手順書をもとにインフラを構築するという特性上
設定の変更を行う場合は必ずコードを編集する必要があるので、更新忘れは起こりません。
さらに、プログラムのソースと同じようにGitなどでバージョン管理を行うことも可能です。

■便利だけど懸念点も

学習コストが当然上がる

コードが書けないとそもそも構成を変更することもできません。
また、デプロイするためのツールの使い方も新しく覚える必要があります。
この点で少なからず学習コストが上がってしまうと思います。
インフラエンジニアもコードが書けないと仕事ができない時代になるのでしょうか・・・（

コードだから想定外のエラーが出る

コードの記述にミスがあるとエラーで停止します。(プログラム言語と同じですね)
ミスがある状態でデプロイをやってしまうと精神衛生上よくないので
Githubなどでコードを共有することでナレッジの属人化を防ぎ
常に第三者の目を通してミスに気付けるような運用フローが必要かと思います。

■まとめ

知識編は正直長い文章を読むだけですね（
きちっと仕組みを理解して運用できれば魅力的な考え方だと思います。
何よりinfrastructure as codeという響きがかっこいいです。
・・・・冗談はここまで、次回は技術編なので手を動かしましょう。お楽しみに！！