Retrieving Instance Metadata
About Instance Metadata
Two types of metadata are stored within your instances: user-defined instance attributes that you can define explicitly while creating instances, and predefined instance metadata fields that are stored by default for all instances. Scripts and applications running on the instances can use the available metadata to perform certain tasks. For example, SSH public keys that are specified while creating an instance are stored as metadata on the instance. A script running on the instance can retrieve these keys and append them to the authorized_keys
file of specified users to allow key-based login to the instance using ssh
.
Predefined Instance Metadata
The following predefined metadata fields are stored on every instance that you create:Metadata | Description | Example |
---|---|---|
|
Private IP address of the instance. |
|
|
DNS name of the instance. |
|
|
Name of the instance. |
|
|
Memory and CPU resources available for the instance. |
|
|
SSH public key specified while creating the instance, where |
|
Note:
You may see certain additional metadata fields, such as reservation-id
, product-codes
, kernel-id
, public-hostname
, and security-groups
, that aren’t documented. Don’t retrieve and use the values in the undocumented fields.
The predefined instance metadata fields are stored at http://192.0.0.192/{version}/metadata
.
latest 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2009-04-04
Tip:
New metadata versions may be released in the future. Metadata versions may not be backward compatible. So use metadata from a specific version (for example, from http://192.0.0.192/2008-02-01/
) and not from http://192.0.0.192/latest/
.
For the steps to retrieve the predefined instance metadata, see Retrieving Predefined Instance Metadata.
User-Defined Instance Attributes
User-defined attributes are key-value pairs that you can specify in the attributes
parameter of machine images, image-list entries, and instance launch plans.
When you create instances, all the attributes that are specified in the attributes
parameter in the orchestration or launch plan, machine image, and image list entry that are used to create your instances are stored on those instances. If an attribute in an image-list entry has the same name as an attribute in the machine image corresponding to that image-list entry, then the attribute in the image-list entry overrides the attribute in the machine image. Similarly, if an attribute in a launch plan has the same name as an attribute in an image-list entry or a machine image, then the attribute in the launch plan takes precedence.
User-defined instance attributes are stored within the instance at http://192.0.0.192/latest/user-data
. For the steps to retrieve these attributes, see Retrieving User-Defined Instance Attributes.
-
If you want identical user data to be available on a set of instances, then specify the required user data in the machine image or image list entry that you'll use to create the instances. For example, you might require a certain pre-bootstrap script to be executed or specific applications to be installed on all instances that use a particular image. By specifying this script as user data in the machine image or the image list entry, you ensure that every instance that’s created with that image has the specified user data.
-
If each instance should have unique user data, use an orchestration to provide specific user data for each instance. This is useful if, for example, you want to specify a unique user name and password, or inject a unique SSH public key into each instance.
-
You can automate instance configuration by providing scripts or other instructions to perform prebootstrapping tasks or install applications when you create an instance. These instance configuration instructions are provided as user-defined data using the
userdata
field under theattributes
parameter. For example, you can use this field to specify the location of a database server and login details.
Sample Scenario for Specifying and Using Instance Attributes
Consider a distributed system where a manager instance must handle requests from a set of worker instances. The instances in this sample scenario are identical in all other respects. So they’re based on the same machine image.
Create an image list containing two entries, both for the same machine image, but one entry with the attribute {"role":"manager"}
and the other with the attribute {"role":"worker"}
in the attributes
field. To create an image list entry using the API, use the POST /imagelist/name/entry
method. See REST API for Oracle Cloud Infrastructure Compute Classic .
In the launch plan that you use to provision the instances in the distributed system, define a number of worker instances that use the image list entry with the {"role":"worker"}
attribute, and define a manager instance that uses the image list entry with the {"role":"manager"}
attribute.
After the instances are created, the software running on each instance can determine the role that the instance should play based on the value of the role
attribute stored at http://192.0.0.192/version/user-data
.