要は(TL;DR)
- 【状況】
IBM CloudでUbuntu 18.04の仮想サーバーを新規オーダー。
起動後にカスタマイズして独自のイメージ・テンプレートを作った
- 【事象】そのイメージ・テンプレートから新たに仮想サーバーをオーダー
したが
ブートが完了しない（ハング状態で最終的にキャンセル) - 【原因】大元の仮想サーバーをオーダーする時()に使用したイメージが"cloud-init" Enabledなもの1だった。起動後にデスクトップ環境を使いたかったので gnome3をインストール(apt install ubuntu-desktop)したが、その過程でネットワーク定義が変更されてしまった。その状態でテンプレートを作ったために、 次回のcloud-initのブートが失敗したもの
- 【対応】始めの仮想サーバーをオーダーする時にデフォルトのメニューからは行わず、パブリック・イメージ・テンプレートからcloud-init" が無効化(Disabled)されたOSイメージを選んで、それを指定して仮想サーバーをオーダーするといいかも！
はじめに
こんにちわ！石田です。先般IBM Cloudで仮想サーバーを使っていた際に遭遇した事象をシェアします。レア・ケースかもしれませんが同様のことでお困りの方のためにメモとして書いておきますネ。
背景・やりたかったこと
IBM Cloudを使ったハンズオンセミナーを調査検討していました。クラウド上の仮想サーバーにカスタマイズしたハンズオン環境を作ってイメージ・テンプレート（AWSでいえばスナップショット)として保存しておけば、あとは参加人数に応じて必要な数の環境を簡単に準備できるのでいいよね！と思ってましたが、ハマりました。。。orz
うまくいかなかった事象の再現
【1】まずはカタログのメニューから仮想サーバーをオーダー
「コンピュート」－「Virtual Server」
【2】OSとしてubuntu 18.04を選んだ以外は全部デフォルトでオーダー
【3】起動したらSSHでroot ログインし、デスクトップが欲しいのでgnome3をインストール(1000個以上を追加するので30分以上かかります）2
apt update
apt install ubuntu-desktop
【4】インストールが終わったらイメージ・テンプレートの作成
仮想サーバーの明細パネルの右上「アクション」－「イメージ・テンプレートの作成」
とれました
- 起動状態にあった仮想マシンは自動的に遮断され、イメージテンプレート作成後に自動的に再度起動されます。テンプレをとる元になる仮想サーバーのほうは何度でもリブートは成功します。失敗するのは「テンプレから起動した仮想サーバー」のほうですので、お間違えなきよう。cloud-initって要は初回のOS導入&起動なので、それが終わればあとは関係ないのでしょう。
【5】いましがた取ったイメージテンプレートをベースにして、仮想マシンをオーダー
「公開VSIの注文」
OSのイメージが「カスタム」である以外は全部同じ
起動してしばらく待ってIPアドレスが割り振られても、パスワードが作られませんし時計マークが消えません（ハング）。。30分位放置するとセンター側でキャンセルされます。(自分ではキャンセルできません）
- ちなみにイメージテンプレートからの起動ではrootのパスワードは初期化されます。root以外に自分でユーザーを作った場合は、そのユーザーは保持されますしパスワードは変わりません。
ブートが完了しない原因
サポートとやり取りしながら、カスタマイズの範囲を段階的に狭めて原因特定・問題判別を行いました。結果的に私の場合にはubuntu-desktopのインストールがcloud-initが想定しているネットワーク構成定義を意図せず上書き破壊したために、その破壊された状態で採取したイメージテンプレートは次回のブート時に基盤(IBM Cloud)との通信ができず、結果的にブートがハング(失敗)したものでした。 詳しく存じませんがcloud-initはその名の通り、クラウド環境でのOSブートの自動化のための機能ですが、「IBM Cloud Standard Imageの正しい取り方」なんて記事があるように結構センシティブで、元の環境と変えると結構な確率でブートに失敗したりするようです。（というかあまり変更してはいけないようです）
対応
ということで「初めに使ったOS起動イメージがcloud-init対応のものであった」ことと「ubuntu-desktopのインストール」が不整合であったことが原因でしたので、「初めに使ったOS起動イメージがcloud-initを使わないもの」であればいいわけです。(cloud-initを使わない場合は従来のSoftlayerの起動スクリプトを使うそうですが、要は起動すればいいんで、 結果オーライですね) IBM Cloudでは「パブリック・イメージ」に様々なイメージが置いてあります。今回はubuntu 18.04を探したら、cloud-initを使ってないイメージもありました！ よって最初の仮想マシンをオーダーする段階で、このイメージを指定すればオーケーです。
Devices- Manage- Imagesで「パブリック・イメージ（すべてのイメージ）」を選び条件検索すると、複数のイメージが列挙されます（ubuntu 18.04でディスク25GBのものは4つ）
これらの明細を見ると、cloud-initが有効(Enabled)なものと無効(Disabled)なものがあります。
今回のubuntuの例ではのイメージは「クラウド初期設定(cloud-init)」が「有効(Enabled)」であり、のイメージは「クラウド初期設定(cloud-init)」が「無効(Disabled)」です。
よってのイメージを選択して右上のボタンから「公開VSIの注文」をすればオーケーです。
私のケースではこのから起動した仮想サーバーにgnome3を入れたり様々なカスタマイズを行いましたが、その後作ったイメージ・テンプレートは正常にブートできました。
ということで長々書きましたが、当記事がIBM Cloud利用中にイメージテンプレートからブートできない方のお役に立てば幸いです。
いわずもがな、ですが一応
当記事の主旨は「cloud-initは一切使わない方がよい」とか「ubuntu18.04にgnome3入れてからイメージテンプレ取ると、絶対にブート失敗する3」とかを言ってるわけではありません。「不整合」なので、生憎何と何がぶつかるか、はぶつかってみないとわかりません。当記事の主旨は「普通に仮想マシンをオーダーしてテンプレ作っただけなのに、そのテンプレからのブートが失敗したなら、cloud-init使わないOSイメージを使ったら回避できるかもよ！」ということです。