このページは Cloud Translation API によって翻訳されました。

9.. Bootstrapper Server のインストール

完了までの推定時間: 3 時間

操作可能なコンポーネントの所有者: OLT/ノード

スキルプロファイル: デプロイエンジニア

ブートストラップマシンは、Google Distributed Cloud（GDC）エアギャップセルに最初にインストールされるサーバー情報システム（IS）であり、残りの Distributed Cloud 情報システムのブートストラップに使用されます。プリフライトチェック後、マシンはワーカークラスタノードとして再イメージングされます。

3 番目のラックの最初の標準サーバーをブートストラッパーに使用します。たとえば、ラボ検証では、アセットタグの一部としてベースを含まない 3 番目のラック ac の最上位サーバーである xx-ac-bm15 を使用します。ブートストラッパーには特定の要件がないため、ラック内の任意のマシンを使用できますが、この目的のために特定のマシンが標準化されています。ただし、名前が base のサーバーはルート管理者クラスタとオペレーションクラスタに使用されるため、最初の 3 つのラックでは使用しないでください。

9.1. OS をインストールする

モニタとキーボードでブートストラップマシンに接続します。
iLO 専用ネットワークポートに IP を設定します。最後のオクテットが 160 の管理 IP 範囲のアドレスを使用します。
ワークステーションの IP を同じサブネットの別のアドレスに設定し、クロスオーバーイーサネットケーブルで背面イーサネットポートに一時的に接続します。

9.1.1. ローカル ISO ファイルを使用したワークステーションによるインストール

オフラインワークステーションのブラウザから、ブートストラップマシンの iLO コンソールに接続し、ナビゲーションツリーの [Remote Console & Media] メニューに移動します。USB iLO を介してリモートメディアを使用しないでください。
[Virtual Media] をクリックし、[Connect CD/DVD-ROM] で仮想メディアの URL を指定します。
省略可: [Boot on Next reset] を選択します。[Boot on Next reset] を選択すると、サーバーは次のサーバー再起動時にのみこのイメージで起動します。イメージは 2 回目のサーバー再起動時に自動的に取り出されるため、サーバーがこのイメージで 2 回起動することはありません。このチェックボックスがオンになっていない場合、イメージは手動で取り出すまで接続されたままになります。
[メディアを挿入] をクリックして検証します。
ブートストラップマシンを .iso イメージから起動するには、マシンをリセットする必要があります。
1. iLO コンソールで、[Power & Thermal - Server Power] をクリックします。
2. [リセット] をクリックします。仮想コンソールを開いて、マシンのリセットと .iso ファイルの起動をモニタリングできます。
ブートストラップが完了したら、ログインとパスワードを指定して、ブートストラップマシン（root アカウント）に接続します。ブートストラップは Google が作成した ISO ファイルを使用してブートストラップされるため、Google がデフォルトの root パスワードを指定します。

オペレーターはパスワードにアクセスでき、必要に応じて別のユーザーを作成できます。

ブートストラップ ISO には docker や kubectl などの必要なツールがすべて含まれているため、別途インストールする必要はありません。

9.1.2. USB ドライブに書き込まれた ISO を使用したインストール

9.1.2.1. ISO を USB ドライブに書き込む

システムコントローラは rocky イメージを使用します。これにより、dd コマンドまたは [ディスク] ユーザーインターフェース（UI）を使用できます。
ディスク UI を使用する場合:
1. フラッシュドライブを接続します。
2. ナビゲーションメニューで [フラッシュドライブ] をクリックし、メニューバーのハンバーガーメニューをクリックします。[Restore Disk Image] をクリックし、ダウンロードした ISO のブートストラップを指定します。
dd の場合:
1. どのディスクが USB ドライブであるかを確認するには、次のコマンドを実行します。 sudo fdisk -l
2. [Disk size] を使用して、デバイスが USB であるかどうかを判断します。次の手順で使用するため、デバイス名をメモしておきます。
3. 前の手順で指定したデバイス名でディスクをマウントします。sudo umount <device name>
4. ドライブをフォーマットします。 sudo mkfs.vfat <device name>
5. ISO をドライブにコピーします。 sudo dd bs=4M if=<path to ISO file> of=<device name> status=progress

9.1.2.2. USB ブートドライブを使用して起動する

