OpenStack’e Başlangıç: Temel Kavramlar, Mimari ve İlk Kurulum

Bir yazılım ekibinin yeni bir test ortamına ihtiyacı olduğunu düşünün: birkaç sanal makine, bunları birbirine bağlayan bir ağ ve verilerin tutulacağı diskler. Her talepte sunucu, ağ ve depolama ayarlarını tek tek yapmak yerine, ekip bu kaynakları bir panelden veya API üzerinden oluşturabilseydi ne olurdu?

OpenStack, bu tür bir altyapıyı kurmanıza yardımcı olur. Bu makalede önce temel kavramları ve servislerin birlikte nasıl çalıştığını öğrenecek, ardından tek bir Linux makinesinde laboratuvar kurup ilk sanal makinenizi başlatacaksınız.

Hedef kitle: Temel Linux komutlarına aşina, bulut altyapılarına yeni başlayan okuyucular.

Örnek ortam: Ubuntu Server 24.04 LTS, x86_64 ve DevStack’in stable/2026.1 dalı. 6 Eylül 2026 itibarıyla OpenStack 2026.1 Gazpacho, bakımı sürdürülen bir sürümdür. İleride uygularken işletim sistemi ve sürüm uyumluluğunu yeniden kontrol edin. OpenStack sürüm tablosu

1. OpenStack nedir?

OpenStack; işlemci, bellek, depolama ve ağ kaynaklarını API üzerinden yönetilebilir bir bulut altyapısına dönüştüren açık kaynaklı servisler bütünüdür. Temel kullanım modeli Infrastructure as a Service — IaaS, yani hizmet olarak altyapıdır. Kullanıcılar kendilerine ayrılan yetki ve kotalar içinde kaynak oluşturabilir. OpenStack’e genel bakış

Örneğin bir geliştirici, bir işletim sistemi imajı seçip “2 vCPU, 4 GB RAM ve bir özel ağ” talep edebilir. OpenStack bu talebi fiziksel altyapıdaki uygun kaynaklarla karşılamak için servislerini koordine eder. Geliştirici, sanal makinenin hangi fiziksel sunucuda çalışacağını genellikle seçmek zorunda kalmaz.

OpenStack’i anlamak için sanallaştırma ile bulut yönetimi arasındaki ilişkiyi görmek gerekir. KVM/QEMU sanal makineleri çalıştırır; OpenStack bu makinelerin oluşturulmasını, kaynak yerleşimini, ağlarını ve erişim yetkilerini yönetir. Nova bu amaçla hipervizör sürücülerinden yararlanır. Nova mimarisi

Bu yaklaşım, örneğin geliştirme ekiplerine ortak bir özel bulut sunarken faydalıdır. Ekipler ayrı projelerde çalışır, altyapı ekibi ise toplam kapasiteyi ve erişim politikalarını yönetir.

2. Başlamadan önce bilmeniz gereken kavramlar

| Kavram | Anlamı | Basit örnek | | --- | --- | --- | | Instance | Oluşturulmuş sanal makine | Bir test sunucusu | | Image | Makinenin başlangıç imajı | Ubuntu veya CirrOS imajı | | Flavor | İşlemci, RAM ve disk kaynak profili | 1 vCPU, 512 MB RAM | | Project | Kaynakların ve yetkilerin gruplandığı kapsam | gelistirme projesi | | Network / Subnet | Sanal ağ ve bu ağın IP adresleme bilgileri | Bir ağ ve 10.20.0.0/24 alt ağı | | Port | Bir cihazın sanal ağa bağlantısını temsil eden nesne | VM’nin IP ve MAC adresi bulunan bağlantısı | | Router | Ağlar arasında yönlendirme sağlayan mantıksal kaynak | Özel ağın dış ağa bağlantısı | | Floating IP | Uygun ağ kurulumunda VM’nin sabit IP’sine eşlenen dış ağ adresi | Dışarıdan SSH için kullanılan adres | | Security group | Portlara uygulanan trafik izin kuralları | TCP 22 erişimine izin vermek | | Volume | Sanal makineye bağlanabilen blok depolama birimi | 20 GB veri diski | | Key pair | VM’ye SSH erişimi için kullanılan anahtar çifti kaydı | Açık anahtarın OpenStack’e kaydedilmesi | | Quota | Bir projenin tüketebileceği kaynakların sınırı | En fazla 10 VM |

