Skip to content. | Skip to navigation

Navigation

You are here: Home / Support / Guides / Tools / OpenStack / Methodology

Personal tools

OpenStack

Methodology

We want to create servers for various purposes: DNS, NTP etc., web service, email. Perhaps more exotic things like PBXs.

Most of these, though, start off as a generic Linux server which we then add relevant packages too. So that's what we'll aim to do, create a generic Linux server image as a starter for ten then modify it for each specific purpose.

That means our final server is long-lived. That's not the normal life-cycle for a cloud server but it's not ruled out. We must be careful to not terminate one of our servers in the same casual way you might terminate one of many identikit web servers in a web farm. Our servers are important!

Another issue with OpenStack is that when you associate a server with a network you'll normally get back a random port (and by inference a random IP address on the subnet). We can't do that as we require particular IP addresses as we're going to publish them to the world [1].

This is easily done by creating ports with fixed IP addresses. You can associate such a port with a VM on the command line but you can't choose such ports through the GUI (in Liberty at least).

[1]

If you are using IPv4 behind a NAT'ing broadband modem this may appear moot as everything is going to use the modem's public IPv4 address anyway. However, you'll need to tell the modem where to forward traffic to if your (internal) server's IP address changes.

If you're using IPv6 then the chances are you're using one of the IPv6 addresses your broadband modem is acting as the RA for. Those IP addresses are publicly routable and so you don't want to be changing it if it is going to be published on the Internet.

Less of a problem of you can do dynamic DNS updates of your own domain, more of a problem if results get dropped into some registrars' DNS glue records

Document Actions