Learn OpenStack - Production Deployment with Kolla-Ansible

#Introduction

Up to episode 13, all learning ran on DevStack — an environment designed for experimentation, not production workloads. Starting with episode 14, you enter the last and most important phase: production deployment. The tool isn't the stack.sh script, it's Kolla-Ansible.

Episode 14 answers the big questions: why DevStack isn't enough, what Kolla-Ansible is and why it has become the deployment standard, how the node topology is arranged, and how the entire deployment process runs — from the globals.yml configuration and inventory setup to kolla-ansible deploy.

#Why DevStack Isn't Suitable for Production

#DevStack's Limits

DevStack has a noble but narrow goal: building a complete OpenStack environment as fast as possible for development. The consequences:

• All services on a single node: no separation between control plane and compute.
• No HA: no redundancy for the database, message queue, or APIs.
• No isolation: services run directly on the host, not in containers.
• No update management: no safe upgrade path.

For production, you need a deployment that's reproducible, containerized, and upgradeable — that's exactly what Kolla-Ansible provides.

#Production Deployment Criteria

A production deployment must be able to answer yes: can services be split across nodes, is there HA for critical components, can upgrades be done without downtime, and is the whole configuration documented as code? DevStack fails on every point; Kolla-Ansible answers all of them.

#Introducing Kolla-Ansible

#Services in Docker, Orchestration via Ansible

Kolla-Ansible is OpenStack's official deployment tool, combining two technologies:

• Docker: every OpenStack service (Keystone, Nova, Neutron, and others) is packaged into official container images from Kolla.
• Ansible: playbooks orchestrate pulling images, configuring, and starting services across all nodes.

Kolla-Ansible (Ansible playbooks)
        ↓ orchestrate
Node Controller → keystone-api, nova-api, mariadb containers
Node Compute    → nova-compute container
Node Network    → neutron-agents container

The result: consistent deployment across all nodes, the same images everywhere, and simple rollback — change the image tag, run the upgrade.

#Key Advantages

Kolla-Ansible is widely used in production because it's: containerized, making isolation and image distribution easy, declarative, since configuration lives in version-controlled files, HA-ready, with components like Galera and RabbitMQ clusters, and battle-tested, since it's OpenStack's official release path.

#Deployment Topology

#All-in-One for an Advanced Lab

The all-in-one topology runs every role (control, compute, network, storage) on a single host. It isn't for real production, but it bridges the gap from DevStack to multi-node — the same Kolla-Ansible configuration, only the inventory differs.

#Multi-Node for Production

The multi-node topology separates roles onto different hosts:

Controllers are usually tripled for HA. This separation is what makes the cluster resilient to a single node failing — we'll design this topology in full in episode 20.

#The Kolla-Ansible Deployment Process

#Preparing the Inventory

Deployment starts with an inventory file defining the node groups:

[control]
controller01 ansible_host=10.0.0.11
controller02 ansible_host=10.0.0.12
controller03 ansible_host=10.0.0.13
 
[compute]
compute01 ansible_host=10.0.0.21
compute02 ansible_host=10.0.0.22
 
[network]
network01 ansible_host=10.0.0.31
 
[storage]
storage01 ansible_host=10.0.0.41

The file above is an example of the multinode inventory — each node goes into its role's group. Ansible then uses this file to place services on the right nodes.

#Configuring globals.yml

globals.yml is the center of the deployment configuration:

kolla_base_distro: "ubuntu"
openstack_release: "caracal"
network_interface: "ens192"
kolla_internal_vip_address: "10.0.0.99"
enable_heat: "yes"
enable_cinder: "yes"
enable_octavia: "yes"

The commands above show the configuration pattern: kolla_base_distro and openstack_release determine the images, network_interface points to the management NIC, and the enable_* flags turn on services as needed. Every enabled service is deployed by the playbooks.

#From Bootstrap to Deploy

The deployment process runs in sequence:

kolla-ansible -i multinode bootstrap-servers
kolla-ansible -i multinode prechecks
kolla-ansible -i multinode deploy
kolla-ansible -i multinode post-deploy

kolla-ansible -i multinode deploy is the heart of the process — it creates every service container on all nodes. After post-deploy, generate the admin credentials:

source /etc/kolla/admin-openrc.sh
openstack service list

The output of openstack service list shows all services running as containers — proof that your production cluster is alive.

#Summary

Episode 14 takes you out of the lab: understanding DevStack's limitations for production, meeting Kolla-Ansible as the deployment tool that packages OpenStack in Docker and orchestrates it via Ansible, choosing between the all-in-one or multi-node topology, and running the deployment flow from globals.yml and inventory through bootstrap, prechecks, deploy, and post-deploy.

Key takeaways:

• DevStack is for learning, Kolla-Ansible is for production.
• Kolla-Ansible = Docker services + Ansible orchestration.
• Multi-node separates control, compute, network, and storage.
• globals.yml determines the images and which services are enabled.
• Deployment flow: bootstrap, prechecks, deploy, post-deploy.
• kolla-ansible -i multinode deploy is the heart of the process.

In episode 15, we'll cover Production Networking: Provider Networks, VXLAN & DVR — laying out a dual-NIC design for nodes, mapping provider networks to physical VLANs, isolating tenants with the VXLAN overlay, and using the Distributed Virtual Router to eliminate the bottleneck at a centralized network node.