यदि आप एक OpenStack योगदानकर्ता हैं, तो आप शायद अपने अधिकांश काम के लिए DevStack पर भरोसा करते हैं। DevStack लंबे समय से वास्तविक मंच है जिसका उपयोग योगदानकर्ता विकास, परीक्षण और समीक्षा के लिए करते हैं। इस लेख में, मैं आपको एक ऐसे प्रोजेक्ट से परिचित कराना चाहता हूं जिसका मैं योगदानकर्ता हूं, जिसे openstack-ansible कहा जाता है। पिछले कुछ महीनों से, मैं OpenStack अपस्ट्रीम विकास के लिए DevStack के विकल्प के रूप में इस प्रोजेक्ट का उपयोग कर रहा हूं, और अनुभव बहुत सकारात्मक रहा है।
DevStack में क्या गलत है?
इससे पहले कि मैं openstack-ansible में तल्लीन करूं, मैं उन कारणों पर संक्षेप में चर्चा करना चाहता हूं जिन्होंने मुझे DevStack के विकल्प की तलाश करने के लिए प्रेरित किया। कुल मिलाकर, DevStack एक अच्छी तरह से विकसित प्रोजेक्ट है, लेकिन कुछ आर्किटेक्चरल निर्णय हैं जो मुझे परेशान करते हैं।
सबसे पहले, DevStack एक मोनोलिथिक इंस्टॉलर के साथ आता है। इंस्टॉल करने के लिए, आप stack.sh चलाते हैं और यह आपके द्वारा कॉन्फ़िगर किए गए सभी मॉड्यूल इंस्टॉल करता है। यदि आप बाद में मॉड्यूल जोड़ना या हटाना चाहते हैं, तो एकमात्र विकल्प सब कुछ अनइंस्टॉल करने के लिए unstack.sh चलाना है, और फिर अपडेटेड कॉन्फ़िगरेशन के साथ stack.sh को फिर से चलाना है। कुछ बार, जब मैंने एक मॉड्यूल में स्रोत कोड परिवर्तन किए, तो मैंने अनजाने में मॉड्यूल को अनियमित तरीके से संचालित करने का कारण बना। अगर मैं उस स्थिति में हूं, तो सबसे सुरक्षित विकल्प इसे पुनः इंस्टॉल करना है, और DevStack के साथ ऐसा करने का एकमात्र तरीका सब कुछ पुनः इंस्टॉल करना है।
DevStack सभी मॉड्यूल का विकास इंस्टॉलेशन करता है, जो एक ऐसा वातावरण बनाता है जो उत्पादन डिप्लॉयमेंट से बहुत अलग है। मेरी राय में, एक उचित विकास वातावरण में वह मॉड्यूल विकास के लिए इंस्टॉल होगा जिस पर मैं काम कर रहा हूं, बाकी सब कुछ उत्पादन के लिए इंस्टॉल होगा। यह DevStack के साथ करना संभव नहीं है।
DevStack के साथ मुझे एक और समस्या थी निर्भरता को एक सुसंगत स्थिति में रखने के लिए निरंतर संघर्ष। DevStack में, निर्भरता सभी मॉड्यूल के बीच साझा की जाती है, इसलिए एक मॉड्यूल के लिए निर्भरता को सिंक करने की सरल कार्रवाई एक श्रृंखला प्रतिक्रिया का कारण बन सकती है जिसके लिए कई अन्य मॉड्यूल को अपडेट करने की आवश्यकता होती है। कुछ हद तक, हाल के DevStack रिलीज़ में प्रति-मॉड्यूल वर्चुअल एनवायरनमेंट के उपयोग से इसे कम किया जा सकता है, लेकिन, फिर भी, OS स्तर के पैकेज साझा रहते हैं।
OpenStack Ansible (OSA) क्या है?
OpenStack-Ansible प्रोजेक्ट एक Rackspace ओपन सोर्स पहल है जो OpenStack को तैनात करने के लिए Ansible की शक्ति का उपयोग करती है। आपने इस प्रोजेक्ट के बारे में StackForge पर os-ansible-deployment नाम से सुना होगा, इससे पहले कि यह OpenStack बिग टेंट में चला गया।
DevStack की तरह, openstack-ansible अपने git रिपॉजिटरी से सीधे सभी OpenStack सेवाओं को तैनात करता है, बिना किसी विक्रेता पैच या ऐड-ऑन के। लेकिन बड़ा अंतर यह है कि openstack-ansible OpenStack सेवाओं को LXC कंटेनरों में तैनात करता है, इसलिए एक नोड पर होस्ट की गई सेवाओं के बीच पूर्ण OS स्तर और Python पैकेज अलगाव होता है।
DevStack और openstack-ansible के बीच एक और अंतर यह है कि बाद वाला एक उत्पादन वितरण है। इसके साथ, आप एंटरप्राइज स्केल निजी क्लाउड तैनात कर सकते हैं जो मुट्ठी भर नोड्स से लेकर सैकड़ों या हजारों नोड्स वाले बड़े क्लस्टर तक होते हैं।
निम्न आरेख openstack-ansible निजी क्लाउड की संरचना को दर्शाता है:
इसे देखने के बाद, आप शायद अपना सिर खुजला रहे होंगे कि यह प्रोजेक्ट DevStack की सरलता से अपस्ट्रीम विकास के लिए कैसे मेल खा सकता है, यह देखते हुए कि यह स्पष्ट रूप से मल्टी-नोड निजी क्लाउड की ओर उन्मुख है। निराश न हों! मैं इसे अगले खंड में कवर करता हूं।
OSA ऑल-इन-वन
OpenStack-Ansible प्रोजेक्ट के योगदानकर्ता दिन-प्रतिदिन के काम और गेटिंग के लिए सिंगल-नोड डिप्लॉयमेंट का उपयोग करते हैं, क्योंकि यह बहुत अधिक सुविधाजनक और संसाधन-कुशल है। इस डिप्लॉयमेंट विधि के साथ, क्लाउड सर्वर या वर्चुअल मशीन पर OSA खड़ा करना संभव है, इसलिए इस सुविधा का लाभ उठाने से यह प्रोजेक्ट DevStack के बराबर हो जाता है।
दुर्भाग्य से, OSA के सिंगल-नोड डिप्लॉयमेंट के लिए होस्ट आवश्यकताएं DevStack से अधिक हैं, मुख्य रूप से कंटेनर इंफ्रास्ट्रक्चर द्वारा पेश किए गए ओवरहेड के कारण। एक उपयोग योग्य इंस्टॉलेशन के लिए, होस्ट में 16GB RAM और 80GB डिस्क स्थान होना चाहिए। इस समय, समर्थित एकमात्र होस्ट OS Ubuntu 14.04 है।
एक अच्छा लाभ जो OSA के पास DevStack पर है, वह यह है कि कंटेनराइज़्ड आर्किटेक्चर के लिए धन्यवाद, यह सिंगल-नोड इंस्टॉल पर भी अनावश्यक सेवाओं को तैनात कर सकता है। डिफ़ॉल्ट सिंगल-नोड डिप्लॉयमेंट पर, galera, rabbitmq, और keystone को अतिरेक के साथ तैनात किया जाता है, और HAProxy को लोड बैलेंसिंग करने के लिए होस्ट में इंस्टॉल किया जाता है।
क्या आप अपने हाथ गंदे करने के लिए तैयार हैं? यदि आपके पास एक नया Ubuntu 14.04 सर्वर है जो ऊपर बताई गई स्पेक्स को पूरा करता है, तो आप निम्न कमांड के साथ OSA रिपॉजिटरी को क्लोन कर सकते हैं:
# apt-get -y install git
# git clone https://github.com/openstack/openstack-ansible /opt/openstack-ansible
आपको प्रोजेक्ट को इस डायरेक्टरी में क्लोन करने की आवश्यकता नहीं है। इसके बजाय, आप इसे जहां चाहें क्लोन कर सकते हैं।
अगला, एक सिंगल-नोड कॉन्फ़िगरेशन फाइल जनरेट करें। सौभाग्य से, प्रोजेक्ट एक स्क्रिप्ट के साथ आता है जो आपके लिए ऐसा करता है:
# cd /opt/openstack-ansible
# scripts/bootstrap-aio.sh
उपरोक्त कमांड चलाने के बाद, डायरेक्टरी /etc/openstack_deploy YAML प्रारूप में कई कॉन्फ़िगरेशन फाइलों से भर जाएगी। विशेष रुचि की फाइल user_secrets.yml है, जिसमें आपके इंस्टॉलेशन में उपयोग किए जाने वाले सभी पासवर्ड होते हैं। ये पासवर्ड बेतरतीब ढंग से उत्पन्न होते हैं, इसलिए इन्हें याद रखना मुश्किल होता है। मैं आमतौर पर एडमिन पासवर्ड को संपादित करता हूं, क्योंकि मैं इसका बहुत उपयोग करता हूं। मूल रूप से मैं इसे बदलता हूं:
keystone_auth_admin_password: cY3QHwjMLRdSuZMlKI3OvujScCNeIMdH
इसमें:
keystone_auth_admin_password: secrete
शेष पासवर्ड इतने उपयोगी नहीं हैं, इसलिए मैं उन्हें अकेला छोड़ देता हूं। हालांकि, आप किसी भी पासवर्ड को बदल सकते हैं जिसे आप उपयोग करना चाहते हैं और जिसे याद रखना आसान हो।
अगला, एक और स्क्रिप्ट चलाएं जो होस्ट में Ansible इंस्टॉल करती है, साथ ही कुछ Ansible एक्स्ट्रा और रैपर स्क्रिप्ट जो इसके उपयोग को सरल बनाते हैं:
# scripts/bootstrap-ansible.sh
इस बिंदु पर, होस्ट OSA इंस्टॉल प्राप्त करने के लिए तैयार है, इसलिए इंस्टॉलेशन को पूरा करने वाले Ansible प्लेबुक चलाएं:
# scripts/run-playbooks.sh
Rackspace पब्लिक क्लाउड सर्वर पर, सभी प्लेबुक के माध्यम से एक पूर्ण रन को पूरा होने में लगभग 45 मिनट लगते हैं। Ansible के साथ काम करने का एक अच्छा पहलू यह है कि सभी कार्य आइडेम्पोटेंट हैं, जिसका अर्थ है कि प्लेबुक को कई बार निष्पादित किया जा सकता है बिना किसी समस्या के। यदि कोई कार्य पहले ही किया जा चुका है, तो इसे दूसरी बार चलाने से कुछ नहीं होता। यह वास्तव में बहुत उपयोगी है, क्योंकि यह उचित कॉन्फ़िगरेशन फाइलों को बदलकर और प्लेबुक को फिर से चलाकर, बिना सब कुछ पहले तोड़े, एक लाइव सिस्टम को पुनः कॉन्फ़िगर करना संभव बनाता है।
OpenStack Ansible का एक त्वरित दौरा
इस खंड में, मैं OSA सिंगल-नोड संरचना का अवलोकन देना चाहता हूं, ताकि आप में से जो लोग इसे खड़ा करने के लिए पर्याप्त बहादुर थे, वे जान सकें कि सब कुछ कहां है।
सबसे पहले, Horizon डैशबोर्ड तैनात है और होस्ट के पब्लिक IP पते पर पहुंच योग्य होना चाहिए। आप admin खाते का उपयोग कर सकते हैं, जिसका पासवर्ड आपने /etc/openstack_deploy/user_secrets.yml फाइल में दर्ज किया था। यदि आपने इस फाइल को संपादित नहीं किया है, तो आपको इस फाइल को खोलना होगा और keystone_auth_admin_password सेटिंग का पता लगाना होगा ताकि पता चल सके कि किस पासवर्ड का उपयोग किया गया था।
जैसा कि मैंने ऊपर उल्लेख किया है, सर्वर सभी LXC कंटेनरों में इंस्टॉल हैं। निम्न कमांड आपको कंटेनरों की सूची दिखाता है:
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)
इस सूची को देखकर, आप देख सकते हैं कि कौन सी सेवाएं तैनात की गई थीं। आप lxc-attach कमांड का उपयोग करके एक कंटेनर के अंदर जा सकते हैं। एक विशेष रूप से दिलचस्प कंटेनर वह है जिसका नाम सूची के नीचे utility है। इस कंटेनर में प्रवेश करने के लिए यह वह कमांड है जिसका आपको उपयोग करना चाहिए:
# lxc-attach -n aio1_utility_container-d83fab91
यूटिलिटी कंटेनर उपयोगी है क्योंकि इसमें सभी OpenStack कमांड लाइन क्लाइंट इंस्टॉल हैं, साथ ही एडमिन खाते के लिए एक तैयार openrc फाइल है। निम्न उदाहरण सत्र में, मैं अपनी तैनाती में उपयोगकर्ताओं की सूची क्वेरी करने के लिए openstack उपयोगिता का उपयोग करता हूं:
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 |
+----------------------------------+--------------------+
कंटेनर से बाहर निकलने और होस्ट पर वापस जाने के लिए, exit टाइप करें या Ctrl-D दबाएं।
Ansible की एक और अच्छी विशेषता: यह आपको एक सेवा को पुनः इंस्टॉल करने की अनुमति देता है, जैसे कि विकास के दौरान गलती से भ्रष्ट हो गया। ऐसा करने के लिए, बस प्रभावित कंटेनर को नष्ट करें:
# lxc-stop -n
# lxc-destroy -n
बीमार कंटेनर को नष्ट करने के बाद, प्लेबुक को एक बार फिर से चलाने से एक नया ताजा कंटेनर प्रतिस्थापन के रूप में बन जाएगा, उस समय के एक अंश में जो सब कुछ खरोंच से इंस्टॉल करने में लगेगा।
विकास वर्कफ़्लो
आप निश्चित रूप से जानना चाहते हैं कि मैं OSA ऑल-इन-वन डिप्लॉयमेंट का उपयोग DevStack के प्रतिस्थापन के रूप में व्यावहारिक शब्दों में कैसे करता हूं। इस प्रक्रिया में कुछ सरल चरण शामिल हैं:
OSA-AIO तैनात करें
जाहिर है, सब कुछ सिंगल-नोड openstack-ansible क्लाउड तैनात करने से शुरू होता है। मैं आमतौर पर अपने होस्ट के रूप में Rackspace पब्लिक क्लाउड सर्वर का उपयोग करता हूं, लेकिन आप ऊपर सूचीबद्ध स्पेक्स के साथ किसी भी Ubuntu 14.04 होस्ट का उपयोग कर सकते हैं।
लक्ष्य कंटेनर से अटैच करें
मैं फिर उस कंटेनर के अंदर जाता हूं जो उस सेवा को चलाता है जिस पर मैं काम करना चाहता हूं, ऊपर दिखाए गए
lxc-attachकमांड का उपयोग करके। अगर मैं एक ऐसी सेवा पर काम करने जा रहा हूं जिसे अतिरेक के साथ तैनात किया गया था, तो मैं पहले HAProxy कॉन्फ़िगरेशन को संपादित करके केवल एक कंटेनर को सक्रिय छोड़ देता हूं। शेष कंटेनरों का उपयोग बैकअप के रूप में किया जा सकता है अगर चयनित एक के साथ कुछ गलत होता है।लक्ष्य सेवा बंद करें
कंटेनर उस सेवा का उत्पादन संस्करण चला रहा है जिस पर मैं काम करना चाहता हूं। क्योंकि यह सेवा मेरे लिए किसी काम की नहीं है, मैं मानक
serviceकमांड का उपयोग करके इसे रोक देता हूं। उदाहरण के लिए, अगर मैं heat-engine कंटेनर में हूं, तो मैंstop service heat-engine stopचलाऊंगा।विकास संस्करण क्लोन करें
अब मेरे पास एक कंटेनर है जो लक्ष्य सेवा चलाने के लिए तैयार है, इसलिए मैं वास्तविक कोड क्लोन कर सकता हूं जिस पर मैं काम करूंगा। इसके लिए, मैं आधिकारिक git रिपॉजिटरी, कस्टम परिवर्तनों के साथ मेरा फोर्क, या शायद Gerrit से एक पैच उपयोग कर सकता हूं, अगर मैं समीक्षा कर रहा हूं।
निर्भरता अपडेट करें
विकास संस्करण को Ansible प्लेबुक द्वारा इंस्टॉल किए गए संस्करण की तुलना में निर्भरता के एक अलग सेट की आवश्यकता हो सकती है, इसलिए सुरक्षा के लिए, मैं कंटेनर में
pip install -r requirements.txtचलाता हूं। चूंकि OSA अपना निजी Python पैकेज रिपॉजिटरी बनाता है, इसलिए पैकेज का आवश्यक संस्करण इसमें उपलब्ध नहीं हो सकता है। जब ऐसा होता है, तो मैं कंटेनर के /root/.pip/pip.conf फाइल मेंno-index = Falseसेट करके pypi तक पहुंच सक्षम करता हूं, और फिर पुनः प्रयास करता हूं।डेटाबेस सिंक करें
OSA के साथ इंस्टॉल किए गए मूल संस्करण और मेरे विकास संस्करण के बीच डेटाबेस माइग्रेशन में एक और संभावित अंतर है, इसलिए मैं हमेशा डेटाबेस को सिंक करता हूं, बस मामले में। ऐसा करने की कमांड सेवाओं के बीच थोड़ी भिन्न होती है, लेकिन आमतौर पर मैनेजमेंट स्क्रिप्ट को
db_syncविकल्प के साथ लागू करने की आवश्यकता होती है। उदाहरण के लिए, Keystone के साथ काम करते समय, डेटाबेस को सिंक करने की कमांडkeystone-manage db_syncहैयदि आवश्यक हो तो मूल कॉन्फ़िग फाइलों में परिवर्तन करें
प्लेबुक सभी सेवाओं के लिए कॉन्फ़िगरेशन फाइलें बनाते हैं, इसलिए ज्यादातर मामलों में, इंस्टॉलर द्वारा /etc डायरेक्टरी में छोड़ी गई कॉन्फ़िगरेशन का उपयोग विकास के लिए बिना परिवर्तन के किया जा सकता है। अगर मुझे अपने काम से संबंधित कोई कस्टम परिवर्तन करने की आवश्यकता है, तो मैं उन्हें टेक्स्ट एडिटर के साथ मैन्युअल रूप से करता हूं।
मैन्युअल रूप से चलाएं, या सेवा के रूप में इंस्टॉल करें और चलाएं
अंत में, विकास संस्करण शुरू किया जा सकता है। इसे आसानी से करने के लिए, बस पायथन एप्लिकेशन को सीधे चलाएं। उदाहरण के लिए, अगर मैं heat-engine सेवा पर काम कर रहा हूं, तो मैं प्रोजेक्ट के रूट डायरेक्टरी से
bin/heat-engineचलाकर सेवा को फोरग्राउंड में शुरू कर सकता हूं, लॉग टर्मिनल पर जा रहे हैं। सेवा को रोकने के लिए, मैं Ctrl-C दबा सकता हूं, जैसे DevStack में किया जाता है।टर्मिनल-फ्रेंडली डिबगर्स, जैसे pdb (कमांड लाइन) या pudb (इंटरैक्टिव), कंटेनरों के अंदर इंस्टॉल किए जा सकते हैं और बहुत अच्छा काम करते हैं। होस्ट से कंटेनर पर SSH पर रिमोट डिबगिंग भी संभव है, अगर आप PyCharm जैसे अधिक जटिल डिबगर्स का उपयोग करना पसंद करते हैं।
अधिकांश सेवाओं के लिए, उन्हें मैन्युअल रूप से चलाना DevStack के साथ जितना आरामदायक है उतना ही आरामदायक है। एकमात्र अपवाद उन सेवाओं के लिए है जो सीधे पायथन स्क्रिप्ट नहीं चलाते हैं, जैसे Keystone, जो सामान्य रूप से Apache के तहत चलता है। भले ही Apache उत्पादन में उपयोग किया जाता है, विकास के लिए सीधे पायथन एप्लिकेशन चलाना पूरी तरह से सुरक्षित है, जो संभवतः एक इवेंटलेट-आधारित वेब सर्वर चलाएगा। यदि किसी कारण से Apache का उपयोग वांछित है, तो विकल्प
python setup.py installचलाकर विकास संस्करण को इंस्टॉल करना और फिर पहले से इंस्टॉल की गई Apache सेवा कोservice apache2 restartके साथ पुनरारंभ करना है। इसके अलावा,python setup.py developके साथ इंस्टॉल करके और फिर होम डायरेक्टरी को Apache साइट कॉन्फ़िगरेशन फाइल में जोड़कर अपने स्रोत डायरेक्टरी से एप्लिकेशन चलाना भी संभव है।
OSA-AIO: लाभ
DevStack के स्थान पर OSA के साथ काम करना मेरे लिए एक ज्यादातर सुखद अनुभव रहा है। अब निर्भरता संघर्ष न होना बहुत अच्छा है, क्योंकि OSA के साथ, अगर मुझे किसी सेवा को रीबेस करने की आवश्यकता है और उसके लिए नई निर्भरता की आवश्यकता है, तो अन्य सेवाएं अपने स्वयं के कंटेनरों में अप्रभावित रहती हैं।
मैंने यह भी पाया है कि मुझे शायद ही कभी पूरे डिप्लॉयमेंट को खरोंच से पुनः बनाने की आवश्यकता होती है। मैं आमतौर पर ऐसा तब करता हूं जब मैं पूरे सिस्टम को OpenStack के एक नए रिलीज़ में अपग्रेड करना चाहता हूं, लेकिन, दिन-प्रतिदिन के काम के लिए, मुझे मौजूदा इंस्टॉलेशन पर स्थानीय अपडेट या मरम्मत करना आसान लगता है। मुझे एक कंटेनर को नष्ट करने और फिर Ansible को इसे मेरे लिए पुनर्जीवित करने की अनुमति देने में सक्षम होना पसंद है बिना बाकी सेवाओं को छुए।
अंत में, मुझे वास्तव में पसंद है कि OSA मुझे यह चुनने की अनुमति देता है कि सिस्टम का कौन सा हिस्सा मैं विकास पैकेज के रूप में इंस्टॉल करता हूं, जबकि बाकी OpenStack क्लाउड को उत्पादन उपयोग के लिए इंस्टॉल और कॉन्फ़िगर किया जाता है।
OSA-AIO: नुकसान
लेकिन निश्चित रूप से, हर चीज के साथ, OSA के साथ काम करने के कुछ पहलू हैं जो महान नहीं हैं, इसलिए मैं आपको कहानी का वह पक्ष भी देना चाहता हूं।
OSA एक युवा प्रोजेक्ट है, और, इस तरह, इसमें उस व्यापक सामुदायिक समर्थन का अभाव है जिसका DevStack आनंद लेता है। यह विशेष रूप से महत्वपूर्ण है यदि आप उन मॉड्यूल पर काम करते हैं जो OpenStack के मूल में नहीं हैं। जिस समय मैं इसे लिख रहा हूं, OSA Keystone, Nova, Neutron, Glance, Cinder, Swift, Heat, Ceilometer और Horizon की तैनाती का समर्थन करता है। यदि आप इस सूची में शामिल नहीं किए गए मॉड्यूल पर काम करना चाहते हैं, तो OSA शायद आपके लिए उतना उपयोगी नहीं है। लेकिन दूसरी तरफ, यदि आप वर्तमान में समर्थित नहीं किए गए मॉड्यूल के लिए Ansible प्लेबुक बनाना चाहते हैं, तो आपका खुली बाहों से स्वागत किया जाएगा।
सामान्य तौर पर, सभी मॉड्यूल के लिए Ansible चर के रूप में उचित संख्या में कॉन्फ़िगरेशन विकल्प उजागर किए जाते हैं, एक अपवाद के साथ। जब Neutron की बात आती है, तो कॉन्फ़िगरेशन उतना लचीला नहीं है। कंटेनरों और VMs में नेटवर्क टनल हमेशा Linux Bridge का उपयोग करने के लिए कॉन्फ़िगर किए जाते हैं। उदाहरण के लिए, यदि आपको Open vSwitch के साथ काम करने की आवश्यकता है, तो आपको प्लेबुक चलाने के बाद मैन्युअल रूप से कॉन्फ़िगरेशन को संशोधित करना होगा, जो मजेदार नहीं है। इसके अलावा, इस समय कोई भी Neutron प्लगइन समर्थित नहीं हैं।
निष्कर्ष
मुझे आशा है कि आप openstack-ansible के साथ मेरे वर्कफ़्लो को सीखने और उपयोग करने के लिए दिलचस्प पाएंगे। इसने Heat अपस्ट्रीम सुविधाओं और बग फिक्स पर काम करते समय मेरा समय बचाया है। मैंने Keystone फेडरेशन को डीबग और समस्या निवारण करने के लिए OSA पर बहुत भरोसा किया है।
यदि आप OSA का उपयोग करने में रुचि रखते हैं, तो मैं आपको थोड़ी खोज करने के लिए भी प्रोत्साहित करता हूं, क्योंकि यह आपको अधिक लेखों और ब्लॉग पोस्ट (जैसे यह वाला या यह अन्य वाला) की ओर ले जाएगा, जिसमें अन्य OpenStack योगदानकर्ता बताते हैं कि उन्होंने OSA को अपने स्वयं के वर्कफ़्लो में कैसे शामिल किया।
