Ubuntuのサーバー版イメージには最初からcloud-initがインストールされています。このcloud-initはクラウド上のインスタンスを立ち上げる際，もろもろの初期設定を行ってくれる強力なツールです。今回はそのcloud-init先生に，ローカルのマシンにおいてもがんばってもらいましょう。

cloud-initの位置づけ

まずはcloud-initの位置づけから説明します。cloud-initそのものを知っている・使っているのであれば，次の項目まで読み飛ばしてください。

今世紀に入って「Linuxのインストール」は劇的に簡単になりました。インストールするだけでも一苦労，まともに動けばラッキーだった時代も昔の話。今はUSBデバイスから起動して，いくつかの質問に回答するだけでインストール完了です。さらにWindowsマシンがあるならば「3クリックでデスクトップLinux」が立ち上がりますし，極端な話，Webブラウザーとクレジットカードだけ準備すればマウス操作だけでLinuxサーバーを用立てられる時代です。

ただし，インストールが簡単になったとは言え，インストール時の設定が不要になったわけではありません。たしかにハードウェアの標準化が進んだ結果，自動的に設定される項目が増えたのは事実です。それでもユーザー名やパスワード，インストール先のデバイスなど，利用者固有の設定は必要になります。

従来，これらの設定はインストーラーが担っていました。つまり利用者はインストーラーの内容が表示されるディスプレイの前に座って，インストーラーの質問に対してマウスやキーボードで答える必要があったのです。しかしながら「クラウド」の場合，ディスプレイやキーボード・マウスをどこにどうやって繋ぐのか，という問題が発生します。さらには「たくさんのインスタンスをデプロイできる」クラウドにおいて，デプロイのたびにインストーラーの質問に答えなくてはならないのも煩雑です。

「自動化できるものは自動化する」の観点から作られたのがcloud-initです。と言っても，もともとのパッケージ名が「ec2-init」だったことからかもわかるように，Amazon EC2専用のツールでした（※1⁠）⁠。初期のec2-initのパッケージは次のような説明されていたのです。

Description: Init scripts for EC2 instances
 EC2 instances need special scripts to run during initialisation
 to get hold of ssh keys and to let the user run various scripts.

※1

パッケージとして投入されたのは2009年の9月です。つまり9.10のリリース直前です。Ubuntu Weekly Topicsの2009年10月16日号や2009年7月10日号にもあるように，9.10は「Ubuntu Enterprise Cloud」と題した「クラウド向けとしてのUbuntuサーバーの機能」を充実させている時期でした。この頃はまだUbuntuもEucalyptusをがんばっていたのです。

EC2には「インスタンスメタデータとユーザーデータ」というインスタンスを設定・管理する仕組みが存在します。これはインスタンスに外部から任意のデータを渡すと，インスタンス内部からIPv4のリンクローカルアドレス（169.254.169.254）で取得できる仕組みです。一番最初のec2-initは，この仕組みを用いて，Upstartのジョブから次の2つの設定を実現していました。

• メタデータのpublic-keysを「/root/.ssh/authorized_keys」に追加し，インスタンスが起動したらrootでsshログインできるようにする（※2⁠）⁠。
• ユーザーデータをそのまま「/tmp」以下にコピーして実行する。

※2

そう，最初はrootのみsshログインできる設定だったのです。次のバージョンから「ubuntu」ユーザーに公開鍵が登録されるようになります。

その後，Ubuntu 10.04 LTSに向けて大幅に改修・機能追加し，名前を「cloud-init」に変更した上で，今に至ります。

当初はAmazon EC2専用のツールでしたが，その後はさまざまなクラウドサービスの方式（データストア）に対応しました。またアカウントだけではなくリポジトリの設定やパッケージのインストールから，RHELのサブスクリプション登録まで，多種多様な機能をサポートしています。もちろん任意のスクリプトの実行も可能です。

サーバーの構成管理と言えばAnsibleが定番です。cloud-initのできることはAnsibleとかぶる部分もあるものの，どちらかと言うと構成管理よりは「初期セットアップ」が目的です。たとえばSSHログインできるようにするための設定のように，「⁠Ansibleを動かす前にやっておきたいことはcloud-initで実行する」などと使い分けると良いでしょう（※3⁠）⁠。

※3

Ubuntuサーバーの旧インストーラーとしても採用されていたDebian-Installerには「preseeding」という事前設定スクリプトによるインストール自動化機能が存在します。物理マシンへのインストール時のようにインストーラーを動かすのならpreseedingを使って初期セットアップが可能です（参考：第154回　さくらVPSへのネットブートインストールをPreseedingで自動化する⁠）⁠。しかしながらクラウドサービスで使用されるクラウドイメージは，インストーラーを実行せず，インストール済みのイメージを使うためpreseedingは使えません。また，Ubuntuサーバーの新しいインストーラーであるSubiquityもpreseedingに対応していません。

VagrantfileやDockerfileも機能的に近い存在です。設定済みのイメージファイルを作りたいならVagrantfile/Dockerfileを使い，作成済みのイメージファイルを起動する際にセットアップしたいならcloud-initを使うような分担が一般的なようです（※4⁠）⁠。

※4

もちろん「どれか一つのツールだけですべてを賄う」との考えのもとにがんばることは否定しません。

cloud-initの仕組み

cloud-initは「メタデータとユーザーデータ」を「何らかの方法」で受け取って，それを元に初期セットアップを行う仕組みです。

「何らかの方法」は使用するクラウドサービスに依存します。たとえばAmazon EC2ならインスタンスの起動時にWebフォームやコマンドから渡せますし，OpenNebulaならマシンテンプレートとして設定したものがCD-ROMイメージとしてインスタンスに渡ってくるようです。大抵はネットワーク経由ですが，設定によってはrootfsの中にあるファイルを使うことも可能です。

cloud-initはデータの取得方法をサービスごとの「データストア」として実装しています。

メタデータについては大抵の場合クラウドサービスが自動的に付加します。cloud-initはメタデータ内部の情報（インスタンスIDやホスト名設定など）に合わせて，再コンフィグが可能かどうかやユーザーデータ適用前の事前設定を実施します。利用者はメタデータを意識することはないはずですが，そういう仕組みが存在することは覚えておくと良いでしょう。

cloud-initの本体はユーザーデータになります。cloud-initは「#cloud-config」で始まっているユーザーデータをcloud-init用のデータ（cloud-config）として解釈します。cloud-configの書き方はcloud-initのドキュメントを参照してください。