It's impossible to go anywhere these days without hearing about cloud computing. If you currently work in the technology world, I'm sure you've been at a gathering with family or friends when someone finally asks you, "so... what IS the cloud?" Even to the most technically savvy, it is a difficult question to answer. "Cloud" is often used as a buzzword, describing computing or storage infrastructure that can be accessed by many users from any location. To provide the right context, let's take a moment to dive into a brief history of the cloud. If you've heard this story before, feel free to skip ahead!

The application. Whether we are swiping through colorful icons on our smartphone home screens or logging on to our laptop's operating system, the app is everywhere. In fact, the term is used so frequently that it's difficult to give app a proper definition.

So, rather than attempt to define what apps are, we can surely define what they do: solve problems. Apps can provide solutions to some of our most critical business headaches, saving and making money for organizations (and individuals). But more importantly, they often present users with unrealized needs. Think about how many people consider Twitter, Facebook, and LinkedIn on their smartphone to be a necessity to their daily lives.

We typically call the minds behind applications software developers. But life for the software developer wasn't so easy 20 years ago. A developer would hack away on their home or office desktop, perfecting and testing their code into the late hours of the night. When the time for them to share their work with the world, they would need a physical computing device with CPU, disk, and memory. The computer would likely require internet access so it could reach a greater population. And in order to make that happen, a software developer would typically rely on a group of system engineers to call up a hardware vendor and get this machine shipped to the office or data center.

After going through the grueling process of getting the machine unboxed, racked, stacked, and wired up, system engineers would then need to configure the operating system, install the necessary programs and frameworks, and ensure the software developer could connect to the machine from their desktop. Consider some of the technical practices at this time: high availability and fault tolerance, although widely discussed, were not commonly enforced.

Once the servers were ready to go, the software developer would share their masterpiece, placing it on the provided infrastructure. As users accessed the application, all would be great... until the app was no longer accessible. Suddenly, the software developer's phone would ring in the middle of the night. System engineers would struggle to fix hardware failures, thus bringing down the application and facing many angry end users. This required trips to the data center—which itself needed disaster recovery plans in case of a fire, flood, or storm. And how about if the application had a spike of major success? If tons of users rushed to type the URL into their browsers and navigate to the site, resources on existing hardware could be overloaded. The system engineers would need to purchase and install additional servers, firewalls, and load balancers to provide more resources for the additional traffic. All of these potential hazards could be a headache for everyone involved—especially a software developer whose focus should stay on the application itself.

November 10, 2003: A group of IT executives in dresses, business suits, and blazers stood around a boardroom, watching a screen projecting a video clip of Terminator II: Judgement Day. "Are you ready?" said one of the men standing at a podium. On the bottom right of the screen, a small box of a few Microsoft Windows control panels displayed icons representing running servers.

These servers were virtual machines, and the video clip the room was watching was being played from a file server on one of these virtual machines. Suddenly, the host clicked on a few context menus on the virtual machine and a progress bar appeared. The video continued to play as the T-1000 Advanced Prototype morphed from liquid metal into human form, chasing John Connor in a burning police car. The room exploded with hoots, hollers, and cheers—and it wasn't because of the Terminator. This was a demo of a technology called VMotion, which would revolutionize the IT operations world for years to come.

Although virtualization had been around out since the 1960s, VMware can certainly be credited for bringing it to the masses in their official release of VMware VirtualCenter featuring VMotion. VMotion allowed system engineers to convert their existing physical machines to hypervisors, enabling the running of virtual machines. It also kept those virtual machines up by live-migrating them to another hypervisor in the event of an underlying hardware problem. This was done by transferring the virtual machine's active memory and execution state over the network.

Software developers and system engineers alike were overjoyed with the technology, knowing they would now sleep quite well while their application hummed along regardless of hardware headaches. The software developers continued to develop their incredible applications, but their development methodology remained the same. They were still developing their application as if they were on traditional physical machines!

Gartner, the information technology research and advisor company, has labeled this type of environment Mode 1, otherwise known as enterprise virtualization. In fact, enterprise virtualization still exists today and is the most adopted type of the cloud by enterprises around the world. See Figure 1.1.

Here are some common characteristics of the enterprise virtualization cloud:

• GUI-emphasized: When one creates a new virtual machine in this model, they typically do so via a Graphical User Interface (GUI). This may be something like vSphere Web Client or Hyper-V Manager. Command-line tools may exist but are less popular with a majority of its operators.
• Expensive hardware: Enterprises that buy into enterprise cloud also buy into expensive blade servers, SANs, network/fabric switches, component redundancy, and high-cost, boutique super microcomputers—specialized hardware with a high price tag.
• Vertical scaling: If your application begins getting more traffic, the ability to scale will be necessary. In the enterprise virtualization world, this means assigning more resources to virtual machines powering the application. When one scales up or vertically, they go about this by adding more CPU, RAM, or disk space to the individual virtual machines. This is the opposite philosophy to scaling horizontally.
• Proprietary: The infrastructure code in this model is closed source. This includes software such as VMware VCenter powered by Microsoft Windows Server. If a bug is discovered while working with the software, it must be filed with the vendor. Because one monolithic organization controls access to the code, bug fixes can take weeks or months to be patched.
• Traditional software development: In an Enterprise Virtualization cloud, the software developer continues to develop the applications in the same manner they developed applications on physical machines. This is sometimes referred to as the monolithic approach. Although the web server or database may reside on different virtual machines, the application's functions are combined into a single program from a single platform. This differs drastically from the cloudy development approach explained in the next section.