Bu terimleri bir talepte birleştirelim: “demo projesinde, bir CirrOS image kullanarak, küçük bir flavor ile bir instance oluştur; bunu özel bir network üzerine bağla.” OpenStack sözlüğü, Neutron ağ kavramları

3. OpenStack’in temel servisleri

Her servis belirli bir sorumluluk üstlenir. Bu modüler yapı, ihtiyacınız olan özellikleri seçmenizi ve kapasiteyi farklı alanlarda artırmanızı sağlar.

| Servis | Temel görevi | Yanıtladığı soru | | --- | --- | --- | | Keystone | Kimlik doğrulama, proje/rol bilgileri ve servis kataloğu | Kullanıcı kim, hangi servisleri kullanabilir? | | Nova | Sanal makinelerin yaşam döngüsünü yönetmek | Makine nerede ve nasıl çalıştırılacak? | | Placement | Kaynak envanteri, kullanım ve tahsis bilgilerini tutmak | Talebi karşılayabilecek kaynaklar hangileri? | | Glance | İmajları ve imaj metaverisini yönetmek | Hangi işletim sistemi imajı kullanılacak? | | Neutron | Ağ, subnet, port, router ve ağ politikalarını yönetmek | Makine ağa nasıl bağlanacak? | | Cinder | Blok depolama birimlerini yönetmek | VM’ye hangi kalıcı disk bağlanacak? | | Swift | Nesne depolama sunmak | Dosya ve nesneler API üzerinden nasıl saklanacak? | | Horizon | Web tabanlı yönetim arayüzü sunmak | Kaynakları tarayıcıdan nasıl yöneteceğim? |

Tabloyu servislerin resmi tanımlarıyla birlikte okuyabilirsiniz: Keystone, Nova, Placement, Glance, Neutron, Cinder, Swift, Horizon.

Placement ile Nova Scheduler’ın görevleri farklıdır: Placement kaynak adayları ve tahsis bilgilerini sağlar; Nova Scheduler adayları değerlendirerek uygun compute sunucusunu seçer. Nova zamanlama akışı

İmaj, volume ve nesne depolama arasındaki fark

Bir imajı, yeni bilgisayara kuracağınız başlangıç şablonu gibi düşünebilirsiniz. Volume, çalışan makineye bağladığınız disktir. Swift’teki nesne ise uygulamanın API ile yüklediği bir fotoğraf, arşiv veya başka bir veri parçası olabilir.

Cinder volume’ları VM’den bağımsız bir yaşam döngüsüne sahip olabilir. Ancak VM silindiğinde bağlı diskin korunup korunmayacağı, bağlantıdaki delete_on_termination ayarına da bağlıdır. Ayrıca snapshot almak ile bağımsız bir yedekleme düzeni kurmak farklı ihtiyaçları karşılar. Cinder belgeleri, Compute API — block device mapping

4. Mimari: yönetim kararları ve çalışan iş yükleri

Mimariyi iki açıdan incelemek faydalıdır:

• Kontrol düzlemi — control plane: API istekleri, kimlik doğrulama, kaynak seçimi ve yapılandırma işlemleri.
• Veri düzlemi — data plane: Sanal makinelerin çalışması, uygulama paketlerinin taşınması ve disk verisinin okunup yazılması.

Örneğin “bir ağ oluştur” talebi kontrol işlemidir. O ağ üzerinden iki VM’nin haberleşmesi ise veri trafiğidir. Ağın gerçek uygulaması OVN/Open vSwitch gibi bileşenlere ve seçilen sürücülere bağlıdır. Neutron veri merkezi ağları

Aşağıdaki diyagram, servislerin ilişkisini kavramsal olarak gösterir. Bütün API çağrılarını, veritabanlarını ve ağ yollarını içermez.

Kesik çizgiler yapılandırma ilişkisini belirtir. VM’nin uygulama trafiği Keystone veya Nova API üzerinden geçmez. Disk verisinin yolu da depolama sürücüsüne göre değişir; Cinder API bir veri aktarım geçidi gibi düşünülmemelidir. Nova mimarisi, Cinder mimarisi

Servisler hangi sunucularda çalışır?

| Düğüm rolü | Tipik sorumluluk | | --- | --- | | Controller | API servisleri, kimlik yönetimi, zamanlama ve koordinasyon | | Compute | nova-compute, hipervizör ve sanal makineler | | Network / Gateway | Seçilen ağ mimarisinde dış ağ erişimi ve yönlendirme işlevleri | | Storage | Seçilen depolama sisteminin diskleri ve servisleri |

