すべてのプロダクト
Search

このプロダクト

    :インスタンスユーザーデータを使用して、インスタンスの起動時にコマンドまたはスクリプトを自動的に実行する

    ドキュメントセンター

    :インスタンスユーザーデータを使用して、インスタンスの起動時にコマンドまたはスクリプトを自動的に実行する

    最終更新日:Sep 06, 2024

    インスタンスユーザーデータとは、スクリプト、命令、設定ファイルなど、インスタンスにアップロードされるデータを指します。 インスタンスユーザーデータを使用して、インスタンスを初期化または設定できます。 たとえば、インスタンスが最初に起動されると、インスタンスは自動的にユーザーデータを使用してサービス起動スクリプトを実行し、ソフトウェアをインストールし、ログを印刷します。 このトピックでは、ユーザーデータをElastic Compute Service (ECS) インスタンスに渡し、ユーザーデータを変更し、ユーザーデータを表示する方法について説明します。

    インスタンスが初めて起動されると、インスタンスは自動的にユーザーデータを実行します。 Linuxインスタンスを起動するたびに、特定の形式のユーザーデータを実行することもできます。 詳細については、このトピックの「ユーザーデータの形式と実行頻度」をご参照ください。

    制限事項

    • インスタンスは仮想プライベートクラウド (VPC) にデプロイする必要があります。

    • インスタンスは、次のオペレーティングシステムのパブリックイメージ、またはパブリックイメージから派生したカスタムイメージから作成する必要があります。

      • Alibaba Cloud Linux、CentOS、CentOS Stream、Ubuntu、SUSE Linux Enterprise Server、Red Hat Enterprise Linux、openSUSE、Debian、AlmaLinux、Rocky Linux、Fedora

      • Windows Server 2008 R2以降

    • 廃止されたインスタンスタイプの場合、I/O最適化インスタンスはユーザーデータをサポートし、非I/O最適化インスタンスはユーザーデータをサポートしません。 詳細は、「廃止されたインスタンスタイプ」をご参照ください。

    インスタンスユーザーデータの使用

    ユーザーデータをECSインスタンスに渡す

    1. ユーザーデータを準備します。

      サポートされている形式、実行頻度、ユーザーデータの説明については、このトピックの「ユーザーデータの形式と実行頻度」をご参照ください。

      重要

      ユーザーデータがBase64でエンコードされる前は、ユーザーデータのサイズは最大32 KBしかありません。

    2. ユーザーデータをECSインスタンスに渡します。

      • インスタンスの作成時にユーザーデータを渡すと、インスタンスの最初の起動時、インスタンスで実行されているオペレーティングシステムが置き換えられたとき、またはインスタンスに接続されているシステムディスクが再初期化されたときに、ユーザーデータが実行されます。

      • 既存のインスタンスのユーザーデータを変更した場合、インスタンスで実行されているオペレーティングシステムを置き換えるとき、またはインスタンスに接続されているシステムディスクを再初期化するときに、新しいユーザーデータが実行されます。

        Linuxインスタンスを起動するたびに、特定の形式のユーザーデータを実行できます。 詳細については、このトピックの「ユーザーデータの形式と実行頻度」をご参照ください。

      3. インスタンスの作成時にユーザーデータを渡す

      ECSインスタンス購入ページの [カスタム起動] タブで、[詳細設定 (オプション)] セクションをクリックします。 [ユーザーデータ] フィールドに、インスタンスのユーザーデータを入力します。

      [Base64エンコード情報の入力] を選択した場合、ユーザーデータがBase64でエンコードされ、Base64エンコード前のサイズが32 KBを超えないようにします。 Enter Base64 Encoded Informationを選択しない場合、システムは自動的にBase64でユーザーデータをエンコードします。

      既存のインスタンスのユーザーデータの変更

      1. インスタンスのステータスが [停止済み] であることを確認します。

        重要

        従量課金方式を使用してインスタンスが課金され、VPCにある場合は、インスタンスを停止するときに [停止モード] セクションで [標準モード] を選択することを推奨します。 [エコノミーモード] を選択した場合、インスタンスのコンピューティングリソース (vCPUとメモリ) がリサイクルされます。 その結果、リソース不足によりインスタンスの再起動に失敗することがあります。 詳細については、「経済モード」をご参照ください。

      2. [インスタンス] ページで、icon1 > [インスタンス設定] > [ユーザーデータの設定] を選択します。 [ユーザーデータの設定] ダイアログボックスで、[ユーザーデータ] フィールドにユーザーデータを入力します。 [確認] をクリックします。

    3. ユーザーデータが期待どおりに実行されているかどうかを確認します。

      説明

      ユーザーデータスクリプトの実行時に問題が発生した場合は、次の一般的なCloud Assistantコマンドを実行してエラーログを取得できACS-ECS-UserData-Check-for-linux.sh。 ログにエラーメッセージが表示された場合、スクリプトの実行時にエラーが発生しました。 ログにエラーメッセージが表示されない場合、スクリプトの実行時にエラーは発生しませんでした。 他の側面からスクリプトを確認して、問題の原因を特定します。 一般的なCloud Assistantコマンドの詳細については、「一般的なコマンドの表示と実行」をご参照ください。

      たとえば、次のユーザーデータスクリプトがLinuxインスタンスに渡されます。

      #!/bin/sh