In March of 2006, Michael Arrington—founder of Silicon Valley news blog TechCrunch—had an exciting announcement:

Amazon Web Service is launching a new web service tonight called S3 – which stands for “Simple Storage Service”. It is a storage service backend for developers that offers “a highly scalable, reliable, and low-latency data storage infrastructure at very low costs… This is game changing.”

Arrington was right. At this time, Amazon Web Services had yet to release the catalog of services we all know today. Simple Storage Service (S3) provided users with the ability to create an account, enter their credit card number, and have access to upload files to AWS's hosted infrastructure within seconds. One benefit stood out above all: unlimited storage space.

At the time, hosting companies offered virtual private servers (VPS), allowing one to rent a server and use it for backup or file storage. The problems with these solutions was the space limitation on a particular server, not to mention the responsibility of the customer to maintain the health and security of the operating system. While a VPS may have charged users with monthly or yearly flat rates, S3 billed the user for what they used, much like a household electricity bill. The software developer now had the power to avoid the purchase of additional physical servers and storage arrays.

In 2006, there was one surprise left from AWS. On August 25, 2006, Jeff Bar, Chief Evangelist at AWS, announced the launch of Elastic Compute Cloud (EC2):

"Amazon EC2 gives you access to a virtual computing environment. Your applications run on a "virtual CPU", the equivalent of a 1.7 GHz Xeon processor, 1.75 GB of RAM, 160 GB of local disk and 250 Mb/second of network bandwidth. You pay just 10 cents per clock hour (billed to your Amazon Web Services account), and you can get as many virtual CPUs as you need."

This post was the shot heard 'round the IT operations world. Not only could the software developer have access to unlimited storage space with S3, but create as many virtual machines as they wanted. A college student in their dorm now had access to the data centers, bandwidth, and computing power of large-scale enterprises. It was the competitive advantage they needed. This truly provided power to developers. They would quickly scale their application during times of success (with a few clicks of a button) and quickly handle failure elegantly if anything went wrong.

Gartner labeled this type of cloud Mode 2, otherwise known as elastic cloud. See Figure 1.1.

Here are some common characteristics of the elastic cloud:

• API emphasized: Both AWS S3 and EC2 offered Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) APIs at the time of launch. The power of the API is the ability for a developer to easily incorporate these web services into their web application software logic. Visualize a website allowing users to upload and share photos. The developers creating the web application could make API calls to S3 whenever a user uploads or downloads a photo, thus ensuring all the users' uploaded photos were stored in AWS's S3 infrastructure. Although the SOAP API was deprecated by AWS in December 2015, the much more elegant REST API allows browsers to easily communicate with GET, PUT, POST, HEAD, and DELETE methods over the protocol that powers the web: HTTP.
• Standard hardware: Werner Vogels, Vice President and CTO of Amazon, once said everything fails all the time. The inevitability of hardware failures means that redundancy and high availability are going to be a fundamental part of the application running on top of the underlying hardware. If hardware fails, it shouldn't be a problem because the developer has ensured that their application follows the cloudy development style (see final bullet point).
• Horizontal scaling: When one needs more computing power, they rarely bother with resizing existing instances. They instead choose the unlimited nature of elastic cloud by creating more virtual machines and do work in parallel. This is also known as scaling horizontally.
• Open source: Although AWS's overall design and infrastructure are considered proprietary information, the release of its core services sparked a revolution in the tech startup world. Startups with a little cash and a few tech-savvy individuals could use and deploy open source tools, adopt a continuous deployment model, and focus on delivering minimum viable products to customers.
• Cloudy development: Perhaps the most important difference with elastic cloud is cloudy development. As AWS continued to release more services and features throughout the late 2000's, its users began to develop new methodologies for deployment and continuous integration. Many of the users embraced the "fail fast" motto by shipping application code into production as soon as possible to enhance the customer experience. These developers also began embracing a new cloudy methodology, moving from monolithic applications to microservices—utilizing message queues to avoid tightly coupled services, and embracing cloud automation and instance personalization via tools such as Puppet and Chef.

Although Amazon was beginning to gain traction as an incredible way to deploy applications, there were many concerns:

