ESXiを自動でインストール

esxi-install-update - 関連記事

1: << この記事 >>

2: profile updateとprofile installの違い

3: Image Builderでカスタムイメージを作る

4: Nested ESXiを使った低コストなinstall検証

はじめに
#

この記事は富士通クラウドテクノロジーズ Advent Calendar 2023の13日目の記事です。

今回はせっかくvSphereベースの国産クラウドを提供しているので、vSphereネタということでESXiのインストール自動化について書こうと思います。

1. ESXiのインストール自動化
#

ESXiのインストール自動化にはいくつかの手法がありますが、基本的にどれもPXEBOOT用のインフラ(専用のNIC、DHCPサーバー)が必要になりハードルが高いです。

vSphere Auto Deploy

vCenterに標準搭載されている機能。
vCenterで管理できる + vLCMによってESXiのverや内部のvibまで管理できるのが強み
自前でPXEBOOT用のインフラの用意が必要。

Ubuntu MaaS

Ubuntuを物理・仮想サーバーに自動でインストールできるMetal as a Service製品。
ESXiのインストールも対応している。
MaaS内部でPXEBOOT用DHCPサーバーも管理してくれるので比較的運用が楽だが、ESXiはオプション扱いなのかbug等もあり非常に使いずらかった。(もしかしたら最近は改善してるかも？)

この解決策となるのが、「kickstartファイルを使ったESXiのカスタムイメージ作成」 + 「RedfishAPIを使用した物理作業の自動化」です。

2. kickstartを用いた、ESXiのカスタムイメージ作成
#

通常ESXiのインストールには簡易的なGUIに従っていくつか設定していくのが普通です。しかし物理サーバーは起動まで時間がかかり、とにかく待ちの多い作業になり無駄が出やすいです。

そこでこれらの作業を自動化するには、インストールイメージの中にkickstart fileを埋め込むという手法が一般的です。 ESXiとkickstartについては、他のblogやVMware公式でも解説されているためここでは深く取り扱いませんが、簡易的なansibleのscriptを作成しましたので是非試してみてください。

ansibleの実演
#

github(ansible-esxi-kickstart)

必要なparameterをvars内に入力する。 (各種変数の意味はREADME参照)
passwordに関してはhash化したpasswordが使用できるので、以下のようにSHA512形式でhash化して使用すると、passwordを公開することなく設定ができます。

openssl passwd -6 "Passw@rd"
(out) $6$X4R4A88rPFj5fb9h$rAXJvz7F7XNBpz1T.T8rlyNRFLpI2VS12d3jkzT5GaLkNMj82ZqwSbXnCOjNFskT8e0QN0QE/bscZSqSO6rum.

物理サーバーがEFI or BIOS起動確認して、efi/biosのtrue falseを設定する。

vars:
    rootpw:
      password: $6$mR5/hJcMaNQhDGgS$Ntm4c/UztOulIi/.U4SnOTs31uuiQk2DpQTqO4r.YIIPSYALDcWHu/GIgz8MnOAvtl5M9InDluAdAqtFoJbLI0
      crypted: true
    network:
      device: vmnic0
      ip: 10.0.10.11
      netmask: 255.255.254.0
      gateway: 10.0.10.1
      hostname: v10-nesxi-01.lab.local
      vlanid: 10
      nameserver: "10.0.10.1"
    path:
      esxi_image: VMware-VMvisor-installer-8.0U1-21495797.x86_64.iso
      tmp_dir: /tmp/extract
      output_image: custom_esxi.iso
    efi: true
    bios: true

作成したカスタムイメージから起動して、自動インストールされるか確認

ISOをマウントして、サーバーを起動するだけでkickstartに従って設定が開始する。Reading installation scriptという画面に移ればOK

設定ミスやWARNがあれば黒いpopupが出てくるので確認しておくこと。

例えば以下の画像ではNested ESXiでCPUの再仮想化をONにしてなかったのでWARNで表示されました。他にもkickstartの構文ミスやCPUが古くサポートしてない場合等に黒いpopupが出てきます。

3. RedfishAPIを用いた、物理作業の自動化
#

これによりイメージから起動するだけで自動でインストールできるようになりました。しかしこのカスタムイメージのマウントや物理サーバーの起動はどう自動化するのでしょうか？

そこで使うのがRedfishAPIです。

最近のサーバーであれば、FujitsuならiRMC、HPEならiLO、DELLならiDRACのように物理サーバーの管理コンソールが元々存在し、ここからISOのリモートマウントやKVMコンソールを開いて作業すると思います。これらの作業をAPIで行うことができるのがRedfishAPIになります。

