home

หน้าแรก
 Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

การเปลี่ยนจาก DevStack ไป OpenStack Ansible: ประสบการณ์พัฒนาที่ราบรื่น

ปัญหาของ DevStack

OpenStack Contributors ใช้ DevStack มานานเป็น De-facto Platform สำหรับ Development, Testing, Reviews แต่มี Architectural Decisions ที่รบกวน:

  1. Monolithic Installer: รัน stack.sh Install ทุก Modules configured เพิ่ม/ลบ Modules ต้อง unstack.sh (Uninstall All) → stack.sh ใหม่ Source Code Changes ทำ Module Erratic → Safest = Reinstall All
  2. Dev Environment ≠ Production: DevStack Install ทุก Modules แบบ Development ไม่แยก Module ที่ทำงานอยู่ (Dev) กับที่เหลือ (Production-like)
  3. Dependency Conflicts: Dependencies Shared ทุก Modules Sync Dependencies Module หนึ่ง → Chain Reaction Update Modules อื่นๆ แม้ Per-module Virtual Envs (Recent) OS-level Packages ยัง Shared

OpenStack-Ansible (OSA) คืออะไร?

Rackspace Open Source Initiative ใช้ Ansible Deploy OpenStack (ก่อนหน้า: os-ansible-deployment บน StackForge) Deploy OpenStack Services จาก Git Repositories โดยตรง ไม่มี Vendor Patches/Add-ons

ความแตกต่างสำคัญ:

  • Deploy Services ใน LXC Containers → Complete OS-level และ Python Package Isolation ระหว่าง Services บน Node เดียวกัน
  • Production Distribution: Deploy Enterprise-scale Private Clouds (Handful Nodes ถึง Hundreds/Thousands)

OSA All-In-One (AIO)

Contributors ใช้ Single-node Deployment สำหรับ Daily Work และ Gating (Convenient, Resource Efficient) Stand up OSA บน Cloud Server/VM

Host Requirements (สูงกว่า DevStack):

  • 16GB RAM, 80GB Disk Space
  • Host OS: Ubuntu 14.04 (เวลานั้น)

ข้อได้เปรียบ OSA over DevStack:

  • Containerized Architecture → Deploy Redundant Services บน Single-node ได้: Galera, RabbitMQ, Keystone Redundant + HAProxy บน Host Load Balance

Quick Start OSA-AIO

# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible
# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh  # Generate Single-node Config (/etc/openstack_deploy)
# แก้ไข /etc/openstack_deploy/user_secrets.yml (Passwords) เช่น keystone_auth_admin_password
# scripts/bootstrap-ansible.sh  # Install Ansible + Extras + Wrapper Scripts
# scripts/run-playbooks.sh  # Run Ansible Playbooks (~45 mins on Rackspace Cloud)

Ansible Idempotent: รัน Playbooks ซ้ำได้ ไม่ทำลาย ระบบ Live Reconfigure ได้โดยแก้ Config → Re-run Playbooks

Quick Tour OSA Single-node Structure

Horizon Dashboard บน Public IP ของ Host Login: admin / Password จาก user_secrets.yml

Services ทั้งหมดใน LXC Containers:

# lxc-ls -f
# รายการ Containers: aio1_galera_container-x3, aio1_rabbit_mq_container-x3, aio1_keystone_container-x2, aio1_horizon_container-x2, aio1_nova_*, aio1_neutron_*, aio1_cinder_*, aio1_glance, aio1_heat_*, aio1_ceilometer_*, aio1_swift_proxy, aio1_memcached, aio1_utility, aio1_repo_container-x2, aio1_rsyslog

Utility Container (aio1_utility_container-xxx) มี OpenStack CLI Clients + openrc File Ready:

# lxc-attach -n aio1_utility_container-xxx
# source openrc
# openstack user list  # แสดง Users ใน Deployment

Reinstall Service ที่ Corrupted:

# lxc-stop -n 
# lxc-destroy -n 
# รัน Playbooks อีกครั้ง → Fresh Container แทนที่ (เร็วกว่า Reinstall All)

Development Workflow กับ OSA

  1. Deploy OSA-AIO (Rackspace Cloud Server หรือ Ubuntu 14.04 Host)
  2. Attach Target Container: lxc-attach เข้า Container Service ที่จะงาน หาก Service มี Redundancy → Edit HAProxy ให้เหลือ 1 Active Container
  3. Stop Target Service: service stop (เช่น heat-engine)
  4. Clone Development Version: Git Repo (Official, Fork, หรือ Gerrit Patch)
  5. Update Dependencies: pip install -r requirements.txt ใน Container หา Package ไม่เจอใน Private Repo → Set no-index = False ใน /root/.pip/pip.conf Enable PyPI
  6. Sync Database: ใช้ Management Script + db_sync (เช่น keystone-manage db_sync)
  7. Modify Config Files หากจำเป็น: Playbooks สร้าง Configs ใน /etc มักใช้ได้เลย Custom Changes แก้ Manual
  8. Run Manually หรือ Install as Service:
    • Manual: รัน Python App ตรงๆ (เช่น bin/heat-engine) Logs ไป Terminal Ctrl-C หยุดได้
    • Debuggers: pdb, pudb ใน Container Remote Debug SSH จาก Host ได้
    • Services ที่ไม่รัน Python Direct (เช่น Keystone ใต้ Apache): รัน Python App ตรงๆ OK (Eventlet) หรือ python setup.py install → service apache2 restart หรือ python setup.py develop + Apache Config

OSA-AIO: The Pros

  • No Dependency Conflicts (Containers Isolated)
  • Rarely Recreate Whole Deployment (Local Updates/Repairs ง่าย)
  • Destroy Container → Ansible Regenerate ใหม่โดยไม่แตะ Services อื่น
  • เลือกได้ว่า Part ไหน Install เป็น Dev Packages ส่วนที่เหลือ Production-ready

OSA-AIO: The Cons

  • Young Project: Community Support น้อยกว่า DevStack (สำคัญถ้า Work บน Non-core Modules)
  • Supported Modules (เวลานั้น): Keystone, Nova, Neutron, Glance, Cinder, Swift, Heat, Ceilometer, Horizon ไม่รองรับ Module อื่น → OSA ไม่ใช้ได้
  • Neutron Configuration ไม่ Flexible: Network Tunnels = Linux Bridge เท่านั้น Open vSwitch = Manual Modify หลัง Playbooks Neutron Plugins ไม่รองรับ

สรุป

OSA Workflow ช่วยประหยัดเวลาใน Heat Upstream Features/Bug Fixes และ Keystone Federation Debugging สนใจ OSA ค้นหา Articles/Blog Posts เพิ่มเติมจาก Contributors อื่นๆ ที่นำ OSA ไปใช้ใน Workflow ของพวกเขา