TECH GUIDE OpenStack Installation: A Practitioner’s Guide Introduction TECH GUIDE: OpenStack Installation: A Practitioner’s Guide One of the great things about OpenStack is all the options you have for deploying it – from homebrew to hosted OpenStack to vendor appliances to OpenStack-as-a-service. Previously, Platform9 published a tech guide comparing various OpenStack deployment models. If you opt for a do- it-yourself (DIY) approach, then you face the question of which tool to use. This guide will familiarize you with the landscape of OpenStack installation tools, including an overview of the most popular ones: DevStack, RDO Packstack, OpenStack-Ansible, Fuel and TripleO. OpenStack Architecture Overview If you’re new to OpenStack it may be helpful to review the OpenStack components. (Skip this section if you’re already familiar with OpenStack.) OpenStack’s design, inspired by Amazon Web Services (AWS), has well-documented REST APIs that enable a self-service, elastic Infrastructure-as-a Service (IaaS) cloud. In addition, OpenStack is fundamentally agnostic to the underlying infrastructure and integrates well with various compute, virtualization, network and storage technologies. Heat Clarity UI CLI / Tools Scripts (orchestration) Nova Compute Scheduler (images) Cinder Keystone Glance (identity) Basic Storage Basic Network Neutron Network Block Controller Storage Figure 1: OpenStack architecture is loosely coupled, and extensible to support any hypervisor / container, storage, and network system 2 Plan to get NO help to install & manage YES OpenStack? Want to use Have budget NO existing YES NO for Professional YES infrastructure? Services? Use OpenStack- as-a-service Platform9 Need high Prefer to NO customization? YES NO own infrastructure? YES DIY OpenStack install Use hosted DevStack OpenStack RDO Packstack IBM BlueBox OpenStack-Ansible Rackspace Fuel TripleO Prefer minimal OpenStack Browneld NO lifecycle management? YES NO Environment? YES Use OpenStack Use OpenStack- Use OpenStack Use OpenStack- vendor distro as-a-service vendor distro as-a-service Red Hat Platform9 Red Hat Platform9 Rackspace Rackspace Mirantis Mirantis Short NO timeline to build private YES cloud? DIY OpenStack install DevStack Avoid RDO Packstack NO Vendor lock-in? YES OpenStack-Ansible Fuel TripleO Use OpenStack Use OpenStack- appliances as-a-service Cisco Metapod Platform9 Stratoscale ZeroStack VMware VIO Figure 2: How to choose an OpenStack Deployment Model 3 How to Choose an OpenStack Deployment Model The primary question that drives the choice of deployment models is whether your IT team has the expertise, and the inclination, to install and manage OpenStack. Depending on the desire to host your infrastructure and avoid vendor lock-in, various deployment models are available. If there’s a need for a high degree of customization, along with the flexibility to choose hypervisors, then a DIY install is probably the best option (see highlighted section of the flowchart on previous page). If you choose DIY install, there’s a wide choice of open source tools that are very easy to use and can create environments for use in development, testing or production. These tools can deploy OpenStack on bare metal, virtual machines or even containers. Some even install OpenStack in a production-grade, highly available architecture. But which tools are best suited for your requirements? Read on for an overview of some of the most popular tools, followed by a handy comparison matrix to summarize the options. More detailed documentation is available on each tool’s dedicated website.¹ OpenStack Installation: DevStack DevStack is a series of extensible scripts used to quickly bring up a complete OpenStack environment suitable for non-production use. It’s used interactively as a development environment. Since DevStack installs all-in-one OpenStack environments, it can be used to deploy OpenStack on a single VM, a physical server or a single LXC container. Each option is suitable depending on the hardware capacity available and the degree of isolation required. A multi-node OpenStack environment can also be deployed using DevStack, but that’s not a thoroughly tested use case. For either kind of setup, the steps involve installing a minimal version of one of the supported Linux distributions and downloading the DevStack Git repository. The repo contains a script stack.sh that must be run as a non-root user and will perform the complete install based on configuration settings. The official approved and tested Linux distributions are Ubuntu (LTS plus current dev release), Fedora (latest and previous release) and CentOS/RHEL 7 (latest major release). The supported databases are MySQL and PostgreSQL. RabbitMQ and Qpid are the recom- mended messaging service along with Apache as the web server. The setup defaults to a FlatDHCP network using Nova Network or a similar configuration in Neutron. The default services configured by DevStack are Keystone, Swift, Glance, Cinder, Nova, Nova Networking, Horizon and Heat. DevStack supports a plugin architecture to include additional services that are not included directly in the install. Summary of the Installation Process 1. Install one of the supported Linux Distributions 2. Download DevStack from git 3. git clone https://git.openstack.org/openstack-dev/devstack 4. Make any desired changes to the configuration 5. Add a non-root user, with sudo enabled, to run the install script 6. devstack/tools/create-stack-user.sh; su stack 7. Run the install and go grab a coffee 8. cd devstack /stack.sh 4 Configuration Options DevStack provides a bunch of configuration options that can be modified as needed. The sections below summarize some of the important ones. local.conf DevStack configuration is modified via the file local.conf. It’s a modified .ini format file that introduces a meta-section header to carry additional information regarding the configuration files to be changed. The new header is similar to [[‘ <phase> ‘|’ <config–file–name> ‘]]’, where <phase> is one of a set of phase names defined by stack. sh and <config-file-name> is the configuration filename. If the path of the config file does not exist, it is skipped. The file is processed strictly in sequence and any repeated settings will override previous values. The defined phases are: • local – extracts localrc from local.conf before stackrc is sourced • post-config – runs after the layer 2 services are configured and before they are started • extra – runs after services are started and before any files in extra.d are executed • post-extra – runs after files in extra.d are executed [[post-config|$NOVA_CONF]] [DEFAULT] use_syslog = True [osapi_v3] enabled = False A specific meta-section local|localrc is used to provide a default localrc file. This allows all custom settings for DevStack to be con- tained in a single file. If localrc exists it will be used instead to preserve backward compatibility. [[local|localrc]] FIXED_RANGE=10.20.30.40/49 ADMIN_PASSWORD=secret LOGFILE=$DEST/logs/stack.sh.log 5 openrc openrc configures login credentials suitable for use with the OpenStack command-line tools. openrc sources stackrc at the beginning in order to pick up HOST_IP and/or SERVICE_HOST to use in the endpoints. The values shown below are the default values. OS_PROJECT_NAME=demo OS_USERNAME=demo OS_PASSWORD=secret #The usual cautions about putting passwords in environment variables apply HOST_IP=127.0.0.1 #Typically set in thelocalrc section SERVICE_HOST=$HOST_IP OS_AUTH_URL=http://$SERVICE_HOST:5000/v2.0 #commented out by default # export KEYSTONECLIENT_DEBUG=1 # export NOVACLIENT_DEBUG=1 Minimal Configuration While stack.sh can run without a localrc section in local.conf, it’s easier to repeat installs by setting a few minimal variables. Below is an example of a minimal configuration for values that are often modified. Note: if the *_PASSWORD variables are not set, the install script will prompt for values: • No logging • Pre-set the passwords to prevent interactive prompts • Move network ranges away from the local network • Set the host IP if detection is unreliable [[local|localrc]] ADMIN_PASSWORD=secret DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD #FIXED_RANGE=172.31.1.0/24 #FLOATING_RANGE=192.168.20.0/25 #HOST_IP=10.3.4.5 # export NOVACLIENT_DEBUG=1 Service Repositories The Git repositories used to check out the source for each service are controlled by a pair of variables set for each service. *_REPO points to the repository and *_BRANCH selects which branch to check out. These may be overridden in local.conf to pull source from a different repo. GIT_BASE points to the primary repository server. NOVA_REPO=$GIT_BASE/openstack/nova.git NOVA_BRANCH=master 6 The installation directory defaults to /opt/stack and can be set by the DEST parameter. DEST=/opt/stack Logging By default stack.sh output is only written to the console where it runs. It can be sent to a file in addition to the console by setting LOGFILE to the fully qualified name of the destination log file. Old log files are cleaned automatically if LOGDAYS is set to the number of days to keep old log files. DevStack will log the stdout output of the services it starts. When using screen this logs the output in the screen windows to a file. Without screen this simply redirects stdout of the service process to a file inLOGDIR . Some of the project logs will be colorized by default and can be turned off as below. LOGFILE=$DEST/logs/stack.sh.log LOGDAYS=1 LOG_COLOR=False LOGDIR=$DEST/logs Logging all services to a single syslog can be convenient. If the destination log host is not localhost, the settings below can be used to direct the message stream to the log host. SYSLOG=True SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516 Database Backend The available databases are defined in the lib/databases directory. MySQL is the default database but can be replaced in the localrc section: disable_service mysql enable_service postgresql Messaging Backend Support for RabbitMQ is included. Additional messaging backends may be available via external plugins.