DevOpsのためのPython

第10章. コードとしてのインフラ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

DevOpsの肩書きや仕事内容が派手になる前、私たちは下っ端のシステム管理者、略してシスアドだった。車のトランクにベアメタルサーバを積んでコロケーション（コロ）施設に行き、サーバをラッキングし、配線し、車輪付きのモニタ／キーボード／マウスを取り付け、ひとつひとつセットアップしなければならなかった、クラウド以前の暗い時代だ。まばゆい光と凍えるような空調の中、何時間もコロで過ごしたことを思うと、グリッグは今でもぞっとする。私たちはBashスクリプトの達人になる必要があり、その後Perl、そして幸運な人たちはPythonへと卒業していった。諺にもあるように、2004年頃のインターネットはガムテープと風船ガムで支えられていた。

2006年から2007年にかけてのある時期、私たちはAmazon EC2インスタンスという魔法の世界を発見した。シンプルなポイント・アンド・クリックのインタフェースやコマンドラインツールを使ってサーバをプロビジョニングできるようになった。コロケーション施設まで車で行く必要も、ベアメタルサーバを積み重ねて配線する必要もなくなった。一度に10台のEC2インスタンスを立ち上げることもできた。20台でもいい！100台でもいい！無限の可能性があった。しかし、手動でSSHを使って各EC2インスタンスに接続し、各インスタンスに個別にアプリケーションをセットアップするのは、スケールアップにつながらないことがすぐにわかった。インスタンスのプロビジョニング自体は非常に簡単だった。難しかったのは、アプリケーションに必要なパッケージをインストールし、正しいユーザを追加し、ファイルのパーミッションが正しいことを確認し、最後にアプリケーションをインストールして構成することだった。この痒いところに手が届くように、「構成管理」ツールに代表される第一世代のインフラ自動化ソフトウェアが登場した。Puppetはよく知られた最初の構成管理ツールで、2005年にリリースされ、Amazon EC2がリリースされる前だった。Puppetに続いて登場したのが、2008年のChef、2011年のSaltStack、2012年のAnsibleだ。

2009年までに、世界は新しい用語の到来を歓迎する準備が整っていた：DevOpsである。今日に至るまで、DevOpsの定義は競合している。興味深いのは、DevOpsがインフラ・ソフトウェア自動化の激動の初期に誕生したということだ。DevOpsには重要な人材と文化の側面があるが、この章で際立っているのは、インフラとアプリケーションのプロビジョニング、コンフィギュレーション、デプロイを自動化する能力である。

2011年までには、Amazon Web Services（AWS）スイートを構成するすべてのサービスを把握することが難しくなっていた。クラウドは、生の計算能力（Amazon EC2）やオブジェクトストレージ（Amazon S3）よりもはるかに複雑になっていた。アプリケーションは複数のサービスが相互に作用することに依存するようになり、これらのサービスのプロビジョニングを自動化するためのツールが必要になった。アマゾンはこのニーズを満たすのにそう時間はかからず、2011年にまさにそのようなツールの提供を開始した：AWS CloudFormationだ。これは、コードを通してインフラを記述できるようになったと言える最初の瞬間だった。CloudFormationは、新世代のコードとしてのインフラ（IaC）ツールへの扉を開いた。IaCツールは、第一世代の構成管理ツールが提供するレイヤーの下にある、クラウドインフラそのもののレイヤーで演算子として動作していた。 ...