echo "Hello World. The time is now $(date -R)!" | tee /root/userdata_test.txt

      cat userdata_test.txtコマンドを実行して、スクリプトが期待どおりに実行されているかどうかを確認します。 次のコマンド出力は、システム時刻がuserdata_test.txtファイルに書き込まれていることを示しています。

      view-result

    インスタンスのユーザーデータの表示

    ユーザーデータがインスタンスに渡された後、インスタンスのメタデータまたはECSコンソールでユーザーデータを表示できます。

    メタデータ内のユーザーデータの表示 (通常モード)

    • Linux インスタンス

      curl http://100.100.100.200/latest/user-data

    • Windows インスタンス

      Invoke-RestMethod http://100.100.100.200/latest/user-data

    メタデータ内のユーザーデータの表示 (セキュリティ強化モード)

    たとえば、メタデータサーバーへのアクセスに使用される資格情報の有効期間を180秒に設定します。

    • Linux インスタンス

      TOKEN=`curl -X PUT "http://100.100.100.200/latest/api/token" -H "X-aliyun-ecs-metadata-token-ttl-seconds:180"`
curl -H "X-aliyun-ecs-metadata-token: $TOKEN" http://100.100.100.200/latest/user-data

    • Windows インスタンス

      $token = Invoke-RestMethod -Headers @{"X-aliyun-ecs-metadata-token-ttl-seconds" = "180"} -Method PUT -Uri http://100.100.100.200/latest/api/token
Invoke-RestMethod -Headers @{"X-aliyun-ecs-metadata-token" = $token} -Method GET -Uri http://100.100.100.200/latest/user-data

    ECSコンソールでのユーザーデータの表示

    1. インスタンスのステータスが [停止済み] であることを確認します。

      重要

      従量課金方式を使用してインスタンスが課金され、VPCにある場合は、インスタンスを停止するときに [停止モード] セクションで [標準モード] を選択することを推奨します。 [エコノミーモード] を選択した場合、インスタンスのコンピューティングリソース (vCPUとメモリ) がリサイクルされます。 その結果、リソース不足によりインスタンスの再起動に失敗することがあります。 詳細については、「経済モード」をご参照ください。

    2. [インスタンス] ページで、icon1 > [インスタンス設定] > [ユーザーデータの設定] を選択します。 表示されるダイアログボックスの [ユーザーデータ] フィールドで、設定したユーザーデータを表示します。

    詳細については、「インスタンスメタデータの取得」をご参照ください。

    ユーザーデータでLinuxスクリプトを使用する方法の例

    例1: ユーザーデータスクリプトを使用したカスタムYUMリポジトリとNTPおよびDNSサービスの指定

    インスタンスが起動されると、システムはデフォルトのYellowdog Updater Modified (YUM) リポジトリ、Network Time Protocol (NTP) サービス、およびDomain Name system (DNS) サービスを設定します。 インスタンスのユーザーデータを使用して、設定されているデフォルトのYUMリポジトリ、NTPサービス、およびDNSサービスを変更できます。 以下の点にご注意ください。

    • カスタムYUMリポジトリを使用する場合、Alibaba CloudはYUMリポジトリサポートを提供しなくなります。

    • カスタムNTPサービスを使用する場合、Alibaba Cloudは時刻同期サービスを提供しなくなります。

    次のサンプルコードは、CentOS 7.2を実行するインスタンスに適用できるユーザーデータスクリプトの例を示しています。

    #!/bin/sh