Bu rollerin her biri için ayrı bir fiziksel sunucu zorunlu değildir. Laboratuvarda hepsi aynı makinede bulunabilir. Daha büyük ortamlarda kapasite ve arıza dayanımı ihtiyacına göre dağıtılır. Ağ işlevlerinin bir bölümü compute düğümlerinde de çalışabilir. Örnek düğüm mimarisi

Servisler ayrıca SQL veritabanları ve RabbitMQ gibi destek bileşenlerinden yararlanır. Burada bütün bulutun tek bir ortak veritabanından oluştuğunu düşünmemek gerekir: servisler kendi verilerini yönetir; Nova’da API ve cell veritabanları gibi ek ayrımlar vardır. Nova Cells v2

5. Bir sanal makine oluşturulduğunda ne olur?

Kullanıcı panelde “Launch Instance” düğmesine bastığında arka planda birden fazla servis çalışır:

Bu, sadeleştirilmiş bir akıştır. Gerçek çağrı sırası; imajdan veya volume’dan açılışa, sürücülere ve ağ tasarımına göre değişebilir. İşlem asenkrondur: API’nin talebi kabul etmesi, VM’nin hemen kullanıma hazır olduğu anlamına gelmez. ACTIVE durumu da konuk işletim sisteminde SSH servisinin hazır olduğunu tek başına kanıtlamaz. Nova mimarisi, sunucu durumları ve işlemleri

6. Hangi kurulum yöntemiyle başlamalı?

Başlangıç için bu makalede DevStack kullanacağız. DevStack, OpenStack servislerini kaynak kodlarından kuran, geliştirme ve test odaklı bir araçtır. Temel servisleri tek makinede görmeyi kolaylaştırır. Ubuntu 24.04, resmi başlangıç belgesinde en çok test edilen seçenek olarak belirtilir. DevStack başlangıç rehberi

Üretim ortamı planlarken Kolla-Ansible gibi dağıtım ve işletim araçları değerlendirilir. Kolla-Ansible, OpenStack servislerini container’lar içinde dağıtır. Böyle bir kurulumda ağ, depolama, erişilebilirlik ve yükseltme tasarımı ayrıca yapılır. Kolla-Ansible

Kurulumun kapsamı: Aşağıdaki adımlar yalnızca bu iş için ayrılmış, temiz bir Linux VM veya sunucuda uygulanmalıdır. DevStack işletim sistemi ve ağ üzerinde kapsamlı değişiklikler yapar. Bu laboratuvar üretim kurulumu değildir. DevStack kurulum uyarısı

7. Laboratuvarı hazırlama

Bu çalışma için pratik bir başlangıç profili:

| Kaynak | Bu makale için öneri | | --- | --- | | İşletim sistemi | Ubuntu Server 24.04 LTS, x86_64 | | CPU | 4 vCPU veya daha fazla | | Bellek | 16 GB RAM; daha fazla VM için ek bellek | | Disk | En az 80 GB kullanılabilir SSD alanı | | Sanallaştırma | Erişilebilir KVM; VM içinde kurulumda nested virtualization | | Ağ | İnternet erişimi, çalışan DNS ve değişmeyen yönetim IP’si |

Bu değerler evrensel resmi minimumlar değil, küçük bir öğrenme ortamı için öneridir. Açacağınız VM’ler de aynı makinenin kaynaklarını tüketir.

Tüm kurulum komutları Ubuntu makinesinin terminalinde çalıştırılacaktır. macOS veya Windows kullanıyorsanız önce bu özelliklerde uygun bir Linux ortamı sağlayın.

Mevcut durumu inceleyin:

uname -m
free -h
df -h /
ip -br address
ip route
ls -l /dev/kvm

/dev/kvm görünmüyorsa sanallaştırma desteğini ve VM kullanıyorsanız üst hipervizörde nested virtualization ayarını kontrol edin. QEMU emülasyonu bir seçenek olsa da KVM’ye göre daha yavaştır. DevStack ve iç içe sanallaştırma

Örnekte yönetim adresini 192.168.1.50 kabul ediyoruz. Bunu kendi Ubuntu makinenizin IP’siyle değiştireceksiniz. Yönetim ağı, VPN ağları, VM ağı 10.20.0.0/24 ve floating IP ağı 172.24.4.0/24 birbiriyle çakışmamalıdır. DevStack ağ yapılandırması

