We want OpenStack to make sense, and sometimes the best way to make sense of the cloud is to try out some basic ideas with cloud computing. Flexible, elastic, and scalable are a few attributes of cloud computing, so these tutorials show various ways to use virtual computing or web-based storage with OpenStack components.

In this OpenStack Compute tutorial, we’ll walk through the creation of an elastic, scalable cloud running a WordPress installation on a few virtual machines. The tutorial assumes you have OpenStack Compute already installed on Ubuntu 10.04. You can tell OpenStack Compute is installed by running "sudo nova-manage service list" to ensure it is installed and the necessary services are running and ready. You should see a set of nova- services in a response, and they should have a sideways smiley face in each row, indicating they're running. You should run the tutorial as a root user or a user with sudo access. If you haven't installed OpenStack Compute yet, you can use an ISO image that is based on a Ubuntu Linux Server 10.04 LTS distribution containing only the components needed to run OpenStack Compute. See http://sourceforge.net/projects/stackops/files/ for download files and information, license information, and a README file to get started. We'll go through this tutorial in parts: Setting up a user, project, and network for this cloud. Getting images for your application servers. On the instances you spin up, installing Wordpress and its dependencies, the Memcached plugin, and multiple memcache servers.

In this part, we'll get the networking layer set up based on what we think most networks would work like. We'll also create a user and a project to house our cloud and its network. Onward, brave cloud pioneers! Ideally on large OpenStack Compute deployments, each project is in a protected network segment. Our project in this case is a LAMP stack running Wordpress with the Memcached plugin for added database efficiency. So we need a public IP address for the Wordpress server but we can use flat networking for this. Here's how you set those network settings. Usually networking is set in nova.conf, but VLAN-based networking with DHCP is the default setting when no network manager is defined in nova.conf. To check this network setting, open your nova.conf, typically in /etc/nova/nova.conf and look for -network_manager. The possible options are: -network_manager=nova.network.manager.FlatManager for a simple, no-VLAN networking type, -network_manager=nova.network.manager.FlatDHCPManager for flat networking with a built-in DHCP server, -network_manager= nova.network.manager.VlanManager, which is the most tested in production but requires network hardware with VLAN tagging. Here is an example nova.conf for a single node installation of OpenStack Compute. # Sets the network type --network_manager=nova.network.manager.FlatManager # Sets whether to use IPV6 addresses --use_ipv6=false # DHCP bridge information --dhcpbridge_flagfile=/etc/nova/nova.conf --dhcpbridge=nova-dhcpbridge --flat_network_bridge=br100 --logdir=/var/log/nova # Top-level directory for maintaining nova's state --state_path=/var/lib/nova # These indicate where nova-api services are installed --s3_host=184.106.239.134 --rabbit_host=184.106.239.134 --ec2_api=184.106.239.134 --ec2_url=http://184.106.239.134:8773/services/Cloud # Block of IP addresses that are fixed IPs --fixed_range=192.168.0.0/12 # Number of addresses in each private subnet --network_size=24 # FlatDHCP bridges to this interface if set, be very careful setting it on an interface that does not already have an IP associated with it --flat_interface=eth0 # Public IP of the server running nova-network, when instances without a floating IP hit the internet, traffic is snatted to this IP --routing_source_ip=184.106.239.134 # Not required, but handy for debugging --verbose # Tells nova where to connect for database --sql_connection=mysql://nova:notnova@184.106.239.134/nova Now that we know the networking configuration, let's set up the network for our project. With Flat DHCP, the host running nova-network acts as the gateway to the virtual nodes, so ideally this will have a public IP address for our tutorial. Be careful when setting up --flat_interface in nova.conf, if you specify an interface that already has an IP it will break and if this is the interface you are connecting through with SSH, you cannot fix it unless you have ipmi/console access. Also the --flat_network_bridge is now required. For this tutorial, we set a 24 value for network_size, the number of addresses in each private subnet, since that falls inside the /12 CIDR-notated range that's set in ‘fixed-range’ in nova.conf. We probably won't use that many at first, but it's good to have the room to scale. Currently, there can only be one network set in nova.conf. When you issue the nova-manage network create command, it uses the settings in the nova.conf flag file. From the --fixed_range setting, iptables are set. Those iptables are regenerated each time the nova-network service restarts, also. The nova-manage service assumes that the first IP address is your network (like 192.168.0.0), that the 2nd IP is your gateway (192.168.0.1), and that the broadcast is the very last IP in the range you defined (192.168.0.255). If this is not the case you will need to manually edit the sql db ‘networks’ table.o but that scenario shouldn't happen for this tutorial. Run this command as root or sudo: nova-manage network create public 192.168.3.0/12 1 256 On running this command, entries are made in the ‘networks’ and ‘fixed_ips’ table in the nova database. However, one of the networks listed in the ‘networks’ table needs to be marked as bridge in order for the code to know that a bridge exists. The Network is marked as bridged automatically based on the type of network manager selected. Next you want to integrate this network bridge, named br100, into your network. A bridge connects two Ethernet segments together. The first command you run using nova-manage is one called db sync, which ensures that your database is updated. You must run this as root. nova-manage db sync OpenStack Compute can run many projects for many users, so for our tutorial we'll create a user and project just for this scenario. We control the actions a user can take through roles, such as admin for Administrator who has complete system access, itsec for IT Security, netadmin for Network Administrator, and so on. In addition to these roles controlling access to the Eucalyptus API, credentials are supplied and bundled by OpenStack compute in a zip file when you create a project. The user accessing the cloud infrastructure through ec2 commands are given an access and secret key through the project itself. Let's create a user that has the access we want for this project. To add an admin user named cloudypants, use: nova-manage user admin cloudypants Next we'll create the project, which in turn gives you certifications in a zip file. Enter this command to create a project named wpscales as the admin user, cloudypants, that you created above. nova-manage project create wpscales cloudypants Great, now you have a project that is set apart from the rest of the clouds you might control with OpenStack Compute. Now you need to give the user some credentials so they can run commands for the instances with in that project's cloud. These are the certs you will use to launch instances, bundle images, and all the other assorted API and command-line functions. First, we'll create a directory that'll house these credentials, in this case in the root directory. You need to sudo here or save this to your own directory with mkdir -p ~/creds so that the credentials match the user and are stored in their home. mkdir –p /root/creds Now, run nova-manage to create a zip file for your project called wpscales with the user cloudypants (the admin user we created previously). sudo nova-manage project zipfile wpscales cloudypants /root/creds/novacreds.zip Next, you can unzip novacreds.zip in your home directory, and add these credentials to your environment. unzip /root/creds/novacreds.zip -d /root/creds/ Sending that information and sourcing it as part of your .bashrc file remembers those credentials for next time. cat /root/creds/novarc >> ~/.bashrc source ~/.bashrc Okay, you've created the basic scaffolding for your cloud so that you can get some images and run instances. Onward to Part II!

