Điều gì sai với DevStack?
Nếu bạn là một OpenStack contributor, bạn có thể phụ thuộc vào DevStack cho hầu hết công việc của mình. DevStack là, và đã là trong một thời gian dài, platform de-facto mà các contributor dùng cho development, testing, và reviews. Trong bài viết này, tôi muốn giới thiệu cho bạn một dự án tôi là contributor, gọi là openstack-ansible. Trong vài tháng qua, tôi đã dùng dự án này như một lựa chọn thay thế cho DevStack cho phát triển upstream OpenStack, và trải nghiệm đã rất tích cực.
Vấn đề với DevStack
Trước khi đi sâu vào openstack-ansible, tôi muốn thảo luận ngắn gọn về lý do thúc đẩy tôi tìm lựa chọn thay thế cho DevStack. Tổng thể, DevStack là một dự án well-rounded (hoàn chỉnh), nhưng có một vài quyết định kiến trúc làm phiền tôi.
Thứ nhất, DevStack đi kèm với một monolithic installer (cài đặt nguyên khối). Để cài đặt, bạn chạy stack.sh và nó cài đặt tất cả module bạn cấu hình. Nếu sau đó bạn muốn thêm hoặc bớt module, tùy chọn duy nhất là chạy unstack.sh để gỡ cài đặt mọi thứ, và sau đó re-run stack.sh với cấu hình cập nhật. Vài lần, khi tôi thay đổi source code của một module, tôi vô tình khiến module hoạt động.erratic (không ổn định). Nếu tôi ở tình huống đó, tùy chọn an toàn nhất là cài lại nó, và cách duy nhất để làm vậy với DevStack là cài lại mọi thứ.
DevStack thực hiện development installation của tất cả module, tạo ra môi trường rất khác production deployments. Theo ý kiến của tôi, một development environment thích hợp sẽ có module tôi đang làm việc được cài cho development, với mọi thứ khác cài cho production. Điều này không thể làm được với DevStack.
Vấn đề khác tôi từng gặp với DevStack là cuộc chiến liên tục để giữ dependencies trong trạng thái consistent. Trong DevStack, dependencies được chia sẻ giữa tất cả module, nên một hành động đơn giản là sync dependencies cho một module có thể gây ra chain reaction yêu cầu cập nhật một vài module khác. Trước đây, điều này có thể được giảm bớt ở các bản DevStack gần đây với per-module virtual environments, nhưng ngay cả vậy, OS level packages vẫn được chia sẻ.
OpenStack Ansible (OSA) là gì?
Dự án openstack-ansible là một sáng kiến open source của Rackspace sử dụng sức mạnh của Ansible để triển khai OpenStack. Bạn có thể đã nghe về dự án này với tên os-ansible-deployment trên StackForge trước khi nó chuyển sang OpenStack big tent.
Giống DevStack, openstack-ansible triển khai tất cả OpenStack services trực tiếp từ git repositories của họ, không có vendor patches hoặc add-ons. Nhưng khác biệt lớn là openstack-ansible triển khai OpenStack services trong LXC containers, vì vậy có complete OS level và Python package isolation (cách ly hoàn toàn) giữa các services được host trên một node.
Khác biệt khác giữa DevStack và openstack-ansible là OSA là một production distribution. Với nó, bạn có thể triển khai enterprise scale private clouds từ một vài node đến cluster lớn với hàng trăm thậm chí hàng nghìn node.
Sơ đồ sau cho thấy cấu trúc của một openstack-ansible private cloud:
Hình ảnh sơ đồ cấu trúc OSA private cloud
Sau khi nhìn sơ đồ này, bạn có thể đang gãi đầu suy nghĩ làm sao dự án này có thể match sự đơn giản của DevStack cho upstream development, khi nó rõ ràng hướng tới multi-node private clouds. Đừng tuyệt vọng! Tôi bao gồm điều này trong phần tiếp theo.
OSA All-In-One
Các contributor của openstack-ansible dùng single-node deployment cho công việc hàng ngày và gating, vì đó thuận tiện và hiệu quả tài nguyên hơn. Với phương pháp triển khai này, có thể stand up OSA trên cloud server hoặc virtual machine, nên tận dụng tính năng này làm dự án này comparable với DevStack.
Thật không may, host requirements cho single-node deployment của OSA cao hơn DevStack, chủ yếu do overhead do container infrastructure giới thiệu. Để cài đặt usable, host phải có 16GB RAM và 80GB disk space. Lúc này, host OS duy nhất được hỗ trợ là Ubuntu 14.04.
Một lợi thế tốt của OSA so với DevStack là, nhờ kiến trúc containerized, nó có thể triển khai redundant services ngay cả trên single-node install. Trên default single-node deployment, galera, rabbitmq, và keystone được triển khai với redundancy, và HAProxy được cài trên host để làm load balancing.
Bạn sẵn sàng bốc tay vào việc? Nếu bạn có truy cập vào một fresh Ubuntu 14.04 server đáp ứng spec trên, bạn có thể clone OSA repository với các lệnh:
# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansibleBạn không cần clone project vào thư mục này. Thay vào đó, bạn có thể clone nó bất cứ đâu bạn thích.
Tiếp theo, tạo single-node configuration file. May mắn thay, project đi kèm script làm điều đó cho bạn:
# cd /opt/openstack-ansible
# scripts/bootstrap-aio.shSau khi lệnh trên chạy, thư mục /etc/openstack_deploy sẽ được populate với một số file cấu hình YAML format. Đặc biệt quan tâm là file user_secrets.yml, chứa tất cả password sẽ dùng trong cài đặt. Các password này được generate ngẫu nhiên, nên khó nhớ. Tôi thường edit admin password, vì tôi dùng nó nhiều. Cơ bản tôi đổi từ:
keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdHthành:
keystone_auth_admin_password: secreteCác password còn lại không hữu ích lắm, nên tôi để nguyên. Tuy nhiên, bạn có thể đổi bất kỳ password nào bạn nghĩ bạn có thể cần dùng thành thứ dễ nhớ.
Tiếp theo, chạy script khác cài Ansible trong host, thêm vài Ansible extras và wrapper scripts đơn giản hóa việc dùng nó:
# scripts/bootstrap-ansible.shLúc này, host sẵn sàng nhận OSA install, chạy Ansible playbooks thực hiện cài đặt:
# scripts/run-playbooks.shTrên Rackspace Public Cloud server, một full run qua tất cả playbooks mất khoảng 45 phút. Một khía cạnh hay của làm việc với Ansible là tất cả tasks đều idempotent (ng 멱等), nghĩa là playbooks có thể thực thi nhiều lần mà không gây vấn đề. Nếu task đã được thực hiện, chạy lần thứ hai không làm gì. Điều này thực sự hữu ích, vì nó làm cho việc re-configure một live system chỉ bằng cách thay đổi file cấu hình thích hợp và re-run playbooks, mà không cần tear everything down (xóa sạch mọi thứ) trước.
Tour nhanh openstack-ansible
Trong phần này, tôi muốn cho bạn cái nhìn tổng quan về cấu trúc OSA single-node, để những bạn đủ can đảm stand one up biết mọi thứ ở đâu.
Thứ nhất, Horizon dashboard được triển khai và nên truy cập được trên public IP của host. Bạn có thể dùng account admin, với password bạn nhập trong file /etc/openstack_deploy/user_secrets.yml. Nếu bạn không edit file này, bạn phải mở file và tìm setting keystone_auth_admin_password để biết password nào được dùng.
Như tôi đã nói, các server đều được cài trong LXC containers. Lệnh sau cho bạn danh sách containers:
root@miguel-lxc-server:~# lxc-ls -f
NAME STATE IPV4 IPV6 AUTOSTART
------------------------------------------------------------------------------------------------------------------------------
aio1_ceilometer_api_container-c8e825de RUNNING 10.0.3.203, 172.29.237.195 - YES (onboot, openstack)
aio1_ceilometer_collector_container-2da3371f RUNNING 10.0.3.10, 172.29.238.178 - YES (onboot, openstack)
... (danh sách đầy đủ các container) ...
aio1_utility_container-d83fab91 RUNNING 10.0.3.39, 172.29.237.161 - YES (onboot, openstack)Đi qua danh sách này, bạn thấy services nào được triển khai. Bạn có thể vào bên trong container dùng lệnh lxc-attach. Một container đặc biệt thú vị là cái có tên utility ở cuối danh sách. Để vào container này dùng lệnh:
# lxc-attach -n aio1_utility_container-d83fab91Utility container hữu ích vì nó có tất cả OpenStack command line clients cài đặt, cộng với file openrc sẵn sàng cho admin account. Trong ví dụ session sau, tôi dùng tiện ích openstack để truy vấn danh sách user trong triển khai của tôi:
root@miguel-lxc-server:~# lxc-attach -n aio1_utility_container-d83fab91
root@aio1_utility_container-d83fab91:~# source openrc
root@aio1_utility_container-d83fab91:~# openstack user list
+----------------------------------+--------------------+
| ID | Name |
+----------------------------------+--------------------+
| 2257ddc66d4c41ba8500114944cbb852 | dispersion |
| 22f1824610b34eb2a6cfaba09b8feb93 | ceilometer |
...
| b2b90c7eed704c63bbc8ea0eb23f43c4 | admin |
| bd3eed1e0cf54b93a0d7c6a7849be778 | stack_domain_admin |
+----------------------------------+--------------------+Để thoát container và về host, gõ exit hoặc Ctrl-D.
Đây là tính năng hay khác của Ansible: nó cho phép bạn reinstall một service, như cái bị corrupt trong development bởi nhầm lẫn. Để làm vậy, đơn giản destroy container bị ảnh hưởng:
# lxc-stop -n <container-name>
# lxc-destroy -n <container-name>Sau khi container bị bệnh bị destroy, chạy playbooks một lần nữa sẽ khiến một container fresh được tạo ra như replacement, trong một phần nhỏ thời gian so với cài đặt mọi thứ từ đầu.
Development Workflow (Quy trình phát triển)
Bạn chắc chắn muốn biết tôi dùng OSA all-in-one deployment như thế nào để thay thế DevStack, về mặt thực tế. Quy trình bao gồm vài bước đơn giản:
- Triển khai OSA-AIO: Mọi thứ bắt đầu bằng triển khai single-node openstack-ansible cloud. Tôi thường dùng Rackspace Public Cloud server làm host, nhưng bạn có thể dùng bất kỳ Ubuntu 14.04 host nào với spec tôi liệt kê.
- Attach vào target container: Tôi vào container chạy service tôi muốn làm việc, dùng
lxc-attach. Nếu làm việc trên service deployed với redundancy, tôi trước hết edit HAProxy config để chỉ để một container active. Các container còn lại dùng làm backup nếu có vấn đề với cái được chọn. - Dừng target service: Container đang chạy production version của service tôi định làm việc. Vì service này không dùng cho tôi, tôi dừng nó bằng lệnh chuẩn
service <name> stop. Ví dụ, nếu tôi ở heat-engine container, tôi chạyservice heat-engine stop. - Clone development version: Bây giờ tôi có container sẵn sàng chạy target service, nên tôi clone code thực tế tôi sẽ làm việc. Tôi có thể dùng official git repository, fork của tôi với custom changes, hoặc patch từ Gerrit nếu tôi làm review.
- Cập nhật dependencies: Development version có thể yêu cầu set dependencies khác so với version cài bởi Ansible playbooks, nên để an toàn, tôi chạy
pip install -r requirements.txttrong container. Vì OSA tạo private Python package repository riêng, required version của package có thể không available trong nó. Khi đó, tôi setno-index = Falsetrong file /root/.pip/pip.conf của container để enable access đến pypi, và thử lại. - Sync database: Sự khác biệt có thể giữa version gốc cài với OSA và development version của tôi là database migrations, nên tôi luôn sync database, phòng khi nào. Lệnh làm việc này khác nhẹ giữa services, nhưng thường yêu cầu invoke management script với option
db_sync. Ví dụ, khi làm việc với Keystone, lệnh sync database làkeystone-manage db_sync. - Thay đổi config files gốc nếu cần: Playbooks tạo config files cho tất cả services, nên trong hầu hết trường hợp, cấu hình để lại trong thư mục /etc bởi installer có thể dùng không đổi cho development. Nếu tôi cần custom changes liên quan đến công việc, tôi làm thủ công với text editor.
- Chạy thủ công, hoặc cài đặt và chạy như service: Cuối cùng, development version có thể khởi động. Để làm dễ dàng, chỉ chạy Python application trực tiếp. Ví dụ, nếu tôi làm việc trên heat-engine service, tôi có thể chạy
bin/heat-enginetừ root directory của project để start service ở foreground, với logs ra terminal. Để dừng service, tôi có thể Ctrl-C, giống như DevStack.Terminal friendly debuggers như pdb (command line) hoặc pudb (interactive) có thể cài trong containers và hoạt động tốt. Remote debugging qua ssh từ host đến container cũng khả thi, nếu bạn thích debuggers phức tạp hơn như PyCharm.
Đối với hầu hết services, chạy thủ công đủ để làm việc thoải mái như DevStack. Ngoại lệ duy nhất là services không chạy Python scripts trực tiếp, như Keystone, thường chạy dưới Apache. Dù Apache dùng trong production, cho development hoàn toàn an toàn chạy Python application trực tiếp, sẽ chạy eventlet based web server. Nếu vì lý do nào muốn dùng Apache, thì lựa chọn thay thế là cài development version bằng
python setup.py installvà restart Apache đã cài vớiservice apache2 restart. Cũng có thể chạy application từ source directory bằngpython setup.py developvà thêm home directory vào Apache site config file.
OSA-AIO: The Pros (Ưu điểm)
Làm việc với OSA thay vì DevStack là trải nghiệm mostly pleasant (chủ yếu dễ chịu) cho tôi. Không còn dependency conflicts nữa là tuyệt vời, vì với OSA, nếu tôi cần rebase một service và nó yêu cầu dependencies mới, các service khác không bị ảnh hưởng trong container của chúng.
Tôi cũng thấy tôi hiếm khi cần recreate toàn bộ deployment từ đầu. Tôi thường làm vậy khi muốn upgrade toàn bộ hệ thống lên release OpenStack mới, nhưng cho ngày thường, tôi thấy dễ dàng làm local updates hoặc repairs cho cài đặt hiện có. Tôi thích khả năng destroy một container và sau đó Ansible regenerate nó cho tôi mà không chạm đến các service còn lại.
Cuối cùng, tôi thực sự thích OSA cho phép tôi chọn phần nào của hệ thống cài làm development packages, trong khi giữ phần còn lại của OpenStack cloud cài và cấu hình cho production use.
OSA-AIO: The Cons (Nhược điểm)
Tất nhiên, như mọi thứ, có khía cạnh làm việc với OSA không hay, nên tôi muốn cho bạn phía đó của câu chuyện.
OSA là dự án trẻ (young project), và, như vậy, nó không có wide community support (hỗ trợ cộng đồng rộng) như DevStack. Điều này đặc biệt quan trọng nếu bạn làm việc trên module không ở core của OpenStack. Lúc tôi viết này, OSA hỗ trợ triển khai Keystone, Nova, Neutron, Glance, Cinder, Swift, Heat, Ceilometer và Horizon. Nếu bạn muốn làm việc trên module không trong danh sách này, OSA có thể không hữu ích cho bạn. Но с другой стороны, nếu bạn muốn tạo Ansible playbook cho module hiện không được hỗ trợ, bạn sẽ được đón nhận với open arms (hai tay mở).
Nói chung, có khá nhiều configuration options exposed as Ansible variables cho tất cả module, với một exception (ngoại lệ). Khi nói đến Neutron, configuration không flexible. Network tunnels qua containers và VMs luôn được cấu hình dùng Linux Bridge. Ví dụ, nếu bạn cần làm việc với Open vSwitch, bạn phải manually modify configuration sau khi chạy playbooks, điều này không vui. Cũng không có Neutron plugins nào được hỗ trợ lúc này.
Kết luận
Tôi hy vọng bạn thấy workflow của tôi với openstack-ansible thú vị để học và dùng. Nó đã tiết kiệm thời gian cho tôi khi làm việc trên Heat upstream features và bug fixes. Tôi cũng đã heavily relied (phụ thuộc nhiều) vào OSA để debug và troubleshoot Keystone federation.
Nếu bạn quan tâm dùng OSA, tôi cũng khuyến khích bạn làm một chút searching, vì đó sẽ dẫn bạn đến nhiều bài viết và blog posts hơn (như bài này hoặc bài khác), nơi các OpenStack contributor khác giải thích cách họ incorporate OSA vào workflow của họ.