物理機器(サーバー、ストレージ、ネットワーク)の管理機能を自動化するためのRESTAPI
最近のサーバーには大体存在するので、追加のインフラを準備することなく使えるのが大きなメリット
DMTFによって策定されたオープンな規格であり、異なるベンダー、異なる物理機器であってもある程度同じ操作が可能
IPMI等のCLIと比べて、RESTAPIなのでより自由度の高い作業ができる

どうやって使うのか？
#

メーカー名 + Redfishで検索するとReference guideが出てきますが、正直複雑でこれだけ見れば分かる！というものではありません。従ってRedfishを読み進める方法を「docsがある程度しっかりしているHPE」、「公式のmock」をベースに紹介します。

/redfish/v1
#

まず公式のmockにアクセスしてみましょう。これがRedfishのTOPページである、GET /redfish/v1で出力される内容になります。

様々な情報が出てきますが、この中に@odata.idという記載があるのがわかると思います。

これを見つけて「新たなAPIをリンク先を探す」 + 「公式のdocsを見てそのAPIで何ができるのか」を確認することがRedfishでは一番重要なので解説していきます。

HPEの場合
#

同様にHPEの公式docsでも、RedfishのTOP/redfish/v1にアクセスした場合の挙動が書いてある。

curl https://{iLO}/redfish/v1/ -i --insecure -L

