A Performance comparison: Apache vs NGINX and OpenStack Keystone

In a previous article, I showed how to configure keystone to run behind NGINX instead of current recommended configuration using Apache. Since its inception, NGINX has enjoyed significant growth in the web server space. Netcraft monthly data web server market share for NGINX has grown significantly since its introduction. Data for May 2016 can be found at: https://news.netcraft.com/archives/2016/05/26/may-2016-web-server-survey.html

Run OpenStack Keystone and Horizon using NGINX on Ubuntu 16.04

I previously wrote an article showing how to convert OpenStack from using an Apache server for both Keystone and the Horizon interface. Since that article was written, OpenStack has moved to the Mitaka release, and Unbuntu has moved to a new long term release “Ubuntu 16.04 - xenial”. These two releases bring a number of changes to the configuration. In this article, I show you how to make the transition to ngix running these newer releases.

If you are an OpenStack contributor, you likely rely on DevStack for most of your work. DevStack is, and has been for a long time, the de-facto platform that contributors use for development, testing, and reviews. In this article, I want to introduce you to a project I’m a contributor to, called openstack-ansible. For the last few months, I have been using this project as an alternative to DevStack for OpenStack upstream development, and the experience has been very positive.

In my previous series of articles about installing OpenStack from source, we installed keystone as a standalone application. This technique has been deprecated in the Kilo release in favor of running the keystone server, as a web server gateway interface (wsgi) service behind the Apache server. This allows for each Apache thread to start its own separate keystone thread. Example configuration files are available in the httpd directory in the cloned keystone repo. This article is a how to setup both keystone and the horizon dashboard to run under Nginx.

Federation support in OpenStack has been greatly improved in the Kilo release, and, while there are still some rough edges, the feature is now usable, if you don’t mind adding a little elbow grease. This article focuses on one specific configuration called Keystone-to-Keystone federation (or K2K), in which users of an OpenStack cloud use their credentials to access services in another OpenStack cloud, with both clouds using Keystone as their identity services.

This is the sixth and final installment in a series demonstrating how to install OpenStack from source. The five previous articles:

• Install Keystone
• Install Glance and Neutron
• Install Nova
• Install Neutron on the Network node
• Install the Compute node

Previously we installed the Identity service (keystone), Image service (glance), Networking service (neutron), and the Compute service (nova) onto the controller node. We also installed neutron onto the network node and nova and neutron onto the compute node. In this section, we turn our attention to finishing up by installing the Volume service (cinder) and dashboard (horizon) onto the controller node.

This is the fifth installment in a series of installing OpenStack from source. The four previous articles can be found here:

• Install Keystone,
• Install Glance and Neutron
• Install Nova
• Install Neutron on the Network node

We installed the Identity service (keystone), Image service (glance), Networking service (neutron) and the Compute service (nova) onto the controller node, and then we turned our attention to the network node to install the neutron agents to support the network layers two and three. Now, we turn our attention to the compute node to install both neutron and nova.

This is the fourth installment, in a series showing how to install OpenStack from source. In the three previous articles:

• Install Keystone
• Install Glance and Neutron
• Install Nova

We installed the Identity service (keystone), Image service (glance), Networking service (neutron) and the Compute service (nova) onto the controller node. In this section, we turn our attention to the network node, to install the neutron agents to support network layers two and three.

In article one of this series, we started installing OpenStack from source, and, in article two of this series, we continued the process by installing glance and neutron onto the controller node.

In the first article of this series, we started installing OpenStack from source. We installed keystone and populated it with some basic information including a Services project and an admin user for our new OpenStack install. Additionally, in an initial script we setup users and directories for the upcoming installs of the Image service (glance), Networking service (neutron), Compute service (nova) and Volume service (cinder). Now, let’s continue and install and start the glance process on the controller node.