イメージの要件¶
Linux¶
Linux イメージが OpenStack クラウドで全機能を利用する場合、いくつかの要件があります。これらのいくつかは cloud-init をインストールすることにより、要件を満たせます。イメージを作成する前に、使用する OpenStack の機能をイメージがきちんとサポートするために、このセクションを確認してください。
起動時のディスクパーティション設定およびルートパーティションのサイズ変更 (
cloud-init
)MAC アドレス情報の組み込みなし
SSH サーバーの実行
ファイアウォールの無効化
SSH 公開鍵を使用したインスタンスへのアクセス (
cloud-init
)ユーザーデータと他のメタデータの処理 (
cloud-init
)Linux カーネルの準仮想化 Xen サポート (Linux カーネルバージョン < 3.0 の Xen ハイパーバイザーのみ)
起動時のディスクパーティション設定およびルートパーティションのサイズ変更 (cloud-init)¶
Linux イメージの作成時、ディスクをパーティション化する方法を決める必要があります。パーティション方法の選択により、以下のセクションに記載されているとおり、リサイズ機能に影響を与える可能性があります。
仮想マシンイメージのディスク容量は、イメージの初期作成時に決められます。しかしながら、OpenStack により、別のフレーバーを指定して、インスタンスを別の容量で起動できます。例えば、イメージが 5GB ディスクで作成し、インスタンスを m1.small
のフレーバーで起動した場合、仮想マシンインスタンスはデフォルトで 20 GB の主ディスクを持ちます。インスタンスのディスクが容量拡張された場合、単に最後に 0 が書き込まれます。
イメージは、ユーザーにより要求された容量になるよう、起動時にパーティションをリサイズできる必要があります。そうでなければ、インスタンスのディスク容量がイメージ作成時のディスク容量を超えるフレーバーと関連づけられている場合、インスタンスの起動後、追加のストレージにアクセスできるよう、手動でリサイズする必要があります。
Xen: ext3/ext4 パーティション 1 つ (LVM なし)¶
OpenStack XenAPI ドライバーを使用する場合、Compute のサービスは、インスタンスの起動時にパーティションとファイルシステムを自動的に調整します。以下の条件がすべて満たされる場合、自動リサイズが実行されます。
auto_disk_config=True
が、イメージレジストリーにあるイメージのプロパティとして設定されている。イメージのディスクが 1 つのパーティションを持ちます。
1 つのパーティションのファイルシステムが ext3 または ext4 です。
そのため、Xen を使用する場合、イメージの作成時に、(LVM により管理されていない) ext3 / ext4 パーティションを作成することを推奨します。それ以外の場合、このまま読み進んでください。
cloud-init/cloud-tools ありの非 Xen : ext3/ext4 パーティション 1 つ (LVM なし)¶
イメージのこれらの項目を設定する必要があります。
イメージのパーティションテーブルは、イメージの元々の容量を記載しています。
イメージのファイルシステムは、イメージの元々の容量になっています。
そして、ブート中に以下を実行する必要があります。
追加領域を認識させるためにパーティションテーブルを変更します。
LVM を使用してない場合、既存のルートパーティションをこの追加領域を含むまで拡張するために、テーブルを変更する必要があります。
LVM を使用している場合、新規 LVM 項目をパーティションテーブルに追加し、新規 LVM 物理ボリュームを作成し、それをボリュームグループに追加し、ルートボリュームの論理パーティションを拡張できます。
ルートボリュームのファイルシステムをリサイズします。
Depending on your distribution, the simplest way to support this is to install in your image:
the cloud-init package,
the cloud-utils package, which, on Ubuntu and Debian, also contains the
growpart
tool for extending partitions,Fedora、 CentOS 7、 RHEL 7 の場合、
cloud-utils-growpart
パッケージ。このパッケージに含まれるgrowpart
ツールでパーティションを拡張できます。Ubuntu、Debian の場合、 cloud-initramfs-growroot パッケージ。最初に起動するルートパーティションの容量を変更できます。
これらのパッケージをインストールすると、このイメージは、起動時にルートパーティションの容量変更を実行できるようになります。例えば、 /etc/rc.local
にあります。
cloud-initramfs-tools
をインストールできない場合、Robert Plestenjak 氏が linux-rootfs-resize という GitHub プロジェクトを行っています。これには、イメージを起動時にリサイズできるよう、 growpart
を使用することにより、ラムディスクを更新するスクリプトが含まれます。
If you can install the cloud-init
and cloud-utils
packages,
we recommend that when you create your images, you create
a single ext3 or ext4 partition (not managed by LVM).
cloud-init/cloud-tools なしの非 Xen: LVM¶
ゲスト内に cloud-init
と cloud-tools
をインストールできず、リサイズをサポートしたい場合、パーティションテーブルを変更するために、イメージが起動時に実行するスクリプトを書く必要があります。この場合、パーティションを管理するために、LVM を使用することを推奨します。Linux カーネルの制限 (執筆時点) により、現在マウントされているローディスクのパーティションテーブルを変更できませんが、LVM の場合は実行できます。
スクリプトは以下のようなことを実行する必要があります。
ディスクの追加領域を利用可能かどうかを検知します。例えば、
parted /dev/sda --script "print free"
の出力を解析します。この追加領域を用いて新規 LVM パーティションを作成します。例えば、
parted /dev/sda --script "mkpart lvm ..."
。新規物理ボリュームを作成します。例えば、
pvcreate /dev/sda6
。この物理パーティションを用いてボリュームグループを拡張します。例えば、
vgextend vg00 /dev/sda6
。ルートパーティションを含む論理ボリュームを合計容量に拡張します。例えば、
lvextend /dev/mapper/node-root /dev/sda6
。ルートファイルシステムをリサイズします。例えば、
resize2fs /dev/mapper/node-root
。
お使いのイメージが、 /boot
が LVM により管理されていないという要件がある古い Linux ディストリビューションでなければ、 /boot
パーティションは必要ありません。
MAC アドレス情報の組み込みなし¶
ネットワーク永続化ルールにより、インスタンスのネットワークインターフェースが eth0 以外のインターフェースとして起動するため、イメージでそのルールを削除する必要があります。これは、最初にインストールしたときに、ネットワークインターフェースカードの MAC が記録されるため、インスタンスの起動ごとに別の MAC アドレスになるためです。以下のファイルを変更します。
/etc/udev/rules.d/70-persistent-net.rules
を空のファイルに置き換えます。これは、MAC アドレスなどのネットワークの永続的ルールを含みます。/lib/udev/rules.d/75-persistent-net-generator.rules
を空のファイルに置き換えます。これは上述のファイルを生成します。Fedora 系イメージにおいて
/etc/sysconfig/network-scripts/ifcfg-eth0
から HWADDR 行を削除します。
注釈
ネットワーク永続化ルールのファイルを削除すると、起動時に udev カーネル
の警告が出るかもしれません。そのため、これらを空ファイルで置き換えることを推奨します。
SSH サーバーの動作確認¶
イメージの中に SSH サーバーをインストールし、起動時に開始するよう設定する必要があります。そうでなければ、OpenStack 内に起動したインスタンスに SSH 接続できません。このパッケージは、一般的に openssh-server
という名前です。
ファイアウォールの無効化¶
一般的に、イメージ内のファイアウォールを無効化し、インスタンスへのアクセスを制限するために OpenStack のセキュリティーグループを使用することを推奨します。その理由は、インスタンスにインストールされたファイアウォールは、インスタンスに接続できない場合に、ネットワークの問題のトラブルシューティングが難しくなるからです。
SSH 公開鍵を使用したインスタンスへのアクセス (cloud-init)¶
ユーザーが OpenStack で動作する仮想マシンにアクセスする一般的な方法は、公開鍵認証を使用した SSH です。このために、仮想マシンイメージは、OpenStack メタデータサービスやコンフィグドライブから SSH 公開鍵を起動時にダウンロードするよう設定する必要があります。
XenAPI エージェントと cloud-init
が両方ともイメージに存在する場合、 cloud-init
が SSH 鍵インジェクションを処理します。イメージが cloud_init_installed
プロパティーを持つとき、システムは cloud-init
が存在すると仮定します。
cloud-init を使用した公開鍵の取得¶
The cloud-init
package automatically fetches the public key
from the metadata server and places the key in an account.
The account varies by distribution.
On Ubuntu-based virtual machines, the account is called ubuntu
,
on Fedora-based virtual machines, the account is called fedora
,
and on CentOS-based virtual machines, the account is called centos
.
You can change the name of the account used by cloud-init
by editing the /etc/cloud/cloud.cfg
file and adding a line
with a different user. For example, to configure cloud-init
to put the key in an account named admin
, use the following syntax
in the configuration file:
users:
- name: admin
(...)
公開鍵の取得のためのカスタムスクリプトの書き込み¶
ゲスト内に cloud-init
をインストールできない場合、したくない場合は、公開鍵を取得し、ユーザーアカウントに追加するために、カスタムスクリプトを作成できます。
SSH 公開鍵を取得し、root アカウントに追加するために、 /etc/rc.local
ファイルを編集し、 touch /var/lock/subsys/local
行の前に以下の行を追加します。このコードは rackerjoe oz-image-build CentOS 6 template から引用しました。
if [ ! -d /root/.ssh ]; then
mkdir -p /root/.ssh
chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
ATTEMPTS=30
FAILED=0
while [ ! -f /root/.ssh/authorized_keys ]; do
curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/metadata-key 2>/dev/null
if [ $? -eq 0 ]; then
cat /tmp/metadata-key >> /root/.ssh/authorized_keys
chmod 0600 /root/.ssh/authorized_keys
restorecon /root/.ssh/authorized_keys
rm -f /tmp/metadata-key
echo "Successfully retrieved public key from instance metadata"
echo "*****************"
echo "AUTHORIZED KEYS"
echo "*****************"
cat /root/.ssh/authorized_keys
echo "*****************"
else
FAILED=`expr $FAILED + 1`
if [ $FAILED -ge $ATTEMPTS ]; then
echo "Failed to retrieve public key from instance metadata after $FAILED attempts, quitting"
break
fi
echo "Could not retrieve public key from instance metadata (attempt #$FAILED/$ATTEMPTS), retrying in 5 seconds..."
sleep 5
fi
done
注釈
いくつかの VNC クライアントは、 : (コロン) を ; (セミコロン) に、 _ (アンダースコア) を - (ハイフン) に置き換えます。VNC セッション経由でファイルを編集する場合、http: が http; ではないこと、authorized_keys が authorized-keys ではないことを確認してください。
ユーザーデータと他のメタデータの処理 (cloud-init)¶
In addition to the ssh public key, an image might need additional information from OpenStack, such as to povide user data to instances, that the user submitted when requesting the image. For example, you might want to set the host name of the instance when it is booted. Or, you might wish to configure your image so that it executes user data content as a script on boot.
メタデータサービス、または、 コンフィグドライブへのメタデータの保存 により、この情報にアクセスできます。OpenStack メタデータサービスは、Amazon EC2 メタデータサービスの 2009-04-04 版と互換性があるので、ユーザーデータの取得に関する詳細は Using Instance Metadata にある Amazon EC2 ドキュメントを参照してください。
この類の機能をサポートする最も簡単な方法は、イメージ内に cloud-init
パッケージをインストールすることです。これは、デフォルトでユーザーデータを実行可能スクリプトとして取り扱い、ホスト名を設定します。
イメージがブートログをコンソールに書き込むことの確認¶
You must configure the image so that the kernel writes
the boot log to the ttyS0
device. In particular, the
console=tty0 console=ttyS0,115200n8
arguments must be passed to
the kernel on boot.
お使いのイメージがブートローダーとして grub2
を使用している場合、grub 設定ファイルに設定行があります。例えば、 /boot/grub/grub.cfg
が以下のようになっているでしょう。
linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=tty0 console=ttyS0,115200n8
If console=tty0 console=ttyS0,115200n8
does not appear, you must
modify your grub configuration. In general, you should not update the
grub.cfg
directly, since it is automatically generated.
Instead, you should edit the /etc/default/grub
file and modify the
value of the GRUB_CMDLINE_LINUX_DEFAULT
variable:
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"
次に grub 設定を更新します。Ubuntu などの Debian 系のオペレーティングシステムの場合、このコマンドを実行します。
# update-grub
RHEL、CentOS などの Fedora 系の場合、openSUSE の場合、このコマンドを実行します。
# grub2-mkconfig -o /boot/grub2/grub.cfg
カーネルの準仮想化 Xen サポート (Xen ハイパーバイザーのみ)¶
Linux カーネル 3.0 以前は、Linux カーネルのメインラインブランチが準仮想化 Xen 仮想マシンインスタンス (Xen は DomU ゲストと呼びます) をサポートしていません。Xen を準仮想化で実行している場合、Linux カーネル 3.0 以前の古い Linux ディストリビューションのイメージを作成したければ、そのイメージが Xen サポート付きでコンパイルされたカーネルを起動する必要があります。
イメージキャッシュの管理¶
nova.conf
ファイルにあるオプションを使用して、未使用のイメージを /var/lib/nova/instances/_base/
に保存するかどうか、どの期間保存するかを制御します。インスタンスのライブマイグレーションを設定した場合、すべてのコンピュートノードは 1 つの /var/lib/nova/instances/
ディレクトリを共有します。
OpenStack における libvirt イメージの詳細は、 Pádraig Brady 氏の The life of an OpenStack libvirt image を参照してください。
設定オプション=規定値 |
(型) 説明 |
---|---|
preallocate_images=none |
(文字列型) 仮想マシンイメージの事前割り当てのモード:
|
remove_unused_base_images=True |
(論理型) 未使用のイメージが削除されるかどうかです。True (真) に設定した場合、ベースイメージが削除される間隔は、以下の 2 つの設定で設定されます。False (偽) に設定した場合、ベースイメージは Compute により削除されません。 |
remove_unused_original_minimum_age_seconds=86400 |
(整数型) この時間内は、未使用かつ容量変更のないベースイメージが削除されません。デフォルトは 86400 秒 (24 時間) です。 |
remove_unused_resized_minimum_age_seconds=3600 |
(整数型) この時間内は、未使用かつ容量変更のあるベースイメージが削除されません。デフォルトは 3600 秒 (1 時間) です。 |
この設定が、稼働中のインスタンスの削除にどのような影響を与えるかを確認する場合、イメージが保存されているディレクトリを確認してください。
# ls -lash /var/lib/nova/instances/_base/
/var/log/compute/compute.log
ファイルで識別子を検索します。
2012-02-18 04:24:17 41389 WARNING nova.virt.libvirt.imagecache [-] Unknown base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removable base files: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3 /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removing base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3
remove_unused_original_minimum_age_seconds
のデフォルト時間は 86400 秒 (24 時間) なので、ベースイメージが削除されたことを確認するために、その時間待つことができます。または、 nova.conf
ファイルにより短い時間を設定します。 nova.conf
ファイルの設定を変更した後、すべての nova サービスを再起動してください。