{
  "@odata.context": "/redfish/v1/$metadata#ServiceRoot",
  "@odata.etag": "W/\"B869D8CC\"",
  "@odata.id": "/redfish/v1/",
  "@odata.type": "#ServiceRoot.v1_1_0.ServiceRoot",
  "AccountService": {
      "@odata.id": "/redfish/v1/AccountService/"
  },
  "Chassis": {
      "@odata.id": "/redfish/v1/Chassis/"
  },

  ### 省略 ###

  "Systems": {
      "@odata.id": "/redfish/v1/Systems/"
  },

/redfish/v1/Systems
#

redfish/v1の出力の中に、/redfish/v1/Systemsというリンクがあったのでこちらにアクセスしてみます。(mockの場合はclickすればOK)

すると、以下のようにこのRedfishが管理しているserverの一覧が出てきます。(通常のラックサーバーであれば1つ、ブレードサーバー等であれば複数出ることもあります。)

この中から作業対象のserverを選ぶ必要があるので、再びリンクを辿っていきます。 (mockの場合は /redfish/v1/Systems/437XR1138R2)

HPEの場合
#

同様にHPEの公式docsでも、/redfish/v1/Systemsにアクセスした場合の挙動が書いてある。

この場合/redfish/v1/systems/1/が該当のserverになる。 mockとHPEの例のようにこの時点でベンダーによってAPIのリンクに差が出てくるので、Redfishはで異なるベンダー間で似ているぐらいの認識が良い。(全く同じではない。ちょっと似てるぐらい。)

curl https://{iLO}/redfish/v1/systems/ -i --insecure -u username:password -L

{
    "@odata.id": "/redfish/v1/systems/",
    "@odata.context": "/redfish/v1/$metadata/",
    "@odata.type": "#ComputerSystemCollection.ComputerSystemCollection",
    "[email protected]": 1,
    "Members": [
        {
            "@odata.id": "/redfish/v1/systems/1/"
        }
    ]
}

/redfish/v1/Systems/{server}/
#

ここまで辿るとserverの情報(host名、model名、health状態)が確認できるようになります。このSystemsがRedfishのリンクを辿る上で一番情報があるので、まずはここを確認するようにしましょう。(次点で/redfish/v1/Managers)

この中でActionsという項目があり、重要になるのでみていきます。

Actions欄にはこのserverに対して操作を加えることができる内容が書いてあり、以下のようにserverの電源状態を変更することができることが推測できます。ただし、Redfishの出力では不十分なこともあるので、合わせて公式のdocs等を使って確認することをお勧めします。

POSTかどうか
- ベンダーのdocsを見て判断する。Redfishの出力にはmethodの記載はない。
request body
- [email protected]とあるので、keyがResetType、valueがOn, ForceOff, GracefulShutdown...と任意のものを選べる。
Oem
- Actions欄は、Redfishによってルールがあるので各ベンダー間で似たようなAPIになる。
- ただしこのOem欄だけは特別で、Redfish規格に合わないベンダー独自のAPIを詰め込むことができる。
- 電源の操作ぐらい一般的なものであれば問題ないが、boot順序を変更する等の込み入ったことをする場合はする場合はこのOemを使うことが多々ある。

HPEの場合
#

同様にHPEの公式docsでも、電源操作を行う/redfish/v1/Systemsの挙動が書いてある。

curl --header "Content-Type: application/json" --request POST --data '{"ResetType": "ForceRestart"}' https://{iLO}/redfish/v1/Systems/1/Actions/ComputerSystem.Reset -u username:password --insecure

{
  "Actions": {
      "#ComputerSystem.Reset": {
          "[email protected]": [
              "On",
              "ForceOff",
              "ForceRestart",
              "Nmi",
              "PushPowerButton"
          ],
          "target": "/redfish/v1/Systems/1/Actions/ComputerSystem.Reset"
      }
  }
}

まとめ
#

このようにRedfishAPIでは「APIを実行」→「結果から別のAPIを見つける」→「docsを見る」を繰り返すことによって、目的のAPIを探し挙動を確かめることが非常に重要になります。

最後にESXiの自動インストールの参考になりそうなAPIをいくつか紹介して終わりたいと思います。

[HPE] ISOのリモートマウント
#

参考サイト

公式doc

POST /redfish/v1/Managers/1/VirutalMedia/2/Actions/Oem/Hp/HpiiLOVirtualMedia.InsertVirtualMedia/

{
    "Image": "http://192.168.1.100/mnt/tank/custom_esxi.iso" #http-serverのurl、nfs,https等も可
}

[HPE] bootorderの変更
#

参考サイト

公式doc

PATCH /redfish/v1/Managers/1/VirtualMedia/2/

{
    "Oem": {
        "Hp": {
            "BootOnNextServerReset": true
        }
    }
}

[Fujitsu] ISOのリモートマウント
#

参考サイト

外部blog: https://mmurayama.blogspot.com/2018/05/fujitsu-irmc-redfish-examples.html
公式doc
githubのsample: https://github.com/mmurayama/fujitsu-redfish-samples

POST /redfish/v1/Systems/0/Actions/Oem/FTSComuputerSystem.VirtualMedia

{
    "FTSVirtualMediaAction": "ConnectCD",
    "ShareType": "HTTP",
    "Server": "192.168.1.100",
    "ShareName": "/mnt/tank",
    "ImageName": "custom_esxi.iso"
}

[Fujitsu] bootorderの変更
#

参考サイト

外部blog: https://mmurayama.blogspot.com/2018/05/fujitsu-irmc-redfish-examples.html
公式doc
githubのsample: https://github.com/mmurayama/fujitsu-redfish-samples

PATCH /redfish/v1/Systems/0/Oem/ts_fujitsu/BootConfig

{
    "BootDevice": "Cd",
    "NextBootOnlyEnabled": true
}

いかがだったでしょうか。物理関連の自動化はベンダー固有のものが多く非常に手間ですが、このようにある程度共通化されているRedfishAPIがあるとかなり楽になるのでとてもおすすめです。

次回は @tomonai さんが「Google ColaboratoryでChat GPTを動かしてみた話」について書いてくれるので、是非checkしてみてください。

富士通クラウドテクノロジーズ Advent Calendar 2023 13日目の記事でした。

esxi-install-update - 関連記事

1: << この記事 >>

2: profile updateとprofile installの違い

3: Image Builderでカスタムイメージを作る

4: Nested ESXiを使った低コストなinstall検証

MINISFORUM UM580 review

2023-06-12·1923 文字

Blog Review Homelab

はじめに #

1. ESXiのインストール自動化 #

2. kickstartを用いた、ESXiのカスタムイメージ作成 #

ansibleの実演 #

3. RedfishAPIを用いた、物理作業の自動化 #

どうやって使うのか？ #

/redfish/v1 #

HPEの場合 #

/redfish/v1/Systems #

HPEの場合 #

/redfish/v1/Systems/{server}/ #

HPEの場合 #

まとめ #

[HPE] ISOのリモートマウント #

[HPE] bootorderの変更 #

[Fujitsu] ISOのリモートマウント #

[Fujitsu] bootorderの変更 #

Related

はじめに
#

1. ESXiのインストール自動化
#

2. kickstartを用いた、ESXiのカスタムイメージ作成
#

ansibleの実演
#

3. RedfishAPIを用いた、物理作業の自動化
#

どうやって使うのか？
#

/redfish/v1
#

HPEの場合
#

/redfish/v1/Systems
#

HPEの場合
#

/redfish/v1/Systems/{server}/
#

HPEの場合
#

まとめ
#

[HPE] ISOのリモートマウント
#

[HPE] bootorderの変更
#

[Fujitsu] ISOのリモートマウント
#

[Fujitsu] bootorderの変更
#