8. DevStack’i adım adım kurma

Adım 1: Gerekli başlangıç araçlarını yükleyin

Mevcut sudo yetkili Ubuntu kullanıcınızla:

sudo apt update
sudo apt install -y git curl ca-certificates openssh-client

Adım 2: Kurulumu çalıştıracak kullanıcıyı oluşturun

Temiz makinede stack isimli kullanıcıyı oluşturup gerekli sudo erişimini verin:

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 chmod 440 /etc/sudoers.d/stack
sudo visudo -cf /etc/sudoers.d/stack
sudo -u stack -i

Bu kullanıcı, DevStack kurulumu için geniş sistem yetkilerine sahiptir. Bundan sonraki komutları stack kullanıcısının Bash oturumunda çalıştırın. stack.sh doğrudan root olarak çalıştırılmaz. DevStack kullanıcı hazırlığı

Adım 3: DevStack kaynak kodunu indirin

git clone --branch stable/2026.1 https://opendev.org/openstack/devstack
cd /opt/stack/devstack

Burada stable/2026.1 dalını açıkça seçiyoruz. Bu seçim sürüm ailesini belirler; dal zaman içinde düzeltmeler alabileceği için tek başına birebir aynı kurulum çıktısını garanti etmez. DevStack 2026.1 kaynak kodu

Adım 4: local.conf dosyasını hazırlayın

Önce 192.168.1.50 adresini kendi yönetim IP’nizle değiştirin. Ardından aşağıdaki bloğu terminale girin:

umask 077
cat > local.conf <<'EOF'
[[local|localrc]]
HOST_IP=192.168.1.50

IPV4_ADDRS_SAFE_TO_USE=10.20.0.0/24
FLOATING_RANGE=172.24.4.0/24
PUBLIC_NETWORK_GATEWAY=172.24.4.1

LOGFILE=/opt/stack/logs/stack.sh.log
LOG_COLOR=False
EOF

Devamında parolayı terminal geçmişine yazmadan alın ve dosyaya ekleyin. Bu laboratuvarda DevStack’in uyumluluk önerisine uyarak yalnızca harf ve rakam kullanın:

read -r -s -p 'Uzun bir lab parolasi girin (yalnizca harf ve rakam): ' LAB_PASSWORD
printf '\n'
if [[ "$LAB_PASSWORD" =~ ^[a-zA-Z0-9]{20,}$ ]]; then
    printf 'ADMIN_PASSWORD=%s\n' "$LAB_PASSWORD" >> local.conf
    cat >> local.conf <<'EOF'
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
EOF
else
    printf 'En az 20 karakterlik, yalnizca harf ve rakam iceren parola girin. Bu blogu tekrarlayin.\n'
fi
unset LAB_PASSWORD
chmod 600 local.conf

Hata mesajı aldıysanız parola bloğunu geçerli bir değerle tekrarlayın. Parola dosyada düz metin tutulur; dosyayı paylaşmayın. Aynı parolanın farklı servislerde kullanılması burada yalnızca laboratuvarı basitleştirir. DevStack parola ayarları

HOST_IP API erişim adresini, IPV4_ADDRS_SAFE_TO_USE özel VM ağını, FLOATING_RANGE ise floating IP havuzunu belirler. Bu örnekte fiziksel ağ kartını Neutron’a devreden PUBLIC_INTERFACE ayarı kullanılmaz; DevStack’in tek makine laboratuvar ağı korunur. Yapılandırma seçenekleri, DevStack ağı

Adım 5: Kurulumu başlatın

./stack.sh

Paketler, imajlar ve servis kaynakları indirilir; ağ ve servis ayarları hazırlanır. Süre, makinenin ve internet bağlantısının hızına göre değişir. Kurulum başarıyla bittiğinde ekranda erişim bilgileri gösterilir. DevStack kurulum adımı

Adım 6: Paneli açın ve servisleri kontrol edin

Kurulumun sonunda yazdırılan Horizon adresini tarayıcıda açın. Bu adres genellikle http://192.168.1.50/dashboard biçimindedir; kurulum çıktısındaki URL’yi esas alın. Kullanıcı adı admin, parola ise belirlediğiniz ADMIN_PASSWORD değeridir. Yönetim IP’sine tarayıcınızdan ulaşabilmeniz gerekir.

Komut satırını hazırlayın:

