This section will demonstrate how to build an Ubuntu 14.04 server in a new OpenStack tenant. After you have completed the steps you will be able to log on to the server via SSH from anywhere on the internet using an SSH key.
This section assumes that you have already setup a Catalyst Cloud account and have been assigned a tenant and a user in that tenant who has permissions to create the required resources.
When a new tenancy is created it will have a network, subnet and router built by default. For completeness the process below includes the steps required to do this in the case that the default setup has been deleted or an additiional network is required.
Steps 1 & 2 below can be skipped on a new tenancy where the default networking is still in place. The creation of your first instance can proceed from step 3.
Here are the steps for creating your first cloud instance.
There are a number of different ways to provision resources on the Catalyst Cloud. We will show you how to complete these steps using the dashboard and the command line tools. If you are starting out it will be easiest to use the dashboard. As you become more familiar with the Catalyst Cloud it is worth learning how to provision resources programmatically.
You are free to use whichever method suits you, you can use these methods in isolation or they can be combined. If you do not use the dashboard to launch the compute instance, it can still be useful to make use of it to verify the stack that you have created via another method.
Before launching an instance, it is necessary to have some network resources in place. These may have already been created for you. In this documentation we are going to assume your are starting from an un-configured tenant so we will be demonstrating how to set these up from scratch.
The requirements are:
Catalyst operate a number of recursive DNS servers in each cloud region for use by Catalyst Cloud instances, free of charge. They are:
|Region||DNS Name Servers|
|nz-por-1||188.8.131.52, 184.108.40.206, 220.127.116.11|
|nz_wlg_2||18.104.22.168, 22.214.171.124, 126.96.36.199|
When creating a router and network/subnet keep any network requirements in mind when choosing addressing for your networks. You may want to build a tunnel-mode VPN in the future to connect your OpenStack private network to another private network. Choosing a unique subnet now will ensure you will not experience collisions that require renumbering in the future.
The flavor of an instance is the CPU, memory and disk specifications of a compute instance. Catalyst flavors are named ‘cX.cYrZ’, where X is the ‘compute generation’, Y is the number of vCPUs, and Z is the number of gigabytes of memory.
Flavour names are identical across all regions, but the flavour IDs will vary.
In order to create an instance, you will need to have a pre-built operating system in the form of an Image. Images are stored in the Image service (Glance). The Catalyst Cloud provide a set of images for general use and also allows you to upload your own images.
Image IDs for the same operating system will be different in each region. Further, images are periodically updated receiving new IDs over time. You should always look up for an image based on its name and then retrieve the ID for it.
When an instance is created, OpenStack will pass an ssh key to the instance which can be used for shell access. By default, Ubuntu will install this key for the ‘ubuntu’ user. Other operating systems have different default users, as listed here: Images provided by Catalyst
Tip: name your key using information like the username and host on which the ssh key was generated so that it is easy to identify later.
Keypairs must be created in each region being used.
Security groups are akin to a virtual firewall. All new instances are put in the ‘default’ security group. When unchanged, the default security group allows all egress (outbound) traffic, but will drop all ingress (inbound) traffic. In order to allow inbound access to our instance via SSH a security group rule is required.
While we could create security group rules within the default group to allow access to our instance it is sensible to create a new group to hold the rules specific to our instance. This is a useful way to group the rules associated with our instance and provides a convenient way to delete all rules for an instance when we need to cleanup resources. It is also a useful way to assign the same rules to subsequent instances that you may create.
Note that by using the CIDR 0.0.0.0/0 as a remote, you are allowing access from any IP to your compute instance on the port and protocol selected. This is often desirable when exposing a web server (eg: allow HTTP and HTTPs access from the Internet), but is insecure when exposing other protocols, such as SSH, Telnet and FTP. We strongly recommend you to limit the exposure of your compute instances and services to IP addresses or subnets that are trusted.
In order to connect to our instance, we will need to allocate a floating IP to the instance. Alternately, one could create a VPN and save some money by avoiding floating IPs altogether. VPNs are not feasible when the instance will be offering a service to the greater internet.