Mirantis OpenStack Express:
Application On-boarding Guide
Version 1
06.05.2014
Table of Contents
Table of Contents ... 2
1.0 Summary ... 5
2.0 Mirantis OpenStack Express ... 5
2.1 Components ... 6
2.1.1 Mirantis OpenStack Express Dashboard ... 7
2.1.2 Fuel Control Plane Dashboard ... 8
2.1.3 Mirantis OpenStack Horizon Dashboard ... 14
2.2 Navigating Mirantis OpenStack Express ... 15
2.2.1 Create unprivileged user ... 15
2.2.2 Basic tool configuration ... 18
2.3 Application Deployment Architecture ... 24
3.0 Image Creation ... 27
3.1 Creating your own image ... 27
3.2 Pre-‐built OpenStack Images ... 27
3.3 Convert Image ... 30
4.0 Upload Image ... 32
4.1 GUI based upload using Horizon ... 32
4.2 Command line upload using Glance CLI ... 33
4.2.1 Upload the image file to the Controller Node ... 34
4.2.2 Validate authentication to Mirantis OpenStack ... 34
4.2.3 Upload Image to OpenStack using glance ... 34
4.2.4 Extended usage examples of Glance ... 35
5.0 Image customization ... 40
6.0 Application Infrastructure on Mirantis OpenStack Express ... 44
6.1 Networking ... 44
6.1.1 Enable LBaaS functionality in Mirantis OpenStack Express ... 44
6.1.2 Create networks to support a three tier application deployment ... 50
6.2 Security Groups ... 51
6.3 Jump Server Instances ... 52
6.5 Floating IP ... 53
7.1.1 Dump source mySQL Database ... 57
7.1.2 Create mySQL Database Virtual Machine in Mirantis OpenStack Express ... 57
7.1.3 Copy the SQL to create the database to the Mirantis OpenStack Express mySQL Virtual Machine ... 60
7.1.4 Configure /etc/hosts (as root) ... 61
7.1.5 Install mysql-‐server package (as root) ... 61
7.1.6 Configure mySQL listener address and port (as root) ... 62
7.1.7 Enable mysql auto-‐start and start mysql server (as root) ... 62
7.1.8 Set the mySQL root user and password (as root) ... 63
7.1.9 Configure iptables (as root) ... 64
7.1.10 Load data into mySQL on Mirantis OpenStack Express ... 65
7.2 Weblogic Managed Servers ... 66
7.3 Weblogic Administrative Server ... 70
7.3.1 Convert the VMware virtual machine ... 70
7.3.2 Perform root level changes within the Administrative Server on Mirantis OpenStack Express ... 72
7.3.3 Launch the Weblogic Administrative Console ... 72
7.3.4 Configure Security Groups for the Weblogic Administrative Console ... 73
7.3.5 Associate a Floating IP ... 74
7.3.6 Re-‐configure application resources using the Weblogic Administrative Console ... 76
7.4 Pack and upack the domain to the managed servers ... 79
7.4.1 Pack the domain ... 79
7.4.2 Unpack the domain on each Managed Server ... 80
7.4.2 Update the firewall on each Managed Server ... 81
7.4.3 Launch NodeManager on each Managed Server ... 82
7.4.4 Start the Application Servers and verify the application is running ... 82
7.5 HA Proxy Servers ... 84
7.6 Configure front end load balancer ... 86
8.0 Demo Application Deployment ... 94
8.1 Manage Security Groups via Horizon ... 95
8.1.1 Creating Security Groups ... 95
8.1.2 Editing Security Group Rules ... 97
8.2 Preparation of environment ... 101
8.3 Install HAProxy server ... 104
8.4 Install DB server ... 106
8.5 Install an application server (Wordpress+Apache) ... 108
8.6 Validate Application ... 112
9.0 Migration from X to Mirantis OpenStack Express ... 115
9.1.1 Create a snapshot of the Virtual Machine ... 116
9.1.2 Export the Virtual Machine Image out of Glance and download it ... 118
9.1.3 Upload Virtual Machine image into Mirantis OpenStack Express ... 119
9.1.4 Launch the migrated Virtual Machine on Mirantis OpenStack Express ... 121
9.2 AWS to Mirantis OpenStack Express ... 123
9.2.1 Windows Virtual Machine Migration ... 123
9.2.2 Linux ... 144
9.3 VMWare to Mirantis OpenStack Express ... 148
9.3.1 Windows Virtual Machine ... 149
9.3.2 Linux Virtual Machine ... 165
10.0 Workload Management Solutions ... 172
10.1 Scalr Enterprise Cloud Management Platform ... 172
10.1.1 Scalr installation ... 173
Appendix A: Manual Image Creation ... 187
Appendix B: Virtual Disk Development Kit (VDDK) ... 212
1.0 Summary
The purpose of this document is to assist in on boarding to Mirantis OpenStack Express. This document will cover general application deployment and maintenance while running on Mirantis OpenStack Express. Specifically, this document is intended to describe the following processes: • Image creation
• Application deployment • Virtual Machine instantiation
2.0 Mirantis OpenStack Express
When you purchase Mirantis OpenStack Express, you don’t just get an OpenStack Cloud for you to deploy your applications to. You get all of the parts and components that make up an OpenStack Cloud as well. You get full access to your OpenStack Cloud configuration right down to the operating system it is running on. You get configurable resources that you can re-define your OpenStack Cloud as your workloads change. You get flexibility to add and remove resources as needed based on technical and/or financial needs of your organization. Additionally, you don’t just get one OpenStack Cloud, you get a multi-cloud management platform to put you in control of as many OpenStack Clouds as your organization needs. You get the ease of mind in knowing the hardware you’re running on has been thoroughly tested and guaranteed to work in an OpenStack environment. And lastly, you get the confidence in knowing that in the unfortunate event you run into difficulties with OpenStack, you have the support of one of the top contributers to the OpenStack platform to help you resolve those issues. That is what you get when you purchase Mirantis OpenStack Express and in this section we are going to cover the dashboard components that make up that multi-cloud management platform.
2.1 Components
When you purchase Mirantis OpenStack Express, you will receive an e-mail with login credentials to the Mirantis OpenStack Express Dashboard. This is one of the three (minimum) dashboards that make up Mirantis OpenStack Express management interfaces. The minimum three dashboards are:
• Mirantis OpenStack Express Dashboard
This is the very first dashboard you will log into for Mirantis OpenStack Express. You can think of this Dashboard as your 10,000 foot view of all of your cloud environments. It has basic information such as the number of servers, login credentials and relevant IP address information for accessing the environment.
• Fuel Control Plane Dashboard
This is where you manage your clouds and your cloud resources. This is your multi-cloud management platform that allows you to define the resources that make up your clouds, deploy relevant projects, such as Murano, Sahara or Ceilometer when you build your clouds and manage the cloud resources of existing clouds. When you deploy your clouds using Fuel, you will configure the various networks which make up the data center that is hosting your OpenStack Cloud.
• Mirantis OpenStack Horizon Dashboard (at least one)
This is the Horizon console component of OpenStack. Here is where you define the components inside your OpenStack environment, such as tenants, networks and virtual machines. Because you can manage multiple clouds with Fuel, every cloud you create will have it’s own unique Horizon Dashboard.
2.1.1 Mirantis OpenStack Express Dashboard
When you first login to Mirantis OpenStack Express, you are presented with the Mirantis OpenStack Express Dashboard:
This dashboard has key information regarding your cloud: • The URL to the Fuel Control Plane Dashboard
• The credentials for the Fuel Control Plane Dashboard • The credentials for the Fuel Control Plane Server (SSH)
• The list of floating IP addresses associated with your Data Center • The URL to the Mirantis OpenStack Horizon Dashboard
• The credentials for the Mirantis OpenStack Horizon Dashboard • The list of nodes in your Data Center
Additionally, if you wanted to add or remove physicial servers, you can click on the Configure button on the top right and increase or decrease the servers which make up the environment.
Note: In order to decrease the number of servers, you must first free up the server in the Fuel Control Plane Dashboard as an Unallocated Node.
Lastly, you can delete your entire environment from this page, freeing up all resources and returning them back to the data center.
2.1.2 Fuel Control Plane Dashboard
Accessing the URL for the Fuel Control Plane Dashboard will show your deployed cloud:
NOTE: You may receive a certificate warning when accessing this page. This is because the certificate that is being used here is using ‘fuelmaster’ as the server name and we are accessing the server utilizing the IP address. You can see that the connection is still encrypted by viewing the warning:
From here, you can drill down on the Express Cloud that was built for you to see the nodes that make up your OpenStack Deployment:
When you first purchase Mirantis OpenStack Express, a single cloud is created for you as a convenience, however there is no reason you need to keep the cloud that was created for you. You can select nodes from that cloud and click the Delete button to return those nodes to the Unallocated Nodes resource pool and then create additional clouds from those newly freed resources.
A full user guide for Fuel can be found on the Mirantis website here.
2.1.2.1 Controller node identification
One thing you will notice is the way the nodes here are named, they don’t match the node list from the Mirantis OpenStack Express Dashboard or the Hypervisors listed within your OpenStack cloud. If you’re leveraging the logging capability of Fuel, you may want to rename the nodes here to match the names in the other 2 locations so finding the appropriate logs on the
appropriate node will be easier. You can use the MAC address of each of the nodes listed in the Fuel Dashboard to identify their names in the other 2 dashboards.
First, SSH into the Fuel Node using the credentials from the Mirantis OpenStack Express Dashboard.
Next, run a for loop to show the MAC address of eth0 on nodes 1-4:
for X in $(seq 1 4); do ssh root@node-${X}.domain.tld 'ifconfig eth0 | grep -i hwaddr'; done
From this we can now view the settings on each node in the Fuel Dashboard, compare the eth0 MAC address and rename the node appropriately:
So we know the Controller Node, NODE_controller_0 is actually node-2.domain.tld. Just click the name and rename the node in the Fuel Dashboard. You can perform this for all of the nodes listed:
When you executed the command to find the MAC addresses of eth0, it leveraged an SSH key that is installed on the Fuel node to login to each of the nodes as the root user. While SSH’d into the Fuel Node, you can display the private key on the Fuel Node:
cat /root/.ssh/id_rsa
This key can be leveraged to directly log into any of the nodes remotely. Copy this key out into a secure location as a local file for safe keeping. See Navigating Mirantis OpenStack Express for additional details.
2.1.3 Mirantis OpenStack Horizon Dashboard
Click the URL from the Mirantis OpenStack Express Dashboard to launch a browser to the Horizon login page:
From here, utilize the credentials from the Mirantis OpenStack Express Dashboard page to login and view your environment. Because Mirantis OpenStack is a Pure Play OpenStack distribution, all functionality and usage of OpenStack can be found on the official OpenStack documentation page.
Realize, though, that this is only the initial Horizon Dashboard created for you. In the event that you create a new cloud utilizing Fuel, there will be a competely unique Horizon Dashboard for that cloud. The URL for that Horizon Dashboard will be visible from Fuel only. At this time, new clouds that are created by customers in Fuel do not have their URL’s reported and displayed on the Mirantis OpenStack Express Dashboard.
2.2 Navigating Mirantis OpenStack Express
When working with Mirantis OpenStack, sometimes you will have a need to access the physical servers running the environment such as the Controller Node or the Hypervisors nodes
themselves. Some basic reasons you might need to access these are:
● Utilization of tools, such as qemu-img, to perform disk type conversions or guestfish to perform image editing prior to uploading an image to OpenStack
● Utilization of OpenStack Command Line utilities for nova, glance, etc. ● Troubleshooting/debugging purposes
Mirantis OpenStack Express gives you super-user (root) access to these nodes since they are your nodes. You don’t share this hardware with any other customer unlike many other environments out there. That being said, for the majority of reasons for accessing these nodes, you will not need super-user (root) level access. You can perform most functionality as a non-privileged user and that is the recommended way you should be accessing these nodes to increase your security posture. This document will walk you through the creation of such a user for these purposes. First, log into the Mirantis OpenStack Express Dashboard and obtain the SSH login information for your Fuel node. Utilize this information to SSH into the Fuel node. Once on the Fuel node, SSH into the node that you determined was the Controller Node in the Fuel Control Plane Dashboard Overview.
2.2.1 Create unprivileged user
Now we will create a new Linux group and user to utilize for remote access. You can use whatever name you want for the user and group as long as they adhere to linux user/group naming requirements. We will use Group ID and User ID 1000, which is typically where ‘normal users’ exist. For this example, we will use the following:
User name: mirantis Group name: mirantis Group ID: 1000
User ID: 1000 Create the user:
groupadd -g 1000 mirantis
useradd -g 1000 -u 1000 mirantis su - mirantis
2.2.1.1 Create unprivileged user SSH keypair
Now we will generate a SSH key-pair that can be used to SSH into the Controller Node as the mirantis user ID:
ssh-keygen cd .ssh
cat id_rsa.pub >authorized_keys chmod 600 authorized_keys
Copy the text of the id_rsa output, this is the private key for this user. Save that in a text file somewhere that you can use it in the future to SSH into the Controller Node.
Login to the Mirantis OpenStack Horizon Dashboard, select Project on the left and Navigate to Access & Security then select the ‘API Access’ tab at the top. Click the Download OpenStack RC File button in the top right. After you have downloaded it, scp the admin-openrc.sh file
into the mirantis user home directory. This will set up necessary environment variables for utilizing the OpenStack CLI. See the tools section below for configuring FileZilla to scp this file to the Controller Node.
2.2.2 Basic tool configuration
2.2.2.1 PuTTy
PuTTy is a client for Windows that can be used to SSH to Linux machines. The official website of PuTTy is here:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
In addition to downloading the putty.exe executable, you will also need to download
puttygen.exe to convert the key from the create unprivileged user section into a format that is usable by PuTTy.
Launch puttygen.exe and click the Load button. Select the text file you saved in the create unprivileged user section.
Once it loads, then you can click the Save private key button to save a version of the private key that can be used by putty. You can then close puttygen.exe.
Launch putty.exe. Enter the IP address of the Controller Node and in the Saved Sessions, enter something that will let you know what this session is for:
On the left, click click the + next to SSH and select Auth. Click Browse and select the .ppk private key file you saved from puttygen.exe:
Click back on Session on the left and click the Save button on the right. This will add a new saved session that you can use to connect to the Controller Node.
When you click Open, it will SSH to the Controller Node and prompt for a user name. Enter mirantis and it should utilize the SSH key to log you into the Controller Node.
2.2.2.2 FileZilla
To use FileZilla with the SSH key you created for the mirantis user, launch FileZilla and click Edit->Settings. In the left pane, select SFTP under Connection->FTP and then click Add keyfile… You may get a notice about converting the format and prompting for a new file name, go ahead and do that. You should now have something that looks like this:
After configuring this, you should be able to connect to the Controller Node using the Controller Node IP, username mirantis, a blank password and port 22 (which will force a sftp session):
2.3 Application Deployment Architecture
When looking at a typical architecture of a web application, most deployments follow a three tier deployment model:
● Web Tier ● Application Tier ● Database Tier
This is normally depicted as such:
In this model, the systems that run in the three tiers are usually supported/maintained by administrators who are connected via the Enterprise Network. Typically the firewalls are
configured to allow traffic originating from the Enterprise Network into the various network tiers but deny traffic originating from the three tiers into the Enterprise Network. However, with Mirantis OpenStack Express, there is no “Enterprise Network”, so it looks more like this:
Because of this, administrators will need a way to reach the systems on these three networks without sacrificing security posture of the systems running the applications. To accomplish this, create a virtual machine in the Mirantis OpenStack Express environment and open SSH access to just that virtual machine to allow an entry point to reach the other systems in the environment. These servers are often referred to as “jump servers” or “pivot servers” in an environment. When considering the utilization of jump servers, there’s three different ways they can be set up and the choice you choose is dependant on how you want to configure your security posture:
1. Create a single jump server in one tier, assign it a public IP address so it is reachable from the internet and open port 22 to this server. Then allow this server to access any of the tiers on
2. Create a separate jump server in each tier, assign each a public IP address so they are reachable from the internet and open port 22 to each server. Then allow each server to access only other systems within it’s tier on port 22.
3. Create a separate jump server in each tier, assign only the Web Tier jump server a public IP address so it is reachable from the internet and assign the Application Tier and Database Tier jump servers IP addresses from their respective networks. Open port 22 from the internet to the Web Tier jump server and allow the Web Tier jump server to connect to any other system in the Web Tier and the Application Tier jump server on port 22. Doing this restricts access to the Application Tier jump server from only the Web Tier jump server. For the Application Tier jump server, only allow access to it from the Web Tier jump server on port 22. Allow the Application Tier jump server to connect to any other system in the Application Tier network as well as the Database Tier jump server on port 22. Doing this restricts access to the
Database Tier jump server from only the Application Tier jump server. For the Database Tier jump server, only allow access to it from the Application Tier jump server on port 22. Allow the Database Tier jump server to connect to any other system in the Database Tier on port 22. Once this configuration is in place, if you needed to access a machine in the Database Tier, you’d first need to SSH to the Web Tier jump server, then from there, you would SSH into the Application Tier jump server, then you’d SSH into the Database jump server. Finally you’d be able to access the server you needed to access in the Database Tier. An attacker would need to compromise 3 separate jump servers before attempting to attack a server in the Database Tier.
Option #1 allows for the most “ease of access” in working with the environment. You can easily get directly to any server in your environment in 2 hops (SSH first to the jump server in the Web Tier and then SSH a second time to the server you wish to access in the environment). The downside is that every one of your tiers has a single SSH entry point to it from the internet so an attacker would just need to compromise a single server to be able to then attack any server in your environment. Option #2 is very similar to Option #1 in that you can easily get directly to any server in your environment in 2 hops (SSH first to the jump server in the appropriate tier and then SSH a second time to the server you wish to access in that tier). It slightly improves security in that an attacker would need to compromise 3 separate servers to gain access to your whole environment, however, they still only need to compromise one server to access an entire tier. Option #3 addresses the that exposure by limiting the visibility of SSH to each of the tiers, minimizing the attack vector to a single machine for the Application and Database Tiers. The downside is that it is a lot more tedious to work with since you have to make several hops
depending on where in the environment you want to get to. The decision on how you’d like to implement security and access is up to your organizations security standards.
Note: An example of how to configure Option #3 is explained in Jump Server Instances section of this document.
3.0 Image Creation
You have three options for creating images to use inside the Mirantis OpenStack Express environment:
● Create your own image from installation ISO
● Download a ready made Virtual Machine Image that has been pre-built for OpenStack ● Convert an existing image from another infrastructure
If you choose one of the first two options, you will need to customize the image to your application needs so that it will run in OpenStack. If you choose the third option, odds are you already have this image customized. This document will cover all three options listed.
3.1 Creating your own image
Creating your own image is documented on the OpenStack website:
http://docs.openstack.org/image-guide/content/ch_creating_images_manually.html
However, for a detailed walk through on how to perform this, please see Appendix A.
3.2 Pre-built OpenStack Images
A number of operating systems already have pre-created cloud ready images. When you’re downloading these images, typically they come in 2 formats: RAW and QCOW2. We recommend when you have the choice between the two, opt for the QCOW2 image format simply because it is the native format for the KVM hypervisor utilized in Mirantis OpenStack Express.
The ready made images can be found via the OpenStack.org official documentation, here:
At the time of this document creation, the following Operating Systems have ready made cloud based images that can be used natively with OpenStack:
Ubuntu (http://cloud-images.ubuntu.com/)
Canonical maintains an official set of Ubuntu images and they appear to keep it up to date. When you drill down at the site into the proper Ubuntu Release that you are looking for, scroll to the bottom and locate the files utilizing the following naming convention:
64-bit:release-server-cloudimg-amd64-disk1.img 32-bit:release-server-cloudimg-i386-disk1.img
So for the latest Ubuntu LTS release 14.04 (as of this time), the 2 files would be: 64-bit: trusty-server-cloudimg-amd64-disk1.img
32-bit: trusty-server-cloudimg-i386-disk1.img
You can download the images to your local machine and then upload them into Mirantis OpenStack Express, however we recommend just uploading it into Mirantis OpenStack Express directly from the Ubuntu Website. To do this, right click on the image link of the architecture you wish to upload and copy the link address/URL. Use this as the “Image Location” when you are performing the Upload Image process:
On the bottom part of the Fedora page, they have the 64-bit and 32-bit versions for download. You have a choice between RAW and QCOW2 image formats.
You can download the images to your local machine and then upload them into Mirantis OpenStack Express, however we recommend just uploading it into Mirantis OpenStack Express directly from the Fedora website. You can only do this with the QCOW2 image because the RAW image is in a compressed XZ format that isn’t natively supported by OpenStack and needs to be extracted before uploading to Mirantis OpenStack Express.
NOTE: The raw XZ format will upload successfully, however when you attempt to instantiate an
instance from it, it will fail to find a boot device.
To upload the image from the Fedora Website directly into Mirantis OpenStack Express, right click on the “Download Now!” button for the QCOW2 image of the architecture you wish to upload and copy the link address/URL. Use this as the “Image Location” when you are performing the Upload Image process:
CentOS (http://repos.fedorapeople.org/repos/openstack/guest-images/)
It looks like this image is built and hosted by the people at Fedora. At the time of this writing, only the latest CentOS version (6.5) was available. It’s unclear if they will put up any additional images of previous versions of CentOS.
You can download the images to your local machine and then upload them into Mirantis OpenStack Express, however we recommend just uploading it into Mirantis OpenStack Express directly from the Fedora website. The format they provide is QCOW2.
Microsoft Windows Server 2012 (http://www.cloudbase.it/ws2012r2/)
Each of the images listed above are downloadable in a RAW data format or QCOW2. Raw data formats typically have a .raw or .img extension. Download the image of your choice and place it in a directory that you know where to find it. You can now proceed to the “Upload Image to OpenStack” section of the document.
3.3 Convert Image
Many customers already have a pre-existing environment somewhere such as their internal cloud running on a VMware infrastructure or in a public cloud provider such as AWS, that they would like to migrate to Mirantis OpenStack Express. Many times it’s easier to build a fresh new environment on Mirantis OpenStack Express, however sometimes it’s easier to take an existing
virtual machine in one of these environments and copy that virtual machine into Mirantis OpenStack Express. For instance, if a customer already spent time hardening a gold image template in their private VMware infrastructure it might be easier to migrate that image to Mirantis OpenStack Express to launch instances from.
Regardless of the source infrastructure, the virtual machine migration follows the same general path:
● Identify if you have administrator rights on the virtual machine
○ If you have administrator rights, you will make the necessary OS changes prior to converting the image to QCOW2
○ If you do not have administrator rights, you will make the necessary OS changes after converting the image to QCOW2
● Convert the source image format to the QCOW2 format for OpenStack ● Upload the QCOW2 image to OpenStack
● Launch instance from uploaded image
4.0 Upload Image
There’s 2 ways to get your OS Image into OpenStack: ● GUI Based Upload
● Command Line Upload
4.1 GUI based upload using Horizon
Uploading an Image via the GUI is covered in the official OpenStack Documentation here:
http://docs.openstack.org/user-guide/content/dashboard_create_images.html
Here’s a brief summary of what you need to do:
1. Login to the Mirantis OpenStack Express page and obtain the URL and credentials for your Mirantis OpenStack environment
2. Open a new page to your Mirantis OpenStack Environment
3. On the left, change to the Project tab and click “Images & Snapshots” 4. In the top right, click “+Create Image”
NOTE: After clicking Create Image, pay attention to the progress meter in the bottom left of the page:
Occasionally, due to network latency over the internet, this meter may reset back to 0%. If this happens a couple of times, the upload may fail due to HTTP transport timeout. If you experience this, we recommend you follow the Command Line procedure described below.
4.2.1 Upload the image file to the Controller Node
The process here will be to upload the image to the Controller Node and then utilize the CLI of glance to load the image into the environment. Refer to the Navigating Mirantis OpenStack Express section to configure the necessary tools to copy the image to the Controller Node. Once you have uploaded your image to the Controller Node, SSH into the Controller Node as the mirantis user and you should see your image in your home directory:
4.2.2 Validate authentication to Mirantis OpenStack
First, source the admin-openrc.sh file and provide your Mirantis OpenStack password when prompted. Then try to do a simple keystone tenant-list to ensure you’re authenticated:
Now we can use glance to upload the image into our environment: Command:
glance image-create --name CentOS --disk-format=qcow2 \ --container-format=bare --is-public=False \
--file=./CentOS_imageClone.qcow
Now we can launch an instance with our new image.
** Leave this SSH session open, you can use the same session for image customization
4.2.4 Extended usage examples of Glance
● Add image to glance
glance image-create --name test --min-disk 1 --min-ram 768 --file \ centos-6.5-20140117.0.x86_64.qcow2 --is-public True --property net_model=e1000 property \ disk_bus=ide disk-format=qcow2 --container-format ovf --progress
where
Optional arguments:
--id <IMAGE_ID> ID of image to reserve. --name <NAME> Name of image.
--store <STORE> Store to upload image to. --disk-format <DISK_FORMAT>
Disk format of image. Acceptable formats: ami, ari,
aki, vhd, vmdk, raw, qcow2, vdi, and iso. --container-format <CONTAINER_FORMAT>
Container format of image. Acceptable formats: ami,
ari, aki, bare, and ovf. --owner <TENANT_ID> Tenant who should own image.
--size <SIZE> Size of image data (in bytes). Only used with '--
location' and '--copy_from'.
--min-disk <DISK_GB> Minimum size of disk needed to boot image (in gigabytes).
--min-ram <DISK_RAM> Minimum amount of ram needed to boot image (in
megabytes). --location <IMAGE_URL>
URL where the data for this image already resides. For
example, if the image data is stored in swift, you
could specify
'swift://account:[email protected]/container/ obj'.
--file <FILE> Local file that contains disk image to be uploaded
during creation. Alternatively, images can be passed
to the client via stdin. --checksum <CHECKSUM>
Hash of image data used Glance can use for verification. Provide a md5 checksum here. --copy-from <IMAGE_URL>
Similar to '--location' in usage, but this indicates
that the Glance server should immediately copy the
data and store it in its configured image store.
--is-public [True|False]
Make image accessible to the public. --is-protected [True|False]
Prevent image from being deleted. --property <key=value>
Arbitrary property to associate with image. May be used multiple times.
--human-readable Print image size in a human-friendly format. --progress Show upload progress bar.
Parameter --property use to describe you image. You can see this in image info glance image-show test
● To get list of images use command: glance image-list
http://docs.openstack.org/grizzly/openstack-compute/admin/content/adding-images.html
Examples:
● Creating of image
glance imagecreate name "Window Server 2008 R2" ispublic=true --disk-format=qcow2 --container-format=ovf --file WIN2K8R2.qcow2
● Creating of image
glance image-create --name MSE-kl-test --disk-format=raw --container-format=bare --is-public=True --property hw_vif_model=e1000 --property hw_disk_bus=ide --file=MSE.raw
● Transferring parameters for drivers of virtual devices needed for this image on other
virtualization platforms, the --property argument is used. This is useful if the image is taken from another platform such as VMware.
hw_disk_bus=ide hw_vif_model=e1000
This values will be saved in the glance database for transfer to VM parameters in the process of creation instance with current type of storage.
● Delete image
image-delete {image name} ● Convert of image
qemu-img convert -f {initial format} -O {target format} {source file} {destination file}
Example:
5.0 Image customization
There are a couple reasons why you would want to customize an image from the default operating system installation. Some of those reasons are:
● You find that you are always installing the same packages/applications every time you create a new instance. (For instance, always installing Apache or tomcat)
● You want a ready made image of your application that can be utilized for automated cloud-scaling.
There are a couple different methods to customizing an image. If the customization only requires the editing of files contained in the image there are a couple different ways to do this. These processes are described in the official OpenStack documentation located here:
http://docs.openstack.org/image-guide/content/ch_modifying_images.html
If the customization requires extensive changes, such as adding packages to the system, you can perform the customization while building the image manually or if that is not an option, you can create an instance of the image, customize that instance and then snapshot the instance into a new usable image. Here we walk through customizing the image we uploaded in the Upload Image to OpenStack section. Launch an instance of that image onto net04, open a console to it and login with the root credentials. Here we are going to look for the openssh-clients package which is needed to scp files to/from the VM. We also check for nc (netcat) which is a very useful tool for testing ACL rules (Security Groups).
We could install any other packages we want, make changes to configuration files, or whatever customization we want to do to this instance. When we are ready to create a new image from this instance, we need to perform the following things in the instance to ‘clean it up’ to turn it into a usable image. Some items are just clean up items and some are necessary to create a functioning image:
yum clean all #Cleans out yum DB
logrotate -f /etc/logrotate.conf #Force rotate logs
rm -f /var/log/*-???????? /var/log/*.gz #Delete rotated logs cat /dev/null >/var/log/audit/audit.log #Clear audit log cat /dev/null >/var/log/wtmp #Clear login file
rm -f /etc/udev/rules.d/70-* #Remove dynamic udev rules rm -rf /tmp/* /var/tmp/* #Clean temporary directories
rm -f /etc/ssh/ssh_host* #Force regeneration of host key on start rm -f ~root/.bash_history #Clear the root user history
After typing the last command, don’t do anything else on this image. If you still have the SSH session open to the controller node from the Upload Image to OpenStack section, switch back to that window, othewise open a new SSH session to the controller node and source the admin-openrc.sh file again as detailed in the create unprivileged user section, providing the proper credentials.
First we will use nova list to display the running instances and then use nova image-create to image-create a new image from the running instance:
NOTE: Your console session to your instance will disconnect when you run this. You can just re-establish the console session once it’s complete.
After running this, it creates a snapshot that has our updated image that can now be utilized to instantiate new instances:
As we can see, when we launch an instance from this snapshot, it has the packages we just added:
6.0 Application Infrastructure on Mirantis OpenStack Express
This section will walk through creating the base infrastructure for a three tiered application deployment on Mirantis OpenStack Express. As a reminder, here’s the general layout of our three tier architecture:
Before we start building out a cloud, it might be best to consider what features we might want to use in OpenStack. One of the most common components that any enterprise application
leverages is a load balancer for high availability. In the Networking section, we will cover the changes needed to enable this functionality in your cloud before starting to build out the cloud. Adding this functionality in OpenStack later, has shown mixed results ranging from it just
working all the way to having to bounce all of the instances in the cloud. This is not specific to Mirantis OpenStack, but something that is seen in almost all distributions.
6.1 Networking
6.1.1 Enable LBaaS functionality in Mirantis OpenStack Express
First, obtain your credentials from the Mirantis OpenStack Express Dashboard and also make note of the node names that make up your OpenStack Cluster. Typically the names are in sequential order, so for the sample environment in this document, it consists of node-1 through node-4. For any commands the perfor a loop through the nodes, substitute the node numbers appropriately for your environment.
6.1.1.1 Install HAProxy on the Mirantis OpenStack Express nodes
Next, SSH into the Fuel Node as you will use that to reach the other nodes that make up your Mirantis OpenStack Express Cloud. Once logged in, loop through the nodes in your cluster and install the haproxy package:
for X in $(seq 1 4); do ssh root@node-${X} 'yum install haproxy -y' ; done
Note: Again, change ‘seq X Y’ to X = lowest node number and Y = highest node number.
6.1.1.2 Update lbaas_agent.ini
After haproxy has been installed, update /etc/neutron/lbaas_agent.ini on each system, uncommenting the interface_driver and device_driver lines identified below as well as uncommenting and setting the user_group as such:
Note: This file is identical on all nodes, feel free to change one and then copy it to all of the other nodes:
6.1.1.3 Update neutron.conf
Next, we need to update the neutron server configuration on the Controller Node. If you’re not sure which node is your controller node, refer to the controller node identification section to figure it out.
Edit the /etc/neutron/neutron.conf file on the controller node:
Locate the service_plugins line and you will want to uncomment it and change it so it looks like this:
service_plugins =
neutron.services.loadbalancer.plugin.LoadBalancerPlugin Next locate the service_provider line and uncomment it. It should read as:
service_provider =
LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.pl ugin_driver.HaproxyOnHostPluginDriver:default
6.1.1.5 Update Horizon Dashboard
6.1.1.6 Enable/start Controller Node services
On the Controller node:
● Enable the neutron-lbaas-agent service to start on a reboot chkconfig neutron-lbaas-agent on
● Start the neutron-lbaas-agent service
service neutron-lbaas-agent start ● Restart the neutron-server service
service neutron-server restart ● Restart the httpd service
service httpd restart
Note, you can ignore the warning regarding the MaxClients and the ServerName.
6.1.1.7 Enable/start all other node services
On all of the other nodes:
● Enable the neutron-lbaas-agent service to start on a reboot chkconfig neutron-lbaas-agent on
● Start the neutron-lbaas-agent service
service neutron-lbaas-agent start
6.1.1.8 Validate Horizon Dashboard
Logging into the Horizon Dashboard should now show a Load Balancer selection item on the left:
6.1.2 Create networks to support a three tier application deployment
● Web Tier Network: 192.168.111.0/24 (We will just utilize the net04 network that is created by default for you)
● Application Tier Network: 192.168.200.0/24 ● Database Tier Network: 192.168.220.0/24
Documentation on how to create a network can be found on the OpenStack Website here:
http://docs.openstack.org/user-guide/content/dashboard_create_networks.html
Once you have your networks created, your Network Topology map should look something like this:
6.2 Security Groups
Next, we will create several Security Groups to lock down this environment. Management of security groups is covered in the official OpenStack documentation here:
http://docs.openstack.org/user-guide/content/Launching_Instances_using_Dashboard.html
For our sample application, we will create the following (leaving the default Egress rules): Security Group: WebTier
Rules:
Ingress from 0.0.0.0/0 for 80/tcp # Inbound HTTP connections
Ingress from Security Group WebJump for 22/tcp # SSH from jump-web Security Group: ApplicationTier
Rules:
Ingress from Security Group WebTier for 8001/tcp # Inbound Weblogic connections Ingress from Security Group ApplicationJump for 22/tcp # SSH from Jump Server Security Group: DatabaseTier
Rules:
Ingress from Security Group ApplicationTier for 3306/tcp # Inbound MYSQL connections Ingress from Security Group DatabaseJump for 22/tcp # SSH from Jump Server
Security Group: WebJump Rules:
Ingress from 0.0.0.0/0 for 22/tcp # Inbound SSH connections Security Group: ApplicationJump
Rules:
Ingress from Security Group WebJump for 22/tcp # Inbound SSH connections from Web Tier Jump Server
Security Group: DatabaseJump Rules:
Ingress from Security Group ApplicationJump for 22/tcp # Inbound SSH connections from Application Tier Jump Server
Next, let’s create our jump servers for each of the networks by launching instances of the vanilla CentOS image we uploaded into OpenStack. Before launching an instance, you may want to either upload the key pair created earlier or create a new key pair to ease access. When launching the instance, be sure to select the appropriate Security Group
(WebJump,ApplicationJump or DatabaseJump) as well as the appropriate network for each instance. After launching one instance per tier, your Network Topology should look like this:
In this example, we opted to go with jump server Option #3 described in the Application Deployment Architectures section. While being more tedious for moving around in the environment, it limits internet exposure to a single jump server/IP address.
6.5 Floating IP
The last thing to do is to assign floating IP addresses to the jump-web servers. This is covered in the official OpenStack documentation here:
http://docs.openstack.org/user-guide/content/floating_ip_allocate.html
However, the coverage explains how to do it via the command line. To associate a floating IP address through the Horizon Dashboard:
Log into Horizon utilizing the credentials obtained from the Mirantis OpenStack Express Dashboard
Select Project on the left and click Access & Security
Select the Floating IP tab on the top and you will see the list of IP addresses available
Pick one and click the Associate button next to it and you will get a dialog that looks something like this:
Select jump-web and click Associate.
At this point, our environment is able to be administered on all three tiers from outside the network. The next step is to deploy an application. This could be a new application deployment, where you create all of your servers from clean images or it could be an application migration from another environment.
7.0 Application Migration
When considering migration of applications onto Mirantis OpenStack Express it is essentially the same considerations you would give when migrating an application on to your own private OpenStack cloud without the difficulties of racking, stacking and building the underlying hardware infrastructure.
Every application brings a unique scenario to the table when designing a migration strategy. Simply looking at how an application is deployed today and replicating the deployment infrastructure elsewhere is not always the best strategy when performing a migration. More often than not, an applications functionality and purpose change over time due to business rules, financial restrictions or poor architectural decisions that are too costly to change mid-life.
While there is not a ‘one size fits all’ model for application migration, we have assembled a ‘best practices’ check list to assist with designing a migrations strategy:
● Identify the functions of the various components within the application architecture o HTTP Servers
o Reverse proxy servers o Application servers o Database servers o Message queue servers o Mail servers
o Authentication servers o Load balancers
o Name servers
● Identify which components should be migrated versus which components should be created new
o Migrating a virtual machine from one infrastructure to another takes a considerable amount of time where as the creation and configuration of various components from scratch can save valuable time and resources
● Identify security requirements of the application architecture o Component segregation requirements
o Component hardening requirements
o Common & disparate networks o Port communications required ● Create a migration strategy/plan
Build from the ground up within Mirantis OpenStack Express: ● Create the appropriate network layout
o Create needed private networks
o Create needed Security Groups for communications o Create jump servers to reach infrastructure components ● Create a base image that will be used for the whole environment
o Include datacenter specific customization in this image such as: § default accounts
§ SSH keys
§ hardening configuration (iptables, SElinux, IDS/IPS, etc) § sendmail configuration
§ authentication configuration (AD, LDAP, etc)
● Create customized augmentations of the base image for components
Utilizing these checklists, we are going to walk through what a typical three tiered application migration might look like.
We are going to take a weblogic application that is currently deployed on a VMware environment and migrate this application to the Mirantis OpenStack Infrastructure we created in the
Application Infrastructure on Mirantis OpenStack Express section. This application consists of:
● 2 HA Proxy Servers
● 2 Weblogic 12.1.2 Managed Servers in a cluster configuration
These processes are run as the user weblogic:weblogic which has a UID and GID of 1000 ● 1 Weblogic 12.1.2 Administrative Server
These processes are run as the user weblogic:weblogic which has a UID and GID of 1000 ● 1 mySQL Database
In preparing for this migration, the following items were decided:
● The HA Proxy Servers will be installed fresh and not migrated due to the minimal configuration involved
● The HA Proxy Servers will be load balanced
● The mySQL Database will be installed fresh and the data exported from the VMware Database and imported into the database residing on Mirantis OpenStack Express ● The Weblogic Administrative Server will be migrated
● The Managed Servers will be recreated utilizing Weblogic Tools on the Administrative Server
7.1 mySQL Database
7.1.1 Dump source mySQL Database
For our demo application, our database consists of a single table. We will utilize the mysqldump utility for dumping the contents of our database:
Note: Use the --databases switch to ensure the create database commands are included in your output.
7.1.2 Create mySQL Database Virtual Machine in Mirantis OpenStack Express
Next, we will create an instance in the Mirantis OpenStack Express Database Network to run the database:
7.1.3 Copy the SQL to create the database to the Mirantis OpenStack Express
mySQL Virtual Machine
Once the instance is up, we will upload the DemoDB.sql to the WebJump server and push it back to the mysql server we just stood up by using scp to move it from jump server to jump server and finally to the mysql server::
7.1.4 Configure /etc/hosts (as root)
Now we will su to the root user and ensure that /etc/hosts is set up properly with the host name. If it is not, edit it and set it properly:
7.1.5 Install mysql-server package (as root)
Install the mysql-server package by executing: yum install mysql-server -y
7.1.6 Configure mySQL listener address and port (as root)
After mySQL is installed, configure the listening address and port by editing the /etc/my.cnf file and add the bind-address and port directives in the [mysqld] section as such:
Note: Set the IP address to the IP address of your mysql server.
7.1.7 Enable mysql auto-start and start mysql server (as root)
After configuring the /etc/my.cnf file, ensure mysql starts on a server reboot and start mysql by issuing the following commands as root:
chkconfig mysqld on service mysqld start
7.1.8 Set the mySQL root user and password (as root)
First thing you must do is set the root password to mySQL since it has no password by default. You can do so by issuing the following commands:
/usr/bin/mysqladmin -u root password '<password>'
7.1.9 Configure iptables (as root)
The last configuration settings you’ll need to do as the root user is to open up the OS firewall to allow connections to mySQL. Edit the /etc/sysconfig/iptables and add the line below and restart iptables:
At this point, we no longer need to be logged in as the root user, so we can exit back out to the cloud-user.
7.1.10 Load data into mySQL on Mirantis OpenStack Express
Next, we load the data into mySQL:
Last thing we need to do is add a user to mySQL for our application to utilize.
7.2 Weblogic Managed Servers
Because applications need to scale, the best approach here would be to create a virtual machine image that is pre-configured with JRockit and Weblogic 12.1.2 that can be used to stand up additional servers in the future.
To do this, you would follow the steps detailed under image customization. The
CentOS-Weblogic12.1 image used below is the same image used in mySQL Database section above, just with JRockit and Weblogic 12.1.2 installed on it. The weblogic group and user were added to the image and all JRockit and Weblogic file ownerships changed to be owned by the weblogic user:group. Once you have this base image, you can quickly stand up multiple managed servers:
Once these come up, we will rename them just so that they are easier to identify and work with later.
Afterwards, login to them and as the root user:
● Update /etc/sysconfig/network with the new hostname ● Update /etc/hosts to ensure it has the proper information in it
At this point we are done with the Managed Servers until we copy the domain over.
7.3 Weblogic Administrative Server
The Weblogic Administrative Server contains all of the necessary configuration details needed to move the whole domain. Due to this, we can migrate the single Virtual Machine from VMware and then use that to replicate out the necessary supporting Managed Server instances.
7.3.1 Convert the VMware virtual machine
The Weblogic Administrative Server we are migrating is a CentOS virtual machine running Weblogic 12.1.2 on JRockit 1.8. The process for migrating a linux Virtual Machine is covered in detail in Migrating a VMware Linux Virtual Machine.
7.3.2 Perform root level changes within the Administrative Server on Mirantis
OpenStack Express
After the image is up, utilize the jump servers to log into the image as the root user. We need to update some of the files here:
● /etc/sysconfig/network should be updated with the proper hostname ● /etc/hosts should be updated with the proper IP addresses for components
● /etc/hosts should contain a line with this hosts hostname and appropriate IP address. Weblogic will not start properly without it.
● Issue the hostname command to set the current hostname
Note: Your prompt won’t update until you either log out and log back in or your source your .bash_profile again.
7.3.3 Launch the Weblogic Administrative Console
Once the server is started, you’ll see the RUNNING message:
Now that the Administrative Server is up, we need a way to access it. Because the Administrative Server is not needed for daily functions of the applications running on Weblogic, we recommend assigning a floating IP address to it in an ‘as needed’ basis.
7.3.4 Configure Security Groups for the Weblogic Administrative Console
First, we will create a WeblogicAdmin Security group with the following rule: Security Group: WeblogicAdmin
Rules:
We will add this Security Group to the weblogic-as server: ● Select Instances on the left
● Next to the weblogic-as instance, drop down the More button and select Edit Security Groups
● Click the + next to the WeblogicAdmin Security Group ● Click Save
Additionally, we need to add a rule to the ApplicationTier Security Group to allow the Administrative Server to communicate to the Managed Servers on all ports.
Security Group: ApplicationTier Rule to add:
Ingress TCP ALL from Security Group Weblogic Admin # Inbound Weblogic Admin Console connections
7.3.5 Associate a Floating IP
Now we need to add a Floating IP address so we can reach the Administrative Console from the internet.
● Select Access & Security on the left ● Select Floating IPs tab at the top
● If there are no available Floating IPs, click Allocate IP to Project button on the right ○ Click Allocate IP on the pop up window that appears
● Pick an unused IP address and click Associate next to it
● Select the weblogic-as server as the port to associate it with
● Click Associate
Now you should have an IP associated with the Weblogic Admin Server that you should be able to access in a web browser to access the Admin Console.
7.3.6 Re-configure application resources using the Weblogic Administrative
Console
Login using your weblogic credentials. We will need to make some changes to the configuration. First, we will update the Database Resource to reflect the new IP address of the database:
● In the Domain Structure window on the left, expand Services and select Data Sources
● Next, click on the Database name and select the Connection Pool tab
● Update the IP address in the URL to reflect the new IP address of the mySQL server
● Click Save
Next, we will update the IP addresses for the 2 Managed Server Machines.
● Click on the first machine and go to the Node Manager tab
● Update the IP address of this machine to match the new Managed Server Machine we create
earlier.
● Perform the same process for the other machine. Also, note the listening port (5556) as we will need to add that to the iptables rules on the Managed Servers when we configure them next.
After the changes have been saved, we need one more piece of information from the
Administrative Console. Expand Environment and select Servers. You should see something like this:
The 2 DemoServers here are our JVM’s that will be executing the application. You’ll want to make a note of the Machine those JVM’s are on as well as the Listen Ports for those JVM’s. They will be needed in the next step when you configure the firewall on the Managed Servers. Now all of the changes have been saved, we need to pack the configuration and move it to the Managed Servers we instantiated earlier.
7.4 Pack and upack the domain to the managed servers
Utilize the jump servers to SSH into the weblogic admin server and change user to the weblogic user.
7.4.1 Pack the domain
In the common/bin directory of the Weblogic installation are 2 utility scripts pack.sh and unpack.sh. Weblogic Administrators should be familiar with these tools as they are utilized to create domains on Managed Nodes. We will use the pack.sh script to pack the current domain:
We will then copy that base_domain.jar to the Managed Server nodes we created earlier.
7.4.2 Unpack the domain on each Managed Server
Next, SSH into each of the Managed Server Nodes and perform the following: ● Move base_domain.jar into /tmp and ensure it is world readable
● Change to the weblogic user.
7.4.2 Update the firewall on each Managed Server
Before we start the NodeManager, we need to open up some ports in the Managed Server Firewall to allow:
Nodemanager to receive requests on port 5556 Managed Servers to receive requests on port 8001
Perform this on both Managed Servers.
7.4.3 Launch NodeManager on each Managed Server
Switch to the weblogic user and launch the NodeManager process in the background:
7.4.4 Start the Application Servers and verify the application is running
Now we are ready to start up the Application Servers and start the application. Go back to the Administrative Console for Weblogic in your Web Browser
Click on Servers
On the right select the Control tab
Select both servers that host the application Click Start
After the servers show running:
7.5 HA Proxy Servers
The HA Proxy Servers are built just like the mySQL Server: ● Launched 2 instances of the CentOS Image
● Installed haproxy on both instances once they came up ○ As root: yum install haproxy -y
● Updated /etc/haproxy/haproxy.cfg accordingly
●
○ As root: chkconfig haproxy on
● Updated iptables and restarted the service
● Started the haproxy service ○ As root: service haproxy start
At this point, you can configure a Floating IP address to either or both of your HA Proxy Servers and hit your application:
Click Add
Click the Members tab Click Add Member
Click the Monitors tab Click Add Monitor
Note: Ensure that you have a proper URL listed because if the Monitor does not get back the Expected HTTP Status Code, it will bring down the VIP and you won’t be able to get to anything via the load balancer.
At this point, you can test your VIP by utilizing wget or curl from the jump server in the web tier if you like.
Next, we need to be able to access this from the internet by associated a Floating IP. Click Access & Security then select the Floating IPs tab at the top.
Pick one of the IP’s and click Associate
Note: The name of the load balancer is ‘None:’ however you can identify it by the IP address you assigned to the VIP.
After you assign this Floating IP address, your application should now be available from the internet.
8.0 Demo Application Deployment
For this Demo Application Deployment, we will deploy a Wordpress application utilizing the following technologies:
●
● HAProxy
● MySQL database server ● Wordpress
● Apache
Additionally Security Groups will be utilized to enforce security policy by limiting connections between ports, e.g. HAProxy can open only 8080 port but not any other. In this case
8.1 Manage Security Groups via Horizon
Security groups are sets of IP filter rules that are applied to an instance's networking. They are project specific and project members can edit the default rules for their group as well as add new rule sets. All projects have a "default" security group, which is applied to instances that have no other security group defined. Unless changed, this security group denies all incoming traffic.
8.1.1 Creating Security Groups
●
● Click on the +Create Security group button
● Enter the name of your new Security Group and the description. ● Click the Create Security Group button.
*Examples below will reference the sample_one Security Group
● After this we can see the new security group in the list of groups:
8.1.2 Editing Security Group Rules
● Press Edit Rules button next to the Security Group you want to add/edit rules. We will use the sample_one Security Group created above.
Note: By default all ports are opened for outbound connections and no inbound connections are