USB ドライブを前面の USB ポート（iLO とマークされているポートではない）に挿入します。
iLO インターフェースで電源ボタンの [Momentary Press] を選択します。仮想ボタンの色が黄色に変わるまで待ちます。これは、マシンが電源オフになったことを示します。
[管理]、[起動順序] の順に選択します。
[One-Time Boot Status] > [Select One-Time Boot] セクションで、[USB drive] を選択します。
iLO インターフェースの電源ボタンで [Momentary Press] を選択し、仮想ボタンが緑色に変わったことを確認します。OS のインストールは自動で行われ、再起動も自動で行われます。コンソールに bootstrapper login プロンプトが表示されたら、ブートストラップのインストールは完了です。
USB ドライブを取り外します。

9.1.3. 監査ロギングのインストール

ブートストラップ監査ロギングを手動でインストールして有効にするには:

次のブロックを /etc/bash.bootstrapper_audit.sh の新しいファイルにコピーします。

function log_previous_cmd() {
rc=$? ; [[ "$rc" -eq 130 ]] && return
line="rc=${rc};;pwd=$(pwd);;ppid=${PPID}"
line="${line};;started=$(history 1|awk 'NR==1{$0=gensub(/^.{0,7}([^ ]*) /,"\\1;;cmd=","g",$0)}1')"
logger --priority local6.info --id="$$" "${line}"
}
export PROMPT_COMMAND='log_previous_cmd'
export HISTTIMEFORMAT='%G-%m-%dT%T '

この行を /etc/bash.bashrc の末尾に追加します。
```
[ -f /etc/bash.bootstrapper_audit.sh ] && . /etc/bash.bootstrapper_audit.sh
```
これらの変更を保存すると、新しいシェルはすべてシステムジャーナルに監査ログエントリを記録するようになります。

注: 現在のシェルでは、この変更は反映されません。source /etc/bash.bashrc を使用して、現在のシェルで監査ロギングを有効にします。

（省略可）監査ロギングが機能していることを確認する

監査ログが正常に記録されていることを確認するには、次のコマンドを実行し、同様の出力が生成されることを確認します。

USER@bootstrapper:~$ echo 'a command'
USER@bootstrapper:~$ sudo journalctl -eo short-iso -p info SYSLOG_FACILITY=22
2024-10-12T00:30:24+0000 bootstrapper USER[96558]: rc=0;;pwd=/root;;ppid=96479;;started=2024-10-12T00:30:24;;cmd=date
2024-10-12T00:30:47+0000 bootstrapper USER[96558]: rc=0;;pwd=/root;;ppid=96479;;started=2024-10-12T00:30:47;;cmd=echo 'a command'

（省略可）監査ロギングを無効にする

監査ロギングが他のブートストラップオペレーションに影響している疑いがある場合は、現在のシェルで次のコマンドを使用して、この機能をすばやく無効にできます。
```
USER@bootstrapper:~$ unset PROMPT_COMMAND
```
監査ロギングが何も影響していないことを確認したら、現在のシェルで source /etc/bash.bashrc を使用して再度有効にします。

9.2. 管理インターフェースとルートを設定する

このセクションでは、ブートストラッププロセスに必要な管理インターフェースとルートを設定します。

9.2.1. 管理 IP、CIDR、ゲートウェイアドレスを確認する

cellcfg/serv-core.yaml ファイルでブートストラップの管理 IP を見つけます。

yq eval -r 'select(.metadata.annotations."system.private.gdc.goog/bootstrapper" == "true") | .spec.managementNetwork.ips[0]' PATH_TO_SERV_CORE_FILE

PATH_TO_SERV_CORE_FILE は、cellcfg/serv-core.yaml ファイルのパスに置き換えます。

ブートストラッパーは、アノテーション system.private.gdc.goog/bootstrapper: "true" で識別されます。spec.managementNetwork.ips[0] の管理 IP アドレスは、この例では 172.22.80.76 です。

apiVersion: system.private.gdc.goog/v1alpha1
kind: Server
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
    system.private.gdc.goog/bootstrapper: "true"
  creationTimestamp: null
  labels:
    system.private.gdc.goog/rack-name: mb-aa
  name: mb-aa-bm13
  namespace: gpc-system
spec:
  bmc:
    credentialsRef:
      name: bmc-credentials-mb-aa-bm13
      namespace: gpc-system
    ip: 172.22.80.108
    mac: 5c:ba:2c:42:a9:68
    protocol: redfish
    redfish:
      systemPath: /redfish/v1/Systems/1
  dataplaneNetwork: {}
  encryptDisk: true
  firmwareInstall: true
  secureErase: true
  luks:
    enable: false
  managementNetwork:
    ips:
    - 172.22.80.76
    link: LOM1

管理インターフェースの IP アドレスの設定に必要な CIDR アドレス範囲を確認します。これは CIQ アンケートで確認できます。

