インフラエンジニアの yamamoto と申します。通称“ヤマカズ”です。
会社のブログにはでかでかと出してもらったのですが、こちらのブログは初参戦だったりしますw
どうぞよろしくお願いいたします。
アクトインディではインフラエンジニア(SRE)として、いこーよや各種プロダクト、社内システムなどのインフラ環境・開発パイプライン等を構築管理しています。
実はインフラ関連は20年以上前からやってて、これまでも社内サーバーやアプライアンスの設定などをしていました。
一時期、Web開発の方でフロントやバックエンドをやっていたのでインフラから離れていたのですが、再びインフラに戻りました。
やっぱり機械いじりが好きなんですね……
筋トレ必須!?職人芸エンジニア=インフラ
昔はサーバーは全て物理マシンでやってて、マシンを大量に積んでセットアップするとか、マシンをかついで移動するとか、ITなのに肉体労働という意味不明な業界でした。
その後アプライアンスが進歩したり、仮想化やクラウド、コンテナ化でどんどん効率化が進み、少なくともマシンを並べなくてよくなったので、なんとなくITっぽくなりましたね。
また今までは、サーバーを構築するのに手順書を書いて、それに基づいてゴリゴリセットアップしていましたし、職人が目利きと手作業で作る「インフラは一点物」という世界でした。
IaCのメリット・デメリット
しかし数年前、Infrastructure as Code (IaC) という概念が出てきました。文字通り、インフラ構築の手順をコードにしてしまおう、という流れです。
コードにしてしまえばそれがそのまま手順書になりますし、同じ構成のサーバーをいくつも立ち上げられます。
また、クラウドや仮想サーバー等と親和性が高く、APIを叩くことでサーバーを立ち上げ、そのままログインしてOS以上のセットアップも続けて行うことができます。
当初はシェルスクリプトなどで実現していましたが、べき等性(何度実行しても同じ結果になる性質)を考慮するとコードが肥大化してしまいがちなので、それを考慮したツールも数多く登場してきました。
IaCにするメリットは、明らかにデメリットを上回ります。
メリットとしては、
- コード化することで手順書代わりになる
- コード化することで同じサーバー構成で何度でも作れる
- コード化することで作業が楽になる
- コード化することで同じ作業が誰でもできる
逆にデメリットは
- コードに書き起こさなければならない
- コードをミスると致命的な不具合が出る
- 設定を試しながら調整する場合やりにくい
とありますが、最初はサーバーをいじりながら試し、そこからコードに起こすという方法でカバーできます。
IaC のススメ
私も古い人間なもので「インフラは職人技」みたいな気分がなかなか抜けなかったのですが、一度体験してしまうとこれはもう、ゾクゾクするほどたまらなく面白い!
逆に昔からインフラやってる人ほど、脳汁大放出なぐらい興奮できます。
とっつきにくいところも多々あるかと思いますが、まだIaCを体験していないインフラエンジニアの方は、ダマされたと思って今すぐ体験してみてください。
手近なところでは「Vagrant」を使えばスクラップアンドビルドし放題ですし、OSレベルからいじりたい場合は「Ansible」はお手軽で導入も簡単です。
環境レベルだと「docker」を使えば、1台のサーバー上にいくつでも何度でもWordPress環境が作れてしまいます。
さいごに
アクトインディでは、Infrastructure as Code を鋭意推進しております。
興味のある方はぜひお越しください!