Understanding what you can do with cloud computing means you should have a grasp on the concept of virtualization. With virtualization, you can run operating systems and applications on virtual machines instead of physical computers. To use a virtual machine, you must have an image that contains all the information about which operating system to run, the user login and password, files stored on the system, and so on. For this tutorial, we've created an image that you can download that allows the networking you need to run web applications and so forth. In order to use it with the OpenStack Compute cloud, you download the image, then use uec-publish-tarball to publish it. Here are the commands to get your virtual image. Be aware that the download of the compressed file may take a few minutes. image="ubuntu1010-UEC-localuser-image.tar.gz" wget http://c0179148.cdn1.cloudfiles.rackspacecloud.com/ ubuntu1010-UEC-localuser-image.tar.gz uec-publish-tarball $image wpbucket amd64 What you'll get in return from this command is three references: emi, eri and eki. These are acronyms - emi stands for eucalyptus machine image, eri stands for eucalyptus ramdisk image, and eki stands for eucalyptus kernal image. Amazon has similar references for their images - ami, ari, and aki. You need to use the emi value when you run the instance. These look something like “ami-zqkyh9th″ - basically a unique identifier. Okay, now that you have your image and it's published, realize that it has to be decompressed before you can launch an image from it. We can realize what state an image is in using the 'euca-describe-instances' command. Basically, run: nova image-list and look for the state in the text that returns. You can also use euca-describe-images to ensure the image is untarred. Wait until the state shows "available" so that you know the instances is ready to roll.

Once that state is "ACTIVE" you can enter this command, which will use your credentials to start up the instance with the identifier you got by publishing the image. nova boot --image 1 --flavor 1 --key_path /root/creds/ Now you can look at the state of the running instances by using euca-describe-instances again. The instance will go from “launching” to “running” in a short time, and you should be able to connect via SSH. Look at the IP addresses so that you can connect to the instance once it starts running. Basically launch a terminal window from any computer, and enter: ssh -i mykey ubuntu@10.127.35.119 On this particular image, the 'ubuntu' user has been set up as part of the sudoers group, so you can escalate to 'root' via the following command: sudo -i Now, you can install WordPress. Create and then switch to a blog directory: mkdir blog cd blog Download WordPress directly to you by using wget: wget http://wordpress.org/latest.tar.gz Then unzip the package using: tar -xzvf latest.tar.gz The WordPress package will extract into a folder called wordpress in the same directory that you downloaded latest.tar.gz. Next, enter "exit" and disconnect from this SSH session. Next, SSH into another virtual machine and install MySQL and use these instructions to install the WordPress database using the MySQL Client from a command line: Using the MySQL Client - Wordpress Codex. Memcache makes Wordpress database reads and writers more efficient, so your virtual servers can go to work for you in a scalable manner. SSH to a third virtual machine and install Memcache: apt-get install memcached From a web browser, point to the IP address of your Wordpress server. Download and install the Memcache Plugin. Enter the IP address of your Memcache server.

That's it! You're now running your blog on a cloud server in OpenStack Compute, and you've scaled it horizontally using additional virtual images to run the database and Memcache. Now if your blog gets a big boost of comments, you'll be ready for the extra reads-and-writes to the database.