Nếu bạn là người đóng góp cho OpenStack, bạn có thể dựa vào DevStack cho hầu hết công việc của mình. DevStack là và đã có từ lâu, là nền tảng phi thực tế mà những người đóng góp sử dụng để phát triển, thử nghiệm và đánh giá. Trong bài viết này, tôi muốn giới thiệu với bạn một dự án mà tôi là người đóng góp, có tên làopenstack-ansible. Trong vài tháng qua, tôi đã sử dụng dự án này như một giải pháp thay thế cho phát triển ngược dòng của DevStack cho OpenStack và trải nghiệm rất khả quan.
DevStack có chuyện gì?
Trước khi đi sâu vào openstack-ansible, tôi muốn thảo luận ngắn gọn về những lý do đã thúc đẩy tôi tìm kiếm một giải pháp thay thế cho DevStack. Nhìn chung, DevStack là một dự án hoàn hảo, nhưng có một vài quyết định về kiến trúc khác với tôi.
Trước hết, DevStack đi kèm với một trình cài đặt nguyên khối. Để thực hiện gỡ cài đặt, bạn chạy stack.sh và cài đặt tất cả các mô-đun bạn đã định cấu hình. để gỡ cài đặt mọi thứ, rồi chạy lại stack.sh với cấu hình cập nhật. Một vài lần, khi tôi thực hiện các thay đổi mã nguồn đối với một mô-đun, tôi đã vô tình làm cho mô-đun đó hoạt động theo cách vô thức. Nếu tôi ở trong tình huống đó, tùy chọn an toàn nhất là cài đặt lại nó và cách duy nhất để làm điều đó với DevStack là cài đặt lại mọi thứ.
DevStack thực hiện cài đặt phát triển tất cả các mô-đun, điều này tạo ra một môi trường rất khác với việc triển khai sản xuất. Theo ý kiến của tôi, một môi trường phát triển thích hợp sẽ có mô-đun tôi đang làm việc được cài đặt để phát triển, với mọi thứ khác được cài đặt để sản xuất. Điều này không thể thực hiện vớiDevStack.
Một vấn đề khác mà tôi từng gặp phải với DevStack là cuộc chiến liên tục để duy trì sự phụ thuộc ở trạng thái nhất quán. Trong DevStack, các phần phụ thuộc được chia sẻ giữa tất cả các mô-đun, vì vậy một hành động đơn giản là đồng bộ các phần phụ thuộc cho một mô-đun có thể gây ra phản ứng dây chuyền yêu cầu cập nhật một số mô-đun khác. Ở một mức độ nào đó, điều này có thể được giảm bớt trong các bản phát hành DevStack gần đây với việc sử dụng môi trường ảo đa mô-đun, nhưng, ngay cả với điều đó, các gói cấp hệ điều hành vẫn được chia sẻ.
openstack-ansible (OSA) là gì?
Dự án openstack-ansible là một sáng kiến mã nguồn mở Rackspace sử dụng sức mạnh củaAnsible để triển khai OpenStack. Bạn có thể đã nghe nói về dự án này với tên os-ansible-deploy trên StackForge trước khi nó chuyển đến lều lớn OpenStack.
Giống như DevStack, openstack-ansible triển khai tất cả các dịch vụ OpenStack trực tiếp từ kho lưu trữ git của họ mà không cần bất kỳ bản vá lỗi hoặc tiện ích bổ sung nào của nhà cung cấp. Nhưng điểm khác biệt lớn là openstack-ansible triển khai các dịch vụ OpenStack trong LXCcontainers, do đó, có mức độ hệ điều hành hoàn chỉnh và cách ly gói Python giữa các dịch vụ được lưu trữ trên anode.
Một sự khác biệt khác giữa DevStack và openstack-ansible là latteris là một bản phân phối sản xuất. Với nó, bạn có thể triển khai các đám mây riêng quy mô doanh nghiệp bao gồm từ một số ít các nút đến một cụm lớn với hàng trăm hoặc hàng nghìn sự kiện của các nút.
Sơ đồ sau đây cho thấy cấu trúc của một privatecloud có thể mở được:
Sau khi nhìn vào điều này, có lẽ bạn đang vò đầu suy nghĩ làm thế nào mà dự án này phù hợp với sự đơn giản của DevStack để phát triển ngược dòng, vì rõ ràng nó được định hướng cho các đám mây riêng nhiều nút. Đừng tuyệt vọng! Đề cập đến vấn đề này trong phần tiếp theo.
OSA Tất cả trong Một
Những người đóng góp cho dự án openstack-ansible sử dụng việc triển khai một nút cho công việc hàng ngày và cho việc kiểm soát, bởi vì điều đó sẽ thuận tiện hơn và hiệu quả hơn về tài nguyên. Với phương pháp triển khai này, có thể hỗ trợ OSA trên máy chủ đám mây hoặc máy ảo, do đó, lợi thế của tính năng này khiến dự án này có thể so sánh với DevStack.
Thật không may, các yêu cầu máy chủ để triển khai một nút của OSA cao hơn DevStack, chủ yếu là do chi phí do cấu trúc khung chứa đưa vào. Để cài đặt có thể sử dụng được, máy chủ lưu trữ phải có 16GB RAM và 80GB dung lượng ổ đĩa. Tại thời điểm này, hệ điều hành máy chủ duy nhất được hỗ trợ là Ubuntu14.04.
Một ưu điểm tuyệt vời mà OSA có so với DevStack là, nhờ vào kiến trúc được kiểm soát, nó có thể triển khai các dịch vụ dự phòng ngay cả khi cài đặt asingle-node. Trên triển khai một nút mặc định, galera, Rabbitmq và andkeystone được triển khai với khả năng dự phòng và HAProxy được cài đặt trong máy chủ lưu trữ để thực hiện việc cân bằng tải.
Bạn đã sẵn sàng để có được bàn tay của bạn bẩn? Nếu bạn có quyền truy cập vào máy chủ Ubuntu14.04 mới đáp ứng các thông số kỹ thuật được đề cập ở trên, bạn có thể sao chép OSArepository bằng các lệnh sau:
# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible
Bạn không cần sao chép dự án vào thư mục này. Thay vào đó, bạn có thể sao chép ở bất kỳ đâu bạn muốn.
Tiếp theo, tạo một tệp cấu hình một nút. May mắn thay, dự án đi kèm với một tập lệnh thực hiện điều đó cho bạn:
# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh
Sau khi lệnh trên chạy, thư mục / etc / openstack_deploy sẽ được phổ biến với một số tệp cấu hình ở định dạng YAML. Mối quan tâm đặc biệt là tệp user_secrets.yml , chứa tất cả các mật khẩu sẽ được sử dụng trong cài đặt của bạn. Những mật khẩu này được tạo ngẫu nhiên, vì vậy chúng rất khó nhớ. Tôi thường chỉnh sửa mật khẩu quản trị, vì tôi sử dụng nó rất nhiều. Về cơ bản, tôi thay đổi điều này:
keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdH
về điều này:
keystone_auth_admin_password: secrete
Các mật khẩu còn lại không hữu ích cho lắm, vì vậy tôi để lại chúng. Tuy nhiên, bạn có thể thay đổi bất kỳ mật khẩu nào mà bạn nghĩ rằng bạn có thể cần để sử dụng mật khẩu nào đó dễ nhớ.
Tiếp theo, hãy chạy một tập lệnh khác cài đặt Ansible trong máy chủ, cùng với một số tính năng bổ sung Ansible và tập lệnh trình bao bọc giúp đơn giản hóa việc sử dụng:
# scripts/bootstrap-ansible.sh
Tại thời điểm này, máy chủ đã sẵn sàng nhận cài đặt OSA, chạy các sách phát Ansible tiến hành cài đặt:
# scripts/run-playbooks.sh
Trên máy chủ Rackspace Public Cloud, quá trình chạy đầy đủ tất cả các playbook mất khoảng 45 phút để hoàn thành. Một khía cạnh tuyệt vời của việc làm việc với Ansible là tất cả các tác vụ đều không có giá trị, có nghĩa là các playbook có thể được thực thi nhiều lần mà không gây ra bất kỳ sự cố nào. Nếu một nhiệm vụ đã được thực hiện, chạy nó lần thứ hai sẽ không có tác dụng gì. Điều này thực sự rất hữu ích, vì nó giúp bạn có thể định cấu hình lại một hệ thống trực tiếp chỉ bằng cách thay đổi các tệp cấu hình thích hợp và chạy lại playbook mà không cần phải chia nhỏ mọi thứ trước.
Tham quan nhanh openstack-ansible
Trong phần này, tôi muốn cung cấp cho bạn cái nhìn tổng quan về cấu trúc nút đơn OSA, để những người trong số bạn đủ dũng cảm đứng lên biết mọi thứ ở đâu.
Trước hết, bảng điều khiển Horizon được triển khai và sẽ có thể truy cập được trên địa chỉ IP công khai của máy chủ. Bạn có thể sử dụng quản trị viên tài khoản, với mật khẩu mà bạn đã nhập trong /etc/openstack_deploy/user_secrets.yml Nếu bạn không chỉnh sửa tệp này, bạn phải mở tệp này và tìm keystone_auth_admin_password cài đặt để tìm ra mật khẩu nào đã được sử dụng.
Như tôi đã đề cập ở trên, các máy chủ đều được cài đặt trong các thùng chứa LXC. Lệnh Thefollowing hiển thị cho bạn danh sách các vùng chứa:
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)
aio1_cinder_api_container-88e59c04 RUNNING 10.0.3.125, 172.29.238.106, 172.29.247.183 - YES (onboot, openstack)
aio1_cinder_scheduler_container-69d2bec4 RUNNING 10.0.3.4, 172.29.239.79 - YES (onboot, openstack)
aio1_galera_container-2f36d624 RUNNING 10.0.3.95, 172.29.237.18 - YES (onboot, openstack)
aio1_galera_container-3b8e14d7 RUNNING 10.0.3.18, 172.29.237.166 - YES (onboot, openstack)
aio1_galera_container-618973ae RUNNING 10.0.3.82, 172.29.238.189 - YES (onboot, openstack)
aio1_glance_container-4b41140f RUNNING 10.0.3.21, 172.29.237.77, 172.29.246.233 - YES (onboot, openstack)
aio1_heat_apis_container-40ec9f3e RUNNING 10.0.3.193, 172.29.239.6 - YES (onboot, openstack)
aio1_heat_engine_container-36e270c9 RUNNING 10.0.3.171, 172.29.239.171 - YES (onboot, openstack)
aio1_horizon_container-3497588e RUNNING 10.0.3.33, 172.29.239.114 - YES (onboot, openstack)
aio1_horizon_container-6cac5348 RUNNING 10.0.3.30, 172.29.238.168 - YES (onboot, openstack)
aio1_keystone_container-821e7cf8 RUNNING 10.0.3.38, 172.29.238.105 - YES (onboot, openstack)
aio1_keystone_container-d63c657e RUNNING 10.0.3.69, 172.29.239.208 - YES (onboot, openstack)
aio1_memcached_container-8baf34d5 RUNNING 10.0.3.158, 172.29.237.135 - YES (onboot, openstack)
aio1_neutron_agents_container-21b819b7 RUNNING 10.0.3.233, 172.29.239.130, 172.29.240.182 - YES (onboot, openstack)
aio1_neutron_server_container-b4279bbe RUNNING 10.0.3.52, 172.29.239.216 - YES (onboot, openstack)
aio1_nova_api_metadata_container-79faf41a RUNNING 10.0.3.60, 172.29.239.110 - YES (onboot, openstack)
aio1_nova_api_os_compute_container-fed67563 RUNNING 10.0.3.231, 172.29.239.17 - YES (onboot, openstack)
aio1_nova_cert_container-72f66c56 RUNNING 10.0.3.155, 172.29.237.152 - YES (onboot, openstack)
aio1_nova_conductor_container-7d0f1b0f RUNNING 10.0.3.164, 172.29.239.144 - YES (onboot, openstack)
aio1_nova_console_container-62af2918 RUNNING 10.0.3.106, 172.29.238.236 - YES (onboot, openstack)
aio1_nova_scheduler_container-e6b79b3b RUNNING 10.0.3.250, 172.29.236.153 - YES (onboot, openstack)
aio1_rabbit_mq_container-0e0fe308 RUNNING 10.0.3.86, 172.29.239.93 - YES (onboot, openstack)
aio1_rabbit_mq_container-a4a04124 RUNNING 10.0.3.253, 172.29.237.188 - YES (onboot, openstack)
aio1_rabbit_mq_container-b9c6dce6 RUNNING 10.0.3.22, 172.29.238.111 - YES (onboot, openstack)
aio1_repo_container-6a8377fc RUNNING 10.0.3.102, 172.29.237.47 - YES (onboot, openstack)
aio1_repo_container-b92c563a RUNNING 10.0.3.223, 172.29.239.251 - YES (onboot, openstack)
aio1_rsyslog_container-a6e4f7d4 RUNNING 10.0.3.170, 172.29.237.249 - YES (onboot, openstack)
aio1_swift_proxy_container-9f0130d3 RUNNING 10.0.3.20, 172.29.237.227, 172.29.247.52 - YES (onboot, openstack)
aio1_utility_container-d83fab91 RUNNING 10.0.3.39, 172.29.237.161 - YES (onboot, openstack)
Bằng cách xem qua danh sách này, bạn có thể thấy những dịch vụ nào đã được triển khai. Bạn đặt bên trong một vùng chứa bằng cách sử dụng lxc-attachment yêu cầu. Vùng chứa đặc biệt thú vị là vùng chứa có tiện ích tên ở cuối danh sách. Để vào vùng chứa này, đây là lệnh bạn nên sử dụng:
# lxc-attach -n aio1_utility_container-d83fab91
Vùng chứa tiện ích rất hữu ích vì nó đã cài đặt tất cả các dòng lệnh OpenStack, cộng với một openrc sẵn sàng tệp cho tài khoản quản trị. Trong phiên ví dụ sau, tôi sử dụng openstack tiện ích truy vấn danh sách người dùng 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 |
| 271f9bd069b2440ebb27c8f460bb3bcf | neutron |
| 2ecb372f6563410ab8138625c45a72e3 | heat |
| 35a7c9373ff640c4ba768963c1f53f02 | keystone |
| 37041c2377c44f5cb84ffafee5bfed6f | cinder |
| 4b7f43c7c2cc443889cd6b5d90a30e49 | glance |
| 6ee6a4abb7e64b3d801f2653efb9c9ec | swift |
| 9b375e06cb0a481a8ed2f94e28e1cb39 | nova |
| b2b90c7eed704c63bbc8ea0eb23f43c4 | admin |
| bd3eed1e0cf54b93a0d7c6a7849be778 | stack_domain_admin |
+----------------------------------+--------------------+
Để thoát khỏi vùng chứa và quay lại máy chủ, hãy nhập exit hoặc nhấnCtrl-D.
Đây là một tính năng hay khác của Ansible:nó cho phép bạn cài đặt lại một dịch vụ, chẳng hạn như một dịch vụ đã bị hỏng trong quá trình phát triển bymistake. Để thực hiện việc này, chỉ cần phá hủy vùng chứa bị ảnh hưởng:
# lxc-stop -n <container-name>
# lxc-destroy -n <container-name>
Sau khi thùng chứa bị bệnh bị phá hủy, việc chạy playbook thêm một lần nữa sẽ khiến một cuốn sách mới được tạo ra để thay thế, trong một khoảng thời gian ngắn sẽ có thể cài đặt mọi thứ lại từ đầu.
Quy trình phát triển
Bạn chắc chắn muốn biết cách tôi sử dụng triển khai OSA tất cả trong một để thay thế cho DevStack, về mặt thực tế. Quá trình này bao gồm một vài bước đơn giản:
-
Triển khai OSA-AIO
Rõ ràng, mọi thứ bắt đầu với việc triển khai một openstack-ansiblecloud một nút. Tôi thường sử dụng máy chủ Rackspace Public Cloud làm máy chủ lưu trữ của mình, nhưng bạn có thể sử dụng máy chủ Ubuntu 14.04 bất kỳ với các thông số kỹ thuật mà tôi đã liệt kê ở trên.
-
Đính kèm vào vùng chứa đích
Sau đó, tôi vào bên trong vùng chứa chạy dịch vụ mà tôi muốn làm việc, sử dụng
lxc-attachmentlệnh tôi đã hiển thị ở trên. Nếu tôi định làm việc trên aservice đã được triển khai dự phòng, trước tiên tôi chỉnh sửa cấu hình HAProxycon để chỉ để lại một vùng chứa hoạt động. Các vùng chứa còn lại có thể được sử dụng làm bản sao lưu nếu có sự cố với vùng đã chọn. -
Dừng dịch vụ mục tiêu
Vùng chứa đang chạy phiên bản sản xuất của dịch vụ mà tôi dự định làm việc. Bởi vì dịch vụ này không có ích gì đối với tôi, tôi dừng nó bằng cách sử dụng
dịch vụtiêu chuẩn yêu cầu. Ví dụ:nếu tôi đang ở trong thùng chứa động cơ nhiệt, tôi sẽ chạystop dịch vụ dừng động cơ nhiệt. -
Phiên bản phát triển nhân bản
Bây giờ tôi có một vùng chứa được chuẩn bị để chạy dịch vụ đích, vì vậy tôi có thể ép xung mã thực mà tôi sẽ làm việc. Đối với điều này, tôi có thể sử dụng kho lưu trữ git chính thức, fork của tôi với các thay đổi tùy chỉnh hoặc có thể là một bản vá từ Gerrit, nếu tôi đang thực hiện đánh giá.
-
Cập nhật phần phụ thuộc
Phiên bản phát triển có thể yêu cầu một tập hợp phụ thuộc khác với phiên bản đã được cài đặt bởi Ansible playbooks, vì vậy, để đảm bảo an toàn, Irun
pip install -r sources.txttrong thùng chứa. Vì OSA tạo kho lưu trữ gói Python riêng tư, nên một phiên bản gói ứng dụng bắt buộc có thể không có sẵn trong đó. Khi điều đó xảy ra, tôi đặtno-index =Falsetrong vùng chứa /root/.pip/pip.conf tệp để cho phép truy cập pypi và sau đó thử lại. -
Đồng bộ hóa cơ sở dữ liệu
Một sự khác biệt có thể có giữa phiên bản gốc được cài đặt với OSA và phiên bản phát triển của tôi là trong việc di chuyển cơ sở dữ liệu, vì vậy tôi luôn đồng bộ hóa cơ sở dữ liệu, đề phòng. Lệnh để thực hiện việc này hơi khác nhau giữa các dịch vụ, nhưng nó thường yêu cầu gọi tập lệnh quản lý bằng
db_syncquyền mua. Ví dụ:khi làm việc với Keystone, lệnh đồng bộ hóa cơ sở dữ liệu làkeystone-management db_sync -
Thực hiện thay đổi đối với tệp cấu hình ban đầu, nếu cần
Playbook tạo các tệp cấu hình cho tất cả các dịch vụ, vì vậy, trong hầu hết các trường hợp, cấu hình được để lại trong / etc thư mục của trình cài đặt có thể được sử dụng mà không cần thay đổi để phát triển. Nếu tôi cần thực hiện bất kỳ thay đổi tùy chỉnh nào liên quan đến công việc của mình, tôi sẽ thực hiện chúng theo cách thủ công với người gửi tin nhắn.
-
Chạy thủ công hoặc cài đặt và chạy như một dịch vụ
Cuối cùng, phiên bản phát triển có thể được bắt đầu. Để làm điều đó dễ dàng, chỉ cần chạy ứng dụng Python trực tiếp. Ví dụ:nếu tôi đang làm việc trong dịch vụ động cơ nhiệt, tôi có thể chạy
bin / heat-enginetừ thư mục gốc của dự án để bắt đầu dịch vụ ở phía trước, với đăng nhập ra thiết bị đầu cuối. Để dừng dịch vụ, tôi có thể nhấn Ctrl-C, giống như việc này được thực hiện trong DevStack.Các trình gỡ lỗi thân thiện với thiết bị đầu cuối, chẳng hạn như pdb (dòng lệnh) hoặc pudb (tương tác), có thể được cài đặt bên trong các thùng chứa và hoạt động tốt. Cũng có thể gỡ lỗi qua ssh từ máy chủ đến vùng chứa, nếu bạn muốn sử dụng các trình gỡ lỗi phức tạp hơn như PyCharm.
Đối với hầu hết các dịch vụ, việc chạy chúng theo cách thủ công là đủ để hoạt động thoải mái như với DevStack. Ngoại lệ duy nhất dành cho các dịch vụ không chạy trực tiếp Pythonscripts, chẳng hạn như Keystone, thường chạy dưới Apache. Mặc dù Apache được sử dụng trong sản xuất, nhưng để phát triển, bạn hoàn toàn có thể chạy trực tiếp ứng dụng Python, ứng dụng này có thể sẽ chạy một máy chủ web dựa trên sự kiện. Nếu vì bất kỳ lý do gì mà bạn muốn sử dụng Apache, thì điều kiện cần thiết là cài đặt phiên bản phát triển bằng cách chạy
python setup.py installvà sau đó khởi động lại dịch vụ Apache đã được cài đặt vớidịch vụ apache2 khởi động lại. Cũng có thể chạy ứng dụng từ thư mục nguồn của nó bằng cách cài đặt nó vớipython setup.py developmentvà sau đó thêm thư mục chính vào tệp cấu hình trang Apache.
OSA-AIO:Ưu điểm
Làm việc với OSA thay cho DevStack là một trải nghiệm gần như thú vị. Không có xung đột phụ thuộc nữa là điều tuyệt vời, bởi vì với OSA, nếu cần thiết phải căn cứ lại một trong các dịch vụ và yêu cầu phụ thuộc mới, các dịch vụ khác sẽ không bị ảnh hưởng trong các vùng chứa của chính chúng.
Tôi cũng nhận thấy rằng tôi hiếm khi cần phải tạo lại toàn bộ quá trình triển khai từ đầu. Tôi thường làm điều đó khi tôi muốn nâng cấp toàn bộ hệ thống lên phiên bản mới củaOpenStack, nhưng, đối với công việc hàng ngày, tôi thấy việc cập nhật cục bộ hoặc sửa chữa rất dễ dàng. đến một cài đặt hiện có. Tôi thích có thể phá hủy một container và sau đó để Ansible tái tạo nó cho tôi mà không cần chạm vào phần còn lại của dịch vụ.
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 mà tôi cài đặt dưới dạng các gói phát triển, trong khi vẫn giữ phần còn lại của đám mây OpenStack được cài đặt và định cấu hình để sử dụng trong sản xuất.
OSA-AIO:Nhược điểm
Nhưng tất nhiên, cũng như mọi thứ, có một số khía cạnh của việc làm việc với OSA không được tốt, vì vậy tôi cũng muốn cung cấp cho bạn khía cạnh đó của câu chuyện.
OSA là một dự án trẻ và do đó, nó không có sự hỗ trợ rộng rãi của cộng đồng mà DevStack thích. Điều này đặc biệt quan trọng nếu bạn làm việc trên các mô-đun không phải là cốt lõi của OpenStack. Tại thời điểm tôi viết bài 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 một mô-đun không có trong danh sách này, thì OSA có thể không hữu ích cho bạn. Nhưng ở khía cạnh khác, nếu bạn muốn tạo một playbook Ansible cho một mô-đun hiện không được hỗ trợ, bạn sẽ được đón nhận một cách cởi mở.
Nói chung, có một số tùy chọn cấu hình hợp lý được hiển thị dưới dạng Ansiblevariables cho tất cả các mô-đun, ngoại trừ một ngoại lệ. Khi nói đến Neutron, cấu hình không linh hoạt bằng. Các đường hầm mạng qua các vùng chứa và máy ảo luôn được định cấu hình để sử dụng Linux Bridge. Ví dụ:nếu bạn cần làm việc vớiOpen vSwitch, bạn sẽ cần phải sửa đổi cấu hình theo cách thủ công sau khi chạy playbook, điều này không thú vị chút nào. Ngoài ra, không có plugin Neutron nào được hỗ trợ tại thời điểm này.
Kết luận
Tôi hy vọng bạn thấy quy trình làm việc của tôi với openstack-ansible thú vị để tìm hiểu và sử dụng. Nó đã giúp tôi tiết kiệm thời gian khi làm việc trên các tính năng ngược dòng Nhiệt và các bản sửa lỗi. Tôi cũng đã dựa rất nhiều vào OSA để gỡ lỗi và khắc phục sự cố Keystonefederation.
Nếu bạn quan tâm đến việc sử dụng OSA, tôi cũng khuyến khích bạn thực hiện một chút tìm kiếm, vì điều đó sẽ dẫn bạn đến nhiều bài báo và bài đăng trên blog hơn (ví dụ như bài này hoặc bài này khác), trong khi các cộng tác viên OpenStack giải thích cách họ kết hợp OSA vào quy trình công việc của riêng mình.