【大阪 / 横浜】インフラ / サーバーサイドエンジニア募集中!

【大阪 / 横浜】インフラ / サーバーサイドエンジニア募集中!

【導入実績 500社以上】AWS 構築・運用保守・監視サービス

【導入実績 500社以上】AWS 構築・運用保守・監視サービス

【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス

【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス

【WordPress 専用】クラウドサーバー『ウェブスピード』

【WordPress 専用】クラウドサーバー『ウェブスピード』

【格安】Webサイト セキュリティ自動診断「クイックスキャナー」

【格安】Webサイト セキュリティ自動診断「クイックスキャナー」

【予約システム開発】EDISONE カスタマイズ開発サービス

【予約システム開発】EDISONE カスタマイズ開発サービス

【100URLの登録が0円】Webサイト監視サービス『Appmill』

【100URLの登録が0円】Webサイト監視サービス『Appmill』

【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」

【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」

【中国への旅行・出張・駐在なら】中国SIMサービス「チョコSIM」

【中国への旅行・出張・駐在なら】中国SIMサービス「チョコSIM」

【グローバル専用サービス】北米・中国でも、ビヨンドのMSP

【グローバル専用サービス】北米・中国でも、ビヨンドのMSP

【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」

【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」

【知識編】インフラ構成のコード化。構成管理をスマートにするための「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という響きがかっこいいです。
・・・・冗談はここまで、次回は技術編なので手を動かしましょう。お楽しみに!!

この記事がお役に立てば【 いいね 】のご協力をお願いいたします!
1
読み込み中...
1 票, 平均: 1.00 / 11
5,441
X facebook はてなブックマーク pocket
【2024.6.30 CentOS サポート終了】CentOS サーバー移行ソリューション

【2024.6.30 CentOS サポート終了】CentOS サーバー移行ソリューション

【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション

【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション

【大阪 / 横浜】インフラエンジニア・サーバーサイドエンジニア 積極採用中!

【大阪 / 横浜】インフラエンジニア・サーバーサイドエンジニア 積極採用中!

この記事をかいた人

About the author

寺岡佑樹

2016年ビヨンド入社、現在6年目のインフラエンジニア
MSPの中の人として障害対応時のトラブルシューティングを行いながら
AWSなどのパブリッククラウドを用いたインフラの設計/構築も行っている。
最近はDockerやKubernetesなどのコンテナ基盤の構築や
運用自動化の一環としてTerraformやPackerなどのHashicorpツールを扱うことが多く
外部の勉強会やセミナーで登壇するEvangelistの役割も担っている。

・GitHub
https://github.com/nezumisannn

・登壇経歴
https://github.com/nezumisannn/my-profile

・発表資料(SpeakerDeck)
https://speakerdeck.com/nezumisannn

・所有資格
AWS Certified Solutions Architect - Associate
Google Cloud Professional Cloud Architect