cd /opt/stack/devstack
if [ -f /opt/stack/data/venv/bin/activate ]; then
    source /opt/stack/data/venv/bin/activate
fi
source openrc admin admin

openstack token issue
openstack service list
openstack compute service list
openstack hypervisor list

Python sanal ortamını etkinleştiren bölüm, istemcinin DevStack’in kendi ortamına kurulduğu durumu kapsar. openrc ise istemciye kimlik bilgilerini sağlar. DevStack openrc, 2026.1 ortam varsayılanları

Token üretilebilmeli, servisler listelenmeli ve nova-compute satırı normal durumda enabled / up görünmelidir. Bunlar ilk kontrollerdir; VM oluşturma denemesi işlevsel doğrulamayı tamamlar. OpenStack Compute komutları

9. İlk sanal makinenizi oluşturun

Bu bölümde küçük bir CirrOS test makinesi oluşturacağız. Komutları sırayla, aynı stack oturumunda çalıştırın.

Adım 1: Küçük bir kaynak profili oluşturun

Admin kimliğiyle:

openstack flavor create --vcpus 1 --ram 512 --disk 1 lab.small
source openrc demo demo
openstack image list
openstack network list

Artık günlük kaynak işlemlerini demo kullanıcısı ve projesiyle yapıyoruz. Listede durumu active olan, x86_64 mimarisine uygun CirrOS disk imajını ve private / public ağlarını bulun. Bu kaynaklar varsayılan DevStack laboratuvarında hazırlanır. DevStack ile ilk VM

İmaj kimliğini kopyalayıp aşağıdaki soruya yapıştırın:

read -r -p 'CirrOS imajinin ID degerini girin: ' IMAGE_ID
openstack image show "$IMAGE_ID"

Adım 2: SSH anahtarı ve erişim kuralları ekleyin

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/openstack-lab -N ''
openstack keypair create --public-key ~/.ssh/openstack-lab.pub lab-key

openstack security group create lab-ssh
openstack security group rule create --protocol tcp --dst-port 22 --remote-ip 172.24.4.0/24 lab-ssh
openstack security group rule create --protocol icmp --remote-ip 172.24.4.0/24 lab-ssh

Bu örnek anahtar parolasızdır ve yalnızca laboratuvar içindir; özel anahtar dosyasını paylaşmayın. Aynı dosya daha önce oluşturulmuşsa üzerine yazmayın. Güvenlik kuralları SSH ve ping girişini laboratuvarın floating IP ağıyla sınırlar. Havuzu değiştirdiyseniz kuralları da uyarlayın. Güvenlik grubu komutları

Adım 3: VM’yi başlatın

openstack server create \
  --image "$IMAGE_ID" \
  --flavor lab.small \
  --network private \
  --key-name lab-key \
  --security-group lab-ssh \
  --wait \
  ilk-vm

openstack server show ilk-vm

Başarılı durumda sunucu ACTIVE olur. ERROR görürseniz sonraki adıma geçmeden hata ayrıntısını inceleyin. Sunucu oluşturma komutu

Adım 4: Floating IP atayın ve bağlanın

FIP=$(openstack floating ip create public -f value -c floating_ip_address)
openstack server add floating ip ilk-vm "$FIP"
openstack server list
ping -c 3 "$FIP"
ssh -i ~/.ssh/openstack-lab "cirros@$FIP"

Bu bağlantıyı DevStack’in kurulu olduğu Ubuntu makinesinden başlatın. CirrOS’un açılması ve SSH servisinin hazır olması biraz zaman alabilir. DevStack SSH erişimi

public adı veya “floating IP” ifadesi, adresin internette yönlendirildiği anlamına gelmez. Bu örnekte 172.24.4.0/24 yerel bir laboratuvar ağıdır. Başka bir bilgisayardan erişim için yönlendirme, VPN, SSH geçidi veya uygun fiziksel ağ bağlantısı gerekir. Panelin açılması ile VM’nin floating IP’sine erişebilmek ayrı ağ yollarıdır. DevStack uzaktan erişim seçenekleri

SSH bağlantısı kurulduğunda imaj seçimi, kaynak tahsisi, VM başlatma, ağ ve anahtar erişimi birlikte denenmiş olur. Konuk VM’den çıkmak için exit yazın.

10. Sorun çıktığında nereden başlamalı?

Hatanın görüldüğü katmana odaklanın:

