How to Install & Set Up OpenStack

Prerequisites

• ✓A dedicated Linux host (Ubuntu 22.04/24.04 LTS or CentOS Stream 9 recommended) — a 64-bit install, kept minimal so OpenStack has room to breathe
• ✓For a real proof-of-concept: a controller node (roughly 1 CPU / 4 GB RAM / 5 GB disk) plus at least one compute node (roughly 1 CPU / 2 GB RAM / 10 GB disk); an all-in-one lab wants 8 GB RAM / 2 vCPUs minimum, 16 GB+ if you intend to keep it around
• ✓Two NICs per node if you're following the standard reference layout: one for a private management network, one for the public/provider network
• ✓A non-root user with sudo privileges, outbound internet access, and automatic OS updates disabled (they can quietly break a running cloud)

What is OpenStack?

OpenStack is an open source Infrastructure-as-a-Service platform built from a set of independent, cooperating services rather than one monolithic program. Compute (Nova), Networking (Neutron), Identity (Keystone), the Image service (Glance), and Block/Object Storage (Cinder/Swift) each expose their own REST API and can be installed piecemeal — you don't have to run every service to have a working cloud.

Every service authenticates through Identity and talks to the others over those public APIs (an AMQP message broker, RabbitMQ by default, handles the internal chatter, and each service keeps its state in a shared SQL database). End users reach the cloud through the Horizon web dashboard, the openstack CLI, or by hitting the REST APIs directly.

For a first install, DevStack builds a throwaway, single-node cloud from source in minutes. For anything you plan to keep running, Kolla-Ansible — which packages every service as a container and drives the rollout with Ansible — is the most widely used deployment method today.

Reference architecture: what a cloud is actually made of

A minimal OpenStack layout has two kinds of node. The controller runs Identity, Image, Placement, the management/API pieces of Compute and Networking, plus the supporting cast — SQL database, message queue, and NTP. One or more compute nodes run the actual hypervisor (KVM by default) and a Networking agent that wires instances into virtual networks and enforces their security groups.

Two optional node types round things out: a Block Storage node holding the disks that Cinder hands to instances as volumes, and (in pairs, minimum) Object Storage nodes holding the disks Swift uses for account/container/object data. Both are commonly folded into the controller for a lab and split out for anything real.

The reference topology keeps two network segments apart on purpose: a private management network (every node's admin traffic, DB/queue access, package installs) and a routable provider network (what instances actually get exposed on). DevStack and Kolla-Ansible automate most of this wiring, but it's worth understanding before you hand it to a tool.

Pick a networking model before you install

Neutron gives you a choice between two virtual networking approaches, and it's much easier to decide before you deploy than to switch afterward.

• •Provider networks — the simpler option. Neutron just bridges virtual networks straight onto your physical network with VLAN segmentation and leans on your existing routers for layer-3. Fast to stand up, but there's no tenant self-service networking and no load-balancer/firewall-as-a-service on top of it.
• •Self-service networks — layers tenant-owned private networks over the provider network using an overlay (VXLAN) plus NAT-based routing. Users can spin up their own isolated networks without touching the underlying infrastructure, and it's the prerequisite for LBaaS/FWaaS-style add-ons later.

Environment prerequisites (manual/from-source installs)

DevStack and Kolla-Ansible handle all of this for you automatically, but if you're ever installing OpenStack services by hand — or just want to know what's happening under the hood — every node needs a few supporting pieces in place first: clocks kept in sync with chrony/NTP, the distro's OpenStack package repository enabled, and (on the controller) a shared SQL database, a RabbitMQ message queue, Memcached for Identity token caching, and etcd for distributed locking.

sudo apt install -y chrony        # Debian/Ubuntu
sudo dnf install -y chrony        # RHEL / CentOS Stream
sudo systemctl enable --now chronyd 2>/dev/null || sudo systemctl enable --now chrony

# RHEL / CentOS Stream 9 — via the RDO project
sudo dnf install -y centos-release-openstack-caracal

# Ubuntu 22.04 / 24.04 LTS — via the Ubuntu Cloud Archive
sudo add-apt-repository -y cloud-archive:caracal

sudo rabbitmqctl add_user openstack RABBIT_PASS
sudo rabbitmqctl set_permissions openstack ".*" ".*" ".*"

Option A — All-in-one lab with DevStack

DevStack builds a complete single-node cloud from source. Run it as a dedicated stack user, never as root.

sudo useradd -s /bin/bash -d /opt/stack -m stack
sudo chmod +x /opt/stack
echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
sudo -u stack -i

git clone https://opendev.org/openstack/devstack
cd devstack
cat > local.conf <<'EOF'
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
EOF

./stack.sh

Option B — Production with Kolla-Ansible

Kolla-Ansible runs each OpenStack service in a Docker container and orchestrates the deployment with Ansible.

python3 -m venv /opt/kolla
source /opt/kolla/bin/activate
pip install -U pip
pip install 'ansible-core>=2.16,<2.18'
pip install git+https://opendev.org/openstack/kolla-ansible@stable/2024.2

kolla-ansible install-deps
sudo mkdir -p /etc/kolla
cp -r /opt/kolla/share/kolla-ansible/etc_examples/kolla/* /etc/kolla
# edit /etc/kolla/globals.yml, then:
kolla-genpwd
kolla-ansible bootstrap-servers -i ./inventory
kolla-ansible deploy -i ./inventory

Verify the installation

The Horizon dashboard is reachable at the host IP once services report as up.

source openrc admin admin
openstack service list
openstack endpoint list
openstack server list

Launch a test instance

Once services are up, the fastest way to prove the cloud actually works is to stand up a provider network, a cheap flavor, an SSH keypair, and a security group rule or two, then boot something on it. The CirrOS test image (tiny, pre-baked into DevStack) is perfect for this.

openstack network create --share --external \
  --provider-physical-network provider \
  --provider-network-type flat provider

openstack subnet create --network provider \
  --allocation-pool start=203.0.113.101,end=203.0.113.250 \
  --dns-nameserver 8.8.4.4 --gateway 203.0.113.1 \
  --subnet-range 203.0.113.0/24 provider

openstack flavor create --id 0 --vcpus 1 --ram 64 --disk 1 m1.nano

ssh-keygen -q -N ""
openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey

openstack security group rule create --proto icmp default
openstack security group rule create --proto tcp --dst-port 22 default

openstack server create --flavor m1.nano --image cirros \
  --nic net-id=PROVIDER_NET_ID --security-group default \
  --key-name mykey provider-instance

Firewall considerations

If a restrictive firewall sits in front of your nodes, each service needs its own port opened. The ones you'll hit immediately: Identity on 5000, Image on 9292, Compute's API on 8774 (plus the noVNC console proxy on 6080), Networking on 9696, Block Storage on 8776, and the Horizon dashboard on 80/443. RabbitMQ (5672) and your SQL database (3306 for MySQL/MariaDB) only need to be reachable between nodes, never from outside.

Related Guides