Shulou(Shulou.com)05/31 Report--

Editor to share with you what Metadata is in the OpenStack virtual machine. I hope you will get something after reading this article. Let's discuss it together.

Preface

Friends who have just come into contact with OpenStack know that we choose a key pair when creating a virtual machine, and after the virtual machine is created, we can log in to the virtual machine directly using ssh without a password, so how can the my-key we created be magically put into the virtual machine?

OpenStack metadata

To understand how this is done, we need to understand OpenStack's metadata. Metadata is literally metadata, which is mainly used to provide customers with a mechanism to modify and set OpenStack instence (CVM), such as the requirement that we want to place a public key in the virtual machine, or to set the host name, etc., can be realized through metadata. Let me sort out my ideas:

1.OpenStack has something called Metadata.

two。 The hostname and key pair we set when we created the virtual machine are all stored in Metadata.

3. After the virtual machine is created, get the Metadata at startup and configure the system.

How does the virtual machine get the Metadata?

So how on earth did the virtual machine get this metadata? Let's try this on the virtual machine.

$curl http://169.254.169.254/2009-04-04/meta-data ami-id ami-launch-index ami-manifest-path block-device-mapping/ hostname instance-action instance-id instance-type local-hostname local-ipv4 placement/ public-hostname public-ipv4 public-keys/ reservation-id

Aren't you a little surprised to notice the IP address we requested, 169.254.169.254? what kind of magic is this? Where did an IP address like this come from and it can still be accessed? we certainly have never configured a strange IP address in any OpenStack service.

Let's go to the virtual machine to find out. Since we can access it, according to the OSI seven-layer model, there must be a route to this IP address.

We use ip ro li to list virtual machine routes, and we can see that there is indeed a route: 169.254.169.254 goes out from 192.168.57.100, so who owns the IP address? Let's first take a look at the control node (or, more strictly, the node running Neutron-dhcp-agent).

# ip netns li qdhcp-ec14e723-ff09-4dab-a9e9-26dc6facc0fd

We can see that there is a namespace of qdhcp in the control node, which is generated by starting Neutron-DHCP-Agent, and we can see what its IP address is.

It unexpectedly has two IP addresses, 192.168.57.100 and 169.254.169.254. Before we go any further, let's stop, so how do we set up DHCP to push this route to the virtual machine? The answer was when we were configuring DHCP-Agent.

# vim/etc/neutron/dhcp_agent.ini enable_isolated_metadata = true

Is there a Web service?

Well, because of the bridge card we used, the request to access 169.254.269.254 was sent very smoothly to the namespace of qdhcp-ec14e723-ff09-4dab-a9e9-26dc6facc0fd. So we need to have a Web service listener on port 80 to provide it to us. Let's continue to see:

Sure enough, there is an Apache listening on port 80, providing us with metadata silently. So this is how the virtual machine gets this information:

Get the key injected by the user:

Get hostname

Get the IP address

Now you finally know how OpenStack got the meta-data information after creating the virtual machine. But don't forget. This is a small mirror image of cirros that we use. What if you wouldn't be so smart to create your own image? I'm sure the smart one has come up with the simplest solution:

Execute a script at startup. This script gets the content by accessing meata-data and then sets it to the system. Put this script in / etc/rc.local. If you don't want the script to be executed every time, you can also remove yourself from / etc/rc.local after execution.

Of course, there are other options. For example, use the software package cloud-init.

Why 169.254.169.254?

Maybe you and I have the same question, why the ip address of this meatadata is 169.254.169.254? This is about to mention Amazon. Because metadata was proposed by Amazon. Then when you customize various operating system images for Amazon, the api address of metadata is written as 169.254.169.254. So that these images can also run on OpenStack, to be compatible with it. OpenStack keeps this address. In fact, early versions of OpenStack mapped 169.254.169.254 to the IP address of the real API through iptables NAT. But now it is more flexible, and a routing entry is added directly in the virtual machine to enable the virtual machine to access the IP address smoothly.

After reading this article, I believe you have a certain understanding of "what is Metadata in the OpenStack virtual machine". If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.