ユーザー・データ
IBM Cloud® Virtual Servers for Virtual Private Cloud インスタンスを作成する際に、自動的に一般的な構成タスクを実行したりスクリプトを実行したりするユーザー・データをオプションで指定することができます。 ユーザー・データとユーザー名について詳しくは、 IAM アクセス権限 を参照してください。
IBM Cloud VPC は、仮想サーバー・インスタンスを構成するためにCloud-initテクノロジーを使用している。 **「VPC 用の新規仮想サーバー」*ページの「ユーザー・データ」*フィールドで、ユーザーは cloud-init を使用してカスタム構成オプションを入力することができます。 cloud-init では、yaml などの複数の形式を使用して cloud-config ファイルの構成データを設定できます。
cloud-config データをユーザー・データ・フィールドに直接指定することも、cloud-config データをテキスト・ファイルに入れて、インスタンスの作成時にそのファイル名を指定することもできます。 例えば、cloud-config データを userdata.blob
に保存した場合は、CLI を使用してインスタンスを作成するときに -user-data @userdata.blob
と指定します。
IBM Hyper Protect Container Runtime イメージを使用して仮想サーバー・インスタンスを作成する場合は、 「ユーザー・データ」 フィールドの一部として契約を渡す必要があります。 イメージは SSH アクセスが無効になっているロック・ダウン・イメージであるため、インスタンスと対話する唯一の方法は、契約を渡すことです。
**「ユーザー・データ」**フィールド (またはファイル) のサイズ制限は 64 KB です。
Linux の場合のユーザー・データの例
Linux のデフォルトのユーザーアカウントは、オペレーティングシステムによって異なります。 対応するデフォルトのユーザーアカウントとオペレーティングシステムのリストについては 、「 Linux インスタンスへの接続:デフォルトのユーザーアカウントの確認 」を参照してください。
ユーザーと SSH 鍵の追加
以下の cloud-init の例は、Linux ユーザーがユーザーを追加し、許可された SSH 鍵をそのユーザーに提供する方法を示しています。 Name フィールドには、~/.ssh/authorized_keys
に追加された公開鍵を指定します。
Linux イメージの場合、 Ed25519 SSH 鍵タイプは、オペレーティング・システムの SSH サーバーがこの鍵タイプをサポートしている場合にのみ使用できます。 詳しくは、 SSH 鍵入門を参照してください。
#cloud-config
users:
- name: demouser
gecos: Demo User
sudo: ALL=(ALL) NOPASSWD:ALL
groups: users, admin
ssh_import_id: None
lock_passwd: true
ssh_authorized_keys:
- <ssh public key>
以下のシェル・スクリプトの例は、Linux ユーザーが現行ユーザーの SSH 鍵を追加する方法を示しています。
#!/bin/bash
echo <sshKey> > ~/.ssh/authorized_keys
これらのいずれかの例を**「ユーザー・データ」**フィールドに直接貼り付けることができます。 貼り付けると、プロビジョニング中に仮想サーバー・インスタンスでこのユーザー・データを使用できるようになります。
ファイルをインクルードするように指定し、ファイル名の前にスペースがあると、データは正しく解釈されません。 #!/bin/sh
または #!/bin/bash
が、ファイル終了指定 (<<EOF
) の直後の行の最初の文字であることを確認する。文字をインデントすることはできない。
Linux ユーザー データの例と詳細については、 「クラウド構成の例」を参照してください。
cloud-config スクリプトを使用してディスク 1 台のインスタンス・ストレージを構成する
インスタンス・ストレージとは、VPC の機能の 1 つであり、高速なローカル・ストレージが接続された仮想サーバー・インスタンスを要求できるものです。 インスタンス・ストレージについて詳しくは、インスタンス・ストレージについてを参照してください。
デフォルトでは、インスタンス・ストレージを備えた仮想サーバーをプロビジョンした後に、そのサーバーに初めてログインするときには、インスタンス・ストレージのディスクは構成されていません。 それらはブロック・デバイスとして表示されます (例えば /dev/vdb
など)。ファイル・システムで使用できるようにするには、まず以下の操作を実行する必要があります。
- デバイスをパーティション化する。
- パーティションをファイル・システムでフォーマットする。
- ファイル・システムをマウントする。
**「ユーザー・データ」**フィールドを使用して仮想インスタンスをプロビジョンする場合は、これらの操作も自動的に実行することができます。 cloud-config
スクリプトで以下の操作を定義します。
- 仮想インスタンスの最初のブート時に実行するクラウド初期化プロセスを指示します。
- デバイスを自動的にパーティション化する。
- パーティションを
ext4
ファイル・システムでフォーマットする。 - ファイル・システムをマウントする。
仮想インスタンスの定義に含まれていないインスタンス・ストレージのディスクを自動的に構成する操作は、**「ユーザー・データ」**フィールドに指定しないでください。 仮想インスタンスの定義に含まれていないインスタンス・ストレージのディスクを自動的に構成しようとすると、dev/vdb device
がターゲットになり、cloud-init データ・ソースが指定される可能性があります。その結果、ホスト名や SSH 鍵などの cloud-init 構成が破損する可能性があります。
以下の例は、インスタンス・ストレージのディスクを自動的に構成するユーザー・データを示しています。 この例は、ディスク 1 台が定義されたインスタンス・プロファイルで使用できます。
#cloud-config
# Cloud-init supports simple partition and file system config.
# This user data yaml will create a full partition on the first
# virtio_blk device after the boot device, initialize ext4 on it and
# mount it on a folder matching the label.
#
disk_setup:
/dev/vdb:
table_type: 'mbr'
layout:
- 100
overwrite: false
fs_setup:
- label: /mnt/inststg1
filesystem: 'ext4'
device: /dev/vdb1
overwrite: false
runcmd:
- [ mkdir, /mnt/inststg1 ]
mounts:
- ["/dev/vdb1", "/mnt/inststg1"]
mount_default_fields: [ None, None, "auto", "defaults,nofail", "0", "2" ]
このスクリプトは、仮想インスタンスで使用可能な virtio_blk インターフェースタイプの最初のインスタンスストレージデバイスを /dev/vdb, 設定します。 このスクリプトを**「ユーザー・データ」**フィールドに張り付けることも、UI の「ユーザー・データのインポート」リンクを使用してインポートすることもできます。
このスクリプトは、Ubuntu 20.04 LTS Focal Fossa
のストック・イメージを使用してテストされています。 このスクリプトは他の Linux ストック・イメージやカスタム・イメージにも使用できる場合がありますが、スクリプトの調整が必要になる可能性があります。
この cloud-config スクリプトは、Windows 仮想サーバーには適していません。 インスタンスにインスタンス・ストレージが含まれていない場合は、このスクリプトを使用しないでください。 意図しないデバイスが構成される可能性があります。
cloud-config スクリプトに記載されている項目については、以下の情報をご覧ください
- disk_setup: マスター・ブート・レコードを使用して、ディスク全体にわたる単一のデフォルト・パーティションを作成します。 「overwrite: false」を指定しているので、デバイスが既にパーティション化されている場合、この操作はスキップされます。
- fs_setup: vdb ブロック・デバイスの最初のパーティションに ext4 ファイル・システムを作成し、「inststg1」というラベルを付けます。 ファイル・システムのタイプとラベルは、ニーズに合わせて調整できます。 「overwrite: false」設定で、パーティションが既にファイル・システムでフォーマットされている場合には、フォーマットしないようにしています。
- runcmd: マウント・ポイントとして使用するディレクトリーを、階層型の親のファイル・システムの「/」以外の場所に作成します。
- mounts: /inststg1 へのファイル・システム・デバイスのマウントを実行します。 このディレクトリー・パスと runcmd 下のディレクトリー・パスの名前は変更できます。
- mount_default_fields: /etc/fstab ファイルに永続的なマウント・ディレクティブを作成します。 リブート・コマンドを実行すると、仮想サーバーは、以前と同じくインスタンス・ストレージのファイル・システムがマウントされた状態で再起動します。
CLIとAPIは、 ユーザー・データ ・フィールドもサポートしている。
この例の cloud-config スクリプトでは、インスタンス・ストレージの /dev/vdb
ブロック・デバイスが自動的に構成されます。 仮想サーバーを再起動するだけで、コンフィギュレーションとデータが保持されるため、このコンフィギュレーションは機能し続けます。 ただし、以前に停止していた仮想サーバーを起動すると、仮想サーバーの起動時にインスタンス・ストレージ・ディスクのセットが新しくなります。 この状態では、cloud-init 手順を手動で再実行する必要があります。
デフォルトでは、cloud-configスクリプトは最初の起動時にのみ実行されます。 cloud.config ファイルの cloud-init セクションを編集して、ブートするたびに cloud-init 手順を自動的に実行することもできます。 その手順については、ブートするたびに実行するように cloud.config ファイルの cloud_cloud_init_modules セクションを編集するセクションを参照してください。
cloud-configスクリプトを使用した2ディスクインスタンスストレージの設定
以下の例は、インスタンス・ストレージのディスクを自動的に構成するユーザー・データを示しています。 この例は、ディスク 2 台が定義されたインスタンス・プロファイルで使用できます。
#cloud-config
# Cloud-init supports simple partition and file system config.
# This user data yaml will create a full partition on the first two
# virtio_blk devices after the boot device, initialize ext4 on them and
# mount them on new folders off of ‘/mnt/’.
#
disk_setup:
/dev/vdb:
table_type: 'mbr'
layout:
- 100
overwrite: false
/dev/vdc:
table_type: 'mbr'
layout:
- 100
overwrite: false
fs_setup:
- label: /mnt/inststg1
filesystem: 'ext4'
device: /dev/vdb1
overwrite: false
- label: /mnt/inststg2
filesystem: 'ext4'
device: /dev/vdc1
overwrite: false
runcmd:
- [ mkdir, /mnt/inststg1 ]
- [ mkdir, /mnt/inststg2 ]
mounts:
- ["/dev/vdb1", "/mnt/inststg1"]
- ["/dev/vdc1", "/mnt/inststg2"]
mount_default_fields: [ None, None, "auto", "defaults,nofail", "0", "2" ]
この cloud-config スクリプトの例では、インスタンス・ストレージ /dev/vdb
と dev/vdc
ブロック・デバイスの両方を自動的に構成し、インスタンス・ストレージの virtio_blk
インターフェース・タイプを想定しています。 仮想サーバーを再起動するだけで、コンフィギュレーションとデータは保持されるため、このコンフィギュレーションは機能し続けます。
停止していた仮想サーバーを起動すると、仮想サーバーの起動時にインスタンス・ストレージ・ディスクのセットが新しくなります。 このような状況では、クラウドイニットの手順を手動で再度実行する必要がある。 デフォルトでは、cloud-configスクリプトは最初の起動時にのみ実行されます。 cloud.config ファイルの cloud-init セクションを編集して、ブートするたびに cloud-init 手順を自動的に実行することもできます。
ブートするたびに実行するように cloud.config ファイルの cloud_cloud_init_modules セクションを編集する
上記の例の cloud-config スクリプトでは、インスタンス・ストレージの /dev/vdb
ブロック・デバイスが自動的に構成されます。 仮想サーバーを再起動するだけで、コンフィギュレーションとデータが保持されるため、このコンフィギュレーションは機能し続けます。 ただし、停止していた仮想サーバーを起動すると、仮想サーバーの起動時にインスタンス・ストレージ・ディスクのセットが新しくなります。 このような状況では、クラウドイニットの手順を手動で再度実行する必要がある。
デフォルトでは、cloud-configスクリプトは最初の起動時にのみ実行されます。
- 前の例のcloud-init yamlデータを指定する User Dataフィールドを持つプロビジョニングされたインスタンスが必要です。
- 起動したインスタンスにログインすると、ファイルシステムが構成されマウントされている必要があります。
- cloud-config yamlのdisk_setupセクションやmountセクションには、ユーザーデータとして指定されている他のディレクティブはありません。
連続したブートごとにcloud-configスクリプトを実行するには、以下の手順を使用します:
-
etc/cloud/cloud.cfg
ファイルを編集します。 -
cloud_init_modules
セクションを探します。disk_setupとmountモジュールが含まれています。 -
disk_setup と mount のモジュールの行を
always
に変更します。 セクションは以下のようになります。# The modules that run in the 'init' stage cloud_init_modules: - migrator - seed_random - bootcmd - write-files - growpart - resizefs - [disk_setup, always] - [mounts, always] - set_hostname - update_hostname - update_etc_hosts - ca-certs - rsyslog - users-groups - ssh
-
ファイルを保存したら、インスタンスを停止して再始動します。 新しくパーティション化され、フォーマットされたファイル・システムに、マウントが自動的に作成されます。
Windows の場合のユーザー・データの例
以下の例は、Windows インスタンスに渡すことができるユーザー・データを示しています。 このユーザーデータ・サンプルはタイムゾーンを設定する。
"user_data": "Content-Type: multipart/mixed; boundary=MIMEBOUNDARY\nMIME-Version: 1.0\n\n--MIMEBOUNDARY\nContent-Type: text/cloud-config; charset=\"us-ascii\"\nMIME-Version: 1.0\nContent-Transfer-Encoding: 7bit\nContent-Disposition: attachment; filename=\"cloud-config\"\n#cloud-config\n\nset_timezone: America/Detroit\n\n--MIMEBOUNDARY--\n"
Windowsユーザーデータの例と情報については、 Cloudbase-init 1.0 ドキュメントを参照。
Fedora Core OS のユーザー・データの例
以下の例は、Fedora Core OS インスタンスに渡すことができるユーザー・データを示しています。
ユーザー・ログイン「root」は、Fedora Core OS ではデフォルトで無効になっています。 ユーザー・ログイン「core」は、Fedora Core OS インスタンスへのログインに使用できます。
Fedora Core OS ユーザー・データは Ignition 形式でなければなりません。
次の例を使用して、Fedora Core OS インスタンスをブートします。
ibmcloud is instance-create $NAME $VPC $ZONE $PROFILE $SUBNET --image-id $IMAGE --key-ids $SSHKEY --user-data @example.ign
次の例を使用して、ローカル・ユーザーを作成します。
-
Butane 構成を YAML 形式で記述します。
Butane 構成
variant: fcos version: 1.4.0 passwd: users: - name: demouser
-
Butane を使用して、Butane 構成を Ignition 構成に変換します。
Ignition 構成
"ignition": { "version": "1.4.0" }, "passwd": { "users": [ { "name": "demouser" } ] } }
以下のサンプル・ユーザー・データを使用して、ローカル・ユーザーのSSH鍵を追加してください。
-
Butane 構成を YAML 形式で記述します。
Butane 構成
variant: fcos version: 1.4.0 passwd: users: - name: demouser ssh_authorized_keys: - <ssh public key>
-
Butane を使用して、Butane 構成を Ignition 構成に変換します。
Ignition 構成
"ignition": { "version": "1.4.0" }, "passwd": { "users": [ { "name": "demouser", "sshAuthorizedKeys": [ "<ssh public key>" ] } ] } }
Fedora コア OS ユーザー・データの例および情報について詳しくは、 Fedora プロジェクトの資料を参照してください。
次のステップ
プロファイルを選択したら、次はインスタンスの計画と作成を行います。