• Security: Amazon has significantly improved its security offerings over the years, but at the time of its release, Amazon only offered shared hosted infrastructure. The physical machine hosting your virtual machine most likely served other customers, including competitors! Companies with strict security compliance requirements found this unacceptable.
• Cost: There's no doubt that Amazon is much cheaper than choosing to purchase, deploy, manage, and support the infrastructure yourself. But what about all that AWS cloud spending over time? This is a subject of much debate. But in some scenarios, hiring a company to manage your cloud may be cheaper over time.
• Vendor lock-in: As companies began to place more and more of their production workloads on AWS, this required employees investing hours and days of their time learning the ins and outs of the unique AWS ecosystem. This included digging through official AWS documentation so that one could learn how to code to their APIs. As a single organization in charge of all aspects of the offering, AWS could easily choose to change their API syntax or even raise their resource usage prices. Imagine the hassle involved in attempting to migrate workloads on AWS to another cloud provider.

In 2008, NASA was interested in utilizing AWS EC2 to perform scientific computation, but had some concerns about security. As a result, they decided to build their own open-source cloud platform called Nebula. Nebula was a scalable compute-provisioning engine that was loosely based on the EC2 offering.

Around the same time, Rackspace, a managed hosting company from San Antonio, Texas, was working on an open source project called Swift. Swift was (and still is) a distributed object storage system similar to AWS S3, which became a part of Rackspace's Cloud Files offering.

It wasn't until July of 2010 that NASA and Rackspace officially announced the plan to actively combine the Nebula and Swift projects, inviting the world to begin contributing code to a new open source cloud project known as OpenStack. Discussions about the direction of OpenStack began immediately, as more than 100 architects and developers from more than 25 companies traveled to Austin for the first OpenStack conference. Just as quickly, hundreds of developers, hardware manufacturers, and IT software companies began contributing code, inspired by the OpenStack mission:

"To produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable."

This mission statement appeared on the wiki on May 24th, 2010 and still captures the long-term goal of the OpenStack community today.

Now that we understand a bit about enterprise virtualization, elastic cloud computing, and the origin of OpenStack, let's discuss some details about the OpenStack project.

The OpenStack Foundation was created in 2012 with the simple mission to protect, empower, and promote OpenStack software and the community around it.

Since the Foundation's initial formation, there have been more than fifteen OpenStack Summits. The OpenStack Summit is an incredible gathering of more than 5,000 software developers, CIOs, systems engineers, and technical writers from all over the world. Membership of the foundation is free and accessible to anyone; everyone from individual contributors to large enterprises are members, including companies like AT&T, Red Hat, Rackspace, Ubuntu, SUSE, Google, and IBM.

Even if you haven't used OpenStack yet, join the OpenStack Foundation! It's fast, free, and fun. https://www.openstack.org/join/ .

The OpenStack Foundation is committed to ensuring that OpenStack follows "the four opens":