| Belirti | İlk kontrol | | --- | --- | | openstack: command not found | DevStack Python ortamının etkin olduğunu kontrol edin. | | Kimlik doğrulama hatası | Doğru kullanıcı/proje için source openrc ... çalıştırın; Keystone erişimini kontrol edin. | | VM ERROR durumunda | server show içindeki hata bilgisini, kapasiteyi ve compute loglarını inceleyin. | | No valid host | Flavor gereksinimleri, kaynak envanteri ve compute servis durumunu kontrol edin. | | VM ACTIVE, SSH çalışmıyor | Floating IP, rota, güvenlik grubu, kullanıcı adı, anahtar ve konuk açılışını inceleyin. | | Kurulum paket indirirken duruyor | DNS, internet erişimi, disk alanı ve kurulum logunu kontrol edin. | | Yeniden başlatma sonrası laboratuvar çalışmıyor | Systemd servislerini ve sanal ağları kontrol edin; DevStack’i üretim yaşam döngüsü aracı gibi değerlendirmeyin. |

Örnek inceleme komutları:

openstack server show ilk-vm
openstack console log show ilk-vm
openstack port list --server ilk-vm
openstack floating ip list
openstack security group rule list lab-ssh

sudo systemctl --failed
sudo systemctl list-units 'devstack@*' --all
sudo journalctl -u [email protected] -n 100 --no-pager
ls -lt /opt/stack/logs/

Servis birimi adlarını list-units çıktısından doğrulayın. DevStack servis logları systemd journal içinde bulunur; kurulum logu ise yapılandırdığınız log dizinine yazılır. DevStack systemd ve log inceleme

11. Üretim ortamına geçerken yaklaşım nasıl değişir?

Laboratuvarın amacı servislerin birlikte çalışmasını öğrenmektir. Üretimde ise “tek sunucu bozulursa ne olur?”, “veri nasıl geri yüklenir?” ve “sürüm nasıl yükseltilir?” sorularına da yanıt gerekir.

Örneğin API servislerinin birden fazla controller üzerinde çalışması için yük dengeleme ve servis durumunun korunması tasarlanır. Veritabanı ve mesajlaşma sistemlerinin kendi süreklilik ihtiyaçları bulunur. Compute kapasitesi artırılırken ağ ve depolama darboğazları da ölçülür. VM’lerin bulunduğu sunucunun kaybından sonra nasıl kurtarılacağı ayrıca planlanır; controller yedekliliği bunu tek başına çözmez.

Kurulum planınız; IP adreslerini, ağ arayüzlerini, depolama arka ucunu, sürüm uyumluluğunu, erişim yetkilerini, izlemeyi ve geri yükleme yöntemini kapsamalıdır. Kolla-Ansible’ın genel akışı, ortam ve inventory hazırlığı, yapılandırma/parolalar, host hazırlığı, ön kontroller, dağıtım ve dağıtım sonrası kontrollerden oluşur. all-in-one seçeneği ise tek başına yüksek erişilebilirlik sağlamaz. Kolla-Ansible dağıtım rehberi

İlk laboratuvardan sonra öğrenmeyi şu uygulamalarla sürdürebilirsiniz:

1. İkinci bir VM oluşturup özel IP’ler üzerinden iletişim kurun; gereken security group kuralını tanımlayın.
2. Bir Cinder volume oluşturup VM’ye bağlayın; VM ile volume yaşam döngülerini ayrı ayrı gözlemleyin.
3. Yeni bir proje ve kullanıcı oluşturarak kaynak görünürlüğünü ve kotaları inceleyin.
4. Ağ, subnet ve router kaynaklarını elle oluşturarak hazır laboratuvar topolojisini yeniden kurun.
5. Ayrı bir ortamda Kolla-Ansible ile dağıtım ve işletim akışını öğrenin.

Her denemede aynı soruyu sorun: Bu işlemi hangi servis yönetiyor ve sorun çıkarsa hangi katmanı incelemeliyim? Bu bağlantıyı kurabildiğinizde OpenStack’in çok sayıdaki servisi, anlaşılır bir bütün oluşturmaya başlar.

---

Hazırlanma ve kaynak kontrol tarihi: 6 Eylül 2026. Komutlar resmi belgeler ve DevStack’in ilgili sürüm kaynak koduyla karşılaştırılmıştır; bu makale hazırlanırken bir OpenStack ortamında uçtan uca kurulum çalıştırılmamıştır. Diyagramların görsel gösterimi için Mermaid destekleyen bir Markdown görüntüleyici gerekir.