CIQ の例:
```
oobManagementCIDRs:
- ipFamily: IPv4
  ipv4: 172.23.16.0/24
- ipFamily: IPv4
  ipv4: 172.23.17.0/24
- ipFamily: IPv4
  ipv4: 172.23.18.0/24
- ipFamily: IPv4
  ipv4: 172.23.19.0/24
```
この例では、CIDR 範囲 172.23.16.0/22 が、リストされているすべての管理 CIDR アドレスをカバーしています。

ブートストラッパーが管理ネットワークとの通信に使用するゲートウェイアドレスを確認します。ブートストラップが ac ラックにある場合は、次のコマンドで CIDRClaim リソースの名前を確認します。

grep -A 10 -B 10 "ac-mgmtsw01-server-os-cidr" cellcfg/pnet-core.yaml`.

出力は次のようになります。

apiVersion: system.private.gdc.goog/v1alpha1
kind: CIDRClaim
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
  labels:
    cidrclaims.system.private.gdc.goog/cidr-category: internal
    cidrclaims.system.private.gdc.goog/cidr-org: root
    cidrclaims.system.private.gdc.goog/node-type: leaf
    network.private.gdc.goog/mgmtnw-device-category: server-os
    network.private.gdc.goog/mgmtsw: ag-ac-mgmtsw01
  name: ag-ac-mgmtsw01-server-os-cidr
  namespace: root
spec:
  ipv4Spec:
    staticCidrBlocks:
    - 172.28.120.128/26
  parentCidrClaimName: server-os-mgmt-network-cidr

ag-ac-mgmtsw01-server-os-cidr という名前の CIDRClaim リソースの ipv4Spec.staticCidrBlocks で見つかった 172.28.120.128/26 を使用すると、ゲートウェイアドレスは 172.28.120.128/26 の最初の IP アドレス（172.28.120.129）になります。

9.2.2. 管理インターフェースの IP アドレスを構成する

ip address add dev MGMT_INTERFACE MGMT_IP/MGMT_SUBNET_PREFIX

次のように置き換えます。

MGMT_INTERFACE: 管理インターフェース名の例は ens15f0 です。cellcfg/serv-core.yaml の MAC アドレスを使用して、管理ネットワークに使用されるインターフェースを特定します。
MGMT_IP: 管理 IP と CIDR を確認するセクションで確認した管理 IP アドレス。
MGMT_SUBNET_PREFIX: 管理 CIDR サブネットプレフィックス（前の例の 172.23.16.0/22 の 22 など）。詳細については、管理 IP と CIDR を確認するをご覧ください。

次に、ブートストラップでスクリプトを実行します。このスクリプトは、IP アドレスを管理インターフェースに割り当て、管理 CIDR 範囲のデフォルトルートを作成します。

9.2.3. 管理インターフェースを有効にする

このセクションでは、管理インターフェースを有効にする手順について説明します。cellcfg/serv-core.yaml のブートストラップで管理インターフェースの MAC アドレスを見つけ、ブートストラップの ip a 出力でこの MAC アドレスを相互参照して、管理インターフェースを特定します。

この例では、管理インターフェースの値は ens15f0 です。これらの手順に沿って操作する際は、独自の値を使用してください。cellcfg/serv-core.yaml ファイルにある管理 IP アドレスを使用して IP アドレスを追加します。

apiVersion: system.private.gdc.goog/v1alpha1
kind: Server
metadata:
  annotations:
    lcm.private.gdc.goog/claim-by-force: "true"
    helm.sh/resource-policy: keep
    system.private.gdc.goog/bootstrapper: "true"
  creationTimestamp: null
  labels:
    system.private.gdc.goog/rack-name: ma-ac
  name: ma-ac-bm15
  namespace: gpc-system
spec:
  bmc:
    credentialsRef:
      name: bmc-credentials-ma-ac-bm15
      namespace: gpc-system
    ip: 172.29.8.208
    mac: 5c:ba:2c:42:28:2e
    protocol: redfish
    redfish:
      systemPath: /redfish/v1/Systems/1
  dataplaneNetwork: {}
  encryptDisk: true
  firmwareInstall: true
  secureErase: true
  luks:
    enable: false
  managementNetwork:
    ips:
    - 172.29.24.147
    link: LOM1
  provider: external
  serverHardware:
    bmhNetworkRef:
      name: ma-ac-bm15
    dataplaneNICPorts:
    - mac: 5c:ba:2c:61:83:90
      name: s1p1
    - mac: 5c:ba:2c:61:83:98
      name: s1p2
    machineClassName: o1-standard1-64-gdc-metal
    managementNICPort:
      mac: 98:f2:b3:28:0b:70
      name: LOM1
    portBond:
      name: s1p1-s1p2
      networkBondModeType: 802.3ad
      nicPortNames:
      - s1p1
      - s1p2
status: {}

この YAML ファイルの例では、管理 IP アドレスは 172.29.24.147 です。管理 IP、CIDR、ゲートウェイアドレスの検索で確認した CIDR ブロックが /26 であるため、プレフィックス長 /26 が使用されます。

管理 IP アドレスを管理インターフェースに追加します。

sudo ip addr add 172.29.24.147/26 dev ens15f0,

次に、次の ip コマンドを使用してインターフェースを設定します。

ip link set ens15f0 up

インターフェースの構成が成功したかどうかを確認するには、ip link show ens15f0 を使用します。

ip link show ens15f0

出力は次のようになります。UP メッセージは成功を示します。

6: ens15f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 98:f2:b3:28:0b:70 brd ff:ff:ff:ff:ff:ff
    inet 172.29.24.147/26 brd 172.29.24.191 scope global ens15f0
       valid_lft forever preferred_lft forever
    inet6 fe80::9af2:b3ff:fe28:b70/64 scope link
       valid_lft forever preferred_lft forever

9.2.4. ルーティング構成を設定する


MGMT_GATEWAY=MGMT_GATEWAY
MGMT_CIDR=MGMT_CIDR
MGMT_INTERFACE=MGMT_INTERFACE

ip route add $MGMT_CIDR via $MGMT_GATEWAY dev $MGMT_INTERFACE proto static"

次のように置き換えます。

MGMT_GATEWAY: 管理 IP、CIDR、ゲートウェイアドレスを確認するセクションで確認したゲートウェイ IP アドレス。
MGMT_CIDR: 管理 CIDR は CIQ から取得されます。管理 IP、CIDR、ゲートウェイアドレスを確認するをご覧ください。
MGMT_INTERFACE: 管理インターフェース名の例は ens15f0 です。cellcfg/serv-core.yaml の MAC アドレスを使用して、管理ネットワークに使用されるインターフェースを特定できます。

次に、ブートストラッパーでスクリプトを実行します。

9.3. ブートストラップのクロックを構成する

この時点では、NTP サーバーはまだありません。ブートストラップのクロックを UTC の妥当な精度（リアルタイムの 1 秒以内）で手動で設定する必要があります。24 時間制を使用していることが確実な場合を除き、「AM」または「PM」を使用してください。時計が正しく設定されていないと、後の段階で修復できない影響が生じます。

date --set "DATE_TIME_UTC"

DATE_TIME_UTC は、UTC の日時に置き換えます（2023-03-21 01:14:30 AM UTC など）。

ブートストラップサーバーからログアウトした場合は、ブートストラップマシンの物理的な場所で、またはシステムコントローラを使用して、再度ログインできます。

物理マシンからブートストラップサーバーにログインします。

キーボード、マウス、モニタをブートストラップマシンに接続します。
デフォルトのユーザー名とパスワードを使用してマシンにログインします。

システムコントローラを使用してブートストラップサーバーにログインします。

システムコントローラを持ってクラッシュカートに移動します。
次のコマンドを実行します。
```
ssh ubuntu@BOOTSTRAPPER_IP_ADDRESS
```
BOOTSTRAPPER_IP_ADDRESS は、ブートストラップサーバーの IP アドレスに置き換えます。

9.5. ファイル構造

以降の操作はすべて root ユーザーとして行います。次のディレクトリ構造は推奨されますが、必須ではありません。

    root
    ├── kubeconfigs/ - recommend creating this directory to keep track of the many kubeconfigs
    └── .kube/config - location of bootstrap(KIND) cluster kubeconfig
    └── full-release-y.y.y-gdch.yyy - Extraction of the gdch tar from step download-files
        ├── bootstrapper.iso
        ├── docs
        ├── examples
        ├── gdcloud
        ├── harbor
        ├── oci
        └── operations_center
        └── root-admin/root-admin-kubeconfig - where the root-admin kubeconfig will be put after root-admin creation
    └── full-release-y.y.y-gdch.yyy-hotfix - if necessary, hotfixes will be extracted to another folder
        ├── README - explains how to apply the hotfix
        ├── oci - directory containing the hotfix
    ├── config - this is for the output of the "create configuration files" step
        ├── output/cellcfg - initial CRs applied to the bootstrap cluster
        ├── output/assets
        ├── devices.csv - HW file useful to have for debugging
        ├── cables.csv - HW file useful to have for debugging
        ├── ciq.yaml - HW file useful to have for debugging