# Modify DNS
echo "nameserve 8.8.X.X" | tee /etc/resolv.conf
# Modify yum repo and update
rm -rf /etc/yum.repos.d/*
touch myrepo.repo
echo "[base]" | tee /etc/yum.repos.d/myrepo.repo
echo "name=myrepo" | tee -a /etc/yum.repos.d/myrepo.repo
echo "baseurl=https://mirror.centos.org/centos" | tee -a /etc/yum.repos.d/myrepo.repo
echo "gpgcheck=0" | tee -a /etc/yum.repos.d/myrepo.repo
echo "enabled=1" | tee -a /etc/yum.repos.d/myrepo.repo
yum update -y
# Modify NTP Server
echo "server ntp1.aliyun.com" | tee /etc/ntp.conf
systemctl restart ntpd.service
    説明

    • 8.8.X.Xを実際のDNSサーバーアドレスに置き換え、https://mirror.centos.org/centos をCentOSの実際のYUMリポジトリアドレスに置き換え、Alibaba Cloudの実際のNTPサーバーアドレスでサービスを提供しr ntp1.aliyun.com。

    • cloud-configデータを使用してYUMリポジトリを変更することもできます。 ただし、cloud-configデータはユーザーデータスクリプトよりも柔軟性が低く、Alibaba Cloudによって特定のYUMリポジトリが事前設定されているシナリオには適していません。 ユーザーデータスクリプトの使用を推奨します。

    インスタンスの作成時にユーザーデータをインスタンスに渡します。 インスタンスの起動後、インスタンスにログインして、ユーザーデータが期待どおりに実行されているかどうか、およびYUMリポジトリ、NTPサービス、およびDNSサービスが期待どおりに設定されているかどうかを確認します。 次のサンプルコードは、設定が予想どおりに変更されることを示しています。 

    [root@iZbp1csxtw7jo9zp12s**** ~]# cat /etc/yum.repos.d/myrepo.repo
[base]
name=myrepo
baseurl=https://mirror.centos.org/centos
gpgcheck=0
enabled=1
[root@iZbp1csxtw7jo9zp12s**** ~]# cat /etc/resolv.conf
nameserver 8.8.X.X
[root@iZbp1csxtw7jo9zp12s**** ~]# ping www.baidu.com
PING www.a.shifen.com (14.215.XX.XX) 56(84) bytes of data.
64 bytes from 14.215.XX.XX (14.215.XX.XX): icmp_seq=1 ttl=52 time=26.3 ms
64 bytes from 14.215.XX.XX (14.215.XX.XX): icmp_seq=2 ttl=52 time=26.3 ms
64 bytes from 14.215.XX.XX (14.215.XX.XX): icmp_seq=3 ttl=52 time=26.2 ms
^Z
[2]+  Stopped                 ping www.baidu.com
[root@iZbp1csxtw7jo9zp12s**** ~]# cat /etc/ntp.conf
server ntp1.aliyun.com
[root@iZbp1csxtw7jo9zp12s**** ~]# systemctl status ntpd.service
● ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2021-09-06 14:53:19 CST; 13min ago
 Main PID: 5795 (ntpd)
   CGroup: /system.slice/ntpd.service
           └─5795 /usr/sbin/ntpd -u ntp:ntp -g

Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: Listen and drop on 1 v6wildcard :: UDP 123
Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: Listen normally on 2 lo 127.0.XX.XX UDP 123
Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: Listen normally on 3 eth0 192.168.XX.XX UDP 123
Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: Listening on routing socket on fd #20 for interface updates
Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: 0.0.XX.XX c016 06 restart
Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: 0.0.XX.XX c012 02 freq_set kernel 0.000 PPM
Sep 06 14:53:19 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: 0.0.XX.XX c011 01 freq_not_set
Sep 06 14:56:34 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: 0.0.XX.XX c61c 0c clock_step +0.464773 s
Sep 06 14:56:35 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: 0.0.XX.XX c614 04 freq_mode
Sep 06 14:56:36 iZbp1cjdaurreftzgpgvqoZ ntpd[5795]: 0.0.XX.XX c618 08 no_sys_peer

    例2: ユーザーデータスクリプトを使用して管理者アカウントを指定する

    デフォルトでは、Linuxインスタンスはrootアカウントを管理者アカウントとして使用します。 インスタンスのユーザーデータを使用して、別のアカウントを管理者アカウントとして指定できます。

    次のサンプルコードは、CentOS 7.2を実行するインスタンスに適用できるユーザーデータスクリプトの例を示しています。

    #!/bin/sh
useradd test
echo "test   ALL=(ALL)        NOPASSWD:ALL" | tee -a /etc/sudoers
mkdir /home/test/.ssh
touch /home/test/.ssh/authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCRnnUveAis****" | tee -a /home/test/.ssh/authorized_keys
    説明

    上記のコードのssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCRnnUveAis **** を実際の公開鍵に置き換えます。

    サンプルのユーザーデータスクリプトを実行すると、次の結果が得られます。

    • testという名前のアカウントが作成され、管理者アカウントとして使用されます。

    • アカウントはSSHキーペアのみを使用してインスタンスにログインでき、ログインにパスワードを使用することはできません。

    • アカウントを使用して管理権限を必要とする操作を実行する前に、sudoコマンドを実行してアカウントに管理権限を付与します。 権限を付与するときにパスワードを入力する必要はありません。

    インスタンスの作成時にユーザーデータをインスタンスに渡します。 インスタンスの起動後、テストアカウントとSSHキーペアを使用してインスタンスにログインします。 ログインにパスワードを使用しようとすると、エラーが報告されます。 インスタンスにログインした後、sudoコマンドを実行して、テストアカウントに管理権限を付与できます。 次に、テストアカウントを使用して、管理者権限を必要とする操作を実行できます。 例： 

    [test@iZbp1csxtw7jo9zp12s**** ~]$ cd /root
-bash: cd: /root: Permission denied
[test@iZbp1csxtw7jo9zp12s**** ~]$ sudo cd /root
[test@iZbp1csxtw7jo9zp12s**** ~]$

    ユーザーデータの形式と実行周波数

    Linux インスタンス

    Linuxインスタンスは、cloud-initを使用してインスタンスの起動動作を管理します。 最初のインスタンスの起動時に、システムは自動的にユーザーデータを実行します。 インスタンスの再起動時にユーザーデータを実行するかどうかは、ユーザーデータの形式によって決まります。

    Linuxインスタンスが初めて起動されたかどうかを確認する

    インスタンスの起動時、オペレーティングシステムの交換時、またはシステムディスクの再初期化時に、cloud-initは現在の起動がインスタンスの最初の起動であるかどうかを確認します。 Cloud-initは、ステージとブートで使用するためにcloud-initの内部ステータスを格納するキャッシュディレクトリをチェックします。 キャッシュディレクトリが存在する場合、cloud-initは、キャッシュ内のインスタンスIDがインスタンスの実際のIDと同じかどうかを確認します。 インスタンスIDが同じ場合、システムは初めて起動されます。 インスタンスIDが異なる場合、システムは初めて起動されません。 詳細については、「ブートステージ」をご参照ください。

    次のセクションでは、Linuxインスタンスのユーザーデータの一般的な形式について説明します。

    説明

    • ユーザーデータ形式の詳細については、cloud-initドキュメントの「ユーザーデータ形式」をご参照ください。

    • ユーザーデータスクリプト、cloud-configデータ、またはincludeファイルのサイズが32 KBを超える場合は、データ型としてGzip圧縮コンテンツを選択することを推奨します。

    • インスタンスを起動するたびにユーザーデータスクリプトを実行する場合は、データ型としてcloud-config dataまたはUpstart jobを選択することを推奨します。

    ユーザーデータスクリプト

    • 概要

      ユーザーデータスクリプトがLinuxインスタンスに渡された後、スクリプトはシェルスクリプトとして実行され、インスタンスが最初に起動されたときに1回だけ実行されます。

    • ランニング周波数

      • インスタンスブート: ユーザーデータスクリプトは、インスタンスが最初に起動されたときに1回だけ実行されます。 インスタンスの再起動時にスクリプトが実行されません。

      • オペレーティングシステムの交換: スクリプトは自動的に実行されます。

      • システムディスクの再初期化: スクリプトは自動的に実行されます。

      重要

      次のシナリオでは、スクリプトは自動的に実行されません。

      • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

      • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      最初の行は、数字記号と感嘆符 (#!) で始まります。

    • サンプルユーザーデータスクリプト

      #!/bin/sh
echo "Hello World. The time is now $(date -R)!" | tee /root/userdata_test.txt

      サンプルのユーザーデータスクリプトは、インスタンスが最初に起動されたときに1回だけ実行され、システム時刻をuserdata_test.txtファイルに書き込みます。

    クラウド設定データ

    • 概要

      Cloud-initは、特定のタスクを実行し、ソフトウェアパッケージのインストールやネットワーク設定の構成などの構成を実行する一連の機能モジュールを定義します。 Cloud-initは、ベンダーデータ、カスタムデータ、およびカーネルパラメータからcloud-configデータを取得します。 cloud-configデータは、タスクに関与するモジュールと実行するアクションを決定します。 ECSインスタンスを作成する前に、モジュールとタスクを指定してカスタムクラウド設定データを設定し、クラウド設定データをユーザーデータとしてインスタンスに渡すことができます。 インスタンスが起動されると、cloud-initはcloud-configデータを読み取り、解析して、構成ファイルの指示に従ってモジュールを実行し、タスクを実行してインスタンスを構成およびデプロイします。

    • ランニング周波数

      • インスタンスブート: cloud-configデータ内のタスクを実行するかどうかは、タスクに対応するモジュールの実行頻度によって決まります。 モジュールの詳細については、「モジュール」をご参照ください。

        • Once-per-instance: モジュールは、インスタンスが最初に起動されたときに1回だけ実行されます。 たとえば、AptやSet Passwordsなどのモジュールは、インスタンスごとに1回の頻度で設定および実行されます。 インスタンスの再起動時にモジュールは実行されません。

        • 常に: モジュールは、インスタンスが起動されるたびに実行されます。 たとえば、BootcmdやUpdate Etc HostsなどのモジュールがAlwaysの頻度で実行される場合、インスタンスが起動されるたびにモジュールが実行されます。

      • オペレーティングシステムの置き換え: cloud-configデータは自動的に実行されます。

      • システムディスクの再初期化: cloud-configデータが自動的に実行されます。

        重要

        次のシナリオでは、スクリプトは自動的に実行されません。

        • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

        • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      • 最初の行は #cloud-configで始まり、ヘッダーにはスペースが含まれていません。

      • Cloud-configデータは、YAML (Yet Another Markup Language) 構文に従う必要があります。

    • サンプルcloud-config data

      #cloud-config
apt:
 primary:
 - arches: [default]
 uri: https://us.archive.ubuntu.com/ubuntu/
bootcmd:
- echo "Hello World. The time is now $(date -R)!" | tee /root/userdata_test.txt

      この例では、インスタンスが起動されるたびにcloud-configデータが実行され、デフォルトリポジトリが変更され、最新のシステム時刻がuserdata_test.txtファイルに書き込まれます。

    Include file

    • 概要

      インクルードファイルには、ユーザーデータスクリプトまたはクラウド設定データへの1つ以上のリンクが含まれています。 各リンクは別々のラインを占める。 インスタンスが起動されると、cloud-initはリンクを1つずつ読み取り、解析します。 cloud-initがリンクを読み取るときにエラーが発生した場合、cloud-initは残りのリンクの読み取りを停止します。

      説明

      Alibaba Cloud Object Storage Service (OSS) を使用して、ユーザーデータスクリプトまたはクラウド設定データをインスタンスにアップロードしたり、リンクを取得したり、リンクの有効期間を指定したりできます。 詳細については、「OSSコンソールを使用して開始する」をご参照ください。

    • ランニング周波数

      • インスタンスブート: 実行頻度は、リンクの送信先のコンテンツによって異なります。 たとえば、リンクがユーザーデータスクリプトに向けられている場合、スクリプトはインスタンスが最初に開始されたときに1回だけ実行されます。 リンクがcloud-configデータに向けられている場合、cloud-configデータの実行頻度が優先されます。

      • オペレーティングシステムの置き換え: includeファイルは自動的に実行されます。

      • システムディスクの再初期化: インクルードファイルが自動的に実行されます。

        重要

        次のシナリオでは、スクリプトは自動的に実行されません。

        • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

        • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      最初の行は #includeで始まり、ヘッダーにはスペースが含まれていません。

    • サンプルinclude file

      #include
https://ecs-image-test.oss-cn-hangzhou.aliyuncs.com/userdata/myscript.sh

      この例では、includeファイルにはユーザーデータスクリプトへのリンクが含まれており、スクリプトはインスタンスが最初に起動されたときに1回だけ実行されます。

      説明

      インクルードファイルまたはGzip圧縮コンテンツを使用する場合は、ストレージサービスを使用してスクリプトをアップロードし、スクリプトリンクを取得し、リンクの有効期間を指定します。 Alibaba Cloud OSSの使用を推奨します。 詳細については、「OSSコンソールを使用して開始する」をご参照ください。

    Gzip 圧縮コンテンツ

    • 概要

      ユーザーデータスクリプト、cloud-configデータ、またはincludeファイルのサイズが32 KBを超える場合は、Gzipを使用して、. gz形式で、対応するリンクを生成し、インクルードファイルをインスタンスに渡します。 Cloud-initは、Gzip圧縮コンテンツを自動的に解凍します。 解凍されたコンテンツの実行結果は、インスタンスに直接渡される非圧縮コンテンツの実行結果と同じです。

      説明

      Alibaba Cloud OSSを使用して、ユーザーデータスクリプトまたはクラウド設定データをインスタンスにアップロードしたり、リンクを取得したり、リンクの有効期間を指定したりすることもできます。 詳細については、「OSSコンソールを使用して開始する」をご参照ください。

    • ランニング周波数

      • インスタンスブート: 実行頻度は、スクリプトタイプとモジュールタイプによって異なります。 たとえば、リンクがユーザーデータスクリプトであるGzip圧縮コンテンツに向けられている場合、Gzip圧縮コンテンツは、インスタンスが最初に起動されたときに1回だけ実行されます。

      • オペレーティングシステムの置き換え: Gzip圧縮コンテンツが自動的に実行されます。

      • システムディスクの再初期化: Gzip圧縮コンテンツが自動的に実行されます。

        重要

        次のシナリオでは、スクリプトは自動的に実行されません。

        • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

        • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      最初の行は #includeで始まり、ヘッダーにはスペースが含まれていません。

    • Gzip圧縮コンテンツのサンプルコード

      #include
https://ecs-image-test.oss-cn-hangzhou.aliyuncs.com/userdata/myscript.gz

      この例では、includeファイルには、ユーザーデータスクリプトであるGzip圧縮コンテンツへのリンクが含まれています。 cloud-initがGzip圧縮されたユーザーデータスクリプトを読み取った後、スクリプトは自動的に解凍され、インスタンスが最初に起動されたときにのみ実行されます。

    upstart job

    説明

    インスタンスでUpstartジョブを使用するには、インスタンスにUpstartサービスをインストールします。 インスタンスは、CentOS 6、Ubuntu 10、Ubuntu 12、Ubuntu 14、Debian 6、Debian 7のいずれかのオペレーティングシステムを実行する必要があります。

    • 概要

      Upstartは、イベント駆動型初期化システムです。 Upstartジョブは、いつ開始または停止するか、およびサービスまたはタスクを実行する方法を定義する構成ファイルです。 Upstartジョブファイルのファイル拡張子は。confで、/etc/init /ディレクトリにあります。

    • ランニング周波数

      • インスタンスブート: Upstartジョブは、インスタンスが開始されるたびに自動的に実行されます。

      • オペレーティングシステムの交換: Upstartジョブは自動的に実行されます。

      • システムディスクの再初期化: Upstartジョブは自動的に実行されます。

        重要

        次のシナリオでは、スクリプトは自動的に実行されません。

        • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

        • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      最初の行は #upstart-jobで始まり、ヘッダーにはスペースが含まれていません。

    • サンプルUpstartジョブ

      #upstart-job
description "upstart test"
start on runlevel [2345] #Starts at run levels 2, 3, 4, and 5.
stop on runlevel [!2345] #Stops at run levels other than 2, 3, 4, and 5.
exec echo "Hello World. The time is now $(date -R)!" | tee /root/output.txt

      サンプルUpstartジョブは、システムが指定された実行レベルで実行されるときにタイムスタンプを含むメッセージを返し、そのメッセージを /root/output.txtファイルに追加します。 Upstartジョブは、前に指定した実行レベルとは異なる実行レベルでシステムが実行されると停止します。

    Windows インスタンス

    Windowsインスタンスは、VminitコンポーネントのPlugin_Main_CloudinitUserDataを使用してユーザーデータスクリプトを実行します。 このプラグインは、インスタンスが最初に起動されたときに1回だけ実行されます。 Windowsユーザーデータスクリプトは、バッチ形式とPowerShell形式をサポートしています。 詳細は、「Vminitコンポーネント」をご参照ください。

    バッチスクリプト

    • ランニング周波数

      • インスタンスブート: スクリプトは、インスタンスが最初に起動されたときにのみ実行されます。 インスタンスの再起動時にスクリプトが実行されません。

      • オペレーティングシステムの交換: スクリプトは自動的に実行されます。

      • システムディスクの再初期化: スクリプトは自動的に実行されます。

        重要

        次のシナリオでは、スクリプトは自動的に実行されません。

        • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

        • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      • 最初の行は [bat] で、ヘッダーにはスペースが含まれていません。

      • 半角文字のみ入力できます。

      • データ書き込みパスをC:\Usersディレクトリにすることはできません。

        説明

        Windowsシステムでは、C:\Usersディレクトリとそのサブディレクトリは、ユーザープロファイルとデータの既定の保存場所であり、システムにログインした後にのみアクセスできます。 ユーザーデータの実行を伴うシステム初期化フェーズでは、ユーザーはまだシステムにログインしていないため、C:\Usersディレクトリへのデータの書き込みに失敗します。

    • サンプルバッチスクリプト

      [bat]
echo "bat test" > C:\userdata_test.txt

      この例では、バッチスクリプトは、インスタンスが最初に起動されたときに1回だけ実行され、userdata_test.txtファイルに "bat test" が書き込まれます。

    PowerShellスクリプト

    • ランニング周波数

      • インスタンスブート: スクリプトは、インスタンスが最初に起動されたときにのみ実行されます。 インスタンスの再起動時にスクリプトが実行されません。

      • オペレーティングシステムの交換: スクリプトは自動的に実行されます。

      • システムディスクの再初期化: スクリプトは自動的に実行されます。

        重要

        次のシナリオでは、スクリプトは自動的に実行されません。

        • カスタムイメージを使用して、カスタムイメージが作成されたソースインスタンスのオペレーティングシステムを置き換えると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

        • カスタムイメージを使用してインスタンスを作成すると、インスタンスのシステムディスクにデータが保存されます。 システムディスクを初期化すると、システムはインスタンスが初めて起動されていないと判断し、スクリプトを実行しません。

    • Format

      • 最初の行は [powershell] で、ヘッダーにはスペースが含まれていません。

      • 半角文字のみ入力できます。

      • データ書き込みパスをC:\Usersディレクトリにすることはできません。

        説明

        Windowsシステムでは、C:\Usersディレクトリとそのサブディレクトリは、ユーザープロファイルとデータの既定の保存場所であり、システムにログインした後にのみアクセスできます。 ユーザーデータの実行を伴うシステム初期化フェーズでは、ユーザーはまだシステムにログインしていないため、C:\Usersディレクトリへのデータの書き込みに失敗します。

    • サンプルPowerShellスクリプト

      [powershell]
write-output "powershell test" | Out-File C:\userdata_test.txt

      この例では、PowerShellスクリプトは、インスタンスが最初に起動されたときに1回だけ実行され、powershell testをuserdata_test.txtファイルに書き込みます。

    関連ドキュメント

    • ECSインスタンスのユーザーデータを照会するには、API操作を呼び出すことができます。 詳細については、「DescribeUserData」をご参照ください。

    • Auto Scalingのユーザーデータ機能を使用すると、インスタンスの起動時に複数のECSインスタンスが設定済みのスクリプトまたはコマンドを自動的に実行できるようになります。 これにより、ECSインスタンス設定の一貫性が確保され、O&Mが簡素化されます。詳細については、「インスタンスユーザーデータ機能を使用したECSインスタンスの自動設定」をご参照ください。

    • プログラムの例外、インスタンスの再起動、電源障害などの問題によりサービスまたはスクリプトが中断されたときにサービスまたはスクリプトを迅速に復旧させたい場合は、ecs-tool-servicekeepaliveという名前のCloud Assistantプラグインを使用します。 詳細については、「サービスの自動復元」をご参照ください。