1. Open source: The OpenStack source code is licensed under the Apache License Version 2.0 (APLv2). OpenStack is committed to creating truly open source software that is usable and scalable.
2. Open design: OpenStack is also committed to an open design process. Every six months, the development community meets for a Project Team Gathering (PTG) to create the roadmap for the next release. This includes brainstorming ideas, gathering requirements, and writing blueprints for upcoming releases. The PTGs are always open to the public.
3. Open development: OpenStack keeps its source code publicly available through the entire development process (https://github.com/openstack). Everything is open, including code reviews, release roadmaps, and technical discussions.
4. Open community: All processes are documented, open, and transparent. The technical governance of the project is democratic, with a community of contributors electing technical leads and members of technical committees. Project meetings are held in public IRC channels, and technical communication is primarily done through public mailing lists.

Wandering the exhibition floor of an OpenStack Summit can be extremely daunting to the OpenStack newcomer. Every major IT company appears to have some sort of OpenStack solution, and it's often difficult to decipher what is actually being offered. The best way to explain these various OpenStack offerings is by breaking them down into four distinct types. See Figure 1.2.

• Project: The OpenStack project can be found at http://github.com/openstack. This contains the publicly available source code that thousands of developers are actively committing to throughout the day. It's free to download and install yourself.
• Distributions/appliances: OpenStack is incredibly complex due to its many moving parts, and therefore difficult to deploy, manage, and support. To reduce complexity, companies and communities alike create OpenStack distributions or "appliances." These are easy, turnkey approaches to deploying OpenStack. They typically provide opinionated methods for deployment by using popular configuration management tools such as Ansible, Puppet, or Chef. They may install OpenStack directly from the project source code on GitHub, or via packages that have been developed by popular operating system communities like Ubuntu and Red Hat.
• Hosted private clouds: Customers looking for the security and reliability of a private OpenStack cloud without the need to manage it themselves should consider a hosted private cloud solution. These solutions typically use an existing OpenStack distribution and also include 24/7 customer support, with guaranteed uptime via an SLA (Service Level Agreement).
• Public clouds: There are quite a few public clouds built on OpenStack software. These include Rackspace and OVH Public Cloud. Similar to Amazon Web Services, Azure, or Google Cloud Platform, an OpenStack Public Cloud solution resides in the provider's data centers. The provider is responsible for the management of the environment, which is used by multiple customers on shared hardware.

As you can see from Figure 1.3, the need for those with OpenStack skills has been increasing over the years:

But what specific positions are available to those who know OpenStack? Let's break down a few of the different roles an individual with OpenStack skills may possess.

The application developer who understands OpenStack uses it to create virtual resources so they can deploy their applications on top of OpenStack. They typically have a background in Amazon Web Services, Azure, or Google Cloud Platform, and treat OpenStack as an Infrastructure as a Service (IaaS) platform. They are most likely full-stack developers, well-versed in all layers of web applications. They love the speed and agility of OpenStack. It allows them to instantly deploy an application when inspiration strikes and ship applications to their customers quickly and efficiently.

The OpenStack administrator or operator is the target audience for the Certified OpenStack Administrator exam. This individual typically has some years of experience as a Linux System Administrator, and is comfortable acting as the go-to individual for all OpenStack-related questions. They are responsible for managing new users, domains, and projects. They must also know how to interact with OpenStack, as well as how to train others to create virtual resources using the services installed in the environment.

An OpenStack engineer may spend a lot of their time in the datacenter working with automation tools like Puppet, Chef, and Ansible. When OpenStack needs more capacity, the OpenStack engineer is responsible for racking, stacking, and wiring up the servers, ensuring the operating systems have the latest patches, and seeing that all proper OpenStack components get the proper configuration file values, permissions, and settings. Although the Certified OpenStack Administrator exam doesn't require test takers to understand specific values for configuration files (or how to upgrade existing services), OpenStack engineers most likely know how to do this inside and out—often finding themselves working on automation scripts to ease their daily responsibilities.

The OpenStack product developer works on developing an OpenStack distribution or appliance. They understand the difficulty of building clouds; in turn, they create opinionated distributions to ease the OpenStack deployment and management process. Examples include Red Hat OpenStack Platform Director, SUSE OpenStack Cloud, and Rackspace Private Cloud. These companies may also offer professional service or support in addition to the product.

Those eager to contribute to the actual OpenStack project are known as OpenStack upstream developers. These developers develop for OpenStack—building blueprints, chatting with other OpenStack developers on IRC, attending the PTG meet-ups, and contributing code—as they to make OpenStack the ubiquitous cloud operating system. Upstream developers have an impact on the OpenStack roadmap and are part of a healthy community that strengthens enterprise adoption.

OpenStack is made up of a variety of services that are all written in the Python programming language and serve a specific function. OpenStack's modular nature facilitates the modern cloudy application design philosophy and also allows easy expandability; any person, community, or company can develop an OpenStack service that can easily integrate into its ecosystem.

The OpenStack Foundation has successfully identified nine key services they consider part of the core of OpenStack, which we'll explore in detail.

Keystone handles authentication. It acts as a common authentication system across all core services in an OpenStack environment. Both human users and services must authenticate to Keystone to retrieve a token before interacting with other services in the environment.

Visualize the process of logging on to a website with your username and password. When a user does this on the Horizon dashboard, they authenticate against Keystone to successfully login and begin creating virtual resources. Keystone also stores the service catalog, users, domains, projects, groups, roles, and quotas—exam objective concepts you'll examine in Chapter 3, Keystone Identity Service.

Glance provides discovery, registration, and delivery services for disk images.

When one boots a virtual machine (also known as an instance), it is typically required to provide a disk image. These typically contain an operating system (such as Ubuntu or Red Hat Enterprise Linux), and are best described as a snapshot of a disk's contents. Examples of disk image types include QCOW2, VMDK, VHDX, ISO, and RAW. The disk image has usually been previously created by a person or script who has gone through the initial installation procedure and has installed specific configuration files to ensure it is cloud-aware. Glance can store images in a variety of data stores, including the local filesystem or OpenStack Swift.

Inspired by Amazon EC2, Nova is the compute service and the core of the OpenStack cloud. It is designed to manage and automate pools of compute resources, and can work with widely available virtualization technologies as well as bare metal servers.

It's important to note that Nova is not a hypervisor. It's a system of services that sit above the hypervisor, orchestrating availability of compute resources. Some examples of hypervisors include Hyper-V, VMware ESXi, Xen, and the most popular, KVM (Kernel-based Virtual Machine). Nova also supports the ability to utilize Linux container technology such as LXC and Docker.

In OpenStack, the term booting is used to refer to the creation of a virtual machine. A virtual machine booted with Nova is often called an instance.

Neutron is a service that allows users to manage virtual network resources and IP addresses.

If one wants to boot an instance, they typically need to provide a virtual network on which to boot that instance so that it has network connectivity. With Neutron, users can view their own networks, subnets, firewall rules, and routers—all through the Horizon dashboard, CLI, or API. One's ability to create and manage network resources depends on the specific role they have been assigned.

Neutron also contains a modular framework powered by a variety of plugins, agents, and drivers, including Linux bridge and Open vSwitch.

Inspired by Amazon's Elastic Block Storage (EBS) offering, Cinder allows users to create volumes that can be mounted as devices by Nova instances.

Cinder volumes behave as if they were raw unformatted hard drives. Once data is written to these volumes, the data persists even after terminating the instance or an instance failure. This is because the written data is stored on a dedicated Cinder storage server, not the compute nodes where the instances reside. Cinder also supports snapshots which capture the current state of a volume. These are useful for providing backup protection, and they can also be used to instantiate new volumes that contain the exact data of the snapshot. You can also write images to a block storage devices for compute to use as a bootable persistent instance.

Inspired by Amazon S3, Swift is a redundant storage system that provides developers and IT teams with secure, durable, and highly scalable cloud storage. A user creates a container and stores static files, also known as objects, in the container. These objects can be anything from pictures or movies to spreadsheets and HTML files. From the end user's perspective, storage is limitless, inexpensive, and accessible via a REST API. Features can also be turned on via the Swift API. These include hosting a static website, versioning, setting specific objects to expire, and even setting Access Control Lists (ACLs) allowing public access to the objects inside the container.

On the backend of Swift, static files (also known as objects) are written to multiple disk drives spread throughout servers in a data center. The Swift software is responsible for ensuring data replication and integrity across the cluster. Should a server or hard drive fail, Swift replicates its contents from other active nodes to a new location in the cluster.

Inspired by Amazon's CloudFormation service, Heat helps operators model and set up OpenStack resources so that they can spend less time managing these resources and more time focusing on the applications that run on OpenStack.

You begin with a blueprint or Heat Orchestration Template (HOT) that describes all the OpenStack resources to be provisioned. Heat then takes care of provisioning and configuring, with no need to worry about dependencies or order of execution—a template describes all the resources and their parameters. After the stack has been created, your resources are up and running.

Templates are extremely convenient because they allow operators to check them into a version control system to easily track changes to the infrastructure. If problems occur after deploying a Heat template, you simply restore to a previous version of the template. If you want to make a change to the stack, you can easily update it by providing a modified template with new parameters.

Let's take a high-level look at these OpenStack services in the wild, from the perspective of the Horizon dashboard home screen. See Figure 1.4.

Let's start from the top:

• Instances: The Nova instances section is where you can manage your virtual machines. You can start, stop, pause, lock, and suspend instances—as well as create snapshots, view console logs, and log in into the instances via an interactive console. Learn more about this section in Chapter 5, Nova Compute Service.
• Volumes: In this section, you can create Cinder block volumes, snapshots, and backups. You can also attach your volumes to instances. Learn more about this section in Chapter 7, Cinder Block Storage Service.
• Images: The Glance images section is where you can see your currently available images as well as upload images and edit metadata associated with the images. Learn more about this section in Chapter 4, Glance Image Service.
• Access & Security: This section is a mix of a few services and contains four primary sections: Neutron Security Groups, Nova Keypairs, a list of Service Catalog public endpoints, and a place to download a pre-populated credential file for interacting with OpenStack with a command-line interface with the currently logged-in user. Learn more about this section in Chapter 3, Keystone Identity Service, Chapter 5, Nova Compute Service, and Chapter 6, Neutron Networking Service.
• NETWORK: In this section, you can utilize Neutron by creating tenant networks, tenant subnets, routers, and floating IPs. Learn more about this section in Chapter 6, Neutron Networking Service.
• ORCHESTRATION: Here, you can create Heat stacks by either uploading a Heat orchestration template or pasting it into the dashboard. You can also list and update existing stacks in this area. Learn more about this section in Chapter 9, Heat—Orchestration Service.
• OBJECT STORE: Create Swift containers and upload static objects such as photos, movies, and HTML files. Learn more about this section in Chapter 8, Swift—Object Storage Service.
• Admin: This admin panel only appears when the user logging in has the admin role. It features an admin-only look at all virtual resources across all domains and projects in the environment.
• Identity: This is where Keystone domains, projects, users, roles, and quotas are listed. If one has the admin role, they can do a variety of things in here, including creating new projects, adding new users to those projects, assigning roles, and modifying quotas. Learn more about this section in Chapter 3, Keystone Identity Service.

The power of OpenStack is in the REST API of each core service. These APIs can be publicly exposed and thus accessible from anywhere in the world with public internet access: a smartphone, a laptop on the coffee shop WiFi network, or remote office.

There are a variety of ways in which one can interact with OpenStack to create virtual resources from anywhere. As we work our way down these various methods, the amount of automation increases, allowing a software developer to easily create virtual resources and deploy applications on top of those resources with minimal user interaction. See Figure 1.5.

• Horizon dashboard (GUI): If you are new to OpenStack, this is the best place to begin your journey. You simply navigate to the Horizon URL via the web browser, enter your username and password, verify you are scoped to the proper project, and then proceed—creating instances, networks, and volumes with the click of a button. See Figure 1.4 for where the services are located upon first logging in. Because not all OpenStack service features are available via the Horizon dashboard, you will need to also interact with OpenStack services via the command-line interface to utilize additional functionality.

• Command-line interface (CLI): The OpenStack command line interface will unlock a majority of the OpenStack service features and can easily be installed on Windows, Mac, and Linux systems. For Linux gurus with Bash shell experience, the CLI is the tool of choice.
• Software development kit (SDK): Although the bash shell and OpenStack CLI combination are extremely powerful, SDKs provide more expressiveness. One example scenario: a developer hosting their popular application on OpenStack virtual infrastructure so that additional resources can be automatically provisioned when specific thresholds are met. Or, imagine an Android application that allows an organization's employees to create OpenStack resources with a few simple clicks of a button. Simply put, OpenStack SDKs allow you to programmatically interact with OpenStack services in the comfort of your favorite language. OpenStack SDKs are currently available in the following languages: C, C++, Closure, Erlang, Go, Java, JavaScript, .NET, Node.js, Perl, PHP, Python, and Ruby.
• Heat orchestration template (HOT): You can deploy Heat templates (similar to Amazon Web Service CloudFormation Blueprints) that utilize the OpenStack service APIs—creating OpenStack resources with the simple click of a button. The user defines their application by describing OpenStack resources in the template. The Heat templates provide maximum automation to the cloud user, deploying an entire application without manual creation of individual resources or dependencies. One can even check these into a version control system such as Git to easily track changes to the infrastructure.

Although the majority of the COA exam can be completed on the Horizon dashboard, understanding how to use the OpenStack CLI is critical if you want to pass! Although it can appear a bit unsettling to those with minimal experience, over time you'll notice that the CLI will reveal the true fun of OpenStack.

Every core OpenStack service has an associated command-line client. Like the OpenStack services, the command-line clients are written in the Python programming language (available at http://github.com/openstack). The clients also contain the service API bindings for developing Python code that can talk directly to a specific service without requiring long-winded API requests. For years, the most popular clients used by OpenStack administrators were the following:

• python-keystoneclient
• python-glanceclient
• python-neutronclient
• python-novaclient
• python-cinderclient
• python-swiftclint
• python-heatclient

Because it was quite frustrating to remember commands for each separate client, the OpenStack community created a new OpenStack client called OSC (OpenStack Client) in 2013. The actual program is named python-openstackclient and available at http://github.com/openstack/python-openstackclient.

See Figure 1.6. python-openstackclient is a CLI client for OpenStack that brings all the traditional service-based clients into a single shell with a uniform command structure. It has a consistent and predictable format for all of its commands and takes the following form:

For example, if you wanted to create a brand new Nova virtual machine instance, you could simply run:

$ openstack server create demo-instance1 --flavor m1.tiny --image cirros MyFirstInstance

You can also view help commands by running the following:

$ openstack help

Now that we've discussed the various ways in which an OpenStack operator interacts with OpenStack via the API, let's discuss internal communication among the core OpenStack services. In Figure 1.7, you can see the color code in the top left that shows the service and daemon. The service is simply the name of the OpenStack service, while the daemon represents the program that is actually running to bring the service to life.

To avoid tight coupling, communication amongst the daemons within a specific service is achieved via an Advanced Message Queueing Protocol (AMQP). In a typical OpenStack environment, this can be software such as RabbitMQ or Qpid.

Recall the cloudy development methodology that we discussed in the history portion of this chapter. While OpenStack encourages its software developers to follow this methodology when deploying applications on it, the actual OpenStack infrastructure follows the exact same principles: highly available, scalable, and loosely coupled.

For example, when a user sends a request to nova-api to boot a server, nova-api will publish this message on the AMQP bus. This message will then be read by nova-scheduler. Now let's visualize an OpenStack cloud that often receives hundreds of requests to boot instances. To solve this problem you would deploy more servers in the infrastructure, install more nova-scheduler daemons, and simply point them to the OpenStack environment's AMQP server. That's Horizontal scaling in action!

While the OpenStack service daemons rely on AMQP for communication among daemons within their specific service, the APIs are used both by OpenStack users wishing to create virtual resources and for service-to-service communication.

Envision a user sending a request to nova-api to boot an instance. In order to boot that server, quite a few internal API calls would need to take place. Let's look at an example sequence of API calls that would take place when booting a virtual machine instance.

An OpenStack user would first send a POST API call to the nova-api daemon with details about what sort of virtual machine they'd like. That message would get put on the AMQP message bus and consumed by the nova-scheduler daemon. The nova-scheduler daemon would then choose the best fit for the virtual machine using its scheduling algorithm. The nova-compute daemon residing on the compute node consumes this message. Before the server can be boot, the following must occur (see Figure 1.8):

• (1): The nova-compute daemon sends an API request to Keystone to retrieve a scoped token.
• (2): nova-compute gets back a 200 HTTP response along with a scoped token. Now nova-compute has a scoped token and can freely communicate with other OpenStack services.
• (3): nova-compute now sends a request to neutron-server to verify whether the specified virtual network on which to boot the instance is available.
• (4): nova-compute receives a response that the network is available and capable of attaching to the instance.
• (5): nova-compute must then send an API call to glance-api to retrieve the operating system image.
• (6): The glance-api responds back with the image that will reside on the compute node.

Now our instance will be booted! That was a lot of work!

Now that you've learned a bit about OpenStack, let's get down to why you're really here:

To pass the Certified OpenStack Administrator exam!

Ask anyone about getting started in the IT world and they may suggest looking into industry-recognized technical certifications. IT certifications measure competency in a number of areas and are a great way to open doors to opportunities. While they certainly should not be the only determining factor in the hiring process, achieving them can be a measure of your competence and commitment to facing challenges.

Upon achieving a passing grade, you will receive your certificate (see Figure 1.9). Laminate, frame, or pin it to your home office wall or work cubicle—it's proof that you have met all the requirements to become an official OpenStack administrator. The certification is valid for three years from the pass date, so don't forget to renew.

In addition to the certification, a COA badge will appear next to your name in the official OpenStack Community Directory, available at https://www.openstack.org/community/members/.

Let's begin by walking through some steps to become a Certified OpenStack administrator.

Practice. Practice. Practice. Use this book and the included OpenStack All-in-One Virtual Appliance as a resource as you begin your Certified OpenStack Administrator journey. If you still find yourself struggling with the concepts and objectives in this book, you can always refer to the official OpenStack documentation—or even seek out a live training class at https://www.openstack.org/marketplace/training/.

Once you feel that you're ready to conquer the exam, head to https://www.openstack.org/coa/ and click on Get Started. After signing in, you will be directed to checkout to purchase your exam. The OpenStack Foundation accepts all major credit cards, and costs $300.00 USD as of September 2017 (subject to change, so keep an eye on the website). You can also get a free retake within 12 months of the original exam purchase date if you do not pass on the first attempt.

Once your order is processed, you will receive an email with access to the COA portal. Think of the portal as your personal COA website, where you can download your exam receipt and keep track of your certification efforts. Once you take the exam, you can come back to the COA portal to check your exam status and score, and even download certificates and badges for your website or business cards.

The COA exam can be taken from your personal laptop or desktop, but you must ensure that your system meets the exam's minimum system requirements. A link on the COA portal page will present you with the compatibility check tool, which will run a series of tests to ensure you meet the requirements. It will also assist you in downloading a Chrome plugin for taking the exam. At this time, you must use the Chrome or Chromium browser and have access to reliable internet, a webcam, and microphone.

Figure 1.11 shows a current list of minimum requirements.

You must be at least 18 years old and have proper identification to take the exam. Any of the following pieces of identification are acceptable:

• Passport
• Government-issued driver's license or permit
• National identity card
• State or province-issued identity card

I recommend scheduling your exam a few months ahead of time to give yourself a realistic goal. Click on the Schedule Exam link on the COA portal to be directed and automatically logged in to the exam proctor partner website. Once logged in to the site, type OpenStack Foundation in the search box and select COA exam. You can then choose from available dates and times. The latest possible exam date you can schedule will be 30 days out from the current date. Once you have scheduled it, you can cancel or reschedule up to 24 hours before the start time of the exam.

The day has arrived! You've used this book and have practiced day and night to master all of the covered objectives. It's finally time to take the exam!

One of the most important factors determining your exam success is the location. You cannot be in a crowded place. This means no coffee shops, work desks, or football games. The testing location policy is very strict, so consider taking the exam from home or a private room in the office.

Log in to the COA portal 15 minutes before your scheduled exam time. You should now see a Take Exam link which will connect to the exam proctor partner website so you can connect to the testing environment.

Once in the exam environment, an exam proctor chat window will appear and assist you with starting your exam. You must allow sharing of your entire operating system screen (including all applications), webcam, and microphone. Once it's time to begin, you have two and a half hours to complete all exam objectives. You're almost on your way to becoming a Certified OpenStack Administrator!

The exam expects its test takers to be proficient in interacting with OpenStack via the Horizon dashboard and command-line interface. Figure 1.12 shows is a visual representation of the exam console as outlined in https://www.openstack.org/assets/coa/COA-Candidate-Handbook-V1.4.14.pdf:

The exam console is embedded into the browser. It is composed of two primary parts:

• Content Panel
• Dashboard/Terminal Panel

The Content Panel is the section that displays the exam timer and objectives. As per the COA handbook, exam objectives can only be navigated linearly. You can use the next and back button to move to each objective.

The Dashboard/Terminal Panel gives you full access to an OpenStack environment. Chapter 2, Setting Up Your Practice Exam Environment, will assist you with getting your practice OpenStack environment environment up and running so you can work through all the objectives.

The exam console terminal is embedded in a browser, and you cannot SCP (secure copy) to it from your local system. Within the terminal environment, you are permitted to install a multiplexor such as screen, tmux, or byobu if you think these will assist you, but they are not necessary for successful completion of the objectives.

You are not permitted to browse websites, email, or notes during the exam, but you are free to access https://docs.openstack.org/. However, this can be a major waste of exam time; it shouldn't be necessary after working through the exam objectives in this book. You can also easily copy and paste from the objective window into the Horizon dashboard or terminal.

If you struggle with a question, move on! Hit the Next button and try the next objective. You can always come back and tackle it before time is up.

The exam is scored automatically within 24 hours, and you should receive the results via email within 72 hours after exam completion. At this time, the results will be made available on the COA portal. Be sure to also review the Professional Code of Conduct on the OpenStack Foundation Certification Handbook.

Let's now take a look at the objectives you will be responsible for performing on the exam. As of June 2017, these are all the exam objectives published on the official COA website. These objectives will test your competence and proficiency in the domains listed. These domains cover multiple core OpenStack services as well as general OpenStack troubleshooting. Together, they make up 100% of the exam.

• Understand the components that make up the cloud
• Use the OpenStack API/CLI

• Manage Keystone catalog services and endpoints
• Manage/create domains, groups, projects, users, and roles
• Create roles for the environment
• Manage the identity service
• Verify operation of the identity service

• Deploy a new image to an OpenStack instance
• Manage image types and backends
• Manage images (for example: add, update, or remove)
• Verify operation of the Image Service

• Manage flavors
• Manage compute instance actions (such as launch, shutdown, or terminate)
• Manage Nova user keypairs
• Launch a new instance
• Shut down an instance
• Terminate an instance
• Configure an instance with a floating IP address
• Manage project security group rules
• Assign security groups to an instance
• Assign floating IP address to an instance
• Detach floating IP address from an instance
• Manage Nova host consoles (rdp, spice, tty)
• Access an instance using a keypair
• Manage instance snapshots
• Manage Nova compute servers
• Manage quotas
• Get Nova stats (hosts, services, and tenants)
• Verify operation of the compute service

• Manage network resources (such as routers and subnets)
• Create external networks
• Create project networks
• Create project routers
• Manage network services for a virtual environment
• Manage project security group rules
• Manage quotas
• Verify operation of network service
• Manage network interfaces on compute instances
• Troubleshoot network issues for a tenant network (enter namespace, run tcpdump, and so on)

• Manage a volume
• Create volume group for block storage
• Create a new block storage volume and mount it to a Nova instance
• Manage quotas
• Manage volume quotas
• Manage volume backups
• Back up and restore volumes
• Manage volume snapshots (such as take, list, and recover)
• Verify that block storage can perform snapshotting function
• Snapshot volume
• Manage volume encryption
• Set up storage pools
• Monitor reserve capacity of block storage devices
• Analyze discrepancies in reported volume sizes

• Manage access to object storage
• Manage expiring objects
• Manage storage policies
• Monitor space available for object store
• Verify operation of object storage
• Manage permissions on a container in object storage

• Launch a stack using a Heat/Orchestration template (for example, storage, network, and compute)
• Use Heat/Orchestration CLI and dashboard
• Verify Heat/Orchestration stack is working
• Verify operation of Heat/Orchestration
• Create a Heat/Orchestration template that matches a specific scenario
• Update a stack
• Obtain detailed information about a stack

• Verify operation of the dashboard

• Analyze log files
• Backup the database(s) used by an OpenStack instance
• Centralize and analyze logs (such as /var/log/COMPONENT_NAME, database server, messaging server, web server, and syslog)
• Analyze database servers
• Analyze host/guest OS and instance status
• Analyze messaging servers
• Analyze metadata servers
• Analyze network status (physical and virtual)
• Analyze storage status (local, block, and object)
• Manage OpenStack services
• Diagnose service incidents
• Digest OpenStack environment (Controller, Compute, Storage, and Network nodes)
• Direct logging of files through centralized logging system
• Back up and restore an OpenStack instance
• Troubleshoot network performance

OpenStack is an open source cloud software that provides an Infrastructure as a Service environment, allowing its users to quickly deploy applications by creating virtual resources such as virtual servers, networks, and block storage volumes. The IT industry's demand for individuals with OpenStack skills is continuing to grow, and one of the best ways to prove you have those skills is by taking the Certified OpenStack Administrator exam.

In the next chapter, we will import an All-in-One Virtual Appliance based off the Newton version of OpenStack. This appliance is an incredible learning aid, allowing us to interact with OpenStack anytime and anywhere, while working though all the exam objectives explained in this book. Get ready to become an official Certified OpenStack Administrator!