第561回ではローカルのマシンでもcloud-initを用いて初期設定できる方法を解説しました。そこで今回は、Ubuntuが提供する各種クラウド向けイメージの活用方法を紹介します。
クラウドイメージの利点
Ubuntuでは通常のインストーラー付きイメージとは別に「クラウドイメージ」も提供しています。これは最新のアップデートを適用した「インストール済み」のイメージで、各種仮想マシンやコンテナでそのまま起動できる形式で配布されています。
配布形式はディスクイメージだったり、単にルートファイルシステムをtarでアーカイブしたものだったりとさまざまです。アカウントは設定されていません。rootもロックされた状態なので、もしクラウドイメージを起動してログインする必要があるなら、cloud-initを用いた設定が必要です。もちろん手作業で展開・カスタマイズ・再アーカイブもできます。
主なターゲットはパブリックもしくはプライベートのクラウドサービスです[1]。これらのクラウドサービスでは、インスタンスの立ち上げごとにインストーラーを起動していては煩雑になってしまいます。そこで立ち上げ時に機械的にカスタマイズ可能なインストール済みイメージを提供することで、各サービスベンダーはインスタンスの作成を容易に自動化できるのです。
さらにクラウドイメージは「最新のアップデートが適用済み」の状態で提供されています。つまり定期的にビルドが行われているのです。このためインストール後からアップデート完了までのリスク期間も減らせます。
そもそもUbuntuサーバーを「普通に」インストールしようとしたら、インストールディスク(800MiB程度)をダウンロードし、マシンにインストールし、最新のアップデート(タイミングによっては200MiB程度)をダウンロードし、それを適用しなくてはなりません。それに比べたら、300MiBぐらいのアップデート適用済みイメージをダウンロードして起動したほうがはやいのは当然ですよね。
もちろんこれらの利点はクラウドサービス以外でも意味があります。第561回のように、仮想マシンインフラでもクラウドイメージ(とcloud-init)を活用すれば、個人のネットワークの「ギガが減る」ことなくUbuntuサーバーを構築できるのです[2]。
「クラウドイメージ」だからと言ってクラウドでしか使えないわけではありません。UbuntuはおおよそFLOSSで構築されていますし、Linuxサーバーとして使うにあたってサブスクリプションなども不要です。自分が便利だと思う方法でどんどん活用していきましょう[3]。
クラウドイメージの種類
2019年4月時点でUbuntu 18.04 LTS向けに提供されているクラウドイメージには次の種類が存在します。
- ubuntu-18.04-server-cloudimg-amd64-root.tar.xz
- ルートファイルシステムをただtar.xzで固めたアーカイブです(約140MiB)
- カーネルやブートローダーはインストールされていません
- コンテナのベースイメージや組み込みシステムでの利用を想定しています
- 最小のルートファイルシステムが欲しいなら、Ubuntu BaseやUbuntu Minimalを使いましょう
- ubuntu-18.04-server-cloudimg-amd64.img
- QEMU/KVM向けのQCOWイメージです(約300MiB)
- QEMU/KVMベースの仮想マシン管理システムやOpenStackなどで使われます
- カーネルやブートローダーもインストールされています
- ubuntu-18.04-server-cloudimg-amd64.ova
- OVA(Open Virtual Appliance)形式のイメージです(約300MiB)
- VirtualBoxやVMWareをはじめとするOVA対応の仮想マシンシステムで使います
- フォーマットが異なるだけで内容はQCOWイメージと同じです
- ubuntu-18.04-server-cloudimg-amd64-vagrant.box
- VirtualBox向けのVagrant Boxファイル(OVF形式)です(約300MiB)
- フォーマットが異なるだけで内容はQCOWイメージと同じです
- ubuntu-18.04-server-cloudimg-amd64.vhd.zip
- VHD(Virtual Hardk Disk)形式のイメージです(約400MiB)
- 主にHyper-Vで使います
- フォーマットが異なるだけで内容はQCOWイメージと同じです
- ubuntu-18.04-server-cloudimg-amd64.vmdk
- VMDK(Virtual Machine Disk)形式のイメージです(約300MiB)
- 主にVMWareで使います
- 実はOVAやVagrant Boxにはこのファイルがそのまま入っています
- フォーマットが異なるだけで内容はQCOWイメージと同じです
- ubuntu-18.04-server-cloudimg-amd64.squashfs
- squashfs形式のルートファイルシステムです(約200MiB)
- 読み込み専用のファイルシステムとしてマウントします
- 通常はOverlayFS2などと併用して書き込み領域可能を用意します
- ubuntu-18.04-server-cloudimg-amd64.tar.gz
- ext4イメージファイルをtar.gzでアーカイブしたものです(約300MiB弱)
- QEMU/KVMやXenなど各種仮想マシン管理システムで使えます
- BIOS用のMBRやUEFI用のESPは別途用意する必要があります
- フォーマットが異なるだけで内容はQCOWイメージと同じです
- ubuntu-18.04-server-cloudimg-amd64-lxd.tar.xz
- LXD向けのテンプレートです(約1KiB)
- サイズからもわかるように、これ単体は起動可能なイメージファイルではありません
- 別途ダウンロードしたルートファイルシステムなどと組みあわせて使います
どのイメージも、インストールされているものはほぼ同じです。異なるのはブートローダー関連とカーネルがインストールされているかどうか、です。ディスクイメージタイプはインストールされていて、ただのアーカイブタイプはインストールされていません。
よって使用している仮想マシン管理システムにあわせてダウンロードするフォーマットを決めてください。よく使われるVirtualBoxやVMWareであれば、OVAを選んでおけば問題ないです。
ディスクイメージタイプのルートファイルシステムのパーティションサイズはおおよそ2GiB(tar.gzのext4だけ1GiB)に設定されています。これはインストールされている状態でほぼ使用率100%に近いので、実際に使う場合はパーティションを拡張する必要があります。仮想マシンシステムごとにデプロイする際にパーティションサイズを指定できるはずです。なおファイルシステムのサイズは、パーティションのサイズにあわせて自動拡張されます。
今回は上記の中でも特に「そのまま使える形式」である、QCOW形式、Vagrant Box形式、OVA形式について説明します。
また、QCOWとOVAについてはcloud-initで初期セットアップできると便利です。第561回にローカルでcloud-initを使うためのイメージの作り方を解説していますので、そちらもあわせて参照してください。とりあえず今回はパスワードの設定が必須なので、次のようにcloud-init用のイメージファイルを作っておくこととします。
QCOW形式の使い方
QCOW形式については実は第561回で活用しています。他の方式との比較のために、改めてそのコマンドを紹介しておきましょう。
まずは必要なパッケージをインストールしておきます。
次にイメージをダウンロードし、ストレージサイズを増やしておきます。
今回もUEFI/OVMFを使う例にしているため、最後にOVMFの変数領域を別途コピーしています。詳しいことは第441回を参照してください。
最後にQCOWイメージを起動します。最後の行では、cloud-init用のデータストアをマウントしています。
これで「ubuntu」アカウントとcloud-initで設定したパスワードでログインできるはずです[4]。
仮想マシン上の変更内容はQCOWイメージに保存されます。よって必要に応じてイメージファイルをコピーしておけば、同じ設定の複数のインスタンスを立ち上げることも可能です。
仮想マシンを起動せずにQCOWイメージをカスタマイズしたいなら、NBD(Network Block Device)としてマウントしてしまいましょう。
「ファイルシステム」が「ext4」になっているパーティションがルートファイルシステムです。初期状態では2GiBのパーティションであり、ほぼすべて使い切っています。カスタマイズが終わったら次のようにアンマウントします。
Vagrant Box形式の使い方
Vagrant Box形式では、まず最初に必要なパッケージをインストールしておきます。Ubuntuの提供するVagrant Boxはプロバイダーとして「virtualbox」が記載されていますので、Vagrantに加えてVirtualBoxもインストールしておきましょう。
Boxファイルを追加します。名前は「bionic」にしていますが、任意の名前でかまいません。
Vagrantからこのイメージを起動するためには、Vagrantfileが必要です。「vagrant init」でVagrantfileを生成しましょう。
「bionic」は先程追加したBoxの名前です。カレントディレクトリにVagrantfileが生成されるので必要にあわせて調整してください。Vagrantについては、cloud-initを使うよりもVagrantfileに設定を書いたほうがかんたんかもしれません。もしcloud-initを使いたい場合は、Vagrantfileに次のように記述します。
気をつけたいことは、Vagrant(というかVirtualBox)はファイルの拡張子が「.iso」でないとDVD/CDイメージファイルとして認識してくれない点です。前述の「user-data.img」は「user-data.iso」に名前を変更しておいてください。
「vagrant up」でインスタンスを立ち上げます。
特にエラーメッセージ等が表示されなかったら、無事に起動していることになります。Vagrantで作ったインスタンスなら、cloud-initの有無に関わらず「vagrant ssh」コマンドでログインできます。
ログインするのは「vagrant」という名前の自動生成されたアカウントです。cloud-initを利用していたら「ubuntu」アカウントも作られていることでしょう。
ちなみにUbuntuが提供するVagrant BoxにはConfigDrive方式のデータストアが最初から同梱されています。ただしこのデータストアは、ホスト名「ubuntu-bionic」とし、「manage_etc_hosts
」をlocalhostに変更しているだけのようです。
OVA形式の使い方
OVA(Open Virtual Appliance)は各種仮想マシン管理システムが対応している、業界標準の仮想マシンイメージフォーマットです。最近のVirtualBoxやVMWareなどはOVAをサポートしているので、まずはこのフォーマットを試すと良いでしょう。
VMWare vSphere Hypervisor(ESXi)の場合
VMWareのvSphere Hypervisor(ESXi)の場合は、「仮想マシンの作成/登録」からOVAファイルをインポートできます。ここではバージョン6.7のWebクライアントを元に説明します。
次にESXiのデータストアに、あらかじめ作成しておいたcloud-init用のデータストアイメージをアップロードしておいてください。
仮想マシンを起動する前に、仮想マシンの編集画面から必要な設定を変更します。
- 初期状態だとストレージのサイズは10GiBです。必要に応じて増やしてください。
- 他CPUやメモリ・ネットワークなども適宜調整すると良いでしょう。
あとは通常通り起動するだけです。cloud-initの設定が適用されて無事に最新のUbuntu環境が構築されました。
VirtualBoxの場合
VirtualBoxもまたOVAに対応したソフトウェアです。次の流れで作成してみましょう。
ファイルブラウザーからOVAファイルをダブルクリックするか、「ファイル」から「仮想アプライアンスのインポート」を選択しOVAファイルを指定します。「仮想アプライアンスのインポート」ダイアログが開くので、設定を調整します。
VirtualBoxの場合、ローカルにあるISOイメージファイルをマウントできます。よって起動する前にcloud-init用のデータストアイメージをマウントするように設定しておきましょう。Vagrantのときと同様にファイルの拡張子が「.iso」でないとDVD/CDイメージファイルとして認識してくれません。
作成した仮想マシンを選択し設定ボタンを押します。ストレージの「コントローラー:IDE」にある光学ドライブを追加するアイコンをクリックして、「ディスクを選択」ボタンを押します。ディスクファイルとしてcloud-init用のデータストアイメージを選択してください。
ついでに使わないフロッピーデバイスは削除しておいてもいいかもしれません。
Ubuntuのクラウド向けイメージはOpenSSHサーバーも自動起動するため、基本的にネットワーク越しにログインできます。ただ、VirtualBoxをヘッドレスではない形で使うならシリアルコンソールも使えたほうが便利かもしれません。同じ設定画面の「シリアルポート」の「ポート1」の「シリアルポートを有効化」にチェックを入れておきましょう。
あとは通常通り起動するだけです。cloud-initの設定が適用されて無事に最新のUbuntu環境が構築されました。